Better Product Requirements

Specifications
Tathagat Varma
MindTek, 11-Mar-2004

Contents
Big Picture of The Problem
Common Problems with Requirements
Volere
My Experiences with Volere
References
Q&A

Disclaimer
This presentation is based on

General good practices that I have seen, AND

VOLERE Requirements Specification
Template. While there might be better
methods than Volere, I have found this to be
best in simplicity + effectiveness

Volere Requirements Specification

process is a complete process, and the

template is just one part of it

Dilbert on Requirements

Making a Swing is a childs play ?

Software Horror Stories

The British destroyer H.M.S. Sheffield was sunk in the Falkland

Islands war. According to one report, the ship's radar warning
systems were programmed to identify the Exocet missile as
"friendly" because the British arsenal includes the Exocet's homing
device and allowed the missile to reach its target, namely the
Sheffield. From "The development of software for ballistic-missile
defense," by H. Lin, Scientific American, vol. 253, no. 6 (Dec. 1985),
p. 48
An Iraqi Scud missile hit Dhahran barracks, leaving 28 dead and 98
wounded. The incoming missile was not detected by the Patriot
defenses, whose clock had drifted .36 seconds during the 4-day
continuous siege, the error increasing with elapsed time since the
system was turned on. This software flaw prevented real-time
tracking. The specifications called for aircraft speeds, not Mach 6
missiles, for 14-hour continuous performance, not 100. Patched
software arrived via air one day later. From ACM SIGSOFT
Software Engineering Notes, vol 16, #3. See Story More More More

More Software Horror

The manned space capsule Gemini V missed its landing

point by 100 miles because its guidance program
ignored the motion of the earth around the sun. From
"The development of software for ballistic-missile
defense," by H. Lin, Scientific American, vol. 253, no. 6
(Dec. 1985), p. 49.
During the maiden flight of the Discovery space shuttle,
30 seconds of (non-critical) real-time telemetry data was
lost due to a problem in the requirement stage of the
software development process. Story
The U.S. Social Security Administration systems could
not handle non-Anglo names, affecting $234 billion for
100,000 people, some going back to 1937. From Internet
Risks Forum NewsGroup (RISKS) , vol 18, issue 80

The Problem

Buggy software drags down US profits by about

$60 billion a year. (Forrester)
In the US alone, up to 60% of software
developers are involved in fixing errors (~1998)
A recent task force headed up by Howard Rubin
and including Capers Jones found that fewer
than 6% of organizations have clearly defined
software management processes in place.
Would any other industry get away with treating
quality in this way?

The Problem

Doing it wrong the first time is industry's biggest single

quality expense. The famous late Quality Guru, Philip
Crosby estimates cost of bringing goods back into line
with customer requirements can range as high as 40% of
sales for many firms, with the industry average running
close to 25%. In effect, firms are spending a quarter of
their income patching up their own mistakes.
A general survey of some 300 projects across car
manufacturing, telecoms and aerospace industries
indicated that the main cause of failures were
management and requirements issues. Five of the top
eight issues were related to poor handling of
requirements.

The Problem
For software projects, according to the

Standish Group, 31% of software projects

are cancelled before the product is
delivered to the customers, while 53% cost
189% or more of their original budgets. 4060% of the software defects and failures
being attributed to poor requirements , thus
reflecting extent of the problem and the
need to identify, communicate and manage
IS project requirements.

The Problem

(QAI, USA) Failure to properly identify and

manage requirements is the single most
consistent cause of project failure, regardless of
project size and organization. The requirements
analysis process is defect prone for a variety of
reasons. Post-implementation reviews of most
information systems projects typically show that
60-75% of all defects encountered during a
project, and embedded in the finished systems
products, are defects in requirements.

Hidden Factories
Unacknowledged rework due to defects is

referred to as a hidden factory.

In software development, hidden factories
often make up for more than 50% of the
effort of producing software. The
discovery and elimination of hidden
factories is a gradual process, beginning
with the most obvious rework and
continuing towards the less obvious.

COPR (Cost of Poor Reqs.)

Common Problems with

Requirements

Lack of User Involvement

Lack of Training
Not identifying Software Usability Attributes
Making bad assumptions
Writing implementation (HOW) instead of requirements
(WHAT)
Describing operations instead of writing requirements
Using incorrect terms
Using incorrect sentence structure or bad grammar
Missing requirements
Over-specifying

Lack of Training

Because the quality of any product depends on the

quality of the raw materials fed into it, poor requirements
cannot lead to excellent software. Sadly, few software
developers have been educated about how to elicit,
analyze, document, and verify the quality of
requirements. There arent many examples of good
requirements available to learn from, partly because few
projects have good ones to share, and partly because
few companies are willing to place their product
specifications in the public domain. ..Karl Wiegers

Missing Requirements
Using standards like Mil-Std-490 or IEEE P1233 can help ensure you dont miss out
most of the requirements.
At the minimum, include the following:

Functional
Reliability
Performance
Maintainability
Interface
Operability
Environment
Safety
Facility
Regulatory
Transportation
Security
Deployment
Privacy
Training
Design constraints
Personnel

Using Incorrect Terms

In a specification, there are terms to be avoided and

terms that must be used in a very specific manner.
Authors need to understand the use of shall, will, and
should:

Requirements use shall.

Statements of fact use will.
Goals use should.

All shall statement (requirements) must be verifiable,

otherwise, compliance cannot be demonstrated.
Terms such as are, is, was, and must do not belong in a
requirement. They may be used in a descriptive section
or in the lead-in to a requirements section of the
specification.

Using Incorrect Terms

There are a number of terms to be avoided in writing requirements, because

they confuse the issue and can cost you money, e.g.

The word support is often used incorrectly in requirements. Support is a

proper term if you want a structure to support 50 pounds weight. It is
incorrect if you are stating that the system will support certain activities.

Support
But not limited to
Etc.
And/Or

WRONG: The system shall support the training coordinator in defining training
scenarios.
RIGHT: The system shall provide input screens for defining training scenarios.
The system shall provide automated training scenario processes.

The terms but not limited to, and Etc. are put in place because the person
writing the requirements suspects that more may be needed than is
currently listed. Using these terms will not accomplish what the author wants
and can backfire.

Ambiguous Terms

A major cause of unverifiable requirements is the use of

ambiguous terms. The terms are ambiguous because
they are subjective -- they mean something different to
everyone who reads them. This can be avoided by giving
people words to avoid.
Specific words that should be avoided because they are
vague and general are "flexible", "fault tolerant", "high
fidelity", "adaptable", "rapid or fast", "adequate", "user
friendly", "support", "maximize" and "minimize" ("The
system design shall be flexible and fault tolerant" is an
example). Other words that should be avoided are
"and/or", "etc." and "may".
Only one requirement per sentence !

So, what is the solution ?

The focus must clearly be put on the
customer and the objective must not
simply be to satisfy, but to delight.
This can only be accomplished by
providing the right system and
executing the pertinent project(s) in
the right way.
The provision of the right system is
translated into providing a system to
the customer that reflects both stated
and implied requirements.
Doing things the right way can be
achieved by validating and verifying
requirements, for both external and
internal customers, during the entire
project life cycle.

Requirements Definition

Translate customer needs into a clear, detailed

specification of what the system must do. The
functions that the system must perform will be defined
down to the subsystem (e.g., account administration).
Focuses on understanding the business process flow,
the business requirements, and the prioritization of
requirements
Additionally, during this phase, the technical
infrastructure issues are reviewed as well to
understand the environment requirements where the
product will be operational.

Volere

Volere (Voh-lair-ray) the Italian verb to want, or

to wish
Developed by James and Suzanne Robertsons
of Atlantic System Guild
Available at http://www.volere.co.uk or
http://www.systemsguild.com/
Volere Requirements Process is described in
Mastering the Requirements Process by
Suzanne and James Robertson, AddisonWesley, London, 1999. ISBN is 0-201-36046-2

Volere
Volere is the umbrella that covers the

collection of requirements resources,

templates, process, consulting and
training
This presentation only focuses on Volere
Requirements Specification Template
(http://www.volere.co.uk/template.htm)

The Volere Process

Why Volere ?

It has changed the way I look at projects, and has

helped me to be 10 times more efficient and successful with
gathering customer requirements, and conveying them to
my development team. The framework has worked
excellently, and we are establishing our own template which
is based on your teachings." C. McKinnon - Program
Manager, Microsoft Corporation
We have only had to spend 53% of those dollars. Why?
A much thorough job of requirements development was
performed, resulting in the employment of less
programming contractors. Without this concentration upon
requirements, we would have consumed budget dollars
employing additional programmers for the "normal" rework.
John Capron, Worldwide Systems Technology Manager,
IBM Enterprise Systems Group,Poughkeepsie, N.Y

Some users of Volere

American Express
Aventis Pharmaceuticals
BankOne
Cesky Mobil
Commonwealth Bank
Cordis Europa NV
Emirates Airlines
ETAS GmbH
Federal Express
GEC Marconi
Guinness UDV
H&R Block
Harvard Online
Hewlett-Packard
IBM
Insurance Australia Group
International Atomic Energy Authority
Jaguar
KMD
Lloyds TSB
Micron Computer
Ministry of Defence

MobiFon
National University of Ireland
Nationals Air Traffic Service
Nordstrom Nordstrom
Optus
Patni Computer Systems Ltd. (India)
PixelPark
Plymouth City Council
PriceWaterhouseCoopers
Rohde & Schwarz
SBEI Finland
sd&m
Servcon South Africa
Siemens
Spacetec
Swinburne University
Telecom Italia
Telemedicine,
Victoria Legal Aid
Wachovia
Woolworths

Volere Requirements Specification

Template
There are 5 major sections

Project Drivers
Project Constraints
Functional Requirements
Non-functional Requirements
Project Issues

Each Section has some sub-sections /

chapters, total 27

Project Drivers
Project drivers

are the business- related

forces. For example the purpose of the
product is a project driver, as are all of the
stakeholders each for different reasons.

(01) Purpose of the Product

(02) Client, Customer and other Stakeholders
(03) Users of the Product

Project Constraints

Project constraints identify how the eventual

product must fit into the world. For example the
product might have to interface with or use some
existing hardware, software or business practice,
or it might have to fit within a defined budget or
be ready by a defined date.

(04) Mandated Constraints

(05) Naming Conventions and Definitions
(06) Relevant Facts and Assumptions

Functional Requirements

Specifications of the products functionality

Actions the product must take check,
calculate, record, retrieve
Derived from the fundamental purpose of the
product
Not a quality for example, fast is a quality,
and is therefore a non-functional requirement

(07) The Scope of Work

(08) The Scope of the Product
(09) Functional and Data Requirements

Non-Functional Requirements

Behavioral properties that the specified

functions must have, such as performance,
usability, etc.
Non-functional requirements can be assigned
a specific measurement.

(10) Look and feel Requirements the spirit of the

products appearance
(11) Usability Requirements the products ease of use,
ad any special usability considerations
(12) Performance Requirements ho fast, how safe, how
many, how accurate the functionality be

contd

(13) Operational Requirements the operating

environment of the product, and what considerations must
be made for this environment
(14) Maintainability and Portability Requirements
expected changes, and the time allowed to make them
(15) Security Requirements the security and
confidentiality of the product
(16) Cultural and Political Requirements special
requirements that come about because of the people
involved in the products development and operation
(17) Legal Requirements what laws and standards apply
to the product

Project Issues

Project issues define the conditions under which the

project will be done. We include these in the requirements
specification to present a coherent picture of all the factors
that contribute to the success or failure of the project.

(18) Open Issues

(19) Off-the-shelf Solutions
(20) New Problems
(21) Tasks
(22) Cut-Over
(23) Risks
(24) Costs
(25) User Documentation
(26) Waiting Room
(27) Ideas for Solutions

Capturing using Requirements Shell Card /

Snow Card / Atomic Requirement Template

Fit Criterion

An objective measure that will enable testing to

determine if the goal has been met by the
product
Some guideline for making goals measurable
are:

Specify each adverb and adjective so that everyone

on the project understands the same meaning.
Replace pronouns with the names of specific people
or organizations.
Ensure that the meaning of every noun is defined in
one place in the specification

Fit Criterion: Example

We want to give immediate and complete response to customers

ordering our goods over the telephone.
We - Employees of XYZ Corporation
want to give
immediate - during the course of a telephone call
and
complete - product availability and price
response - verbal information
to
customers - anyone who enquires about our products
our - supplied by XYZ Corporation
goods - products that we manufacture
over the telephone

Requirements Description

A good requirement states something that is necessary, verifiable, and

attainable

Need. If there is a doubt about the necessity of a requirement, then ask: What is
the worst thing that could happen if this requirement were not included? If you do
not find an answer of any consequence, then you probably do not need the
requirement (i.e., it might just be a gold-plating)
Verification. As you write a requirement, determine how you will verify it.
Determine the criteria for acceptance. This step will help insure that the
requirement is verifiable.
Attainable. To be attainable, the requirement must be technically feasible and fit
within budget, schedule, and other constraints. If you are uncertain about
whether a requirement is technically feasible, then you will need to conduct the
research or studies to determine its feasibility. Even is a requirement is
technically feasible, it may not be attainable due to budget, schedule, or other,
e.g., weight, constraints. There is no point in writing a requirement for something
you cannot afford -- be reasonable.
Clarity. Each requirement should express a single thought, be concise, and
simple. It is important that the requirement not be misunderstood -- it must be
unambiguous. Simple sentences will most often suffice for a good requirement.

Req. Desc. contd

NASA has done the most pioneering work

in this area. They deploy an Automated

Requirement Measurement (ARM) Tool to
assess the quality (not the correctness) of
a requirements specification document.
http://satc.gsfc.nasa.gov/tools/arm/

Reviewing Requirements
Irrespective of the SDLC (Waterfall / V-

model / Spiral / etc.), Technical / Peer

Reviews have an excellent ROI on the
Development Process
Use Fagan Inspection / Fagan DefectFree Process, Gilb Inspection, etc.
Involve Dev, QA, Stakeholders, etc.
Use Metrics to exit the review

Testing Requirements

Start testing requirements as soon as you start

writing them.
First test is to determine if you can quantify the
requirement by specifying its fit criterion. This fit
criterion is an objective measure of the
requirements meaning; it is the criterion for
evaluating whether or not a given solution fits
the requirement. If a fit criterion cannot be
adequately specified, then the requirement is
ambiguous, or ill understood. If there is no fit
criterion, then there is no way of knowing if a
solution matches the requirement.

My Experiences with Volere

I used Volere template to prepare PRD for Gigabit-Switch Router

1 Indian and 11 Chinese engineers (who had never earlier written in
English !) completed the 280+ page PRD in little over 15 days.
We identified around 1100+ requirements in the PRD
We wrote over 700,000 LOC of C code by 13 parallel teams (out of
which 2 were outsourced)
Development delayed by 2 months (dev team had 120+ engineers).
We used our processes that were CMM Level 5 processes
We got around 50+ Change Request on the product. The RSI
(Requirements Stability Index) was over 90%
Within 4 months of starting the integration, we were having less than
some 150 defects (in the total code base of around 2M LOC)
This was by far the most successful project of this size (>5M US$) in
the company

References

http://www.processimpact.com/articles/qualreqs.html
http://www.stickyminds.com/sitewide.asp?
ObjectId=6335&Function=DETAILBROWSE&ObjectT
ype=COL
http://www.spmn.com/lessons.html#four
http://www.odegard.com/enews/aug2003/dcopq.htm
http://www.stevemcconnell.com/articles/art04.htm
http://www.artima.com/weblogs/viewpost.jsp?
thread=5446

Any questions ?

Thank you !!!