5. Design 1
Agenda for design activity
1. Tracing requirements2. Managing requirements3. Requirements management tools4. Homework
5. Design 2
1. Tracing requirements
Types of tracingComplexity of tracingReasons for tracingObservationsSuggestions
1. Tracing requirements
5. Design 3
Types of tracing (1 of 2)
Req
Req Req Req
Req ReqReq
Req
Straight through
Expansion Focus Creation End
DesignDesign Design Design Design
Req
Req
Five types of tracingFive types of tracing
1. Tracing requirements
5. Design 4
Types of tracing (2 of 2)
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
An example of each typeAn example of each type
5. Design 5
Complexity of tracing (1 of 2)
Spec
SpecSpec
Often used in tracing and tracing
Simple tracing flows from spec to spec and doesn’t include tracing to design.
It’s the more common practice
Simple tracing flows from spec to spec and doesn’t include tracing to design.
It’s the more common practice
1. Tracing requirements
5. Design 6
Complexity of tracing (2 of 2)
Spec contract
Stakeholders
Design
Spec contract
Stakeholders
Design
Speccontract
Stakeholders
Design
I/F
Flow through design is more complex and is a less common practice. However, it produces less problems
Flow through design is more complex and is a less common practice. However, it produces less problems
Design of the higher product
Note: Flow within a rectangle or ellipse not shown
More complex but provides truer tracing picture
1. Tracing requirements
5. Design 7
Reasons for tracing (1 of 5)
Reason 1: tracing -- Where did requirement get implemented?• Less precise linkage criteria than tracing
for verification/validation• Often done by doing tracing first
1. Tracing requirements
5. Design 8
Reasons for tracing (2 of 5)
Reason 2: tracing for verification/validation -- What lower requirements are used in verifying/validating higher requirements?• Simplest and most repeatable
1. Tracing requirements
5. Design 9
Reasons for tracing (3 of 5)
Reason 3: tracing for origin -- Where did each requirement come from; why does it exist?• more linkages to explain how design
creates requirements
1. Tracing requirements
5. Design 10
Reasons for tracing (4 of 5)
Reason 4: tracing for change impact -- If one requirement changes, what other requirements must change?• More linkages to reflect impacts of
requirements on each other
1. Tracing requirements
5. Design 11
Reasons for tracing (5 of 5)
The four different reasons for tracing can result in four different sets of linkages
1. Tracing requirements
5. Design 12
Observations (1 of 4)
Tracing is a best practice• Supports verification and validation• Makes sure requirements are implemented• Prevents unnecessary requirements• Shows how changing one requirement
changes others• Meets customer expectation
1. Tracing requirements
5. Design 13
Observations (2 of 4)
Tracing is expensive• Tracing is complex and expensive;
$benefit/$cost > 1?• Many believe cost far out weighs the
benefit; takes time, diverts resources, degrades engineers, and drives tools
• Lack of training & rules make trace not repeatable or dependable
1. Tracing requirements
5. Design 14
Observations (3 of 4)
The following rules-of-thumb can cause trouble• All requirements must come from somewhere• All requirements must go somewhere• All requirements shall trace in one direction• Tracing shall be from spec to spec and not
within a spec• Tracing shall not be from spec to design• There shall be one “shall” per requirement• All requirements shall be individually traced
1. Tracing requirements
5. Design 15
Observations (4 of 4)
Design is an essential part of flowdown 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
1. Tracing requirements
5. Design 16
Suggestion (1 of 3)
Set customer expectationsNegotiate with customer to minimize effort
for design and verificationDocument agreements -- in the spec if
possible using clarifications, definitions, and examples
1. Tracing requirements
5. Design 17
Suggestion (2 of 3)
Choose a type of tracing such as tracing to confirm verification and validation
Provide rules and trainingProvide for independent confirmation of
tracing
1. Tracing requirements
5. Design 18
Suggestion (3 of 3)
Req
Req Req Req
Req Req
ExpansionFocusDesign Design
Req
Req Req Req
Req Req
Expansion Focus
Flow expansion and focus through design -- not directlyFlow expansion and focus through design -- not directly1. Tracing requirements
5. Design 19
2. Managing requirements
Requirements attributesData interface attributesPhysical interface attributesDocumenting requirementsManaging requirements change
2. Managing requirements
5. Design 20
Requirements attributes (1 of 2)
Requirement -- textTitle -- short textNumerical identifier -- added by management
toolProduct unique identifier (PUI) -- added by
engineersVerification method -- how requirement
verified
2. Managing requirements
5. Design 21
Requirements attributes (2 of 2)
Owner -- person responsible for successStakeholders -- people with an interestChange history -- change datesFlowdown/traces -- flowdown and trace
linksRationale -- why requirement is the way it is
2. Managing requirements
5. Design 22
Data interface attributes
Data itemCriteriaTimingUnits and enumerationFormatRangesAccuracy
2. Managing requirements
5. Design 23
Physical interface attributes (1 of 2)Electrical• Signals• Power• EMI/EMC• Grounding
2. Managing requirements
5. Design 24
Physical interface attributes (2 of 2)
Mechanical • Dimensions• Mounting• Alignment• Weight• Heating• Cooling
2. Managing requirements
5. Design 25
Documenting requirements
Media• Paper• Office computer tools• Data base
Format• Contractor chosen• Commercial standard• MIL-STD-490A• MIL-STD-490B
2. Managing requirements
5. Design 26
Managing requirements change
Often handled through configuration management
Techniques• Data base• Change pages• Red-line changes
2. Managing requirements
5. Design 27
3. Requirements management tools
INCOSE tools surveyINCOSE tool-selection criteriaTools surveyed by INCOSESelection considerations for ease of useSelection considerations for compatibilitySelection criteria for satisfaction
3. Requirements management tools
5. Design 28
INCOSE tools survey
Comparison made by National Council on Systems Engineering (INCOSE)
Internet address: http\\www.incose.org/workgrps/tools/req_surv.htm
3. Requirements management tools
5. Design 29
INCOSE tool-selection criteria (1 of 2)
1. Capturing requirements identification2. Capturing system element structure3. Requirements flowdown4. Traceability analysis5. Configuration management6. Documents and other output media
3. Requirements management tools
5. Design 30
INCOSE tool-selection criteria (2 of 2)
7. Groupware8. Interfaces to other tools9. System environment10. User interfaces11. Standards12. Support and maintenance13. Other features
3. Requirements management tools
5. Design 31
Tools surveyed by INCOSE (1 of 2)
Cadence -- BonesBoeing North American, Inc. --
CASETSVitech -- COREMesa Systems Guild -- Cradle/SEEZycad -- DOORSTeknowledge -- ProductTrackImage That -- ExtendAscent Logic -- RDD-100Integrated Chipware Inc. -- RTMTD Technologies -- SLATE
3. Requirements management tools
5. Design 32
Tools surveyed by INCOSE (2 of 2)
Cadence -- SPWCompliance Automation -- VITAL LINKTeledyne Brown Engineering -- XTie-RTNu Thena Systems -- ForesightMathWorks -- MATLAB, Simulink,
Stateflow, Real-Time WorkshopRational (Requisite) -- RequisitePro V2.0Statemate -- Magnum
3. Requirements management tools
5. Design 33
Considerations for ease of use
UsingLearningPutting information into the toolExtracting information from the toolKnowing what information is in the tool Navigating among informationGrouping information for comparison and
reportsAssuring quality such as spell checking
3. Requirements management tools
5. Design 34
Considerations for compatibility
Computer and operating system being used on the project
Way team members work
3. Requirements management tools
5. Design 35
Considerations for satisfaction
Gain understanding of the tool before committing to use tool
Avoid choices based on demo by sales person
3. Requirements management tools
5. Design 36
4. Homework
DiagramCustomer wantsTimepiece specTimepiece contractDesignClock specAC adapter specProblem
4. Homework
5. Design 37
Diagram
Customer wantsC1, C2, C3
Timepiece specS1
Timepiece contractX1
Timepiece designD1, D2, D3, D4, D5
Clock specT1
Adapter specU1, U2
4. Homework
5. Design 38
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
4. Homework
5. Design 39
Timepiece spec
S1: The timepiece shall display time accurate to one minute per day since the last setting
4. Homework
5. Design 40
Timepiece contract
X1: Customer will pay $100 for timepiece meeting timepiece spec
4. Homework
5. Design 41
Design (1 of 2)
D1: I’ll design the timepiece using existing components.
D2: I want to make a lot of profitD3: 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
4. Homework
5. Design 42
Design (2 of 2)
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
4. Homework
5. Design 44
AC adapter spec
U1: AC adapter shall be a Hazel model 200 AC adapter
U2: AC adapter shall be beige
4. Homework
5. Design 45
Problem (1 of 4)
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
4. Homework
5. Design 46
Problem (2 of 4)
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
4. Homework
5. Design 47
Problem (3 of 4)
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
4. Homework
5. Design 48
Problem (4 of 4)
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
4. Homework