Traceability

1
Traceability
Systems Engineering STD
Requirements Management2 Traceability
2
Contents

• Terminologies
• Techniques
• A model of traceability
• Tools case study
• (RTM, Slate, DOORS what will be available at
  HPI !!)

3
What specific to Traceability in Req. Management ?

• Traceability increase software quality throughout
  the life of the project
• Most important issue in RM
• Many facets of Soft.Eng. Can be improved through
  RT
• Standard 2167A (US DoD)

4
A recent event Mad cow and Hamburger !!
?
5
Terminologies

• Part of requirement management process
• Technique to provide relationship between
  requirement design and final implementation
• How and why system development products satisfy
  stakeholders requirements
• Ability to discover the history of every feature
  of a system
• A quality factor
• Many standards (2167-A then 498) require the
  development of traceability documents

6
Techniques

• Objectif get all links during lifecycle of
  requirement
• Link to stakeholders
• Associated design
• Associated implementation
• Validation procedure
• Concept of operation
• Etc ...

7
Techniques

• Cross reference schemes
• Keyphrase dependancy
• Templates
• Matrices
• Matrix sequence
• Hypertext
• Integration documents
• All differs in the intent of information
• traced and objective of tracing

8
Essence of traceability

• Of What (information)
• In what way (information prsentation)
• For whom
• Example Who coded the program
• Who we need the programmer
• What way name, the company, the team ?
• For whom to whom this information is addressed
• (not anybody can have any information
• information abstraction and ... Security)

9
Traceability Matrix

• Used to relate requirements to others software
  developments artifacts

The relation can be allocatted a type
Spec.Si



Design Di
S/w modules
Req
R1
R2
X
Rn
N/A
X relational link between a requirement and a
design N/A Non applicable (no apparent link)
10
Cross references and index schemes

• References made across several items (design,
  modules, requirements,..) in order to link two
  items or artifacts.
• Example There should be a high-level of
  traceability between "Logical Architecture" and
  "Physical Architecture"
• The logical and physical architecture are tied
  together with a collection of cross-reference
  tables in the "Traceability Matrix"

11
Tracing languages

• Database query languages
• Used in existing powerfull RT tools (RTM use
  runtime version of Oracle)
• Regular expressions
• Used in formal TOOR approach
• TOOR
• is designed for tracing requirements in system
  development.
• It considers as objects, in the computing science
  sense of the word, any artifacts used during the
  development of a software system, e.g., an
  interview transcript, a video tape, a design
  chart, a program specification text, a system
  manual, etc.
• It also considers the possible relations between
  any two objects as an object itself

12
Tracing Process and models

• Trace definition precise semantic (formalising
  links between objects)
• Trace production results of action (ideally
  automated tracing production)
• Trace model link between classes dont give
  exact purpose of the link
• Trace extraction What are the requirement that
  are linked to a specific software or what are
  the software modules linked to a specific
  requirement
• Traceability support A huge amount of
  information to manage

13
TOOR . A formal approach

• Developped at Oxford (Goguen, Pinheiro)
• Object based (see RTM tool too)
• Declaration using FOOP (based on OBJ)
• Traceability links between any artifacts created
  by different documents
• Graphical interface
• Tracing are forward and backward

14
TOOLS RTM

• Requirements Traceability Module (Chipware)
• Other tools DOORS (telelogic), Slate (QSS)
• Essential approach
• A generic meta model
• All links are specified in the relation between
  between classes
• Document generation
• Can be customised to any meta-model defined by
  user

15
A model of traceability
16
A model of traceability
Separation between source and other objects

• A manager
• A user
• A programmer

• -Email
• Doc
• phone call
• Meeting minutes

• A Requirement
• A Designed architecture
• A software module

17
A model of traceability
18
Dependancy links issues

• Existence of a link and its meaning
• Stakeholders dependencies
• Requirements dependancies a requirement is
  based on the assumption on satisfaction of
  another requirements the software can be coded
  in C only if here is available compiler on
  operating systems imposed in another requirement
• Task dependencies
• Resource dependancies
• Temporal dependancies (temporal order)

19
Relative importance of dependancy links

• Attribution of weight on on link
• Qualitative
• Quantitative
• Example The voltage change in one component
  affect another component
• Links can be many levels of abstraction
• Requirement and derived rtequirement
• Requirement and stackholder
• Not injective or surjective relation

20
Conclusions

• A model of traceability should be defined
• A need for a tool
• Two way to implement the tool
• Specific tool for RT
• A database system as Oracle.

21
Conclusions and recommendations

• State of the art and limitations
• All approaches require a great deal of manual
  effort to define the links
• All rely on purely syntactic information with no
  semantic or context
• capture situations where many people participate
• Capture changing patterns of participants

22
Conclusions and recommendations

• Informational problem
• Tracking useful information
• Inadequate prerequirement traceability
• Informal communication
• People attach great importance to personal
  contact and informal communication
• These always supplement what is recorded in
  database
• Traceability links database tells only a part of
  the story
• Finding the appropriate people

23
Conclusions and recommendations

• Involvement
• ?Who has been involved in the production of a
  requirement and how
• Responsibility
• Who is responsible for a specific requirement
• Who is currently responsible
• Context in defining change of responsibility
• Change
• At what point in the life of a requirement a need
  for a change is possible
• Who needs to be informed by a change

24
Conclusions and recommendations

• Loss of a knowledge
• ? What are the items regarding the loss of a
  project knowledge due to turnover over concerned
  personnel
• Others
• Verification and validation
• Maintenance
• Coverage (types of links)

25
Next lecture
Requirements management Traceability
Validation and Verification
26
Paper Reading and assignments

• Paper reading
• Mandatory Traceability IEEE Trans jan 2001 by
  Jark Ramesh
• Other see list paper reading assignment