Roles and Activities > Analyst Role Set > Requirements Specifier > Detail the Software Requirements
|Input Artifacts:||Resulting Artifacts:|
|Role: Requirements Specifier|
Make sure that all requirements are specified to the level of detail needed to hand off to designers, testers and documentation writers. Review the Checkpoints: Supplementary Specifications to see if further detail is needed to capture any software requirements not included in the use cases.
If producing a formal Software Requirements Specification (SRS), review the Checkpoints: Software Requirements Specification.
If requirements are traced or otherwise formally managed, make sure that each requirement is clearly identified and labeled.
Requirements are often stored and managed using one or more tools. For example, tools for:
This step generates documentation from these tools so that the information can be easily reviewed.
When using Rational tools, the following reports are applicable:
If specialized tools are not used for capturing the requirements, then this step is not applicable (all software requirements would be written directly in the documentation).
For less formal projects, this step consists of bundling the relevant reports and hand-generated documentation, with sufficient supporting material so requirements can be effectively reviewed.
On more formal projects, one or more Software Requirements Specifications (SRS) collect and organize all requirements surrounding the project. For example, a separate SRS may describe the complete software requirements for each feature in a particular release of the product. This may include several use cases from the system use-case model, to describe the functional requirements of this feature, along with the relevant set of detailed requirements in Supplementary Specifications. Refer to the Requirements Management Plan (part of the Software Development Plan) to determine the correct location and organization of the requirements.
The Software Requirements Specification is a formal, IEEE
830-type document, represented by a UML “package” construct. Two sample SRS templates
are provided: one for use with
use-case modeling (rup_srsuc.dot) and one for use without
use-case modeling (rup_srs.dot). The
first (rup_srsuc.dot) references, or encloses, the use-case-model artifacts:
the use-case model survey, the
use-case reports, and the supplementary
specifications. This allows
you to have a formal IEEE-compliant SRS without having to duplicate the information
in these other 3 artifacts.
The second (rup_srs.dot) is an independent document which
This document would require you to use traceability to use-case artifact
requirements, if they are used. Technically,
they both contain the same information, however the information in the use-case
model is enclosed by reference (rather than being duplicated) in the first and
fully duplicated (if using use cases) in the second, which would require much
more effort in maintaining the traceability relationships.
Using the Software Requirements Specification
template, assemble the pieces of the SRS package and supply the remaining information
in order to have a complete definition of the software requirements for this
subsystem or feature.
Rational Unified Process