Topics
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.
|
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.
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.
|