2. Requirements 1 Agenda for Understand Req Activity r1. Objective r2. Identifying the customer r3. Learning what the customer wants r4. Validating customer.

2. Requirements 1

Agenda for Understand Req Activity

1. Objective 2. Identifying the customer 3. Learning what the customer wants 4. Validating customer requirements 5. Writing requirements 6. Flowing down and tracing requirements 7. Managing requirements 8. Homework

2. Requirements 2

Customer-Understanding Flow

Identifying the

customer

Learning what the customer

wants

Validating customer

requirements

Writing requirements

Flowing down and tracing

requirements

Managing requirements

Understanding the customer is a process that starts with identifying the customer and flows through to documenting and managing the

customer requirements

2. Requirements 3

1. Objective

Understand-requirements activity

Product-based activities Products used to control Completion criteria

1. Objective

2. Requirements 4

Understand-Requirements Activity

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

1. Objective

2. Requirements 5

Understand-Requirements Tasks

Productrequirements

review

Assist customer in developing

product requirements and

interfaces

initial SOW, spec, & I/Fs

final SOW, spec, & I/Fs

approval

1. Objective

2. Requirements 6

Completion Criteria

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

1. Objective

2. Requirements 7

Pseudo Completion Criteria

Product specification and external interfaces complete

System Requirements Review (SRR) complete

1. Objective

2. Requirements 8

2. Identifying the Customer

Customer Design context Design Vs requirements Pseudo 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 specs.


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+1

Requirements as seen by level N+1

Design as seen by level N


2. Requirements 12

Pseudo Customers Guiding Design

Level N Spec

Level N+1 Spec 1

Level N+1 Spec 2

Level N+1 Spec M

Level NDesign

Pseudo customers guide design in addition to higher-level requirements.

Pseudo Customers


2. Requirements 13

Example -- Pseudo Customers

EnterpriseProduct lineRe-usabilityPotential customers

Development processDesignBuildTestSupportMaintenance

Other customers Other stakeholders

Pseudo customers


2. Requirements 14

3. Learning What the Customer Wants

What the customer wants Single point of contact for agreement Reaching 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

Customer wants flow from problem, environment, and life cycle3. Learning what the customer wants

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

Customer and contractor stakeholders discuss issue. Each team conveys consensus to its point of contact. Points of contacts have RAA for decisions. They agree on issue and document agreement.

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 stakeholders Write sample requirements that people can review


2. Requirements 18

4. Validating Customer Requirements

Validation of requirement (VOR) Example 1 -- process development

4. Validating customer requirements

2. Requirements 19

Definition of VOR

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.


2. Requirements 20

VOR Techniques

Analysis, modeling, prototyping, experimentation, and survey


2. Requirements 21

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 22

VOR RAA

Lies with the customer, but the contractor can assist.


2. Requirements 23

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 24

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

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

problem

OK requirements for solution

surveyValidation shows

solution won’t solve problem


2. Requirements 25

5. Writing Requirements

Definition of a requirement Guidelines for a good requirement Examples

5. Writing requirements

2. Requirements 26

Definition of a Requirement

Something obligatory or demanded Statement of some needed thing or characteristic


2. Requirements 27

Guidelines for a Good Requirement

Needed Capable of being verified Feasible schedule, cost, and implementation At correct level in hierarchy Cannot be misunderstood Grammatically correct Does not duplicate information


2. Requirements 28

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 29

Example 2 -- Verification (1 of 3)

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


2. Requirements 30


First possible rewording -- The outside wall shall be brick.

More verifiable Limits contractor options Not a customer requirement


2. Requirements 31


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 32

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 33

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.


2. Requirements 34

Example 5 -- Understanding

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


2. Requirements 35

Example 6 -- Duplication

Capable of a maximum rate of 100 gpm Capable of a minimum rate of 10 gpm Run BIT while pumping 10 gallons - 100 gpm Vs: Run BIT while pumping between min. and max.


2. Requirements 36

Example 7 -- Tough Requirements

BIT false alarm rate < 3 percent Computer throughput < 75 percent of capacity Perform over all altitudes and speeds


2. Requirements 37

6. Flowing down and tracing requirements

Types of flowdown Direction Origins and destinations Need Observations and suggestions


2. Requirements 38

Types of Flowdown

Req

Req Req Req

Req ReqReq

Req

Straight through Expansion Focus


2. Requirements 39

Direction -- Simplified Flow

Spec

SpecSpec

Often used in flowdown and tracing


2. Requirements 40

Direction -- Complex Flow

Spec SOW

Stakeholders

Design

Spec SOW

Stakeholders

Design

SpecSOW

Stakeholders

Design

I/F

Note: Flow within rectangle or ellipse not shown

Not often used in flowdown and tracing


2. Requirements 41

Direction -- Flow through Design

Spec SOW

Stakeholders

Design

Spec SOW

Stakeholders

Design

SpecSOW

Stakeholders

Design

I/F

Since the lower specs, interfaces, and SOW plus the ellipse labeled “design” are all part of design of the higher product, it

can be said that all requirements flow through design.

Design of the higher product

Note: Flow within a rectangle or ellipse not shown


2. Requirements 42

Direction -- Notation

Spec

Design

SpecSpec

Although all requirements flow through design, it is common to flowdown requirements that flow straight

through directly from spec to spec

Spec

SpecSpec

Straight-through Expanded or FocusedVs


2. Requirements 43

Origins and Destinations -- Types

Req

Req Req Req

Req ReqReq

Req

Straight through

Expansion Focus Creation End

DesignDesign Design Design Design

Req

Req


2. Requirements 44

Example 1 -- Illustrations

Weight

Weight A Weight B

Spreadsheet

Calculation GraphingNo hazardous material

Straight through

Expansion

Focus Creation

End

DesignDesign

Design Design

Bedroom on east side

Instrumentation

Design

No hazardous material

Building supplies

Missile


2. Requirements 45

Need -- Types (1 of 5)

1. Flowdown -- Where did requirement get implemented?

Less precise linkage criteria than tracing for verification/validation

Often done by doing tracing first


2. Requirements 46


2. Tracing for verification/validation -- What lower requirements are used in verifying/validating higher requirements?

Simplest and most repeatable


2. Requirements 47


3. Tracing for origin -- Where did each requirement come from; why does it exist?

more linkages to explain how design creates requirements


2. Requirements 48


4. Tracing for change impact -- If one requirement changes, what other requirements must change?

More linkages to reflect impacts of requirements on each other


2. Requirements 49


Four types result in different sets of linkages


2. Requirements 50

Observations (1 of 3)

Tracing is complex and expensive Lack of training & rules make trace not repeatable or

dependable Many believe cost far out weighs the benefit Customer may expect flowdown and tracing


2. Requirements 51


Rules of thumb can cause trouble All requirements must come from somewhere All requirements must go somewhere


2. Requirements 52


Design is an essential part of flow down and trace Design is difficult to capture in requirements

management tools Few people use trace to understand the effect of

a requirement change on other requirements


2. Requirements 53

Suggestion 1

Negotiate with customer to minimize effort


2. Requirements 54

Suggestion 2

Provide rules and training


2. Requirements 55

Suggestion 3

Req

Req Req Req

Req Req

ExpansionFocusDesign Design

Req

Req Req Req

Req Req

Expansion Focus

Flow expansion and focus through design -- not directly


2. Requirements 56

7. Managing Requirements

Requirements attributes Interface requirements Requirements change Requirements management tools

7. Managing requirements

2. Requirements 57

Requirements Attributes (1 of 2)

Requirement -- text Title -- short text Numerical identifier -- added by management tool Product unique identifier (PUI) -- added by engineers Verification method -- how requirement verified


2. Requirements 58

Requirements Attributes (2 of 2)

Owner -- person responsible for success Stakeholders -- people with an interest Change history -- change dates Flowdown/traces -- flowdown and trace links Rationale -- why requirement is the way it is


2. Requirements 59

Interface Requirements -- Data Example

Data item Criteria Timing Units and enumeration Format Ranges Accuracy


2. Requirements 60

Interface Requirements -- Physical Example

Electrical Signals Power EMI/EMC Grounding

Mechanical Dimensions Mounting Alignment Weight Heating Cooling


2. Requirements 61

Requirements Documentation

Media Paper Office computer tools Data base

Format Contractor chosen Commercial standard MIL-STD-490A MIL-STD-490B


2. Requirements 62

Requirements Change

Often handled through configuration management

Techniques Data base Change pages Red-line changes


2. Requirements 63

Requirements Management Tools

INCOSE tools survey Considerations in choosing tools Suggestions on tool selection


2. Requirements 64

INCOSE -- Tools Survey

Comparison made by National Council on Systems Engineering (INCOSE)

Internet address: http\\www.incose.org/workgrps/tools/req_surv.htm


2. Requirements 65

INCOSE -- Criteria ( 1 of 3)

1. Capturing requirements identification 2. Capturing system element structure 3. Requirements flowdown 4. Traceability analysis


2. Requirements 66


5. Configuration management 6. Documents and other output media 7. Groupware 8. Interfaces to other tools 9. System environment


2. Requirements 67


10. User interfaces 11. Standards 12. Support and maintenance 13. Other features


2. Requirements 68

INCOSE -- Tools Surveyed (1 of 2)

Cadence -- Bones Boeing North American, Inc. -- CASETS Vitech -- CORE Mesa Systems Guild -- Cradle/SEE Zycad -- DOORS Teknowledge -- ProductTrack Image That -- Extend Ascent Logic -- RDD-100 Integrated Chipware Inc. -- RTM TD Technologies -- SLATE


2. Requirements 69

INCOSE -- Tools Surveyed (1 of 2)

Cadence -- SPW Compliance Automation -- VITAL LINK Teledyne Brown Engineering -- XTie-RT Nu Thena Systems -- Foresight MathWorks -- MATLAB, Simulink, Stateflow,

Real-Time Workshop Rational (Requisite) -- RequisitePro V2.0 Statemate -- Magnum


2. Requirements 70

Considerations for Ease

Use Learning Putting information into the tool Extracting information from the tool Knowing what information is in the tool Navigating among information Grouping information for comparison and reports Quality assurance such as spell checking


2. Requirements 71

Considerations for Compatability

Computer and operating system being used on the project

Way team members work


2. Requirements 72

Considerations for Satisfaction

Gain understanding of the tool before committing to use tool

Avoid choices based on demo by sales person


2. Requirements 73

8. Homework

Diagram Customer wants Timepiece spec Timepiece SOW Design Clock spec AC adapter spec Problem

8. Homework

2. Requirements 74

Diagram

Customer wantsC1, C2, C3

Timepiece specS1

Timepiece SOWX1

Timepiece designD1, D2, D3, D4, D5

Clock specT1

Adapter specU1, U2

8. Homework

2. Requirements 75

Customer Wants

C1: I want a timepiece that I can look at and determine time accurate to one minute per day since the last setting

C2: Cost, size, weight, mechanism, style, power, and everything else are of no consequence

C3: I will give a flat $100 for the timepiece regardless of design

8. Homework

2. Requirements 76

Timepiece Spec

S1: The timepiece shall display time accurate to one minute per day since the last setting

8. Homework

2. Requirements 77

Timepiece SOW

X1: Customer will pay $100 for timepiece meeting timepiece spec

8. Homework

2. Requirements 78

Design

D1: I’ll design the timepiece using existing components. D2: I want to make a lot of profit D3: The Dilmore catalogue shows that its least

expensive clock is the model 100 for $4. It is resettable to correct the time, is accurate to one minute per day since the last setting, but requires an AC adapter

D4: The Hazel catalog shows the model 200 as its least expensive AC adapter compatible with the Dilmore model 100 clock, and the adapter costs $1.

D5: The model 200 AC adapter comes in either black or beige at no extra cost. In my opinion, beige is more attractive in the customer’s environment

8. Homework

2. Requirements 79

Clock Spec

T1: Clock shall be a Dilmore model 100 clock

8. Homework

2. Requirements 80

AC Adapter Spec

U1: AC adapter shall be a Hazel model 200 AC adapter

U2: AC adapter shall be beige

8. Homework

2. Requirements 81

Homework Problem (1 of 2)

1. What items need to be successfully implemented to verify item D5? -- a. T1, U1, & U2; b. U1 & U2; c. U1; d. U2

2. For tracing purposes, what items implement item X1? -- a. D3; b. D4, c. D3 & D4; d. D3, D4, & D5

3. For tracing purposes, where did the requirements for item D4 come from? -- a. D3; b. D1, D2, & D3; c. D1, D2, D3, & X1; d. S1, D1, D2, & D3

4. For tracing purposes, what items implement item C2? -- a. none of the listed items, b. S1 & X1, c. D1, D2, & D3; d. T1, U1, & U2

8. Homework

2. Requirements 82

Homework Problem (2 of 2)

5. What items need to be successfully implemented to verify item S1? -- a. C1; b. D3; c. D2 & D3; d. D3, D4, & D5

6. For tracing purposes, where does item D1 come from? -- a. none of the listed items; b. S1; c. X1; d. S1 & X1

7. For tracing purposes, where does item U2 come from? -- a. none of the listed items; b. D5; c. D4; d. S1

8. If item D3 were to change to no longer require an AC adapter, which items would change? -- a. no items would change; b. D4; c. D4 & U1; d. D4, D5, U1, & U2

8. Homework