Testing Completeness


In Chapter 10, Writing the Requirements, we discussed using the requirements shell as a way of making it easy to gather the components necessary to make a complete requirement. That chapter contains a discussion of each of these components.

Think of the requirements shell as a compartmentalized container for an individual atomic requirement, with each compartment being a component of the requirement. Earlier we suggested using the shell to help write the requirement; now we use it to help you test the completeness of a requirement. (See Figure 11.3) Note that we also refer to the shell as a "snow card." We use cards printed with these components for training purposes and low-tech requirements gathering.

Figure 11.3.

An example of a complete requirement using the Volere Shell. All of the components are present, and the analyst has marked the requirement as having no known conflicts with other requirements. This requirement should pass the completeness tests.


Are There Any Missing Components?

The first test for completeness is to compare the requirement with the components of the shell. While it is not always necessary to have every component for every requirement, if some components are missing, there should be a reason for their absence.

Chapter 10 discusses the process of writing the requirements in detail.


The components of the shell come from successful requirements projects. Over the years, we have found these items to be valuable and to contribute to the clarity and reasoning of a requirement. They are measurements, or explanations, or pointers to other information, or requirements that will be used at several stages of the project. Thus it is advisable to include as many as are appropriate for the requirement.

The Volere Shell is packaged as part of the Requirements Specification Template in appendix B.


Sometimes, however, not all of the shell components are necessary. For example, sometimes the description makes it obvious why the requirement is important. In that case there would be no point in writing the rationale. Sometimes the description can be dropped, because a clear and readable fit criterion is provided. Sometimes there are no supporting materials.

Naturally, if one of the components is missing, then its omission should occur because it is not necessary rather than because it is too difficult or has been overlooked. If the component is missing because you are still investigating it (and perhaps waiting for an answer from someone), then include that information in the requirement to forestall unnecessary questions:

Supporting Material: 10/10/05 waiting for county engineer to supply details of supporting material.


The completeness test says that each requirement must have all relevant components, or you should record the reason why they have not been, or cannot be, completed.

Meaningful to All Stakeholders?

Once you are satisfied about the components of the requirement, you should ensure each component adds to the meaning and common understanding of the requirement.

"Everything should be made as simple as possible, but not one bit simpler."

Source: Albert Einstein


This means that the requirement is written as clearly as possible. While we admire conciseness, you must ensure the requirement is written so all the needed information is included.

Test each component of the requirement and, from the point of view of each stakeholder, ask, "Is it possible to misunderstand this?" For instance, Figure 11.3 includes the following information:

Supporting Material: Specification of Rosa Weather Station


For more on stakeholders' viewpoints, refer to Sommerville, Ian, and Pete Sawyer. Requirements Engineering. John Wiley, 1998.


We ask, "Is it possible to confuse this? Is there more than one specification of the Rosa Weather Station? Is there any doubt about where to find this specification?" The answers to these questions help us to be more precise about exactly what we mean. The resultant entry reads:

Supporting Material: Specification of DM32 Rosa Weather Station, release 1.1 published Jan 22, 2004





Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net