Transcript No Slide Title

Structured requirements - the key to project success
Quality Systems & Software
•
UK Developer of DOORS software - developed in Scotland
•
Market Leader in Requirements Management Solutions
(Standish Group)
•
Over 10,000 licenses serving 40,000 users in over 700
companies world-wide
•
Offices in UK, USA(8), Germany, France, Scandinavia,
world-wide distributor network.
•
Tools, training and consultancy focused around
requirements, systems engineering and information
management
Dr. Richard Stevens, Quality Systems & Software
Northbrook House, Oxford Science Park, Oxford OX4 4GA
Tel: 01865 784285 Fax: 01865 784286 www.qssinc.com
© QSS Ltd.
All rights
reserved
Why projects fail
Sources: Standish Group
& Scientific American.
1: Incomplete requirements
2: Lack of user involvement
3: Lack of resources
4: Unrealistic expectations
5: Lack of executive support
6: Changing reqs/specs
7: Lack of planning
8: Didn’t need it any longer
Low success rate
16% successful
31% partial
53% failed
Planning is unrealistic
- therefore it doesn’t exist
Average cost over-run 89%
Average time over-run 122%
© QSS In c.
All r ig h t s
r e se r v e d
13.1%
12.4%
10.6%
9.9%
9.3%
8.7%
8.1%
7.5%
Serious money
$81bn cost of failed
projects
$59bn of over-runs
n143
Typical requirements problems
design,
not reqs
Mixing design into the requirements
user not
systems
Confusing user and system requirements
no dates or
schedules
why do
it?
who should
do it?
what do
we test?
what do
they want?
All r ig h t s
r e se r v e d
Mixing development and planning information into
the product requirements
Lack of a systems process
Lack of responsibility for implementing a requirement
Verification and test are detached from requirements
(what are you testing against?)
Customer too passive or too intrusive
who wrote
this?
Lack of structure within and across documents repetition, missing requirements,
Configuration management problems
what is
it?
Ambiguity, unverifiability, multiple requirements
what is
it?
Commitment to a set of requirements which is
inherently impractical
difficult to
understand
© QSS In c.
Problems typically do not emerge until
the integration stage.. and again on delivery
r468
© QSS Inc.
The systems engineering lifecycle
User
requirements
All rights
reserved
Review
Requirements from
system level above
System
requirements
Review
Change
Architectural
design
Review
Change
Component
developments
Test
Change
Integration
& verification
System
test
Design
Test Deliverables
Change
Acceptance &
installation
Change
r54
Acceptance
tests
Operations &
maintenance
Review
Retirement
User requirements
System requirements
In user language about
the user domain
Time
Best organized as an
operational scenario
Must be requested by
a user type
End
result
“I want.... to be in this state”
Results that operational
users get from the system
What the user gets
Owned by users or their
representatives (e.g. marketing)
In developer language
applying requirements on
the solution
Organized by similarity of
functions or by system
behavior
An abstract representation
of the solution
Functional
hierarchy
“The system
shall do.... ”
What the system does
Owned by systems
engineers
© QS S Inc .
Differences between user and system requirements
r574
All rig hts
re s e rve d
Key concepts of systems requirements
n
n
o
o
i
i at
t
a
iz rm
n
o
a
f
g
n
Or of i
Fu
nc
tio
na
r162
lity
h
e
B
r
o
i
av
Information
relationships
& history
Functionality &
performance
System dynamics,
behavior &
asynchronicity
info
info
info
state
state
info
state
state
state
state
System
Parallelism,
redundancy
& topology
Site
Site
A
B
Site
C
Data &
control
flows
Factors for analysis
r199
k51
Constraints
© QSS In c.
All r igh t s
r e se r v ed
Concurrent component development
System level
User reqs
Acceptance
& installation Operations
Product management
Engineering management
System
reqs
Arch
design
System
reqs
Arch
design
Integration &
Engineering management verification
Sub-system 1
System
integration
& verification
Component build
Component build
Sub-system 2
System
reqs
Arch
design
Component build
Engineering management
Integration &
verification
Component build
Component build
Component build
Integration &
System Arch
reqs design Engineering management verification
Sub-system 3
Component build
Component build
Sub-system 4
System
reqs
Arch
design
Engineering management
Integration &
verification
Component build
Time
Component build
Component build
Component build
r142
© QSS In c.
SEATOL issues
All r ig h t s
r e se r v e d
n78
Organizational level
Process
standards
Definition of the Knowledge
business and management
competitive
environment for
decision-making
Re-use of development
components across
projects (e.g. software,
facilities, designs, tests)
Measurement and
improvement of overall
development
effectiveness
Definition and
implementation of
organization goals
Innovation, and
evolution into a
committed project
Project
D
Project
D
Project
D
Projects
Products
Preparation and
injection of novel
technology
Allocation of resources
between projects
Bid preparation &
tender evaluation
Interoperability issues
between products
(e.g. comms standards)
r663
Exploration and commitment
Lifecycle exploration
through stage-gates
© QSS Inc.
All rights
reserved
Effort
User
requirements
Stage-gate
Stage-gate
Progressive
commitment
User reqs Sys reqs Design ....
User
requirements
Stage-gate
System
requirements
User reqs Sys reqs Design ....
Stage-gate
on verification c compo
i
t
a
l
l
instalidation & validation onstru nent
ction
& va us
l
a
r
hitecitgun
c
reqesr system
r
a
reqs
des
User reqs Sys reqs Design ....
User
requirements
System
requirements
Architectural
design
0
1
Path of individual project
through the pipeline
2
Risk is acceptable
Overlapping
Innovatory
Reviewable independently
Low cost
Delivers information and decisions
3
4
Lowest acceptable risk
Interoperable
Delivers product
Reviewed comparatively
High cost
n132
© QSS In c.
Evaluating new project feasibility
Importance
Business feasibility 10
Minimum
value
All r igh t s r ese r v e d
Score Impact
8.2
1.8
Budget availability
Organizational fit
Development commitment
Support commitment
2
2
3
3
2.0
2.0
2.1
2.1
0.0
0.0
0.9
0.9
Technical feasibility
15
8.9
6.1
Pre-development quality
Development capability
Capability to build
Development quality & skills
6
4
3
2
1.2
4.0
2.1
1.6
4.8
0.0
0.9
0.4
8.4 16.6
Management feasibility 25
Realistic planning ability
Capability to keep to plan
Managerial capability
2.4
2.4
3.6
8
8
9
Market feasibility 50
Market attractiveness/value
Knowledge of user needs
Product competitiveness
Marketing capability & fit
Roll-out capability
Support capability
5.6
5.6
5.4
27.0 23.0
4.0
2.0
7.0
9.0
2.5
2.5
10
10
10
10
5
5
0
.2
.4
.6
r876
6.0
8.0
3.0
1.0
2.5
2.5
.8 1.0 52.5 47.5
Product
manager
R. Stevens
Stage 2
Start 25-Jan-98
End 25-Mar-98
Next deliverable
Full
prototype
Next stage costs
$68k
Estimated
cost to
completion
$6.3M
Finish
Sept- 98
Some DOORS customers
QSS
© QSS Inc.
Software
All rights
reserved
Consultancy
Process definition
r172
See Web site www.qssinc.com for weekly update
DERA
GTE
Mitre
Rover
Sikorsky
Pepsi
MoD
CNES
ECC
JASP update
Pratt & Whitney
Macdonalds
Swedish Gov (FMV) Loral
USAF
NASA
Tenneco Gas
Rolls-Royce
Kayser Trading
Tellabs
Rockwell
RMS
BIM
Boeing
GTE
Dresden Bank
Texas Instruments
Northrop B2
Zycad
Philips
UTC
USAF Transcom
Renault
Magnavox
Northrop F18
Hughes
GPT
Motorola
HamiltonStandard
Iridium
CERN
Unisys
BAe
Grumman
AT&T
Holmdel
Indian Hill
Whippany
Red Hills
Berkeley Heights etc.
General Dynamics
Pitney-Bowes
USA, UK, Australia
Freddy Mac
Nokia
DTG (BBC, ITV,
Channel 4)
Swedish Air
Force
Alcatel Portugal Belgium
NSA
Hughes
Danish Navy
Carrier
Xerox
ESA
Racal
Alcatel
Telstra
Bell & Howell
Westinghouse
Booz Allen
Nortel
TRW
Thorn Transit
John Hancock
British Telecom
Ford US & UK
EGT
Siemens
Chrysler
Alcatel Recherche
Dassault
SAIC
MCI
Madge
W Atkins
Bell Southern
Israel Aircraft Co
Racal
Marconi Canada
GEC Alsthrom
Thomson
Mentor
Eriksson
Matra Marconi
Lockheed-Martin
Thorn
Opel
Cayenne
Ideas Group
Alcatel
Finnish Army
Signal Computing
Batelle
Lazards
Otis
USAF CEENS
Telia
US West
CASE Corp
NEC
HewlettPackard
Siemens-Elema
US Army
US Navy
GEC
European Bank for
Reconstruction
Procurement
Executive
Californian Mve.
Sagem
FAA
Raven
Holmes-Tucker
General Motors
McDonnellDouglas
CSC
Tomahawk
update
France
DASA
Citicorp,
GEC-Marconi,
Charles Schwab,
BMW, JPL, Kodak,
Fidelity, exporian,
HP Medical etc
Pitney Bowes Consulting
u
Product Architecture Retrieval
Information System (PARIS)
– PARIS Objective
»
–
Re-use across
multiple systems in
a $3bn organization
Facilitate re-use of product and component
specifications and design
PARIS Features
»
»
»
»
Captures product and component
specifications, architecture and attributes
Provides product and component views and
queries
Supports attribute-based queries
Permits functional comparison of multiple
products
r675
Summary
Requirements are the foundation of all project and
organizational effort
Research shows very clearly that requirements are
the key factor for project success or failure. In
particular, technical issues are much less important
Requirements are currently handled so badly that
improvement is relatively easy
The tools and techniques are relatively straightforward
to improve with support - cultural change takes longer
The same same principles can be applied to make the
organization more effective about the level of the
project e.g. for re-use, technology management,
multi-project management.
Time to market with the right product
n210