Are Your Requirements Complete?
Donald G. Firesmith · The Journal of Object Technology · 2005
Good requirements have several useful properties, such as being consistent, necessary, and unambiguous.Another essential characteristic that is almost always listed is that 'requirements should be complete.'But just what does completeness mean, and how should you ensure that your requirements are complete?In this column, we will begin to address these two questions by looking at (1) the importance of requirements completeness, (2) the completeness of requirements models, (3) the completeness of various types of individual requirements, , and (4) the completeness of requirements metadata.In next issue's column, we will continue by addressing (5) the completeness of requirements repositories, (6) the completeness of requirements documents derived from such repositories of requirements, (7) the completeness of sets of requirements documents, (8) the completeness of requirements baselines, and finally (9) determining how complete is complete enough when using an incremental and iterative development cycle.ARE YOUR REQUIREMENTS COMPLETE? 28J OURNAL OF OBJECT TECHNOLOGY V OL. 4, NO. 1• It takes more effort, time, training, and will power to do the non-trivial extra work needed to make requirements complete.• It is difficult to know just how complete the requirements should be given the limited resources (e.g., schedule and personnel) available to the requirements team.• Subject matter experts and other sources of requirements often take certain information for granted and omit it during requirements engineering, even though it is not obvious to other stakeholders.But before we pose some answers to these important questions, we should probably address an even more fundamental question: why is the completeness of the requirements so important?• Acceptance and Satisfaction.Missing or incomplete requirements can cause customers to reject systems and users to be dissatisfied with the systems, even if they pass acceptance testing.Customers want to know that what they are buying will be adequate to meet the users' needs.This is primarily a requirements validation issue.• Development Cost and Schedule.Because requirements are used to estimate system development cost and schedule, missing or incomplete requirements mean that these costs and schedules will be underestimated.One large study implicated incomplete requirements as the cause of 12.3% of cost overruns and failed projects [Standish 1994].The primary reasons why missing or incomplete requirements cause cost and schedule overruns is that: ⎯ The original estimates were too low because missing requirements were not considered and ⎯ Costly rework was needed once these omissions were discovered.• Development.Missing or incomplete requirements ensure that the architecture, design, implementation, and tests that are derived from them will be: ⎯ Incomplete themselves and/or ⎯ Incorrect because the architects, designers, implementers, or testers will make incorrect guesses or assumptions.• Verification.Incomplete requirements are often ambiguous and therefore unverifiable.• Safety.Perhaps the most important aspect of requirements completeness has to do with safety because over time more and more software-intensive systems have been given safety-related responsibilities.Up to 50% of all accidents are due to requirements problems and many of these accidents are due to missing or incomplete requirements [Leveson 1995].In one analysis of 34 safety incidents, "44% had inadequate specification as their primary cause."[HSE 1995] When speaking of the completeness of requirements, it is important to establish the scope of the term 'completeness.'There are at least seven different ways in which the phrase 'requirements completeness' could be interpreted.These include the completeness of: