1.4 A Traditional Requirements Process

We choose to specify these things not because they are easy, but because they are hard.
-John F. Kennedy (what he might have said if he'd been a business analyst)

The traditional approach to specifying requirements is to have a distinct requirements phase that delivers a detailed requirements specification before starting to design and build the system. Figure 1-3 sums up the steps in a typical traditional requirements phase. The steps illustrated most prominently are those where the bulk of the work is done. The funny "Gather information" shape signifies that it's not isolated in a single early step, but continues until the final specification is delivered (although with gradually less time devoted to it, signified by the tapering towards the bottom of the shape).

image from book
Figure 1-3: Activities in traditional requirements process

The steps shown in Figure 1-3 are:

Prepare. The analyst must be given an outline of the mission: some kind of statement of the system's objectives, before the requirements process can begin, either by explanation face-to-face or via a short scope document. Also find your feet: familiarize yourself with the environment (and the culture, if you're new to it) and identify all sources of information.
Gather (or "elicit") information. The main sources of information are people, documents, and existing systems. The key to gathering information well is attention to detail. First, find out as much as you can by reading before talking to people. Familiarize yourself with all relevant systems, too. But people are the best source of information on what your new system must do. The full version of this chapter describes the two prime ways of gathering information from people: individual interviews and collaborative sessions.
Write draft requirements specification. Start writing the first draft as early in the process as you can, but not until you have a reasonable picture of the major pieces. That, however, should take very little time: just a day or two. Write the "Context" section first. Then identify the functional areas, which form top level sections of the specification. Organize according to what you need to say. Don't be afraid to reorganize as you go along.
Have specification reviewed. Subject it to serious scrutiny to verify that you've correctly interpreted and represented everything you've been told. There are various ways to review a requirements specification, and these vary in their degrees of formality and thoroughness. The full version of this section discusses two methods for review: the independent approach involves distributing the specification to a number of reviewers and asking for their feedback; the collaborative approach brings a group of reviewers together at the same time to perform a detailed and systematic inspection of the specification.
Revise after review. Work systematically through all the individual comments that you receive, updating the specification as appropriate. Any comment could hint at other matters that have been omitted or need to be changed; be alert to observations that have wider implications. After creating a new version of the specification that takes into account review feedback, either send it out for review again or decide that you're happy with this version and regard it as finished.

Other activities can be performed in parallel with the main requirements activities. Two common activities are writing use cases and developing a prototype.