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.)

Figure 2.5.

The requirements are captured in written form so as to communicate effectively between the stakeholders and the analysts. Only by writing them down can the team ensure that the required product is built.

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 meetsin other words, fitsthe requirement.

Chapter 9 describes fit criteria in detail.

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.

See appendix B, the Volere Requirements Specification Template.

Of course, the writing activity is not really a separate activity. In reality, it is integrated with the activities that surround ittrawling, 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.

Refer to Chapter 10 for a detailed discussion of writing the requirements.

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 nonsenseone that is quickly detected when the requirement reaches the Quality Gateway.