Agenda for understand-req activity

2. Requirements 1

Agenda for understand-req activity1. Objective2. Identifying the customer3. Learning what the customer wants4. Tools5. Validating customer requirements6. Writing requirements7. Homework

2. Requirements 2

1. ObjectiveUnderstand-requirements activityUnderstand-requirements tasksCompletion criteriaPseudo-completion criteriaUnderstanding-requirements flowOther requirements concepts

1. Objective

2. Requirements 3

Understand-requirements activity

Reaches agreement with the customer on the statement of work, specifications, and interfaces that constrain product development

1. Objective

2. Requirements 4

Understand-requirements tasks

Assist customer in developing

product requirements and

interfaces

initial contract, spec, & I/Fs

final contract,

spec, & I/Fs

1. Objective

Productrequirementsreview (RR)

2. Requirements 5

Completion criteriaComplete when the customer and the

contractor agree on the statement of work, specification, and interfaces that constrain product development

1. Objective

2. Requirements 6

Pseudo-completion criteria

Product specification and external interfaces complete

Requirements review (RR) complete

1. Objective

2. Requirements 7

Understanding-requirements flow

Identifying the

customer

Learning what the customer

wants

Validating customer

requirements

Writing requirements

Review requirements

Understanding requirements identifies the customer & flows through to managing customer requirements

Managing requirements

1. Objective

2. Requirements 8

Other requirements concepts (1 of 2)

1. Understand requirements vs requirements management The understand-requirements activity is

not the same as requirements management• The understand-requirements focuses on

identifying who the customers are and what they want.

• Requirements management focuses on generating and maintaining quality requirements of all types regardless of what activity generates them

1. Objective

2. Requirements 9

Other requirements concepts (2 of 2

Understand requirements vs requirements analysis Requirements analysis is approximately

the same as understanding requirements

• Understand requirements does not include designing although it may use the results of design

• Definition of requirements is a little looser and sometimes includes high-level definition of design

1. Objective

2. Requirements 10

2. Identifying the customer

CustomerDesign contextDesign vs requirementsPseudo customers


2. Requirements 11

Customer

Customers for the product The person who’s paying for the product;

e.g., contracting agency or product engineering for the next higher product.

Users of the product Pseudo customers Note that there may be more than one of

each type of customer for each product


2. Requirements 12

Design context

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Level N+2 Spec 1

Level N+2 Spec 2

Level N+2 Spec P

Level N+1Design 2

Level N+1Design 1

Level N+1Design M

Design occurs at each level and produces lower specsDesign occurs at each level and produces lower specs.2. Identifying the customer

2. Requirements 13

Design vs requirements

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Design at level N becomes requirements at level N+1Design at level N becomes requirements at level N+1

Requirements as seen by level N+1

Design as seen by level N


2. Requirements 14

Pseudo customers (1 of 2)

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

In addition to higher-level requirements,pseudo customers guide design

In addition to higher-level requirements,pseudo customers guide design

Pseudo customers


2. Requirements 15

Pseudo customers (2 of 2)

Other stakeholders2. Identifying the customer

EnterpriseProduct lineRe-usabilityPotential customers

Development process

DesignBuildTestSupportMaintenance

Other customers

Example pseudo customers

2. Requirements 16

3. Learning what customers want

What the customers wantEliciting wants from the customers Single point of contact for agreementReaching agreement

3. Learning what the customer wants

2. Requirements 17

What the customers want (1 of 3)

Customer wants

Customer problem

Customer preferences

Economics

OperationMaintenance

Upgrade

Field test

Validation

Training

Support

Disposal

ProductionPolitics

Schedule

Wants flow from problem, environment, and life cycleWants flow from problem, environment, and life cycle

2. Requirements 18

What the customer wants (2 of 3)IEEE P1220 tasks

1. Customer expectations 2. Project and enterprise constraints 3. External constraints 4. Operational scenarios 5. Measure of effectiveness (MOEs) 6. System boundaries 7. Interfaces 8. Utilization environments

15 tasks from IEEE P 122015 tasks from IEEE P 1220

2. Requirements 19

What the customer wants (3 of 3)IEEE P 1220 tasks (continued)

9. Life cycle 10. Functional requirements 11. Performance requirements 12. Modes of operation 13. Technical performance measures 14. Physical characteristics 15. Human systems integration

15 tasks from IEEE P 1220 (continued)15 tasks from IEEE P 1220 (continued)

2. Requirements 20

Eliciting wants from customersTools

Quality functional deployment Trade studies Published materials -- RFPs, RFIs,

RFQs, trade journals and bulletinsTechniques

Customer-contractor partnerships Engineer-to-engineer contacts Alliances and teaming Techniques taught in customer

elicitation courses3. Learning what the customer wants

2. Requirements 21

Single point of contact for agreement

Documented agreement

Discussion

Consensus Consensus

Customer point of contact

Contractor point of contact

Customer stakeholders Contractor stakeholders

Stakeholders discuss issue. Each team conveys consensus to its POC. POCs have RAA for decisions.

Stakeholders discuss issue. Each team conveys consensus to its POC. POCs have RAA for decisions.

POC has RAA for decisions

POC has RAA for decisions


2. Requirements 22

Reaching agreementDefine functional areas & identify

requirements Prioritize and schedule completion of

requirements Assign points of contact and stakeholdersWrite sample requirements that people can

review


2. Requirements 23

4. ToolsTrade studiesQuality functional deployment (QFD)Caution

4. Tools

2. Requirements 24

Trade studies (1 of 2)

Used to make decisionsMany types of trade studiesA common technique is to use weighted

ranking -- discussed in INCOSE Systems Engineering Handbook Ideal -- Choose weights before study Reality -- Choose weights after study

4. Tools

2. Requirements 25

Trade studies (2 of 2)Option 1 2 3Engine 2 cycle 4 cycle 4 cycleHorsepower 4 3 3.5Cost $200 $300 $350Material alum alum steelStarter manual maual electricWeight 40 lb 60 lb 70 lbColor green red pink

wgt rank r-wgt rank r-wgt rank r-wgtPollution must reject ok okCost 25 10 250 8 200 7 175Power 25 10 250 7 175 8 200Operation 20 8 160 8 160 10 200Durability 15 9 135 8 120 7 105Weight 15 10 150 6 90 4 60Totals 100 945 745 740Selection reject 1 2

2. Requirements 26

QFD (1 of 5)

A requirements elicitation and flowdown technique

Deploys voice of the customerFlows down requirements to design, parts,

and manufacturing

4. Tools

2. Requirements 27

QFD (2 of 5)

Whats/Hows

En

g

HP

Co

st

Mat

'l

Sta

rt

Wg

t

Co

lor

5 4 3 2 1

WhatsPollution X

Cost X

Power X

Operation X

Durability X X

Weight X

How Much

4 cy

cle

3 $300

alu

m

man

ual

60 lb

red

54321

-

-- -

-

4. Tools

2. Requirements 28

QFD (3 of 5)

1 2 3 4 5 6 71 + - - engine2 + - - horsepower3 + - - cost4 + - material5 + - starter6 + weight7 + color

8. evaluation

1.what/ 4.how

2. c

usto

mer

im

port

ance

engi

ne

hors

epow

er

cost

mat

eria

l

star

ter

wei

ght

colo

r

1 --

wor

st

2 3 4 5 --

bes

t

pollution 9 9 5 1 23

cost 8 5 5 10 3 5 23 1

power 8 5 10 23 1

operation 6 3 5 5 12 3

durability 8 9 3 5 23 1

weight 6 3 3 10 3 2 1

6. targets

4 cy

cle

3.5

hp

$200

stee

l

auto

mat

ic

40 lb

gree

n

9. absolute 269 213 80 48 80 90 0 78010. relative 34 27 10 6 10 12 0 100

3. competiton

7. correlation

2. Requirements 29

QFD (4 of 5)

what

how much

how

what

how much

how

what

how much

how

Design

Parts

Manufacturing

4. Tools

2. Requirements 30

QFD (5 of 5)Shortcomings

Duplicates information in specifications

Requires tool

4. Tools

2. Requirements 31

CautionTools should be used because they’re

neededThey shouldn’t be used just because

they’re available or because we feel obligated to use the tools

4. Tools

2. Requirements 32

5. Validating customer requirements Definition of VORVOR techniquesRequirements pitfallVOR RAAAlternate definition of VORExampleCautions

5. Validating customer requirements

2. Requirements 33

Definition of VOR (1 of 2)VOR is the process of confirming that we’ve

solved the customer problem. Verification ensures that we’ve solved the

problem right. Validation ensures that we’ve solved the right problem.


Validation vs verificationValidation vs verification

2. Requirements 34

Definition of VOR (2 of 2)1. Ensure customer requirements are correct

Done early Integral part of understanding requirements

2. Ensure customer approach solves problem Done early

3. Ensure that product solved the problem Done on delivered product Meets requirements but doesn’t solve

problem

Three types of validationThree types of validation

2. Requirements 35

VOR techniquesAnalysis, modeling, prototyping,

experimentation, and survey


2. Requirements 36

Requirements pitfallIt’s possible to have a correct set of

requirements for the solution we’ve chosen, but the solution we’ve chosen may not solve the customer problem.


2. Requirements 37

VOR RAALies with the customer, but the contractor can

assist.However, in generating requirements for lower

products, contractor has RAA for VOR


2. Requirements 38

Alternate definition of VOR

Ensuring that technical requirements are consistent and complete with respect to user requirements, higher specifications, and other stakeholders


2. Requirements 39

Solution provided by customer has correct requirements but doesn’t solve problem

Solution provided by customer has correct requirements but doesn’t solve problem

Example 1 -- Process development

Customer believes engineering is

inefficient

Generates requirements for new engineering

process

Survey asks how engineering will

respond to process

Engineeringwill not use because cost exceeds value

problem

OK requirements for solution

surveyValidation shows

solution won’t solve problem


2. Requirements 40

Cautions (1 of 3)

wrongproblem

spec

rightproblem

Exercise care in telling customer that, in our opinion, they’ve solved the wrong problem

Exercise care in telling customer that, in our opinion, they’ve solved the wrong problem


customerchoice

ourchoice

common approach when contractors want to sell their

product

2. Requirements 41

Cautions (2 of 3)

problem

spec

Exercise care to not confuse customer solutionwith customer problem

Exercise care to not confuse customer solutionwith customer problem

customersolution


virtual problem

realproblem

2. Requirements 42

Cautions (3 of 3)

problem

spec

Exercise care in telling customer that, in our opinion, they’ve solved the problem wrong

Exercise care in telling customer that, in our opinion, they’ve solved the problem wrong

customersolution


oursolution

common approach when contractors want to sell their

product

what validation issupposed to do

2. Requirements 43

6. Writing requirements

Definition of a requirementOccurrence of requirementsGuidelines for a good requirementExamples for each guidelineTools for writing good requirementsNotes


2. Requirements 44

Definition of a requirementSomething obligatory or demandedStatement of some needed thing or

characteristic


2. Requirements 45

Occurrence of requirementsWriting requirements occurs in both the

understand- requirements activity and the design activity

The customer has RAA for requirements in the understand- requirements activity even though the contractor may actually write the requirements

The contractor has RAA for requirements in the design activity


2. Requirements 46

Errors in requirements come mainly from incorrect facts (50%), omissions (30%),

inconsistent (15%), ambiguous (2%), misplaced (2%)

Errors in requirements come mainly from incorrect facts (50%), omissions (30%),

inconsistent (15%), ambiguous (2%), misplaced (2%)

Guidelines for a good requirementNeededCapable of being verifiedFeasible schedule, cost, and

implementationAt correct level in hierarchyCannot be misunderstoodGrammar and spelling correctDoes not duplicate information

6. Writing requirements Compliance Automation

2. Requirements 47

Example for each guidelineExample 1 -- neededExample 2 -- verificationExample 3 -- feasibleExample 4 -- levelExample 5 -- understandingExample 6 -- duplicationExample 7 -- grammar and spellingExample 8 -- tough requirements


2. Requirements 48

Example 1 -- neededThe motor shall weigh less than 10 pounds.The software shall use less than 75 percent of

the computer memory available for software.The MTBF shall be greater than 1000 hours.


2. Requirements 49

Example 2 -- verification (1 of 3)Customer want -- The outside wall shall be a

material that requires low maintenance


2. Requirements 50

Example 2 -- verification (2 of 3)

First possible rewording -- The outside wall shall be brick. More verifiable Limits contractor options Not a customer requirement


2. Requirements 51

Example 2 -- verification (3 of 3)

Second possible rewording -- The outside wall shall be one that requires low maintenance. Low maintenance material is one of the following: brick, stone, concrete, stucco, aluminum, vinyl, or material of similar durability; it is not one of the following: wood, fabric, cardboard, paper or material of similar durability Uses definition to explain undefined

term


2. Requirements 52

Example 3 -- feasibleNot feasible requirement -- The assembly

shall be made of pure aluminum having a density of less than 50 pounds per cubic foot


2. Requirements 53

Example 4 -- level

Airplane shall be capable carrying up to 2000 pounds Wing airfoil shall be of type Clark Y

Airplane

Wing

Wing airfoil shall be of type Clark Y

Wing airfoil type is generally a result of design and should appear in the lower product spec

and not in the higher product spec.

Wing airfoil type is generally a result of design and should appear in the lower product spec

and not in the higher product spec.6. Writing requirements

2. Requirements 54

Example 5 -- understandingAvoid imprecise terms such as

Optimize Maximize Accommodate Etc. Support Adequate


2. Requirements 55

Example 6 -- duplicationCapable of a maximum rate of 100 gpmCapable of a minimum rate of 10 gpmRun BIT while pumping 10 gpm - 100 gpmVs: Run BIT while pumping between min.

and max.


2. Requirements 56

Example 7 -- grammar and spellingThe computers is comercial-off-the-shelf

items Incorrect grammar or spelling will divert

customer review of the requirements from the technical content


2. Requirements 57

Example 8 -- tough requirements

BIT false alarm rate < 3 percentComputer throughput < 75 percent of capacityPerform over all altitudes and speedsConform with all local, state, and national lawsThere shall be no loss of performanceShall be safeThe display shall look the sameTBDs and TBRsStatistics


2. Requirements 58

Tools for writing good requirementsRequirements elicitationModelingTrade studies


2. Requirements 59

NotesPerfect requirements can’t always be

writtenIt’s not possible to avoid all calamitiesRequirements and design are similar and

therefore are often confused and placed at the wrong level in the hierarchy


2. Requirements 60

7. Homework (1 of 3)1. RAA for requirements in the understand-

customer activity lie with (a) requirements management, (b) the customer, (c) the contractor, (d) quality assurance

2. The understand- requirements activity reaches agreement with the customer on which type of interfaces: (a) interfaces external to the product, (b) interfaces internal to the product, (c) all interfaces, (d) none

7. Homework

2. Requirements 61

Homework (2 of 3)3. The customer (a) is always one entity, (b)

may be more than one entity, (c) always the product at the next-higher level, (d) undefined

4. A good practice in reaching agreement with the customer is to have agreements made by (a) management, (b) contracts, (c) a single-point of contact for customer and a single-point of contact for contractor, (d) individual stakeholders

7. Homework

2. Requirements 62

Homework (3 of 3)5. Trade studies should (a) always be done,

(b) always use the method defined in the INCOSE Systems Engineering Handbook, (c) be done only if needed, (d) always include QFD considerations

6. For the requirement “Performance shall be met when speed 200 mph and 400 mph,” performance must be met at (a) requirement unclear, (b) 200 mph and 400 mph, (c) one point in the speed range, (d) all points in the speed range.

7. Homework

Documents

Agenda for understand-req activity