Requirements Traceability'''

1
Requirements Traceability...

• ...is it needed for legacy systems?

Lt(N) Michael Montague
2
Outline

• What is Requirements Traceability (RT)
• How traceability can aid Project Managers
• RT Issues
• Making RT work for you
• Applying RT to a legacy system

3
Lack of Common Definition

• Purpose-driven
• what it should do
• Solution-driven
• how it should do it
• Information-driven
• emphasising traceable information
• Direction-driven
• emphasising traceability direction

4
What is Requirements Traceability?

• Refers to the ability to describe and follow the
  life of a requirement, in both a forwards and
  backwards direction
• Initially mandated by procurement agencies for
  purposes of compliance verification

5
Requirements Traceability
Pre-RS traceability
Post-RS traceability
Requirements Specification
(S0)
(S1)
(Sn)
6
Traceability Aids Project Managers in

• Verification
• only required functions are designed into the
  product
• Cost Reduction
• allocate product requirements early in the
  development cycle

7
Traceability Aids Project Managers in

• Accountability
• data is available for auditors
• Change Management
• determine what related elements of the design are
  affected

8
RT Issues

• Two major problems remain w.r.t. continuous
  change management
• 1. Traceability does not go sufficiently
  backwards to the source of requirements
• 2. Traceability must be produced as a side
  product of normal requirements engineering work
  rather than creating extra effort

9
1. Traceability to the Source

• Unknown reality from which the requirements
  emerged
• design rationale information
• capture the why or reason for design decisions

10
2. Creating Extra Effort

• RT Tasks are time consuming and error-prone
• Users abilities to analyze traceability data are
  limited by the sheer volume of the data

11
Making RT Work For You

• Dont forget Pre-RS traceability!
• Obtain, organize and maintain information
• Increase awareness of information
• Produced as a by-product of main activities
• Use automated tools

12
When is RT fit for use?

• Necessary when any one of these conditions hold
  true
• The customer requires it
• The project is complex
• You must see different types of documentation and
  their interrelationships
• You must ensure that you build and tested the
  system you claimed
• The system is safety critical

13
RT and Legacy Systems

• Systems are being used in an ever-changing real
  world domain
• require continued adaptation to changing needs
  and conditions
• ensure maintenance of user satisfaction
• to replace

14
RT and Legacy Systems

• Change, consequent upon system evolution, will
  commonly require a better understanding of the
  requirements
• Can only be achieved by going back to the source

Pre-RS Traceability
Post-RS Traceability
Requirements Specification
(S0)
(S1)
(Sn)
15
Is RT Needed for Legacy Systems?

• Yes...
• Helps manage changing requirements over the
  lifetime of a system
• but not all systems will benefit from RT
• Satisfy instances where RT will help rather than
  hinder
• Can be expensive to implement if the desired
  initial conditions are not in place

16
Applying RT to TRUMP CCS

• TRUMP CCS is a legacy system
• Developed during the 80s and implemented in the
  90s
• AN/UYK-507
• CMS-2
• SDX

17
Why Apply RT?

• Are the previous reasons for applying RT met?
• Does the customer require it?
• Yes

18
Why Apply RT?

• Is the project is complex?
• Yes

CCS
19
Why Apply RT?

• Must you see different types of documentation and
  their interrelationships?
• Yes

MMI
SRS
UM
20
Why Apply RT?

• Must you ensure that you build and tested the
  system you claimed?
• Yes

21
Why Apply RT?

• Is the system safety critical?
• Yes

22
Is RT Helping TRUMP CCS?

• Advantages
• Successfully track changes
• Small cost 5 of effort
• Limited remaining lifetime
• Weaknesses
• Limited remaining lifetime
• Lack of original SOR
• Concentrate effort on testing requirements

23
Questions?
(A Robs eye view)
24
References 1
1 Gotel, O. Finkelstein, A. (1994). An
Analysis of the Requirements Traceability
Problem. http//citeseer.nj.nec.com/gotel94analysi
s.html 2 Balasubramaniam, R Edwards, M.
(1993). Issues in the Development of a
Requirements Traceability Model. Proceedings of
the IEEE International Symposium on Requirements
Engineering, San Diego, California. pp
256-259. 3 Neal, M Watkins, R. (1994). Why
and How of Requirements Tracing. IEEE Software,
July 1994. pp 104-106. 4 Haumer, P Heymans,
P. et al. (1999). Bridging the Gap Between Past
and Future in RE A Scenario-Based Approach.
Proceedings of the IEEE Symposium on Requirements
Engineering, Limerick, Ireland. pp 66-73.
25
References 2

• 5 Finkelstein, A. (1991) Tracing Back From
  Requirements. IEE Colloquium on Tools
  Techniques for Maintaining Traceability During
  Design (IEE, London), Digest No 1991/180.
• 6 Kahen, G Lehman, M. et al. (1999) Can the
  Legacy Syndrome be Avoided?-Legacy Systems in the
  Context of Software Evolution. http//www-dse.doc.
  ic.ac.uk/Papers/
• 7 Davis, A. Leffingwell, D. (1999) Making
  Requirements Management Work for You.
  http//stsc.hill.af.mil/crosstalk/1999/apr/davis.a
  sp
• 8 Brooks, F. (1995) The Mythical Man-Month
  Essays on Software Engineering, Anniversary
  Edition. Addison Wesley Longman Inc, Berkeley.