Chapter 15. Organizing Requirements Information

Key Points

• For nontrivial applications, requirements must be captured and recorded in a document, database, model, or tool.

• Different types of projects require different requirements organization techniques.

• Complex systems require that requirements sets be developed for each subsystem.

Whether expressed as user needs, a list of features, a storyboard, a set of use cases, or another format, requirements must be captured and documented. If you were the sole developer for a system on which you will also be the sole user and maintainer, you might consider designing and coding it immediately after identifying your needs. However, few system developments have such simplicity. More likely, developers and users are mutually exclusive, and stakeholders, users, developers, analysts, testers, architects , and other team members are involved. All parties must reach agreement about what system is being built.

Realities of budgets and schedules make it unlikely that all user needs are going to be satisfied in any particular release. Inevitable communication problems inherent in a multiple-person effort demand that requirements be captured in a way that they can be reviewed and approved and to which all parties can agree and refer.

Traditionally large documents, called requirements specifications , have been built to capture and communicate this information. The requirements specification for a system or application describes the external behavior of that system. But requirements can rarely be defined in a single monolithic document or in a single use-case model for that matter. There are a number of reasons.

• The system may be very complex, and the volume of documentation demands both organizational and interactive access techniques.

• The system of interest may be a member of a family of related products. No one document can contain all the specifications.

• The system being constructed may be a subsystem of a larger system and may satisfy only a subset of all the requirements identified.

• Marketing and business goals need to be separated from the detailed product requirements.

• Other requirements, perhaps regulatory or legal, may also be imposed on the system, and these requirements may be documented elsewhere.

In any of these cases, you will need to maintain requirements organized into multiple requirements sets , each set reflecting the requirements for a particular system, a subsystem, or a number of subsystems together, as in the examples below.

• One set defines the features of the system in general terms, and another defines requirements in more specific terms. Often, the former is called the Vision document (discussed extensively in Chapter 16), whereas the latter set may consist of the system use-case model and associated supplementary requirements (discussed in Chapter 22).

• One "parent" requirements set defines requirements for the overall "system," including hardware, software, people, and procedures, and another defines requirements for just the software subsystem.

• One set defines the full set of requirements for a family of products, and another defines requirements for just one specific application and for one specific release.

The following sections describe what to do in each case. Any or all of these cases can be combined; for example, one set could contain the full set of requirements from which selected subsets are used for specific releases, as well as all business requirements.