1 / 26

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 ?.

baldwin
Download Presentation

Traceability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 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

More Related