Work Product (Artifact): Supplementary Specifications
var defaultQueryStr = '?proc={38A9C609-9A59-4D03-B835-AA84A716E626}&path={38A9C609-9A59-4D03-B835-AA84A716E626},{28B39D62-9D73-4254-9CB8-26CFA737D45E},_CM61aRi2Edq_uI8xTPML6g'; var backPath = './../../'; var imgPath = './../../images/'; var nodeInfo=null; contentPage.preload(imgPath, backPath, nodeInfo, defaultQueryStr, false, true, false);
Work Product (Artifact): Supplementary Specifications
This artifact captures system requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications.
Purpose
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
Relationships
RolesResponsible:
System Analyst
Modified By:
System Analyst
Input ToMandatory:
None
Optional:
Review Requirements
External:
None
Output From
Structure the Use-Case Model
Description
Main Description
The Supplementary Specifications are an important complement to the Use-Case Model, because together they capture all software requirements
(functional and nonfunctional) that need to be described to serve as a complete Software Requirements Specification.
Brief Outline
It is recommended that the Supplementary Specification be organized according the requirement categories. For a
description of a categorization approach using the "FURPS+" acronym, see Concept: Requirements.
The Supplementary Specification captures all system-wide requirements, not just the non-functional ones. A common
misconception is that all functional requirements reside in the Use Case work products and all non-functional requirements reside in the Supplemental Specification work product. This
is inaccurate as some functional requirements apply to the system as a whole (such as a requirement for online help).
Similarly, some non-functional requirements only apply to a particular use case (or flow within a use case), in which case
the requirement should be attached to the use case, otherwise the system will be over-engineered.
Tailoring
Representation Options
The kinds of supplementary requirements vary widely between projects, so tailoring should be applied to define sections
applicable to your project.