Activity: Detail the Software Requirements

Purpose To collect, detail and organize the set (package) of artifacts that completely describe the software requirements of the system or subsystem.
Steps Detail the Software Requirements Generate Supporting Reports Package the Requirements for Review
Checkpoints Software Requirements Specification Use Case Supplementary Specifications Requirements Attributes
Input Artifacts: Glossary Vision Use-Case Model Use Case Requirements Management Plan User-Interface Prototype Supplementary Specifications Requirements Attributes	Resulting Artifacts: Software Requirements Specification Supplementary Specifications Requirements Attributes
Role: Requirements Specifier
Tool Mentors: Creating a Use-Case Model Survey Using Rational SoDA Creating a Use-Case Report Using Rational SoDA
More Information: Software Requirements Specification Requirements Types of Requirements Requirements Management Traceability

Workflow Details:

Requirements

Refine the System Definition

Detail the Software Requirements

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 requirements are traced or otherwise formally managed, make sure that each requirement is clearly identified and labeled.

Generate Supporting Reports

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.

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

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