Supplementary Spec
Template
This document has two parts:
-----------------------------------------------The Template-----------------------------------------
Supplementary
Specification for <requirements, system or project name>[1]
Title, authors, etc. go
first.
1. Introduction
1.1 Purpose
State the purpose of the document (to collect all functional requirements not expressed in the use-case model, as well as nonfunctional requirements and design constraints.
1.2 Scope
1.3 Definitions, Acronyms, and Abbreviations
1.4 References
1.5 Overview
(an additional section included by some users of this format)
2. Functionality or Functional Requirements
Describe the functional requirements of the system for those requirements that are expressed in the natural language style or are otherwise not included in the use-case model. See p. 258.
2.1 <Functional Requirement One, etc., if a listing of these is done…>
3. Usability
Describe the principal scenarios that
affect usability. See pp. 259-260, and
use the Scenario format shown in Note 2, below,
with related details for Usability. See
also the Yale Style Guide, http://www.webstyleguide.com/,
or User and Task Analysis for Interface
Design by JoAnn T. Hackos
and Janice C. Redish, Wiley Computer Publishing,
1998, ISBN 0-471-17831-4.
3.1 <Usability Requirement One…>
4. Availability
Describe the principal scenarios
for dependability such as “reliability” and/or “availability.” (These are different! See pp. 261-2, web links such as: http://www.weibull.com/SystemRelWeb/availability.htm,
or the book Software Reliability
Engineering, by John D. Musa, cited in your
syllabus.) Use the Scenario format shown
in Note 2, below, with related
details for Availability.
4.1 <Availability Requirement One…>
5. Performance
5.1 <Performance Requirement One…>
Describe the principal required performance and capacity scenarios of the system, expressed quantitatively where possible and related to use cases where applicable. E.g., It’s unlikely they all have to run equally fast. Related terms and requirements are capacity, throughput, and response time. See p. 262 in your book, or Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software, by Connie U. Smith, Lloyd Williams, cited in your syllabus. Use the Scenario format shown in Note 2, below, with related details for Performance.
6. Modifiability
This is close to Leffingwell & Widrig’s “Supportability” requirement. State the requirements that enhance system modifiability, supportability or maintainability. See pp. 262-3 in your book. Use the Scenario format shown in Note 2, below, with related details for Modifiability.
6.1 <Modifiability Requirement One…>
7. Security
Describe the principal security scenarios for the system, using the Scenario format shown in Note 2, below, with related details for Security. System security is a big area – look for suggested topics also from other resources. One example, Security Architecture: Design, Deployment & Operations, by Christopher M. King, et al, Osborne/McGraw-Hill, 2001, ISBN 0-07-213385-6.
7.1 <Security Requirement One…>
8. Testability
Describe the principal testability scenarios for the system, using the Scenario format shown in Note 2, below, with related details for Testability.
8.1 <Testability Requirement One…>
9. Design Constraints
State the design or development constraints imposed on the system or development process. See pp. 263-266 in your book.
9.1 <Design Constraint One…>
10. Documentation, Online Documentation and
Help System Requirements
State the requirements for user and/or administrator documentation.
11. Purchased Components
List the purchased components used with the system (including the planned version numbers and availability / support termination dates!), licensing or usage restrictions (some have a runtime license fee, some don’t), and compatibility/interoperability requirements (“to run this, users must have…” etc.)
12. Interfaces
Define the interfaces that must be supported by the application.
12.1 User Interfaces
12.2 Hardware Interfaces
12.3 Software Interfaces
12.4 Communications Interfaces
13. Licensing Requirements
Describe the licensing and usage enforcement requirements or other restrictions for usage, security, and accessibility (for the system you will be building).
14. Legal, Copyright, and Other Notices
State any required legal disclaimers, warranties, copyright notices, patent notices, trademarks, or logo compliance issues.
15. Applicable Standards
Reference any applicable standards and the specific sections of any such standards that apply.
16. Internationalization and Localization
State any requirements for support and application of different user languages and dialects.
15. Physical Deliverables
Define any specific deliverable artifacts required by the user or customer.
16. Installation and Deployment
Describe any specific configuration or target system preparation required to support installation and deployment of the system.
----------------------------------------------The Notes-------------------------------------------------
Note 1: You’re not done yet! As the book says (pp. 266-7), a well-defined set of requirements should include links or cross-references from the use cases to non-functional requirements and other pieces of this Supplementary Specification. And these ties should be well-defined, so they don’t grow “tired” as changes are made to either document, or new versions of the documents are issued!
Note 2: “Scenario” format for the non-functional requirements, in general:
Source of stimulus: This is
some entity (a human, a computer system, or any other actuator) that generated
the stimulus.
Stimulus: The stimulus is a
condition that needs to be considered when it arrives at a system.
Environment: The stimulus
occurs within certain conditions. The
system may be in an overload condition or may be running when the stimulus
occurs, or some other condition may be true.
Artifact: Some artifact is
stimulated. This may be the whole
system or some pieces of it.
Response: The response is
the activity undertaken after the arrival of the stimulus.
Response measure: When the
response occurs, it should be measurable in some fashion so that the
requirement can be tested.
And -- Possible values of these portions of the scenario, for different Quality Attributes (from Bass, et al[2]):
3. Usability --
Source: End user
Stimulus: Wants to learn system features, use
system efficiently, minimize impact of errors, adapt system, feel comfortable
Artifact: System
Environment: At runtime or configure time
Response: System provides one or more of the following responses:
To support “learn system features”:
Help system is sensitive to context, interface is familiar to user; interface is usable in an unfamiliar context
To support “use system efficiently”:
Aggregation of data and/or commands; support for efficient navigation within a screen; distinct views with consistent operations; comprehensive searching; multiple simultaneous activities
To “minimize impact of errors”:
Undo, cancel, recover from system failure, recognize and correct user error, retrieve forgotten password, verify system resources
To “adapt system”:
Customizability; internationalization
To “feel comfortable”:
Display system
state; work at the user’s pace
Response Measure: Task time, number of errors, number of
problems solved, user satisfaction, gain of user knowledge, ratio of successful
operations to total operations, amount of time/data lost.
à Here’s a sample usability scenario from Bass et al:
Source: Users
Stimulus: Minimize impact of errors
Artifact: System
Environment: At runtime
Response: Wishes to cancel current operations
Response Measure: Cancellation takes less than one second
4. Availability --
Source: Internal to the system; external to the
system
Stimulus: Fault: omission, crash, timing, response
Artifact: System’s processors, communication
channels, persistent storage, processes
Environment:
Response: System should detect event and do one or more of the following:
Record it
Notify appropriate parties, including the user and other systems
Disable sources of events that cause fault or failure according to defined rules
Be unavailable for a
prespecified interval, where interval depends on
criticality of system
Response Measure:
Time interval when the system must be available
Availability time
Time interval in which system can be in degraded mode
Repair time
à Here’s a sample availability scenario from Bass et al:
Source: External to the system
Stimulus: Unanticipated message
Artifact: Process
Environment:
Response: Inform operator continue to operate
Response Measure: No downtime
5. Performance --
Source: One of a number of independent sources,
possibly from within system
Stimulus: Periodic events arrive; sporadic events
arrive; stochastic events arrive
Artifact: System
Environment:
Response: Processes stimuli; changes level of
service
Response Measure: Latency, deadline, throughput, jitter,
miss rate, data loss
à Here’s a sample performance scenario from Bass et al:
Source: Users
Stimulus: Initiate transactions
Artifact: System
Environment: Under normal operations
Response: Transactions are processed
Response Measure: With average latency of two seconds
6. Modifiability --
Source: End user, developer, system administrator
Stimulus: Wishes to add/delete/modify/vary
functionality, quality attribute, capacity
Artifact: System user interface, platform,
environment, system that interoperates with target system
Environment: At runtime, compile time, build time,
design time
Response: Locates places in architecture to be
modified; makes modification without affecting other functionality; tests
modification; deploys modification
Response Measure: Cost in terms of number of elements
affected, effort, money; extent to which this affects other functions or
quality attributes
à Here’s a sample modifiability scenario from Bass et al:
Source: Developer
Stimulus: Wishes to change the UI
Artifact: Code
Environment: At design time
Response: Modification is made with no side effects
Response Measure: In 3 hours
6. Security --
Source: Individual or system that is
Correctly identified, identified incorrectly, of unknown identity
Who is
Internal/external, authorized/not authorized
With access to
Limited resources, vast resource
Stimulus: Tries to
Display
data, change/delete data, access system services, reduce availability to system
services
Artifact: System services, data within system
Environment: Either online or offline, connected or
disconnected, firewalled or open
Response: Authenticates user; hides identity of the
user; blocks access to data and/or services; allows access to data and/or
services; records access/modifications or attempts to access/modify
data/services by identity; stores data in an unreadable format; recognizes an
unexplainable high demand for services, and informs a user or another system,
and restricts availability of services
Response Measure: Time/effort/resources required to
circumvent security measures with probability of success; probability of
detecting attack; probability of identifying individual responsible for attack
or access/modification of data and/or services; percentage of services still
available under denial-of-service attack; restore data/services; extent to
which data/services damaged and/or legitimate access denied
à Here’s a sample security scenario from Bass et al:
Source: Correctly identified individual
Stimulus: Tries to modify information
Artifact: Data within the system
Environment: Under normal operations
Response: System maintains audit trail
Response Measure: Correct data is restored within a day
6. Testability --
Source: Unit developer
Increment integrator
System verifier
Client acceptance tester
System user
Stimulus: Analysis, architecture, design, class,
subsystem integration completed; system delivered
Artifact: Piece of design, piece of code, complete
application
Environment: At design time, at development time, at
compile time, at deployment time
Response: Provides access to state values; provides
computed values; prepares test environment
Response Measure: Percent executable statements executed
Probability of failure if fault exists
Time to perform tests
Length of longest dependency chain in a test
Length of
time to prepare test environment
à Here’s a sample testability scenario from Bass et al:
Source: Unit tester
Stimulus: Performs unit test
Artifact: Component of the system
Environment: At the completion of the component
Response: Component has interface for controlling behavior, and output of the component is observable
Response Measure: Path coverage of 85% is achieved within 3 hours