Presentation is loading. Please wait.

Presentation is loading. Please wait.

Traceability Requirements Management2 Traceability Systems Engineering STD.

Similar presentations

Presentation on theme: "Traceability Requirements Management2 Traceability Systems Engineering STD."— Presentation transcript:

1 Traceability Requirements Management2 Traceability Systems Engineering STD

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 Spec.Si Req R1 R2 Rn Design Di S/w modules X X : relational link between a requirement and a design N/A : Non applicable (no apparent link) N/A The relation can be allocatted a type

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 Separation between source and other objects -Email -Doc - phone call -Meeting minutes - A Requirement - A Designed architecture - A software module - A manager - A user - A programmer

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 Validation and Verification Requirements management Traceability

26 Paper Reading and assignments Paper reading Mandatory : Traceability : IEEE Trans jan 2001 by Jark & Ramesh Other : see list paper reading assignment

Download ppt "Traceability Requirements Management2 Traceability Systems Engineering STD."

Similar presentations

Ads by Google