Date post: | 31-Dec-2015 |
Category: |
Documents |
Upload: | alexander-mckinney |
View: | 222 times |
Download: | 2 times |
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. 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 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+1
Requirements as seen by level N+1
Design as seen by level N
2. Identifying the customer
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. Identifying the customer
2. Requirements 13
Example -- Pseudo Customers
EnterpriseProduct lineRe-usabilityPotential customers
Development processDesignBuildTestSupportMaintenance
Other customers Other stakeholders
Pseudo customers
2. Identifying the customer
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
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 stakeholders Write sample requirements that people can review
3. Learning what the customer wants
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.
4. Validating customer requirements
2. Requirements 20
VOR Techniques
Analysis, modeling, prototyping, experimentation, and survey
4. Validating customer requirements
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.
4. Validating customer requirements
2. Requirements 22
VOR RAA
Lies with the customer, but the contractor can assist.
4. Validating customer requirements
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
4. Validating customer requirements
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
4. Validating customer requirements
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
5. Writing requirements
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
5. Writing requirements
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.
5. Writing requirements
2. Requirements 29
Example 2 -- Verification (1 of 3)
Customer want -- The outside wall shall be a material that requires low maintenance
5. Writing requirements
2. Requirements 30
Example 2 -- Verification (2 of 3)
First possible rewording -- The outside wall shall be brick.
More verifiable Limits contractor options Not a customer requirement
5. Writing requirements
2. Requirements 31
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
5. Writing requirements
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
5. Writing requirements
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.
5. Writing requirements
2. Requirements 34
Example 5 -- Understanding
Avoid imprecise terms such as Optimize Maximize Accommodate Etc. Support Adequate
5. Writing requirements
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.
5. Writing requirements
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
5. Writing requirements
2. Requirements 37
6. Flowing down and tracing requirements
Types of flowdown Direction Origins and destinations Need Observations and suggestions
6. Flowing down and tracing requirements
2. Requirements 38
Types of Flowdown
Req
Req Req Req
Req ReqReq
Req
Straight through Expansion Focus
6. Flowing down and tracing requirements
2. Requirements 39
Direction -- Simplified Flow
Spec
SpecSpec
Often used in flowdown and tracing
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
2. Requirements 46
Need -- Types (2 of 5)
2. Tracing for verification/validation -- What lower requirements are used in verifying/validating higher requirements?
Simplest and most repeatable
6. Flowing down and tracing requirements
2. Requirements 47
Need -- Types (3 of 5)
3. Tracing for origin -- Where did each requirement come from; why does it exist?
more linkages to explain how design creates requirements
6. Flowing down and tracing requirements
2. Requirements 48
Need -- Types (4 of 5)
4. Tracing for change impact -- If one requirement changes, what other requirements must change?
More linkages to reflect impacts of requirements on each other
6. Flowing down and tracing requirements
2. Requirements 49
Need -- Types (5 of 5)
Four types result in different sets of linkages
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
2. Requirements 51
Observations (2 of 3)
Rules of thumb can cause trouble All requirements must come from somewhere All requirements must go somewhere
6. Flowing down and tracing requirements
2. Requirements 52
Observations (3 of 3)
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
6. Flowing down and tracing requirements
2. Requirements 53
Suggestion 1
Negotiate with customer to minimize effort
6. Flowing down and tracing requirements
2. Requirements 54
Suggestion 2
Provide rules and training
6. Flowing down and tracing requirements
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
6. Flowing down and tracing requirements
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
7. Managing requirements
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
7. Managing requirements
2. Requirements 59
Interface Requirements -- Data Example
Data item Criteria Timing Units and enumeration Format Ranges Accuracy
7. Managing requirements
2. Requirements 60
Interface Requirements -- Physical Example
Electrical Signals Power EMI/EMC Grounding
Mechanical Dimensions Mounting Alignment Weight Heating Cooling
7. Managing requirements
2. Requirements 61
Requirements Documentation
Media Paper Office computer tools Data base
Format Contractor chosen Commercial standard MIL-STD-490A MIL-STD-490B
7. Managing requirements
2. Requirements 62
Requirements Change
Often handled through configuration management
Techniques Data base Change pages Red-line changes
7. Managing requirements
2. Requirements 63
Requirements Management Tools
INCOSE tools survey Considerations in choosing tools Suggestions on tool selection
7. Managing requirements
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
7. Managing requirements
2. Requirements 65
INCOSE -- Criteria ( 1 of 3)
1. Capturing requirements identification 2. Capturing system element structure 3. Requirements flowdown 4. Traceability analysis
7. Managing requirements
2. Requirements 66
INCOSE -- Criteria ( 2 of 3)
5. Configuration management 6. Documents and other output media 7. Groupware 8. Interfaces to other tools 9. System environment
7. Managing requirements
2. Requirements 67
INCOSE -- Criteria ( 3 of 3)
10. User interfaces 11. Standards 12. Support and maintenance 13. Other features
7. Managing requirements
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
7. Managing requirements
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
7. Managing requirements
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
7. Managing requirements
2. Requirements 71
Considerations for Compatability
Computer and operating system being used on the project
Way team members work
7. Managing requirements
2. Requirements 72
Considerations for Satisfaction
Gain understanding of the tool before committing to use tool
Avoid choices based on demo by sales person
7. Managing requirements
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