|Task: Develop Supplementary Specifications||
|This task captures the requirements that do not apply to specific use cases.
|To capture requirements that are not readily captured in Use Cases.
Throughout the requirements activities, based upon the stakeholder requests that have been gathered, requirements that
are not applicable to specific Use Cases are captured in the Supplementary Specification. Both
functional and non-functional requirements may be captured in the Supplementary Specification.
For more information in categorizing and capturing requirements, see Concept: Requirements.
While performing this task it is important to make sure that all requirements are specified to the level of detail
needed to hand off to designers, testers and documentation writers. If requirements are traced or otherwise
formally managed, make sure that each requirement is clearly identified and labeled.
Capture Non-Use-Case-Specific Functional Requirements
Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks or
While many of the functional requirements will be documented in Use Cases,
there are some functional requirements that cannot be applied to specific use cases. For example, reporting,
auditing, printing, security, licensing support/enforcement, authentication requirements, etc. Such functional
requirements should be documented in the Supplementary Specification.
If there are a significant number of system-wide functional requirements, it is important to give some thought into the
organization of this section. A typical organization is by feature/feature set, but alternative organization
methods are also possible. For example, organization by user or organization by subsystem, may also be
Functional requirements represent the 'F' in "FURPS+. For more information on "FURPS+", see Concept: Requirements.
Capture System Qualities
Non-functional requirements include both qualities and constraints [MAL2001].
In this step we discuss qualities. Constraints are addressed in a separate step.
[System] qualities are properties or characteristics of the system that its stakeholders care about and hence will
affect their degree of satisfaction with the system. [MAL2001]
Qualities represent the "URPS" in "FURPS+". The concerns of each of these categories of requirements is as
Usability: Aesthetics and consistency in the user interface.
Reliability: Availability (the amount of system "up time"), accuracy of system
calculations, and the system's ability to recover from failure.
Performance: Throughput, response time, recovery time, start-up time, and shutdown time.
Supportability: Testability, adaptability, maintainability, compatibility, configurability,
installability, scalability, and localizability.
For more information on "FURPS+", as well as capturing non-functional requirements, see Concept: Requirements.
Depending on the number of qualities to be documented for the system, you may want to provide sub-sections for each of
these quality types.
The following sections provide some examples of the kids of information you might want to capture for each of these
When describing usability requirements, you may want to specify:
Required training time for a normal users and power users to become productive at particular operations
Measurable task times for typical tasks
Requirements to conform to common usability standards, for example, IBM's CUA standards or Microsoft's GUI
When describing reliability requirements, you may want to specify:
Availability – specify percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode
operations, and the like.
Mean Time Between Failures (MTBF) – this is usually specified in hours but it could also be specified in terms of
days, months or years.
Mean Time To Repair (MTTR) – how long is the system allowed to be out of operation after it has failed?
Accuracy – specify precision (resolution) and accuracy (by some known standard) that is required in the systems
Maximum bugs or defect rate – usually expressed in terms of bugs/KLOC (thousands of lines of code), or
Bugs or defect rate – categorized in terms of minor, significant, and critical bugs: the requirement(s) must define
what is meant by a "critical" bug; for example, complete loss of data or complete inability to use certain parts of
the functionality of the system.
When describing performance requirements, you may want to specify:
Response time for a transaction(average, maximum)
Throughput (for example, transactions per second)
Capacity (for example, the number of customers or transactions the system can accommodate)
Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)
Resource use: memory, disk, communications, and so forth
When documenting performance requirements, be sure to include specific response times. Where applicable, reference
related Use Cases by name.
When describing supportability requirements, you may want to specify:
In this step you document any design constraints on the system being built. In general terms, a constraint is a
restriction on the degree of freedom we have in providing a solution [LEF2000]. Design
constraints represent design decisions that have been mandated and must be adhered to.
A Constraints represent the '+' in "FURPS+" and can be further categorized, as follows:
Design constraint: Specifies or constrains the options for architecting and/or designing a
system. For example, requiring that a relational database be used for persistence.
Implementation constraint: Specifies or constrains the coding or construction of a system. For
example, required standards, processes, tools, implementation languages, hardware platforms, operating systems,
third-party components, class libraries, and resource limits (use of memory or disk space).
Interface constraint: Specifies an external item with which a system must interact, or constraints
on formats or other factors used within such an interaction. For example, interfacing with an external system
via message queues.
Physical constraint: Specifies a physical constraint imposed on the hardware used to house the
system — shape, size, or weight, for example.
Depending on the number of constraints to be documented for the system, you may want to provide sub-sections for each
of the constraint types. Additionally:
If the requirements include the purchase of third-party components, be sure to document any applicable licensing or
usage restrictions, and any associated compatibility/interoperability or interface standards. A separate section
per purchased component is recommended.
If the requirements include specific interface requirements, it is recommended that you provide separate sections
for the different types of interfaces (e.g., user, hardware, software). For each interface, be sure to include
adequate specificity, protocols, ports and logical addresses, and so forth, so that the software can be developed
and verified against the interface requirements. Specifically:
For user interfaces, describe the user interfaces that are to be implemented by the software.
For hardware interfaces, include logical structure, physical addresses, expected behavior, and so on.
For software interfaces include a description of the interfaces to other components of the software system.
These may be purchased components, components reused from another application or components being developed
for subsystems outside of the scope of this system, but with which this software application must interact.
For more information on "FURPS+", as well as capturing constraints, see Concept: Requirements.
Capture Compliance Requirements
By compliance, we include standards compliance (including regulatory standards, coding standards or user interface
style guides), as well as legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, and/or
Compliance requirements may be realized in terms of other requirements (functional, non-functional, and
constraints). In such cases, the details of those requirements should be documented in the applicable sections of
the Supplementary Specification as described in the earlier steps. However, it is important to summarize the
standards and policies that a system must comply with. The resulting compliance requirements may refer to the
applicable detailed requirements, as necessary.
Depending on the number of compliance requirements to be documented for the system, you may want to provide
sub-sections for the different kinds of compliance affecting the system.
The following sections provide some examples of the kids of information you might want to capture for different kinds
Define any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the
Legal, Copyright, and Other Notices
Describe any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo
compliance issues for the software.
Describe (by reference) any applicable standards and the specific sections of any such standards that apply to the
system being described. For example, this could include legal, quality and regulatory standards, industry standards for
usability, interoperability, internationalization, operating system compliance, and so forth.
Capture Documentation Requirements
In this step, you describe the requirements, if any, for documentation. Documentation requirements may include
requirements for online help, as well as and end-user documentation (e.g., installation guides, user's guides, training
Like compliance requirements, documentation requirements drive other types of requirements. Specifically
functional requirements (the system must provide support functional access to the online help), as well as usability
requirements (on demand access to system usage information supports the overall usability of the system).
Thus, like compliance requirements, detailed requirements supporting documentation requirements should be documented in
the applicable sections of the Supplementary Specification as described in the earlier steps, but it is also important
to document and summarize the overall documentation requirements for the system. The resulting requirements may refer
to the applicable detailed requirements.
Depending on the number of documentation requirements to be documented for the system, you may want to provide
sub-sections for the different kinds of documentation to be provided for the system.
The requirements that span use cases (possibly system-wide requirements) tend to drive the development of the
architecture of the system. In fact, on some projects, such requirements can be significantly more important than their
more domain-specific (or use-case-specific) counterparts. For example, if you were developing medical life support
systems, then reliability requirements would be critical.
Unfortunately, such requirements are often difficult to gather and thus are often overlooked. This task describes the
overall approach for gathering these requirements. For more information on a "systematic" approach to gathering
these requirements using specific questionnaires, see [EEL2004].
© Copyright IBM Corp. 1987, 2006. All Rights Reserved.