Roles and Activities > Analyst Role Set > Requirements Specifier > Detail the Software Requirements

  • To collect, detail and organize the set (package) of artifacts that completely describe the software requirements of the system or subsystem.
Input Artifacts: Resulting Artifacts:
Role: Requirements Specifier
Tool Mentors:
More Information:

Workflow Details:

Detail the Software Requirements To top of page

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.

Generate Supporting Reports To top of page

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

Package the Requirements for Review To top of page

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 ( and one for use *without* use-case modeling (  The first ( 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 ( is an independent document which contains *all* the software requirements directly in the document.  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.

Copyright  © 1987 - 2001 Rational Software Corporation

Display Rational Unified Process using frames

Rational Unified Process