{"id":43295,"date":"2014-08-19T13:05:34","date_gmt":"2014-08-19T13:05:34","guid":{"rendered":"https:\/\/wp.lansa.com\/blog\/ambiguity-in-requirements"},"modified":"2024-12-04T06:41:58","modified_gmt":"2024-12-04T12:41:58","slug":"ambiguity-in-requirements","status":"publish","type":"post","link":"https:\/\/lansa.com\/blog\/app-development\/rapid-app-development\/ambiguity-in-requirements\/","title":{"rendered":"Mind the Gap: Addressing Ambiguity in Requirements"},"content":{"rendered":"

The lesson of the Tower of Babel<\/a>, possibly the first post-project review in historical records, is that communication failure within the team will cause project failure. In today\u2019s software requirements, often staffed by cross-functional teams spread across the globe, the communication challenge persists.<\/p>\n

\"Tree

What the customer actually wanted . . .<\/p><\/div>\n

Complexity in problem definition, solution and design tool architecture, organizational structures and market forces demand agility and constant risk assessment. According to the Project Management Institute (PMI)<\/a>, of the two in five projects that fail to meet business objectives, half traced the cause of failure to ineffective communications. In software development projects (including application modernization<\/a> projects) these typically include incomplete or changing requirement specifications, and lack of user input.<\/p>\n

Don\u2019t assume that all project stakeholders have the same understanding of the term \u201crequirements\u201d. A broad ranging definition<\/a> is: Requirements are a specification of what should be implemented. They are descriptions of how the system should behave, of a system property or attribute. They may be a constraint on the development process of the system. A non-functional requirement should define how well the system must do what it does. <\/em><\/p>\n

What Are Requirements In Software Development?<\/strong><\/h2>\n

\u201cRequirement\u201d in software development projects is also a term overloaded with many different meanings and could be relating to any of the typical project artefacts.<\/p>\n

\"Tree<\/a>

Tree Swing Project Management cartoon<\/p><\/div>\n

As the classic tree swing cartoon<\/a> illustrates (originating from the 1970s), all project stakeholders bring their own biases, assumptions, prejudices and expectations which influence the eventual outcome. The IT team or software vendor might be able to define what they can deliver, but only the customer can define what they need from the system. Choosing which project documents are created and reviewed is based on categorization and criteria, such as<\/p>\n