Transcript No Slide Title

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 child’s 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 aren’t 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 don’t
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 product’s 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
product’s appearance
(11) Usability Requirements – the product’s 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 product’s 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 / Vmodel / Spiral / etc.), Technical / Peer
Reviews have an excellent ROI on the
Development Process
 Use Fagan Inspection / Fagan Defect-Free
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
requirement’s 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=6
335&Function=DETAILBROWSE&ObjectType=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 !!!