Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Artifact: Supplementary Specifications
The Supplementary Specification artifact capture system requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications.
Role:System Analyst
Optionality/Occurrence:Used if there are system requirements that cannot be associated with a specific use case.
Templates and Reports:- Template: Supplementary Specification
Examples:- CREG Supplementary Specification - Inception Phase - CREG Supplementary Specification - Elaboration Phase - CSPS Supplementary Specification - Inception Phase - CSPS Supplementary Specification - Elaboration Phase
UML Representation:Not applicable.
More Information:- Concept: Requirements - Guideline: Software Requirements Specification - Checklist: Supplementary Specifications - Guideline: Supplementary Specifications - Informal Representation
Input to Activities: - Architectural Analysis - Assess Viability of Architectural Proof-of-Concept - Class Design - Database Design - Define Test Details - Describe Distribution - Describe the Run-time Architecture - Design the User Interface - Detail a Use Case - Detail the Software Requirements - Identify Design Elements - Identify Design Mechanisms - Implement Design Elements - Manage Dependencies - Prototype the User-Interface - Review Requirements - Review the Architecture - Review the Design - Structure the Implementation Model - Structure the Use-Case Model - Use-Case Analysis - Use-Case DesignOutput from Activities: - Define Automation Requirements - Detail a Use Case - Find Actors and Use Cases

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

Timing

Supplementary Specifications go hand-in-hand with the use-case model, implying that:

  • they begin to be identified in the Inception phase, as a complement to defining the scope and behavior of the system through use cases
  • they are expanded and refined in an incremental fashion during the Elaboration and Construction phases

Responsibility

The System Analyst role is primarily responsible for this artifact, which is an important complement to the use-case model. The Supplementary Specifications and the use-case model together should capture a complete set of requirements on the system.

This artifact is an important input to other software engineering work. The following roles and role sets use the Supplementary Specifications:

  • Analysts create and maintain itSupplementary Specifications, which serve as a communication medium between the analyst, the customer, and developers.
  • Developers use it as a reference when defining responsibilities, operations, and attributes on classes, and when adjusting classes to the implementation environment.
  • Implementers refer to it for input when implementing classes.
  • Managers refer to it for input when planning iterations.
  • Testers use it to validate system compliance.

Tailoring

The kinds of supplementary requirements vary widely between projects, so tailoring should be applied to define sections applicable to your project. Decide which information (attributes) to manage in the Vision, and which to manage using requirements management tools, such as Rational RequisitePro.

Note that Supplementary Specifications may be enclosed within Software Requirements Specification artifacts.