Page 108 -

4.2 The software requirements document 91

FPO Requirements document standards

A number of large organizations, such as the U.S. Department of Defense and the IEEE, have defined standards
for requirements documents. These are usually very generic but are nevertheless useful as a basis for
developing more detailed organizational standards. The U.S. Institute of Electrical and Electronic Engineers
(IEEE) is one of the best-known standards providers and they have developed a standard for the structure of
requirements documents. This standard is most appropriate for systems such as military command and control
systems that have a long lifetime and are usually developed by a group of organizations.

http://www.SoftwareEngineering-9.com/Web/Requirements/IEEE-standard.html

Non-functional requirements such as reliability, safety, and confidentiality
requirements are particularly important for critical systems. I cover these require-
ments in Chapter 12, where I describe specific techniques for specifying dependabil-
ity and security requirements.

4.2 The software requirements document

The software requirements document (sometimes called the software requirements
specification or SRS) is an official statement of what the system developers should
implement. It should include both the user requirements for a system and a detailed
specification of the system requirements. Sometimes, the user and system require-
ments are integrated into a single description. In other cases, the user requirements
are defined in an introduction to the system requirements specification. If there are a
large number of requirements, the detailed system requirements may be presented in
a separate document.
Requirements documents are essential when an outside contractor is developing
the software system. However, agile development methods argue that requirements
change so rapidly that a requirements document is out of date as soon as it is written,
so the effort is largely wasted. Rather than a formal document, approaches such as
Extreme Programming (Beck, 1999) collect user requirements incrementally and
write these on cards as user stories. The user then prioritizes requirements for imple-
mentation in the next increment of the system.
For business systems where requirements are unstable, I think that this approach
is a good one. However, I think that it is still useful to write a short supporting docu-
ment that defines the business and dependability requirements for the system; it is
easy to forget the requirements that apply to the system as a whole when focusing on
the functional requirements for the next system release.
The requirements document has a diverse set of users, ranging from the senior
management of the organization that is paying for the system to the engineers
responsible for developing the software. Figure 4.6, taken from my book with Gerald
Kotonya on requirements engineering (Kotonya and Sommerville, 1998) shows
possible users of the document and how they use it.