1 Agenda for design activity r1. Tracing requirements r2. Managing requirements r3. Requirements management tools

2 1. Tracing requirements rTypes of traces rComplexity of tracing rMethods for tracing rObservations rSuggestions rExample 1. Tracing requirements

3 Types of traces (1 of 5) no hazardous material 1. Straight- through trace no hazardous material A straight-through trace relates a higher requirement directly to lower product requirement without expansion or focusing A straight-through trace relates a higher requirement directly to lower product requirement without expansion or focusing 1. Tracing requirements

4 Types of traces (2 of 5) weight weight Aweight B 2. Expansion trace An expansion trace relates one or a few higher requirement to more lower product requirements with expansion in design. An expansion trace relates one or a few higher requirement to more lower product requirements with expansion in design. 1. Tracing requirements design

5 Types of traces (3 of 5) Spreadsheet CalculationGraphing 3. Focus trace Design A focus trace relates N higher requirements to fewer lower product requirements with focusing in design. A focus trace relates N higher requirements to fewer lower product requirements with focusing in design. 1. Tracing requirements

6 Types of traces (4 of 5) bedroom on east side 4. End trace design An end trace relates a higher requirement to design but not to any lower products An end trace relates a higher requirement to design but not to any lower products 1. Tracing requirements building supplies

7 Types of traces (5 of 5) 5. Creation trace design instrumentation missile A creation trace relates design to lower product requirements design but not to any higher product requirements A creation trace relates design to lower product requirements design but not to any higher product requirements 1. Tracing requirements

8 Complexity of tracing (1 of 2) Spec Specification-to-specification tracing traces from specification to specification and doesn’t include tracing to design. It’s the more common practice Specification-to-specification tracing traces from specification to specification and doesn’t include tracing to design. It’s the more common practice 1. Tracing requirements Specification-to-specification tracing

9 Complexity of tracing (2 of 2) contract stakeholders spec design spec design contract stakeholders spec contract 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 1. Tracing requirements Specification-to-design- to-specification tracing

10 Methods for tracing (1 of 5) rMethod 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

11 Methods for tracing (2 of 5) rMethod 2: tracing for verification/validation -- What lower requirements are used in verifying/validating higher requirements? Simplest and most repeatable 1. Tracing requirements

12 Methods for tracing (3 of 5) rMethod 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

13 Methods for tracing (4 of 5) rMethod 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

14 Methods for tracing (5 of 5) rThe four different methods for tracing can result in four different sets of linkages 1. Tracing requirements

15 Observations (1 of 4) rTracing 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

16 Observations (2 of 4) rTracing 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

17 Observations (3 of 4) rThe 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

18 Observations (4 of 4) rDesign is an essential part of flow down and trace rDesign is difficult to capture in requirements management tools rFew people use trace to understand the effect of a requirement change on other requirements 1. Tracing requirements

19 Suggestion (1 of 3) rSet customer expectations rNegotiate with customer to minimize effort for design and verification rDocument agreements -- in the spec if possible using clarifications, definitions, and examples 1. Tracing requirements

20 Suggestion (2 of 3) rChoose a type of tracing such as tracing to confirm verification and validation rProvide rules and training rProvide for independent confirmation of tracing rUse a trace to environment to reduce number of links rUse traces to studies for expansions, contraction, and design 1. Tracing requirements

21 Suggestion (3 of 3) req Req req Expansion Focus design req Expansion Focus Flow expansion and focus through design -- not directly 1. Tracing requirements

22 Example (1 of 4) Problem -- P1r: Compute taxes faster; P2c: <$2000 Us -- U1c: 20% profit Design 1 -- D1: Computer (vs calculator or internet) Design 2 -- D2: Gateway (vs Dell or Macintosh) Design 3 -- D3: 500 MHz (vs 400 MHz or 600 MHz) Design 4 -- D4: 20 Gbyte(vs 10 Gbyte or 15 Gbyte) Design 5 -- D5: Windows 98 (vs Unix) Design 6 -- D6: Excel 97 (vs Lotus) Design 7 -- D7: Computer <$1100 Design 8 -- D8: Windows 98 <$100 Design 9 -- D9: Excel <$400 Computer -- C1r: Gateway; C2r: 500 MHz; C3r: 20 Gbyte, C4c <$1100 Operating system -- O1r: Windows 98, O2c<$100 Spreadsheet -- S1r: Excel 97; S2c<$ Tracing requirements

23 Example (2 of 4) P1r: faster P2c: <$2000 C1r: Gateway C2r: 500 MHz C3r: 20Gbyte C4c: <$1100 O1r: W98 O2c: <$100 S1r: XL97 S2c: <$ Tracing requirements

24 Example (3 of 4) P1r: faster P2c: <$2000 C1r: Gateway C2r: 500 MHz C3r: 20Gbyte C4c: <$1100 O1r: W98 O2c: <$100 S1r: XL97 S2c: <$400 D1: computer D2: Gateway D3: 500 MHz D4: 20 Gbytes D5: W98 D6: XL97 D7: computer <$1100 D8: W98 <$100 D9: XL97 < $400 U1c: 20% 1. Tracing requirements

25 Example (4 of 4) P1r: faster P2c: <$2000 C1r: Gateway C2r: 500 MHz C3r: 20Gbyte C4c: <$1100 O1r: W98 O2c: <$100 S1r: XL98 S2c: <$400 D1: computer D2: Gateway D3: 500 MHz D4: 20 Gbytes D5: W98 D6: XL97 D7: computer <$1100 D8: W98 <$100 D9: XL97 < $400 U1c: 20% 1. Tracing requirements

26 2. Managing requirements rRequirements attributes rData interface attributes rPhysical interface attributes rDocumenting requirements rManaging requirements change 2. Managing requirements

27 Requirements attributes (1 of 2) rRequirement -- text rTitle -- short text rNumerical identifier -- added by management tool rProduct unique identifier (PUI) -- added by engineers rVerification method -- how requirement verified 2. Managing requirements

28 Requirements attributes (2 of 2) rOwner -- person responsible for success rStakeholders -- people with an interest rChange history -- change dates rFlowdown/traces -- flowdown and trace links rRationale -- why requirement is the way it is 2. Managing requirements

29 Data interface attributes rData item rCriteria rTiming rUnits and enumeration rFormat rRanges rAccuracy 2. Managing requirements

30 Physical interface attributes (1 of 2) rElectrical Signals Power EMI/EMC Grounding 2. Managing requirements

31 Physical interface attributes (2 of 2) rMechanical Dimensions Mounting Alignment Weight Heating Cooling 2. Managing requirements

32 Documenting requirements rMedia Paper Office computer tools Data base rFormat Contractor chosen Commercial standard Government standard 2. Managing requirements

33 Managing requirements change rOften handled through configuration management rTechniques Data base Change pages Red-line changes 2. Managing requirements

34 3. Requirements management tools rINCOSE tools survey rINCOSE tool-selection criteria rSelection considerations for ease of use rSelection considerations for compatibility rSelection criteria for satisfaction 3. Requirements management tools

35 INCOSE tools survey rComparison made by National Council on Systems Engineering (INCOSE) 3. Requirements management tools

36 INCOSE tool-selection criteria (1 of 2) r1. Capturing requirements identification r2. Capturing system element structure r3. Requirements flowdown r4. Traceability analysis r5. Configuration management r6. Documents and other output media 3. Requirements management tools

37 INCOSE tool-selection criteria (2 of 2) r7. Groupware r8. Interfaces to other tools r9. System environment r10. User interfaces r11. Standards r12. Support and maintenance r13. Other features 3. Requirements management tools

38 Considerations for ease of use rUsing rLearning rPutting information into the tool rExtracting information from the tool rKnowing what information is in the tool rNavigating among information rGrouping information for comparison and reports rAssuring quality such as spell checking 3. Requirements management tools

39 Considerations for compatibility rComputer and operating system being used on the project rWay team members work 3. Requirements management tools

40 Considerations for satisfaction rGain understanding of the tool before committing to use tool rAvoid choices based on demo by sales person 3. Requirements management tools