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. Identifying the customer
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. Identifying the customer
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. Identifying the customer
2. Requirements 13
Pseudo customers (2 of 2)
EnterpriseProduct lineRe-usabilityPotential customers
Development processDesignBuildTestSupportMaintenance
Other customers Other stakeholders
Example pseudo customers
2. Identifying the customer
2. Requirements 14
3. Learning what the customer wants
What the customer wantsSingle point of contact for
agreementReaching agreement
3. Learning what the customer wants
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
3. Learning what the customer wants
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
3. Learning what the customer wants
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
5. Quality functional deployment (QFD)
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
-
-- -
-
5. Quality functional deployment (QFD)
2. Requirements 24
QFD flowdown
what
how much
how
what
how much
how
what
how much
how
Design
Parts
Manufacturing
5. Quality functional deployment (QFD)
2. Requirements 25
QFD limitationsDuplicates information in specsRequires tool
5. Quality functional deployment (QFD)
2. Requirements 26
6. Validating customer requirements
Definition of VORVOR techniquesRequirements pitfallVOR RAAAlternate definition of VORExample
6. Validating customer requirements
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.
6. Validating customer requirements
2. Requirements 28
VOR techniquesAnalysis, modeling, prototyping,
experimentation, and survey
6. Validating customer requirements
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.
6. Validating customer requirements
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
6. Validating customer requirements
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
6. Validating customer requirements
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
6. Validating customer requirements
2. Requirements 33
7. Writing requirements
Definition of a requirementOccurrence of requirementsGuidelines for a good requirementTools for writing good requirementsExamplesNotes
7. Writing requirements
2. Requirements 34
Definition of a requirement
Something obligatory or demandedStatement of some needed thing or
characteristic
7. Writing requirements
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
7. Writing requirements
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
7. Writing requirements
2. Requirements 37
Tools for writing good requirementsRequirements elicitationModelingTrade studies
7. Writing requirements
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.
7. Writing requirements
2. Requirements 39
Example 2 -- verification (1 of 3)
Customer want -- The outside wall shall be a material that requires low maintenance
7. Writing requirements
2. Requirements 40
Example 2 -- verification (2 of 3)
First possible rewording -- The outside wall shall be brick. More verifiable Limits contractor options Not a customer requirement
7. Writing requirements
2. Requirements 41
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
7. Writing requirements
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
7. Writing requirements
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.
7. Writing requirements
2. Requirements 44
Example 5 -- understanding
Avoid imprecise terms such as Optimize Maximize Accommodate Etc. Support Adequate
7. Writing requirements
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.
7. Writing requirements
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
7. Writing requirements
2. Requirements 47
Notes
Perfect requirements can’t always be written
It’s not possible to avoid all calamitiesRequirements and design are similar
7. Writing requirements
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