4.3.7 Modifiable
An SRS is modifiable if, and only if, its structure and style are such that any changes to the requirements can
be made easily, completely, and consistently while retaining the structure and style. Modifiability generally
requires an SRS to
a) Have a coherent and easy-to-use organization with a table of contents, an index, and explicit crossreferencing;
b) Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS);
c) Express each requirement separately, rather than intermixed with other requirements.
Redundancy itself is not an error, but it can easily lead to errors. Redundancy can occasionally help to make
an SRS more readable, but a problem can arise when the redundant document is updated. For instance, a
requirement may be altered in only one of the places where it appears. The SRS then becomes inconsistent.
Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modifiable.
4.3.8 Traceable
An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of
each requirement in future development or enhancement documentation. The following two types of traceability
are recommended:
a) Backward traceability (i.e., to previous stages of development). This depends upon each requirement
explicitly referencing its source in earlier documents.
b) Forward traceability (i.e., to all documents spawned by the SRS). This depends upon each requirement
in the SRS having a unique name or reference number.
The forward traceability of the SRS is especially important when the software product enters the operation
and maintenance phase. As code and design documents are modified, it is essential to be able to ascertain the
complete set of requirements that may be affected by those modifications.
4.4 Joint preparation of the SRS
The software development process should begin with supplier and customer agreement on what the
completed software must do. This agreement, in the form of an SRS, should be jointly prepared. This is
important because usually neither the customer nor the supplier is qualified to write a good SRS alone.
a) Customers usually do not understand the software design and development process well enough to
write a usable SRS.
b) Suppliers usually do not understand the customer’s problem and field of endeavor well enough to
specify requirements for a satisfactory system.
Therefore, the customer and the supplier should work together to produce a well-written and completely
understood SRS.
A special situation exists when a system and its software are both being defined concurrently. Then the functionality,
interfaces, performance, and other attributes and constraints of the software are not predefined, but
rather are jointly defined and subject to negotiation and change. This makes it more difficult, but no less
important, to meet the characteristics stated in 4.3. In particular, an SRS that does not comply with the
requirements of its parent system specification is incorrect.