2. requirements1 agenda for understand-req activity r1. objective r2. identifying the customer r3....

2. Requirements 1

Agenda for understand-req activity1. Objective2. Identifying the customer3. Learning what the customer wants4. Trade studies5. Quality functional deployment (QFD)6. Validating customer requirements7. Writing requirements8. Homework

2. Requirements 2

1. Objective

Understand-requirements activityUnderstand-requirements tasksCompletion criteriaPseudo-completion criteriaCustomer-understanding flow

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

Productrequirementsreview (RR)

Assist customer in developing

product requirements and

interfaces

initial contract, spec, & I/Fs

final contract,

spec, & I/Fs

approval

1. Objective

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

Customer-understanding flow

Identifying the

customer

Learning what the customer

wants

Validating customer

requirements

Writing requirements

Flowing down and tracing

requirements

Review requirements

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

Managing requirements

1. Objective

2. Requirements 8

2. Identifying the Customer

CustomerDesign contextDesign vs requirementsPseudo customers

2. Identifying the customer

2. Requirements 9

Customer

Who is the customer? 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


2. Requirements 10

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 11

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 12

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 13

Pseudo customers (2 of 2)

EnterpriseProduct lineRe-usabilityPotential customers

Development processDesignBuildTestSupportMaintenance

Other customers Other stakeholders

Example pseudo customers


2. Requirements 14

3. Learning what the customer wants

What the customer wantsSingle point of contact for

agreementReaching agreement


2. Requirements 15

What the customer wants

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 16

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 17

Reaching agreement

Define functional areas & identify requirements

Prioritize and schedule completion of requirements

Assign points of contact and stakeholdersWrite sample requirements that people can

review


2. Requirements 18

4. Trade studies

UseExample

4. Trade studies

2. Requirements 19

Use

Used to make decisionsShould be have a reason for being doneCommon technique is to use weighted

ranking Ideal -- Choose weights before study Reality -- Choose weights after study

INCOSE Systems Engineering Handbook discusses in detail

4. Trade studies

2. Requirements 20

Example 1 lawn mowerOption 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 21

5. Quality functional deployment (QFD)QFDExampleQFD flowdownQFD limitations

5. Quality functional deployment (QFD)

2. Requirements 22

QFD

A requirements flowdown techniqueDeploys voice of the customerFlows down requirements to design, parts,

and manufacturing


2. Requirements 23

Example 1 lawn mower

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

-

-- -

-


2. Requirements 24

QFD flowdown

what

how much

how

what

how much

how

what

how much

how

Design

Parts

Manufacturing


2. Requirements 25

QFD limitationsDuplicates information in specsRequires tool


2. Requirements 26

6. Validating customer requirements

Definition of VORVOR techniquesRequirements pitfallVOR RAAAlternate definition of VORExample


2. Requirements 27

Definition of VORVOR 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.


2. Requirements 28

VOR techniquesAnalysis, modeling, prototyping,

experimentation, and survey


2. Requirements 29

Requirements pitfall

It’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 30

VOR RAA

Lies with the customer, but the contractor can assist.

However, in generating requirements for lower products, contractor has RAA for VOR


2. Requirements 31

Alternate definition of VOR

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

EIA 632 defines validation in these terms and assigns RAA to the contractor


2. Requirements 32

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 33

7. Writing requirements

Definition of a requirementOccurrence of requirementsGuidelines for a good requirementTools for writing good requirementsExamplesNotes


2. Requirements 34

Definition of a requirement

Something obligatory or demandedStatement of some needed thing or

characteristic


2. Requirements 35

Occurrence of requirements

Writing requirements occurs in both the understand-customer activity and the design activity

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

The contractor has RAA for requirements in the design activity


2. Requirements 36

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 misunderstoodGrammatically correctDoes not duplicate information


2. Requirements 37

Tools for writing good requirementsRequirements elicitationModelingTrade studies


2. Requirements 38

Example 1 -- good requirements

The 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 39

Example 2 -- verification (1 of 3)

Customer want -- The outside wall shall be a material that requires low maintenance


2. Requirements 40


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


2. Requirements 41


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 42

Example 3 -- feasible

Not feasible requirement -- The assembly shall be made of pure aluminum having a density of less than 50 pounds per cubic foot


2. Requirements 43

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.


2. Requirements 44

Example 5 -- understanding

Avoid imprecise terms such as Optimize Maximize Accommodate Etc. Support Adequate


2. Requirements 45

Example 6 -- duplicationCapable of a maximum rate of 100 gpmCapable of a minimum rate of 10 gpmRun BIT while pumping 10 gallons - 100

gpmVs: Run BIT while pumping between min.

and max.


2. Requirements 46

Example 7 -- 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 47

Notes

Perfect requirements can’t always be written

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


2. Requirements 48

8. 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-customer 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) interfaces that constrain product development

8. Homework

2. Requirements 49

Homework (2 of 3)3. The customer is (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

8. Homework

2. Requirements 50

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 greater than 200 mph and speed less that 400 mph,” performance must be met at (a) requirement unclear, (b) 200 mph and 400 mph, (c) any one point in the speed range, (d) all points in the speed range.

8. Homework

2. requirements1 agenda for understand-req activity r1. objective r2. identifying the customer r3....

Documents

level n design level

level n design design

customer slide

spec p level n

customer requirements

customer learning

customer flows

requirements7 customer