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
Template:	Word Template HTML Template
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 Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window)

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

Output from Activities: Define Automation Requirements Develop Vision Find Actors and Use Cases 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.

Brief Outline

(hyperlinks into HTML template in a new window)

1.       Introduction         

    1.1     Purpose     

    1.2     Scope     

    1.3     Definitions, Acronyms and Abbreviations     

    1.4     References     

    1.5     Overview     

2.       Functionality     

    2.1     <Functional Requirement One>     

3.       Usability

    3.1     <Usability Requirement One>     

4.       Reliability

    4.1     <Reliability Requirement One>     

5.       Performance       

    5.1     <Performance Requirement One>     

6.       Supportability    

    6.1     <Supportability Requirement One>     

7.       Design Constraints   

    7.1     <Design Constraint One>     

8.       Online User Documentation and Help System Requirements

9.       Purchased Components 

10.            Interfaces               

    10.1     User Interfaces     

    10.2     Hardware Interfaces     

    10.3     Software Interfaces     

    10.4     Communications Interfaces     

11.            Licensing Requirements               

12.            Legal, Copyright and Other Notices               

13.            Applicable Standards               

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 should together 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 see Artifact: Requirements Attributes).

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process