Page 119 -

sists of use cases, functional requirements, and nonfunctional requirements, which, taken
together, form a complete description of the software.” For complex software, the
requirements for the project might be divided into several SRS documents. In this case,
the scope should indicate which portion of the project is covered in this document.
System overview
This section contains a description of the system. This is essentially a brief summary of
the vision and scope of the project.
References
Any references to other documents (including the vision and scope document) should
be included here. These may include other documents in the organization, work prod-
ucts, articles, and anything else that is relevant to understanding the SRS. If there is an
organizational intranet, this section often includes URLs of referenced documents.
Definitions
The “Definitions” section contains any definitions needed to understand the SRS. Often,
it will contain a glossary, defining terms that the reader may not be familiar with (or
that may have a specific meaning here that differs from everyday use). This section may
also contain definitions of any data files that are used as input, a list of any databases
that may be needed, and any other organizational or workflow-related information that
is needed to understand the SRS.

The remaining sections contain a complete description of the behavior of the software.
The “Use Cases” section contains each of the use cases. Each use case is represented by a
table, which is in the format shown in Table 6-6. The “Functional requirements” section
contains the functional requirements, and the “Nonfunctional requirements” section con-
tains the nonfunctional requirements. Each functional and nonfunctional requirement is
added to the SRS as a table (using the format shown in Table 6-9).
The SRS should also contain a complete table of contents that includes the name and
number of each use case, functional requirement, and nonfunctional requirement.

Functional requirements

Once an initial set of use cases has been created and filled in, the requirements analyst

begins documenting the functional requirements. Table 6-9 shows the template for a func-
tional requirement.

TABLE 6-9. Functional and nonfunctional requirement template
Name Name and number of the functional requirement
Summary Brief description of the requirement
Rationale Description of the reason that the requirement is needed
Requirements The behavior that is required of the software
References Use cases and other functional and nonfunctional require-
ments that are relevant to understanding this one

SOFTWARE REQUIREMENTS 111