Page 110 -

4.2 The software requirements document 93

Chapter Description

Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should
also describe how the system fits into the overall business or strategic
objectives of the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should not
make assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The non-functional
definition system requirements should also be described in this section. This
description may use natural language, diagrams, or other notations that are
understandable to customers. Product and process standards that must be
followed should be specified.

System architecture This chapter should present a high-level overview of the anticipated system
architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.

System requirements This should describe the functional and non-functional requirements in more
specification detail. If necessary, further detail may also be added to the non-functional
requirements. Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between
the system components, the system, and its environment. Examples of possible
models are object models, data-flow models, or semantic data models.
System evolution This should describe the fundamental assumptions on which the system is
based, and any anticipated changes due to hardware evolution, changing
user needs, and so on. This section is useful for system designers as it may
help them avoid design decisions that would constrain likely future changes
to the system.

Appendices These should provide detailed, specific information that is related to the
application being developed; for example, hardware and database descriptions.
Hardware requirements define the minimal and optimal configurations for the
system. Database requirements define the logical organization of the data used
by the system and the relationships between data.

Index Several indexes to the document may be included. As well as a normal
alphabetic index, there may be an index of diagrams, an index of functions,
and so on.

requirements document will leave out many of detailed chapters suggested above.
Figure 4.7 The
structure of a The focus will be on defining the user requirements and high-level, non-functional
requirements system requirements. In this case, the designers and programmers use their judgment
document to decide how to meet the outline user requirements for the system.
However, when the software is part of a large system project that includes interact-
ing hardware and software systems, it is usually necessary to define the requirements