Page 109 -

92 Chapter 4 Requirements engineering

Specify the requirements and
read them to check that they
System
Customers meet their needs. Customers
specify changes to the
requirements.

Use the requirements
document to plan a bid for
Managers
the system and to plan the
system development process.

Use the requirements to
System understand what system is
Engineers
to be developed.

Use the requirements to
System
Test Engineers develop validation tests for
the system.
Use the requirements to
System understand the system and
Maintenance the relationships between
Figure 4.6 Users of a Engineers its parts.
requirements document

The diversity of possible users means that the requirements document has to be a
compromise between communicating the requirements to customers, defining the
requirements in precise detail for developers and testers, and including information
about possible system evolution. Information on anticipated changes can help sys-
tem designers avoid restrictive design decisions and help system maintenance engi-
neers who have to adapt the system to new requirements.
The level of detail that you should include in a requirements document depends on
the type of system that is being developed and the development process used. Critical
systems need to have detailed requirements because safety and security have to be ana-
lyzed in detail. When the system is to be developed by a separate company (e.g.,
through outsourcing), the system specifications need to be detailed and precise. If an in-
house, iterative development process is used, the requirements document can be much
less detailed and any ambiguities can be resolved during development of the system.
Figure 4.7 shows one possible organization for a requirements document that is
based on an IEEE standard for requirements documents (IEEE, 1998). This standard
is a generic standard that can be adapted to specific uses. In this case, I have
extended the standard to include information about predicted system evolution. This
information helps the maintainers of the system and allows designers to include sup-
port for future system features.
Naturally, the information that is included in a requirements document depends
on the type of software being developed and the approach to development that is to
be used. If an evolutionary approach is adopted for a software product (say), the