Activity: Detail the Software Requirements

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

Requirements are often stored and managed using one or more tools. For example, tools for:

• graphical use-case modeling
• traceability and requirements management
• other textual and graphical documentation.

This step generates documentation from these tools so that the information can be easily reviewed. See the More Information section of this activity for details of applicable reports you can run related to this work

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.

Rational Unified Process