Transcript Traceability

Traceability
Systems Engineering STD
Requirements Management2
Traceability
Contents
•
•
•
•
Terminologies
Techniques
A model of traceability
Tools : case study
(RTM, Slate, DOORS : what will be available at HPI !!)
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)
A recent event : Mad cow and Hamburger !!
?
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
Techniques
• Objectif : get all links during lifecycle of
requirement
•
•
•
•
•
•
Link to stakeholders
Associated design
Associated implementation
Validation procedure
Concept of operation
Etc ...
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
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)
Traceability Matrix
• Used to relate requirements to others software
developments artifacts
The relation can be allocatted a type
Req
Spec.Si
Design Di
S/w modules
R1
R2
Rn
X
N/A
X : relational link between a requirement and a design
N/A : Non applicable (no apparent link)
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"
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
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
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
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
A model of traceability
Requirements
Model
Requirements
Traceability
Design Model
Implementation
Model
A model of traceability
Separation between source and other objects
- A manager
- A user
STACKHOLDER
-Email
-Doc
- A programmer
- phone call
Is concerned by
Manages
OBJECT
SOURCE
Documents
- A Requirement
Traces to
-Meeting minutes
- A Designed architecture
- A software module
A model of traceability
Requirement
Developed_for
Verification_proced
satisfy
Derive
Performed_on
Allocated_to
Syst_components
Interface_with
External_System
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)
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
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.
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
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
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
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)
Next lecture
Requirements management
Traceability
Validation and Verification
Paper Reading and assignments
• Paper reading
Mandatory : Traceability : IEEE Trans jan 2001 by Jark &
Ramesh
• Other : see list paper reading assignment