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
Template:	Supplementary Specification template
Purpose Brief Outline Timing Responsibility Tailoring

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

Supplementary Specifications should list the requirements that are not readily capturable in the use cases of the use-case model. For a more detailed outline, see the IEEE recommended practice for software requirements specifications [IEEE Std 830-1993]. Following is a sample outline.

1.   Functionality
        List functional requirements are general to many use cases.

   1.1   <Functional Requirement One>

2.   Usability
       Include all of those requirements that relate to, or affect, the usability of the system. Examples include ease-of-use requirements or training requirements that specify how readily the system can be used by its actors.

   2.1   <Usability Requirement One>

3.   Reliability
        Specify any requirements concerning the reliability of the system. Quantitative measures such as mean time between failure or defects per thousand lines of code should be stated.

   3.1   <Reliability Requirement One>

4.   Performance
        Outline the performance characteristics of the system. Include specific response times. Reference related use cases by name.

   4.1   <Performance Requirement One>

5.   Supportability
        Indicate any requirements that will enhance the supportability or maintainability of the system being built.

   5.1 <Supportability Requirement One>

6. Design Constraints
        Indicate in this section any design constraints on the system being built.

   6.1 <Design Constraint One>

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.