Work Product Descriptor: Supplementary Specifications

Work Product: Supplementary Specifications

This artifact captures system requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications.

Purpose

The Supplementary Specifications capture the system requirements that are not readily captured in the use cases of the use-case model. Such requirements include:

Legal and regulatory requirements, and application standards
Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements
Other requirements such as those for operating systems and environments, compatibility with other software, and design constraints

Relationships

Roles	Responsible: System Analyst	Modified By:
Input To	Mandatory: None	Optional: Architectural Analysis Assess Viability of Architectural Proof-of-Concept	External: None

Description

Brief Outline	It is recommended that the Supplementary Specification be organized according the requirement categories. For a description of a categorization approach using the "FURPS+" acronym, see Concept: Requirements.
Main Description	The Supplementary Specifications are an important complement to the Use-Case Model, because together they capture all software requirements (functional and nonfunctional) that need to be described to serve as a complete Software Requirements Specification.

Properties

Optional
Planned

Illustrations

Examples	CSPS Supplementary Specification - Inception Phase CSPS Supplementary Specification - Elaboration Phase

Key Considerations

The Supplementary Specification captures all system-wide requirements, not just the non-functional ones. A common misconception is that all functional requirements reside in the Use Case work products and all non-functional requirements reside in the Supplemental Specification work product. This is inaccurate as some functional requirements apply to the system as a whole (such as a requirement for online help). Similarly, some non-functional requirements only apply to a particular use case (or flow within a use case), in which case the requirement should be attached to the use case, otherwise the system will be over-engineered.

Tailoring

Representation Options	The kinds of supplementary requirements vary widely between projects, so tailoring should be applied to define sections applicable to your project.

More Information

Checklists	Supplementary Specifications
Concepts	Requirements
Guidelines	Software Requirements Specification Supplementary Specifications — Informal Representation