- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Scenarios
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
Writing the Requirements
A major problem in system development is misunderstood requirements. To avoid this dilemma, the analysts must write their requirements in a testable manner and ensure that the originating stakeholder understands and agrees with the written requirement before it is passed downstream. In other words, the analysts are writing the requirements to ensure that all parties have achieved the identical understanding of what is needed. Although the task of writing down the requirements may seem an onerous burden, we have found it is the only way to ensure that the essence of the requirement has been captured and communicated, and that the delivered product can be tested. (See Figure 2.5.)
)
The requirements analysts are writing for the stakeholders. That is, the requirements are the business requirements, and they must be written using business language so that the nontechnical stakeholders can understand them and verify their correctness. Of course, the requirements also need to be written so that the product designers and other technicians can build precisely what the client wants. To ensure this correctness, and to make the requirement testable, the analysts add a fit criterion to each requirement. A fit criterion is a quantification or measurement of the requirement so the testers can determine precisely whether an implementation meets—in other words, fits—the requirement.
The analysts use two devices to make it easier to write a specification. The first device, the requirements specification template, is an outline of a requirements specification. The analysts use it as a checklist of which requirements they should be asking for and as a guide to writing their specification documents. The second device is a shell, also known as a snow card. Each requirement is made up of a number of components, and the shell is a convenient layout for ensuring that each requirement has the correct constituents.
Of course, the writing activity is not really a separate activity. In reality, it is integrated with the activities that surround it—trawling, prototyping, and the Quality Gateway. However, for the purposes of understanding what is involved in getting the correct requirements in a communicable form, we have chosen to look at it separately.
An alternative to writing functional requirements is building models. Numerous kinds of models are available, and we do not intend this book to describe how to build all of them. While we encourage the use of models for requirements work, we must issue a caution about the tendency of some modelers, and some models, to leap straight into a solution without firstly demonstrating an understanding of the problem. Also bear in mind that models do not specify the nonfunctional requirements. As a result, any models you build must be augmented by written requirements for the nonfunctional requirements.
Lastly, we must consider the primary reason for wanting written requirements. The point is not to have written requirements (although that is often necessary), but rather to write them. The act of writing the requirement, together with its associated fit criterion, means the analyst has to correctly understand the requirement. If the requirement is not correctly understood, and agreed to by the relevant stakeholders, then any attempt to write it will result in a nonsense—one that is quickly detected when the requirement reaches the Quality Gateway.