Level of Detail or Granularity


Note the level of detail. The requirements are written as a single sentence with one verb and, where possible, avoid the use of "and." When you write a single sentence, you make the requirement testable and far less susceptible to ambiguity. Note also the form "The product shall . . ."; it makes the sentence active and focuses on communicating what the product is intended to do. It also provides a consistent form for the developers and other stakeholders who need to have a clear understanding of what the product is intended to do.

Incidentally, the word "shall" does not mean that you will definitely be able to find a solution to satisfy the requirement; it simply means that the requirement is a statement of the business intention. The developers are charged with deriving a technological solution to the requirement, and naturally there will be times when they cannot find a cost-effective solution. In the meantime, the requirement clarifies what the business needs the product to do.

One last word on the form employed to write the requirements description: Sometimes people use a mixture of "shall," "must," "will," "might," and so on to indicate the priority of a requirement. This practice results in semantic confusion, and we advise you against doing it. Instead, use one consistent form for writing your requirements' descriptions and use a separate component to identify the requirement's priority.

Use a separate component on your snow card to define the priority rating for each requirement.


The functional requirements we are talking about here are "business" requirements. That is, they indicate what the product has to do to satisfy the organization's business need. The business stakeholders can verify a requirement and tell you whether the functionality is correct. They might also be able to tell you whether you have written enough functional requirements to achieve the intended outcome of the use case. You should probably not hand over the entire collection of functional requirements to the business stakeholders and ask them to verify the accuracy of the complete specification. That is both unfair and pointless. The business stakeholders participate in the development of the scenarios, so their confirmation of the functional requirements should be restricted to those individual requirements that cause problems or raise additional questions. The use of natural language means the requirements are accessible to all stakeholders, but please do not ask them to review the entire requirements specification.

The detail of each requirement is intended to be sufficient for the developers to write the correct software from it. We must qualify this last statement, however, by pointing out that eventually the product designers add the technological requirements. We look at these requirements later in this chapter.

There is more to a requirement than a single "The product shall . . ." statement. Later in this book we look at how to write the other components of a requirement. We also discuss how to make the requirements testable by adding a fit criterion as well as how to test the requirements before they become part of the specification.

Refer to Chapter 10, Writing the Requirements, for the other components;Chapter 9, Fit Criteria, for suggestions on how to make the requirements testable; and Chapter 11, The Quality Gateway, for guidelines on testing the requirements.





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