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: 
UML Representation:  Not applicable.
More Information:   
Input to Activities:    Output from Activities:   

Purpose To top of page

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 To top of page

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 To top of page

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 To top of page

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.

Rational Unified Process   2003.06.13