Artifact: Supplementary Specifications

Supplementary Specifications	The Supplementary Specifications capture the system requirements that are not readily capturable 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.
Worker:	System Analyst
Enclosed in:	Software Requirements Specification
Template:	Microsoft Word template HTML template
Examples:	Course Registration System Collegiate Sports Paging System (e-Business)
More Information:	Checkpoints: Supplementary Specifications Concepts: Requirements Guidelines: Software Requirements Specification (Defining Non-Functional Requirements)
Purpose Brief Outline Timing Responsibility Annotated Outline (hyperlinks into HTML template in a new window)

Input to Activities: Architectural Analysis Class Design Database Design Describe the Run-time Architecture Design Test Detail a Use Case Detail the Software Requirements Identify Design Elements Identify Design Mechanisms Implement Component Implement Test Manage Dependencies Model the User Interface Perform Unit Tests Plan Test 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 Design

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

Purpose

The following people use the Supplementary Specifications:

• The system analyst creates and maintains the Supplementary Specifications, which serve as a communication medium between the system analyst, the customer, and other developers.
• Designers 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.
• The manager refers to the Supplementary Specifications for input when planning iterations.
• The 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.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process