Product requirements

Collect and analyze product demands

From the authors of:

(c) Kim H. Pries & Jon M. Quigley 1

Overview
ƒ What are requirements
ƒ Who are the stakeholders
ƒ Stakeholder management
ƒ How to gather requirements
ƒ Analyze requirements
ƒ Document requirements
ƒ Change Management
ƒ Verify requirements are met
(c) Kim H. Pries & Jon M. Quigley 2
Background
ƒ Trucks / automotive ($80K and up)
ƒ Used to make money
ƒ Numerous Electronic Control Units
ƒ Large variation in feature content and ECU’s
(different applications)
ƒ High use / demand (130Kmi/year)
ƒ Extreme environmental exposure
What is a Requirement
ƒ A description of a feature or features
expected to provide a benefit
ƒ Benefit may not always be clear
ƒ The features the product must have to be
accepted by the customer
ƒ This is the scope of the product / project
ƒ The driving force behind the ROI for the
company

(c) Kim H. Pries & Jon M. Quigley 4

Requirement types
ƒ Performance requirements
ƒ Design to requirements
ƒ Functional requirements
ƒ Derived requirements
ƒ Irrelevant requirements
ƒ Incorrect requirements
ƒ Redundant requirements
(c) Kim H. Pries & Jon M. Quigley 5
What is a good requirement
ƒ Cohesive ƒ Feasible
ƒ Complete ƒ Unambiguous
ƒ Consistent ƒ Required
ƒ Correct ƒ Verifiable
ƒ Observable
ƒ Traceable

(c) Kim H. Pries & Jon M. Quigley 6

How to gather requirements
ƒ Direct customer interviews
ƒ Regulations or standards
ƒ Competitive assessments
ƒ Sell a great idea
ƒ Functional decomposition
ƒ Organized and hierarchical
ƒ May serve as a requirement ‘poka-yoke’

(c) Kim H. Pries & Jon M. Quigley 7

Know the stakeholders
ƒ Internal / external
ƒ Supplier / Customer
ƒ Direct / Indirect
ƒ Consider using an
adaptation of the
Resource Allocation
Matrix to manage

ƒ Real / False

ƒ Continuous /
Intermittent

ƒ Severe / Cursory

ƒ Correlated / Inverse
(c) Kim H. Pries & Jon M. Quigley
Stakeholder Management
ƒ Negotiation ƒ Compensation
strategies strategies
ƒ Communication ƒ Knowledge
strategies Gathering/Sharing
ƒ Leverage strategies strategies
(Political strategies)
ƒ Ignore-based strategies
ƒ Participatory
strategies ƒ Removal strategies

(c) Kim H. Pries & Jon M. Quigley

 Stakeholder Management
Negotiation
Real / False Ignore-based
Removal
Continuous / Intermittent
Knowledge Gathering/Sharing
Direct / Indirect
Internal / External Leverage (Political)
Communicatio
Supplier / Customer n
Participatory
Severe / Cursory Compensation

(c) Kim H. Pries & Jon M. Quigley

Stakeholder Allocation Matrix

Sy
C

C
C

C
Pr
om

om

st
om

om

M
oj

em
Sy

an
po

ec

po
po

po

Te
st

uf

f te
tM

ve
ne

ne
ne

ne

em

ac

Tr

ch
rm
rif
nt

nt
nt

n
an

ai
tu
t1

-P
To
ic
2

1
2

ar
Sp

ni
ag

rin

ub
at
H

H
SW

SW

ol

ke
Component2 SW RD

ng
ec
W

er

io

g
s

s
t
n
Design Doc Component2 HW SR
Component2 A A In In In In In In Project Manager AC
Systems In In In In In A In In Component1 - SW MB
Component1 In In In A A In In In Component1 - HW SA
Component2 release Systems Spec WC
Hardware A In C C C In C In In In System verification MM
Software A In C C C In C In In In Tools JG
Component1 release Manufacturing BW
Hardware C In A C In C In In In Aftermarket SR
Software C In A C In C In In In Training BB
Testing Tech-Pubs LO
Component2 A A In In In
Component1 In In A A In
Systems In In In In A
Training
Component2 A A R R R
Component1 A A R R R
Systems A R R R

Accountable A
Participant P
Review Required R
Input required I
Sign off required S
Informed In
Consulted C
Requirements sources

Ethnographic
observation
Technology
constraints

Regulatory
Requirements Market
expectations
‘Noise’ control

Requirements
elicitation

(c) Kim H. Pries & Jon M. Quigley 12

Gathering Requirements
ƒ Stakeholder and Customer reviews

ƒ Focus groups

ƒ Field investigations

ƒ Simulation

ƒ Product mock ups (computer based instead of

embedded)

ƒ Rapid prototyping

ƒ Can document with a stakeholder matrix

(c) Kim H. Pries & Jon M. Quigley 13
System modeling
ƒ Aids creation of performance specifications

ƒ Allows for high-level simulations

ƒ Generate a working virtual mockup

ƒ Some of it can be done in spreadsheet

ƒ Provides holistic assessment of product performance

and subsystem interactions

(c) Kim H. Pries & Jon M. Quigley 14

System modeling limits
ƒ All can not be known in the early stages

ƒ If the product is novel this lack of knowledge is even

greater risk

(c) Kim H. Pries & Jon M. Quigley 15

Possible modeling techniques

ƒDiagrams
ƒ Use Case, class, etc.
ƒ Data flow
ƒ Flow chart

ƒPseudocode
ƒ ITU Z.100 SDL
ƒ Z, B-method, VDM, and other formal
languages

(c) Kim H. Pries & Jon M. Quigley 16

 Analyze Requirements
Requirements
Gathering

Requirement
Evaluation

Requirements
Non-Requirement
Documented

(c) Kim H. Pries & Jon M. Quigley 17

Analyze requirements
ƒ Competing / conflicting stakeholder inputs

ƒ Prioritize requirements

ƒ Match concepts to prioritized requirements

(c) Kim H. Pries & Jon M. Quigley 18

Requirements / Constraints
ƒ Complexity issues

ƒ Hierarchical problems (architecture)

ƒ Large modules vs small modules

ƒ Assigning development durations/staffing

ƒ Technical issues (language, compiler, etc.)

(c) Kim H. Pries & Jon M. Quigley 19

Concept Evaluation
ƒ Pugh analysis
ƒ Quality, Function,
Deployment
ƒ Requirements and Pugh MS Office
Excel 97-2003
constraints matrix

http://www.ciri.org.nz/downloads/Requirements%20and%20Constraints.pdf

(c) Kim H. Pries & Jon M. Quigley 20

Document requirements
ƒ If broken down into multiple documents,
need a document tree to manage it
ƒ Follow a standard format
ƒ Identify patterns if meaningful
ƒ Consistency

(c) Kim H. Pries & Jon M. Quigley 21

Document Requirement
ƒ Very specific language – clearly written
ƒ Individually identified – alpha-numeric
designator
ƒ REQ_SW_HMI_20

ƒ Can get complicated when requirement

meets multiple needs
ƒ Disambiguate with disaggregation

(c) Kim H. Pries & Jon M. Quigley 22

Configuration Management
ƒ Requirements form basis of configuration
management
ƒ Requirements met in each
ƒ Software package (SW release notes)
ƒ Hardware package (HW release notes)

ƒ Product configuration (CMP)

ƒ Test configurations (test coverage)
ƒ Configuration audit
(c) Kim H. Pries & Jon M. Quigley 23
Requirements Management
Change
Additional
Requirement Management
(scope)
Identified

Exclude Requirements
Requirement Document
Updated

(c) Kim H. Pries & Jon M. Quigley 24

Change Management
ƒ Change happens!
ƒ Scope impact

ƒ Well defined at project start

ƒ Process
ƒ Areas of responsibility (authority)
ƒ Create formal configuration management plan
ƒ Requirements themselves should fall under configuration
management
ƒ All change to receive cost/time quotations

ƒ Agreed upon by all parties

(c) Kim H. Pries & Jon M. Quigley 25
Change management points
ƒ Ability to flex with change can be a competitive edge

ƒ Product launch process should provide support and

controls for change

ƒ Contingency plans for obvious potential change points

ƒ Product simulation can provide early testing of ideas

(c) Kim H. Pries & Jon M. Quigley 26

Verify requirements
ƒ Difficult if tracing back to potentially nebulous
customer ‘needs’

ƒ At least a one-one correspondence with customer

specification

ƒ Derived requirements will break one-one

(c) Kim H. Pries & Jon M. Quigley 27

Requirements and Verification
ƒ Basis for verification tests
ƒ Compliance testing used to verify
requirements met
ƒ More sophisticated approaches needed to
validate
ƒ Testing to customer needs
ƒ Testing to failure and, maybe, destruction

(c) Kim H. Pries & Jon M. Quigley 28

Traceability
ƒ Quality Function Deployment supports
traceability at a high level
ƒ Can also build traceability matrices
ƒ Surest way to confirm requirement are met
ƒ A solution for each requirement
ƒ Complete
ƒ Traceability matrix indicates requirements met but
give no idea of optimality

(c) Kim H. Pries & Jon M. Quigley 29

Requirement Verification
ƒ Test cases for each individual Requirement
ƒ TC_REQ_SW_HMI_20:1
ƒ TC_REQ_SW_HMI_20:2

ƒ Confirms product delivered meets the

customer demands

(c) Kim H. Pries & Jon M. Quigley 30

Feedback
ƒ Compare requirement to delivery
ƒ Use initial requirements list to control scope
creep
ƒ Consider expressing requirements in a
formal language (VDM, Z, structured
English)

(c) Kim H. Pries & Jon M. Quigley 31

Additional Information
ƒ Jon Quigley: jonmquigley@aol.com

ƒ Kim Pries: khpries@gmail.com

(c) Kim H. Pries & Jon M. Quigley 32