Agenda for design activity

1
Agenda for design activity

• 1. Tracing requirements
• 2. Managing requirements
• 3. Requirements management tools

2
1. Tracing requirements

• Types of traces
• Complexity of tracing
• Methods for tracing
• Observations
• Suggestions
• Example

1. Tracing requirements
3
Types of traces (1 of 5)
1. Straight- through trace
no hazardous material
no hazardous material
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)
2. Expansion trace
weight
design
weight A
weight B
An expansion trace relates one or a few higher
requirement to more lower product requirements
with expansion in design.
1. Tracing requirements
5
Types of traces (3 of 5)
3. Focus trace
Calculation
Graphing
Design
Spreadsheet
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)
4. End trace
bedroom on east side
design
building supplies
An end trace relates a higher requirement to
design but not to any lower products
1. Tracing requirements
7
Types of traces (5 of 5)
5. Creation trace
missile
design
instrumentation
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)
Specification-to-specification tracing
Spec
Spec
Spec
Specification-to-specification tracing traces
from specification to specification and doesnt
include tracing to design. Its the more
common practice
1. Tracing requirements
9
Complexity of tracing (2 of 2)
Specification-to-design- to-specification tracing
contract
spec
design of the higher product
stakeholders
design
spec
contract
spec
contract
I/F
stakeholders
stakeholders
design
design
Note Flow within a rectangle or ellipse not shown
Flow through design is more complex and is a
less common practice. However, it produces
less problems
1. Tracing requirements
10
Methods for tracing (1 of 5)

• Method 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)

• Method 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)

• Method 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)

• Method 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)

• The four different methods for tracing can result
  in four different sets of linkages

1. Tracing requirements
15
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
16
Observations (2 of 4)

• Tracing is expensive
• Tracing is complex and expensive benefit/cost
  gt 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)

• 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
18
Observations (4 of 4)

• 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

1. Tracing requirements
19
Suggestion (1 of 3)

• Set customer expectations
• Negotiate with customer to minimize effort for
  design and verification
• Document agreements -- in the spec if possible
  using clarifications, definitions, and examples

1. Tracing requirements
20
Suggestion (2 of 3)

• Choose a type of tracing such as tracing to
  confirm verification and validation
• Provide rules and training
• Provide for independent confirmation of tracing
• Use a trace to environment to reduce number of
  links
• Use traces to studies for expansions,
  contraction, and design

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

• Problem -- P1r Compute taxes faster P2c
  lt2000
• 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 lt1100
• Design 8 -- D8 Windows 98 lt100
• Design 9 -- D9 Excel lt400
• Computer -- C1r Gateway C2r 500 MHz C3r 20
  Gbyte, C4c lt1100
• Operating system -- O1r Windows 98, O2clt100
• Spreadsheet -- S1r Excel 97 S2clt400

1. Tracing requirements
23
Example (2 of 4)
P1r faster
P2c lt2000
C1r Gateway
C2r 500 MHz
C3r 20Gbyte
C4c lt1100
O1r W98
O2c lt100
S1r XL97
S2c lt400
1. Tracing requirements
24
Example (3 of 4)
P1r faster
P2c lt2000
D1 computer
U1c 20
D2 Gateway D3 500 MHz D4 20 Gbytes
D5 W98 D6 XL97
D7 computer lt1100 D8 W98 lt100 D9 XL97 lt 400
C1r Gateway
C2r 500 MHz
C3r 20Gbyte
C4c lt1100
O1r W98
O2c lt100
S1r XL97
S2c lt400
1. Tracing requirements
25
Example (4 of 4)
P1r faster
P2c lt2000
D1 computer
U1c 20
D2 Gateway D3 500 MHz D4 20 Gbytes
D5 W98 D6 XL97
D7 computer lt1100 D8 W98 lt100 D9 XL97 lt 400
C1r Gateway
C2r 500 MHz
C3r 20Gbyte
C4c lt1100
O1r W98
O2c lt100
S1r XL98
S2c lt400
1. Tracing requirements
26
2. Managing requirements

• Requirements attributes
• Data interface attributes
• Physical interface attributes
• Documenting requirements
• Managing requirements change

2. Managing requirements
27
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. Managing requirements
28
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. Managing requirements
29
Data interface attributes

• Data item
• Criteria
• Timing
• Units and enumeration
• Format
• Ranges
• Accuracy

2. Managing requirements
30
Physical interface attributes (1 of 2)

• Electrical
• Signals
• Power
• EMI/EMC
• Grounding

2. Managing requirements
31
Physical interface attributes (2 of 2)

• Mechanical
• Dimensions
• Mounting
• Alignment
• Weight
• Heating
• Cooling

2. Managing requirements
32
Documenting requirements

• Media
• Paper
• Office computer tools
• Data base
• Format
• Contractor chosen
• Commercial standard
• Government standard

2. Managing requirements
33
Managing requirements change

• Often handled through configuration management
• Techniques
• Data base
• Change pages
• Red-line changes

2. Managing requirements
34
3. Requirements management tools

• INCOSE tools survey
• INCOSE tool-selection criteria
• Selection considerations for ease of use
• Selection considerations for compatibility
• Selection criteria for satisfaction

3. Requirements management tools
35
INCOSE tools survey

• Comparison made by National Council on Systems
  Engineering (INCOSE)

3. Requirements management tools
36
INCOSE tool-selection criteria (1 of 2)

• 1. Capturing requirements identification
• 2. Capturing system element structure
• 3. Requirements flowdown
• 4. Traceability analysis
• 5. Configuration management
• 6. Documents and other output media

3. Requirements management tools
37
INCOSE tool-selection criteria (2 of 2)

• 7. Groupware
• 8. Interfaces to other tools
• 9. System environment
• 10. User interfaces
• 11. Standards
• 12. Support and maintenance
• 13. Other features

3. Requirements management tools
38
Considerations for ease of use

• Using
• 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
• Assuring quality such as spell checking

3. Requirements management tools
39
Considerations for compatibility

• Computer and operating system being used on the
  project
• Way team members work

3. Requirements management tools
40
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