Artifact:  Supplementary Specifications

Supplementary Specifications	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 operating systems and environments, compatibility requirements, and design constraints
Role:	System Analyst
Enclosed in:	Software Requirements Specification
Templates:	HTML Others
Examples:	Supplementary Specification, from the Course Registration System Inception Elaboration Supplementary Specification, from the Collegiate Sports Paging System (e-business) Inception Elaboration
More Information:	Checkpoints:Supplementary Specifications Concepts: Requirements Guidelines: Software Requirements Specification (Defining Non-Functional Requirements)
Purpose Timing Responsibility Tailoring

Input to Activities: Structure the Use-Case Model Manage Dependencies Review Requirements Define Test Details Model the User-Interface Prototype the User-Interface Database Design Implement Component Perform Unit Tests Identify Design Elements Describe the Run-time Architecture Architectural Analysis Structure the Implementation Model Identify Design Mechanisms Assess Viability of Architectural Proof-of-Concept Review the Architecture Review the Design Use-Case Design Class Design Use-Case Analysis Detail a Use Case Detail the Software Requirements

Output from Activities: Develop Vision Find Actors and Use Cases Define Automation Requirements Detail a Use Case Detail the Software Requirements

Purpose

The following roles and role sets use the Supplementary Specifications:

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

Timing

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

• they are initially considered in the Inception phase, as a complement to defining the scope of the system
• they are refined in an incremental fashion during the Elaboration and Construction phases

Responsibility

A system analyst is responsible for producing the Supplementary Specifications, 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.

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 include in the Vision, and which to manage using requirements management tools, such as Rational RequisitePro (see Tool Mentor: Managing Dependencies using Rational RequisitePro®), and also see Artifact: Requirements Attributes.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process