Guideline: System Requirements Specification
Relationships
Main Description

Topics

Introduction

As the heading for the System Requirements Specification artifact description states: "The System Requirements Specification is a composite of the Use-Case Model and the Supplementary Specifications. Its purpose is to provide a formal delivery vehicle for these artifacts, in document form. If the project does not produce these artifacts, then the System Requirements Specification will provide equivalent content."

By default, the expectation in RUP is that the project produce the Use-Case Model and Supplementary Specifications artifacts. If these artifacts are produced, and the project is required to deliver these formally in document rather than tool-readable model form, then the System Requirements Specification can be used to do this. A project which chooses not to produce a Use-Case Model and Supplementary Specifications can use the System Requirements Specification as its prime vehicle for capturing requirements. RUP provides a standard template, and an alternative template which assumes the use of natural-language for capturing functional requirements. If requirements modeling techniques (and associated tools) other than use cases are used, then representations of those models could also be captured. Obviously, without knowing what techniques are used, you cannot say exactly what that representation might be. The table following this paragraph shows choices and decisions to be made.

Intend to produce Use-Case Model? Y Y N N Y Y N N
Intend to produce Supplementary Specifications? Y Y N N N N Y Y
Need formal delivery in document form? Y N Y N Y N Y N
Need to produce System Requirements Specification?
Y N Y

Maybe. It depends what else has been selected to do requirements capture -something is needed.

Y

Maybe. The non-functional requirements must still be captured (assuming some exist). Perhaps they are to be captured in some other artifact-with the Use Cases for example-it would be odd to leave out the Supplementary Specifications and then put exactly the same content in the System Requirements Specification.

Y

Maybe. Some way of capturing the functional requirements is still needed.

Required capabilities (functional requirements)

When use cases are chosen to represent system behavior, then the Report: Use-Case Model Survey and the Report: Use-Case Specification can be used as the basis for the documentation of the functional requirements in the System Requirements Specification. Use cases define interactions between actor and system in pursuit of some useful outcome - essentially defining how required functions are to be delivered or features manifested. It is useful to have both the declarative view and the behavioral view - to describe the functions of the system and then specify how they are to be delivered, and also define the target audience (the actors). The Vision artifact contains the more abstract feature or function-oriented description: the System Requirements Specification needs to map this to the use cases, thus giving a context for the behavior.

When a project chooses some technology other than use cases for representing requirements, the functional requirements must be captured as some refined or derived form of the feature-oriented description in the Vision artifact. The System Requirements Specification can either capture the requirements directly (for example, in natural-language form), or, if requirements modeling tools are used, link to requirements models or extract data from them.

Non-functional requirements and constraints

If the project produces the Supplementary Specifications artifact, then that must be combined with the functional requirements part of the System Requirements Specification for formal delivery. If the project does not produce a separate Supplementary Specifications artifact, then equivalent content must be provided in the System Requirements Specification. This includes physical requirements, environmental requirements, capacity, quality and other "ilities" requirements, specialty engineering requirements, planning/design/implementation/test/deployment, and so forth, constraints, as well as any performance requirements (speed, frequency, accuracy, precision, for example) associated with these.