SUPPLEMENTARY SPECIFICATION DOCUMENT

Definition:
The Supplementary Specifications capture the system requirements that are not captured
in the use cases or other documents. 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.
Usability
Usability should include all of those requirements that affect usability. Examples:
Specify the required training time for a normal users and power users to become
productive at particular operations.
Specify measurable task times for typical tasks or base usability requirements of
the new system on other systems that the users know and like.
Specify requirements to conform to common usability standards e.g., GUI
standards published by Microsoft for Windows XP.
Reliability
Requirements for reliability of the system should be specified here. Suggestions:
Availability specify % of time available (xx. xx%), hours of use, maintenance
access, degraded mode operations etc.
Accuracy specify precision (resolution) and accuracy (by some known standard)
that is required in the systems output.
Maximum bugs or defect rate usually expressed in terms of bugs/KLOC
(thousands of lines of code), or bugs per function-point.
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 (e.g., complete
loss of data, complete inability to use certain parts of the functionality of the
system).
Performance
The performance characteristics of the system should be outlined in this section.
Include specific response times. Where applicable, reference related Use Cases by name.
Response time for a transaction (average, maximum)
Throughput (e.g., transactions per second)
Capacity (e.g., 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 utilization: memory, disk, communications, etc.
Supportability

This section indicates any requirements that will enhance the supportability or
maintainability of the system being built, including coding standards, naming
conventions, class libraries, maintenance access, maintenance utilities.
Design Constraints
This section should indicate any design constraints on the system being built.
Design constraints represent design decisions that have been mandated and must be adhered to.
Example: software languages, software process requirements, prescribed use of
developmental tools, architectural and design constraints, purchased components, class libraries,
etc.
Online User Documentation and Help System Requirements
It describes the requirements, if any, for on-line user documentation, help
systems, help about notices, etc.
Purchased Components
It describes any purchased components to be used with the system , any applicable
licensing or usage restrictions, and any associated compatibility/interoperability or interface
standards.
Interfaces
This section defines the interfaces that must be supported by the application. It
should contain adequate specificity, protocols, ports and logical addresses, etc, so that the
software can be developed and verified against the interface requirements.
i)User Interfaces
Describe the user interfaces that are to be implemented by the software.
ii) Hardware Interfaces
This section defines any hardware interfaces that are to be supported by the
software, including logical structure, physical addresses, expected behavior, etc.
iii) Software Interfaces
This section describes software 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
SRS, but with which this software application must interact.
iv) Communication Interfaces
Describe any communications interfaces to other systems or devices such as local
area networks, remote serial devices, etc.
Licensing Requirements
Define any licensing enforcement requirements or other usage restriction
requirements that are to be exhibited by the software.
Legal, Copyright and Other Notices
Other Requirements
Each transaction must include the following information:

 The terminal ID.

The unit ID
The Date and Time
The User ID
Credit card number
Authentication code (from credit card company)
List of media played and the unit price.
Applicable Standards
[This section describes by reference any applicable standards, such as in-house coding
standards, data standards, etc.
Supplementary Specification:
Supplementary Specification Requirements are categorized by FURPS+ F = Functional
Requirements Use Cases address the F requirements Supplementary Specification
contains the URPS+ requirements Usability Reliability Performance Supportability +
others?
Supplementary Specification Use Cases Strengths Detailing interaction with external
actors Documenting business processes Weaknesses Highly algorithmic or computational
systems Solutions Capture math formulas in Business Rules Formulas Calculations Lists
of data Activity diagrams Embedded systems State machine models
Supplementary Specification Usability Is always an issue Difficult to measure Vary from
customer to customer How should we document/measure?
Supplementary Specification Measurement Approaches Training time User productivity
metrics Task metrics Benchmarking Published/Tested results of other systems Increase
Usability Customization and Visual cues Tooltips Assistance/First time tutorials Help
manuals Training scenarios
Supplementary Specification Users Bill of Rights (Karat 1998) User is always right
Easily install/uninstall SW System must perform as promised Easy-to-use documentation
User right to be in control of the system User always informed about task status &
progress User clearly informed about all requirements to use system User knows systems
limits and capabilities User receives helpful prompts System is natural and intuitive to
use
Supplementary Specification Reliability How to measure Availability Must be up
99.999% of the time 24/365 Mean Time Between Failures (MTBF) What are considered
failures? Mean Time To Repair (MTTR) 90% of failures repaired within 15 minutes
Vendor response In person on site By telephone
Supplementary Specification More Reliability measures Accuracy Outputs must be
reliable Low defect rate Measured in Defects per X Lines of Code Defect severity Minor
Important Major
Supplementary Specification Performance Response times for transactions Throughput
Capacity Max user load How many users before system degradation Maintain 80%
throughput when 120% of capacity Failover are always a good idea If node goes down,
system @ capacity within 5 minutes

 Supplementary Specification Supportability Clients have to be knowledgeable or know

where to find info Developers should be trained on system maintenance Architectural
integrity Follow OO architecture Design patterns (Covered in 2511) Documentation of
system architecture Use UML to model system Ongoing support Provide customer
support at least during hours of possible use Update system documentation with each
release
Supplementary Specification Constraints on Design Hardware and/or Software
restrictions RDBMS OS Server SW design process Regulatory Local State Federal laws
Supplementary Specification Document any additional relevant information artifact (that
need created) Decision Rational List of features/reasons things werent done Anything
else the requirements might have missed Training

USE CASE SPECIFICATION DOCUMENT:

Use case:
A use case is an abstraction of a required behavior of a system.
A use case produces an observable result of value to the user.
A typical system will have many use cases each of which satisfies a goal of a particular
user.
Each use case describes a sequence of interactions between one or more actors and the
system.
A use case narrative is written in a natural language. It is written as a sequence of
numbered steps with a main success scenario and alternate flows.
This sequence of interactions is contained in a use case report and the relationships
between the system and its actors are portrayed in use case diagrams.
Use case-Purposes:
Use cases are used for the following purposes:
To reach a common understanding of system behavior
To design elements that support the required behavior

To identify test cases

To plan and assess work

To write user documentation.

Use case-outline:
A use case typically includes the following information:
Name: The name of the use case
Brief Description: A brief description of the role and purpose of the use case

Flow of Events: A textual description of what the system does in regard to a use case
scenario (not how specific problems are solved by the system). Write the description so
that the customer can understand it. The flows can include a basic flow, alternative flows,
and subflows.

Key scenarios: A textual description of the most important or frequently discussed

scenarios

Special Requirements: A textual description that collects all of the requirements of the
use case that are not considered in the use-case model, but that must be taken care of
during design or implementation (for example, non-functional requirements)

Preconditions: A textual description that defines a constraint on the system when the use
case starts

Post-conditions: A textual description that defines a constraint on the system when the
use case ends

Extension points: A list of locations within the flow of events of the use case at which
additional behavior can be inserted by using the extend-relationship

Use case- strengths:

Simple concept
Easy to comprehend and follow-Contingent on writing skill
User focused ensures that you consider how the system supports its environment
Easy to review with non-technical stakeholders
Easy to incorporate soft topics like goals, capabilities and expectations.
Use case- weaknesses:
Lack precision-Use cases feel vague
Relatively hard to document and organize lots of necessary details
Use cases are not yet used by everyone
Hard to definitively sign off a use case for acceptance testing
Requirements and use cases:
Specific Requirements
Functional requirements state, in formal shall statement notation, the functions that the
system must execute.
Nonfunctional requirements are often performance requirements that specify how well
the system must execute certain functions.
Supplementary Requirements Specification contains the requirements that are associated
with more than one use case. Often they are system wide. Examples include cost,
schedule, reliability, availability, technology, design life,etc.,
Use case-concept:
A use case describes the interactions between one of more Actors and the system in order to
provide an observable result of value for the initiating actor.
The functionality of a system is defined by different use cases, each of which represents a
specific goal (to obtain the observable result of value) for a particular actor.

In an automated teller machine shown in Figure 1, the Bank Customer can withdraw cash from
an account, transfer funds between accounts, or deposit funds to an account. These correspond to
specific goals that the actor has in using the system.

ATM Use-Case Example

Each use case is associated with a goal of one of the actors. The collection of use cases
constitutes all the possible ways of using the system. You should be able to determine the goal of
a use case simply by observing its name.
A use case describes the interactions between the actor(s) and the system in the form of a dialog
between the actor(s) and the system, structured as follows:
1. The actor <<does something>>
2. The system <<does something in response>>
3. The actor <<does something else>>
4. The system ...
Each dialog of this form is called a "Flow of Events".
Because there are many flows of events possible for achieving the goal (for example, the flow
may differ depending upon specific input from the actor), and there are situations in which the
goal cannot be achieved (for example, a required network connection is currently unavailable),

each use case will contain several flows, including one "Basic Flow of Events" and several
"Alternative Flows".
The Basic Flow of Events specifies the interactions between the actor(s) and the system for the
ideal case, where everything goes as planned, and the actor's goal (the observable result of value)
is met. The basic flow represents the main capability provided by the system for this use case.
As the name implies, Alternative Flows specify alternative interactions associated with the same
goal.
Closely related to use cases is the concept of a scenario. A scenario is a specific flow of events,
for a specific set of inputs to the system, states of the system, and states of the system's
environment. Scenarios are closely related to test cases.

Properties of Use Cases

Name
Each use case should have a name that indicates what is achieved by its interaction with the
actors. The name may have to be several words to be understood. Note: No two use cases can
have the same name.
Brief Description
The brief description of the use case should reflect its purpose.
Flow of Events
Flow of Events - Contents
The flow of events should describe the use case's flow of events clearly enough for an outsider to
easily understand. Remember, the flow of events should represent what the system does, not how
the system is design to perform the required behavior.
Follow these guidelines for the contents of the flow of events:

Describe how the use case starts and ends.

Describe what data is exchanged between the actor and the use case.

Do not describe the details of the user interface, unless it is necessary to understand the
behavior of the system. Specifying user interface details too early will limit design
options.

Describe the flow of events, not only the functionality. To enforce this, start every action
with "When the actor ... ".

Describe only the events that belong to the use case, and not what happens in other use
cases or outside of the system.

Avoid vague terminology.

Detail the flow of events. Specify what happens when, for each action. Remember this
text will be used to identify test cases.

Flow of Events - Structure

The two main parts of the flow of events are basic flow of events and alternative flows
of events. The basic flow of events should cover what "normally" happens when the use case is
performed. The alternative flows of events cover behavior of optional or exceptional character in
relation to the normal behavior, and also variations of the normal behavior. You can think of the
alternative flows of events as detours from the basic flow of events, some of which will return to
the basic flow of events and some of which will end the execution of the use case.
Both the basic and alternative flows should be further structured into steps or sub-flows. In doing
this, your main goal should be readability of the text. A guideline is that a sub-flow should be a
segment of behavior within the use case that has a clear purpose, and is "atomic" in the sense that
you do either all or none of the actions described.
Special Requirements:
In the Special Requirements of a use case, you describe all the requirements associated with the
use case that are not covered by the flow of events. These are non-functional requirements that
will influence the design.
Preconditions and Post-conditions:
A precondition is the state of the system and its environment that is required before the use case
can be started. Post-Conditions are the states the system can be in after the use case has ended. It
can be helpful to use the concepts of precondition and post-condition to clarify how the flow of
events starts and ends. However, only use them only if the audience for the description of the use
case agrees that it is helpful. Figure 3 shows an example.

Illustration of preconditions and resulting post-conditions

Examples:
A precondition for the use case Cash Withdrawal in the ATM machine: The customer has a
personally issued card that fits in the card reader, has been issued a PIN number, and is registered
with the banking system.
A post-condition for the use case Cash Withdrawal in the ATM machine: At the end of the
use case, all account and transaction logs are balanced, communication with the banking system
is reinitialized and the card is returned to the customer.

METHODS FOR SOFTWARE PROTOTYPING:

Software Prototyping Process:
Software prototyping is the process of creating an incomplete model of the future fullfeatured software
A prototype can be used to give end-users a concrete impression of the systems
capabilities
Prototyping is becoming increasingly used where rapid development is essential
IEEE defines prototyping as A type of development in which emphasis is placed on
developing prototypes early in the development process to permit early feedback and
analysis in support of the development process.
Process:

Identify basic requirements

Develop Initial prototype

Review with customers users

Revise and enhance

Prototyping Process:

Establish
prototype
objectives

Define
prototype
functionality

Develop
prototype

Evaluate
prototype

Prototyping
plan

Outline
definition

Executable
prototype

Evaluation
report

Types of Software Prototypes:

Throwaway prototype: process of creating a rapid model (demonstration or

marketing)
Evolutionary prototype: build a system then refine
Incremental: final product built as separate prototypes

Applications:
Feasibility (must use)
Human Interface testing
Increases user involvement
Reduce time and cost
DSDM (Dynamic Systems Development Method)
Business prototypes (automation/mechanization)
Usability prototypes
Performance and Capacity
Proof of concept

Prototypes:

Plan to build a prototype

Document feedback from customer for the prototype.
Manage the feedback into the software product

Prototyping with Reuse:

1) Application level development

Entire application systems are integrated with the prototype so that their
functionality can be shared

For example, if text preparation is required, a standard word processor can be

used

2) Component level development

Components are mutually independent

Individual components are integrated within a standard framework to implement

the system

Framework can be a scripting language or an integration platform.

Reusable component composition:

Reusable
software
components

Component
composition
framework

Executable
prototype

Controland
integrationcode

Prototyping Benefits:
Misunderstandings between software users and developers are exposed
Missing services may be detected and confusing services may be identified
A working system is available early in the process
The prototype may serve as a basis for deriving a system specification
The system can support user training and system testing
Improved system usability
Closer match to the system needed
Improved design quality
Improved maintainability
Reduced overall development effort
Prototyping Approaches:

Evolutionary
prototyping

Delivered
system

Outline
Requirements
Throwaway
Prototyping

Executable Prototype+
SystemSpecification

Prototyping as methodology for systems development:

A preliminary design of the system is built using throw-away prototyping.

Demonstrations to end users, as well as investigations on this prototype, allows for the
design of more precise requirements as well as the evaluation of techniques to be used in
the final system.

Refinements on throw-away prototype concerning the requirements are done.

Evolutionary prototyping used to build a model prototype (an accurate and complete
description of the system). These prototypes can be studied under various simulated
conditions.

Refinement on model prototype, concerning the actual system, is done and final system is
rolled out after testing.

Prototyping Objectives:
The objective of evolutionary prototyping is to deliver a working system to end-users

The development starts with those requirements which are best understood.

The objective of throw-away prototyping is to validate or derive the system requirements

The prototyping process starts with those requirements which are poorly
understood

Needs for Prototyping:

Enables us to explore the problem space with the stakeholders.
As a requirements artifact to initially envision the system.
As a design artifact that enables us to explore the solution space of your system.
A vehicle for you to communicate the possible UI design(s) of your system.
A potential foundation from which to continue developing the system
Key points:

 Throw-away prototyping is used to understand the system requirements

In evolutionary prototyping, the system is developed by evolving an initial version to the
final version

EVOLUTIONARY PROTOTYPING:
Must be used for systems where the requirements specification cannot be developed in
advance
Based on techniques which allow rapid system iterations
Verification is impossible as there is no specification.
Validation means demonstrating the adequacy of the system
Evolutionary Prototyping Flow:
Develop abstract
specification

Buildprototype
system

Useprototype
system

N
Deliver
system

YES

System
adequate?

Evolutionary Prototyping Technologies:

Specification, design and implementation are inter-twined

The system is developed as a series of increments that are delivered to the

customer

Techniques for rapid system development are used such as CASE tools and 4GLs

User interfaces are usually developed using a GUI development toolkit

Evolutionary Prototyping Challenges

1) Management problems

Existing management processes assume a waterfall model of development

Specialist skills are required which may not be available in all development teams

2) Maintenance problems

Continual change tends to corrupt system structure so long-term maintenance is

expensive

3) Contractual problems
Advantages of evolutionary prototyping:
Accelerated delivery of the system

Rapid delivery and deployment are sometimes more important than functionality
or long-term software maintainability

User engagement with the system

Not only is the system more likely to meet user requirements, they are more likely
to commit to the use of the system

You are always looking for new ways to improve the system.
This model increases the chance of having the client satisfied with the working system.
The model can be used even when the requirements are not defined.
Quicker delivery of the system
Disadvantages of evolutionary prototyping:
This method can be used to avoid documenting the requirements of the system.
Management is required
Long term maintenance can be expensive
Uncertain design ideas
Information can be lost through so many improvement changes
Prototypes as Specifications:
Some parts of the requirements may be impossible to prototype

E.g., safety-critical functions

An implementation has no legal standing as a contract

Non-functional requirements cannot be adequately tested in a system prototype
Incremental Development:

System is developed and delivered in increments after establishing an overall

architecture
Requirements and specifications for each increment may be developed
Users may experiment with delivered increments while others are being developed

These serve as a form of prototype system

Intended to combine some of the advantages of prototyping

More manageable process

Better system structure

Evolutionary prototyping Phases:

Incremental Development Flow:

THROW-AWAY PROTOTYPING:
Used to reduce requirements risk

 The prototype is developed from an initial specification, delivered for experiment then
discarded
The throw-away prototype must NOT be considered as a final system

Some system characteristics may have been left out

There is no specification for long-term maintenance

The system will be poorly structured and difficult to maintain

Throw Away Prototype is developed from the initial requirements but is not used for the
final project.
Written specifications of the requirements
Some developers believe that this type is a waste of time because you dont use it.
Regardless if prototype is discarded or kept for production, you must use a easy to use
language.

Prototype delivery:
Developers may be pressurised to deliver a throw-away prototype as a final
system
This is not recommended

It may be impossible to tune the prototype to meet non-functional

requirements

The prototype is inevitably undocumented

The system structure will be degraded through changes made during

development

Normal organisational quality standards may not have been applied.

Advantages of throwaway prototyping:

Significantly reduce project risk

Has a short project timeline

Disadvantages of throwaway prototyping:

The prototype actually does nothing, its just presentational.

Only for a limited purpose

Starting became a thing of the past. Not getting used as much now.

RAPID PROTOTYPING TECHNIQUES:

Various techniques may be used for rapid development are as follows;
1. Dynamic high-level language development
2. Database programming
3. Component and application assembly
These techniques are often used together
Visual programming is an inherent part of most prototype development system
1.Dynamic High-level Languages:
Languages which include powerful data management facilities
Need a large run-time support system. Not normally used for large system development
Some languages offer excellent UI development facilities
Some languages have an integrated support environment whose facilities may be used in
the prototype
2. Database Programming Languages:
Domain specific languages for business systems based around a database management
system
Normally include a database query language, a screen generator, a report generator and a
spreadsheet.
May be integrated with a CASE toolset
The language + environment is sometimes known as a fourth-generation language (4GL)

 Cost-effective for small to medium sized business system

Interface
generator

Spreadsheet

DB
programming
language

Report
generator
Databasemanagement system
Fourthgener ationlanguage

3. Component and application assembly:

Prototypes can be created quickly from a set of reusable components plus some
mechanism to glue these component together
The composition mechanism must include control facilities and a mechanism for
component communication
The system specification must take into account the availability and functionality of
existing components
Compound documents:
For some applications, a prototype can be created by developing a compound document
This is a document with active elements (such as a spreadsheet) that allow user
computations
Each active element has an associated application which is invoked when that element is
selected
The document itself is the integrator for the different applications
Visual programming:
Scripting languages such as Visual Basic support visual programming

the prototype is developed by creating a user interface from standard items

and associating components with these items

A large library of components exists to support this type of development

These may be tailored to suit the specific application requirements

Visual programming with reuse:

Hypertext
displaycomponent

Datecomponent

File

Edit

Views

Layout

Options

12thJanuary2000
Rangechecking
script

Help
General
Index

3.876
Userprompt
component+
s cript

Drawcanvas
component

Treedisplay
component

Problems with visual development:

Difficult to coordinate team-based development
No explicit system architecture
Complex dependencies between parts of the program can cause maintainability problems

User interface prototyping:

It is impossible to pre-specify the look and feel of a user interface in an effective way
UI development consumes an increasing part of overall system development costs
User interface generators may be used to draw the interface and simulate its
functionality with components associated with interface entities
Web interfaces may be prototyped using a web site editor
Mindset:
Prototyping is critical system parts that cannot be effectively pre-specified
Rapid prototyping focus on partial functionality
Prototyping techniques include the use of tools, very high-level languages and database
programming
Users must be involved in prototype evaluation

Growing from Prototype to Model: