requirements analysis and collection

8/14/2019 Requirements Analysis and Collection

1/32

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

Product requirementsCollect and analyze product demands

From the authors of:
http://search.barnesandnoble.com/Six-Sigma-for-the-Next-Millennium/Kim-H-Pries/e/9780873896566/?itm=1


2/32


Overview

What are requirements

Who are the stakeholders

Stakeholder management

How to gather requirements

Analyze requirements

Document requirements

Change Management

Verify requirements are met


3/32

Background

Trucks / automotive ($80K and up)

Used to make money

Numerous Electronic Control Units

Large variation in feature content and ECUs

(different applications)

High use / demand (130Kmi/year)

Extreme environmental exposure


4/32


What is a Requirement

A description of a feature or featuresexpected to provide a benefit

Benefit may not always be clear

The features the product must have to beaccepted by the customer

This is the scope of the product / project

The driving force behind the ROI for thecompany


5/32


Requirement types

Performance requirements

Design to requirements

Functional requirements

Derived requirements

Irrelevant requirements

Incorrect requirements

Redundant requirements


6/32


What is a good requirement

Cohesive

Complete

ConsistentCorrect

Observable

Feasible

Unambiguous

Required

Verifiable

Traceable


7/32


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


8/32

Know the stakeholders

Internal / external

Supplier / Customer

Direct / Indirect Real / False

Continuous /

Intermittent

Severe / Cursory

Correlated / Inverse

Consider using anadaptation of theResource AllocationMatrix to manage

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


9/32

Stakeholder Management

Negotiationstrategies

Communicationstrategies

Leverage strategies(Political strategies)

Participatorystrategies

Compensationstrategies

Knowledge

Gathering/Sharingstrategies

Ignore-based strategies

Removal strategies



10/32

Stakeholder Management


RemovalIgnore-based

Knowledge Gathering/Sharing

Compensation

Participatory

Leverage (Political)

Communication

Negotiation

Internal / External

Supplier / Customer

Direct / Indirect

Real / False

Continuous / Intermittent

Severe / Cursory


11/32

Stakeholder Allocation MatrixCom

ponent2SW

Componen

t2HW

ProjectM

anager

Componen

t1SW

Componen

t1HW

SystemSpec

Systemver

ificatioTools

Manufac

turing

Aftermarket

T

raining

Tech-Pubs Component2 SW RD

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 MBComponent1 In In In A A In In In Component1 - HW SA

Systems Spec WC

Hardware A In C C C In C In In In System verification MMSoftware A In C C C In C In In In Tools JG

Manufacturing BW

Hardware C In A C In C In In In Aftermarket SRSoftware 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 ATraining

Component2 A A R R R

Component1 A A R R RSystems A R R R

Accountable A

Participant P

Review Required RInput required I

Sign off required S

Informed In

Consulted C

Design Doc

Component2 release

Component1 release


12/32


Requirements sources

RequirementsRegulatory

N

oisecontrol

Technology

con

straints

Marketexpectations

R

equirements

elicitation

Ethn

ographic

observation


13/32


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


14/32


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


15/32


System modeling limits

All can not be known in the early stages

If the product is novel this lack of knowledge is evengreater risk


16/32

Possible modeling techniques

DiagramsUse Case, class, etc.

Data flow

Flow chart

Pseudocode

ITU Z.100 SDL

Z, B-method, VDM, and other formallanguages



17/32


Analyze Requirements

Non-Requirement

Requirement

Evaluation

Requirements

Documented

Requirements

Gathering


18/32


Analyze requirements

Competing / conflicting stakeholder inputs

Prioritize requirements

Match concepts to prioritized requirements


19/32


Requirements / Constraints

Complexity issues

Hierarchical problems (architecture)

Large modules vs small modules

Assigning development durations/staffing

Technical issues (language, compiler, etc.)


20/32


Concept Evaluation

Pugh analysis

Quality, Function,Deployment

Requirements andconstraints matrix

Pugh MS Office

Excel 97-2003

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


21/32


Document requirements

If broken down into multiple documents,need a document tree to manage it

Follow a standard format

Identify patterns if meaningful

Consistency


22/32


Document Requirement

Very specific language clearly written

Individually identified alpha-numericdesignator

REQ_SW_HMI_20

Can get complicated when requirement

meets multiple needs Disambiguate with disaggregation


23/32


Configuration Management

Requirements form basis of configurationmanagement

Requirements met in each Software package (SW release notes)

Hardware package (HW release notes)

Product configuration (CMP) Test configurations (test coverage)

Configuration audit


24/32


Requirements Management

Requirements

DocumentUpdated

AdditionalRequirement(scope)Identified

ChangeManagement

ExcludeRequirement


25/32


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 configurationmanagement

All change to receive cost/time quotations

Agreed upon by all parties


26/32


Change management points

Ability to flex with change can be a competitive edge

Product launch process should provide support andcontrols for change

Contingency plans for obvious potential change points

Product simulation can provide early testing of ideas


27/32


Verify requirements

Difficult if tracing back to potentially nebulouscustomer needs

At least a one-one correspondence with customer

specification

Derived requirements will break one-one


28/32


Requirements and Verification

Basis for verification tests

Compliance testing used to verifyrequirements met

More sophisticated approaches needed tovalidate Testing to customer needs

Testing to failure and, maybe, destruction


29/32


Traceability

Quality Function Deployment supportstraceability 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 butgive no idea of optimality


30/32


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


31/32


Feedback

Compare requirement to delivery

Use initial requirements list to control scopecreep

Consider expressing requirements in aformal language (VDM, Z, structured

English)


32/32


Additional Information

Jon Quig ley:jonmquig [email protected] om

Kim Pries: [email protected]
mailto:[email protected]:[email protected]:[email protected]:[email protected]

requirements analysis and collection

Documents