Inah Omoronyia and Tor Stålhane Requirements Traceability

1. Institutt for datateknikk og informasjonsvitenskap Inah Omoronyia and Tor Stålhane Requirements Traceability TDT 4242 TDT 4242

2. What is requirements traceability “Requirements traceability refers to the ability to describe and follow the life of a requirement, in both a forwards and backwards direction, i.e. from its origins, through its development and specification, to its subsequent deployment and use, and through periods of on-going refinement and iteration in any of these phases.” Gotel and Finkelstein TDT 4242

3. Traceability Goals - 1 • Project Management • Status: “When will we finish?” and “what will it cost?” • Quality: “How close are we to our requirements?” • QA manager • Improve Quality: “What can we do better?” • Change Management • Versioning, documentation of changes (Why? What? When?) • Change Impact analysis • Reuse • Variants and product families • Requirements can be targeted for reuse TDT 4242

4. Traceability Goals – 2 • Validation • finding and removing conflicts between requirements • completeness of requirements • derived requirements cover higher level requirements • each requirement is covered by part of the product • Verification • assure that all requirements are fulfilled • System Inspection • identify alternatives and compromises • Certification/Audits • proof of being compliant to standards TDT 4242

5. Habitat of Traceability Links – 1 TDT 4242

6. Habitat of Traceability Links – 2 Pre- vs. Post-Requirements Specification TDT 4242

7. Challenges of traceability – 1 • Traces have to be identified and recorded among numerous, heterogeneous entity instances (document, models, code, . . . ). It is challenging to create meaningful relationships in such a complex context. • Traces are in a constant state of flux since they may change whenever requirements or other development artefacts change. TDT 4242

8. Challenges of traceability – 2 • A variety of tool support • based on traceability matrix, hyperlink, tags and identifiers. • still manual with little automation • Incomplete trace information is a reality due to complex trace acquisition and maintenance. • Trust is a big issue: lack of quality attribute • There is no use of the information that 70% of trace links are accurate without knowing which of the links forms the 70% TDT 4242

9. Challenges of traceability – 3 Different stakeholders usage viewpoint (different questions asked by different stakeholders): • QA management: • “how close are we to our requirements” and “what can we do better” to improve quality. • Change management • Tracking down the effect of each change to each involved component that might require adaptations to the change, recertification or just retesting to proof functionality. • Reuse: • Pointing out those aspects of a reused component that need to be adapted to the new system requirements. • Even the requirements themselves can be targeted for reuse. TDT 4242

10. Challenges of traceability – 4 Different stakeholders usage viewpoint (different questions asked by different stakeholders): • Validation: • Tracability can be used as a pointer to the quality of requirements: • Completeness, ambiguity, correctness/noise, inconsistency, forward referencing, opacity • Ensures that every requirement has been targeted by at least one part of the product • Verification • Checking that constraints are not violated (in most cases this is an extension of validation context) • Certification/Audit • Testing, maintenance (reverse engineering) TDT 4242

11. Traceability meta-models – 1 • A model is an abstraction of phenomena in the real world; a meta model is yet another abstraction, highlighting properties of the model itself. • Meta-models for traceability are often used as the basis for the traceability methodologies and frameworks: • Define what type of artefacts should be traced. • Define what type of relations could be established between these artefacts. Traceability Meta Model TDT 4242

12. Traceability meta-models – 2 Low-end traceability TDT 4242

13. High-end traceability TDT 4242

14. Traceability meta-models – 3 European EMPRESS project: Meta model for requirements traceability

15. Traceability meta-models – 4 PRECISE Meta-model (SINTEF)

16. Approaches to traceability Creating trace links: • Critical tasks in requirements traceability: establish links between requirements and between requirements and other artefacts. • Manual linking and maintaining of such links is time consuming and error prone • Focus is on requirements traceability through (semi-)automatic link generation.

17. Manual trace links – 1 • This is the classical traceability methods and • the simplest form of traceability. In this approach, we create a requirements traceability matrices using a hypertext or table cross referencing scheme, often using Excel • Two problems • Long-term difficulty of maintaining a large numbers of links. • The static nature of the links (lack of attributes) limit the scope of potential automation.

18. Manual trace links – 2

19. Scenario driven traceability – 1 • Test-based approach to uncover relations amongst requirements, design and code artifacts (Alexander Egyed ) • Accomplished by observing the runtime behavior of test scenarios. • IBM Rational PureCoverage, open source tool (org.jmonde.debug.Trace) • Translate this behavior into a graph structure to indicate commonalities among entities associated with the behavior

20. Scenario driven traceability – 2 • The method to achieve traceablity uses the idea of “footprint”. • When we are dealing with traceability, a footprint contains two types of information: • The set of classes that were executed when we were testing a specific scenario. • The number of methods that were executed in each class.

21. Footprints – 1 E.g. scenario A uses 10 methods in class CAboutDlg and 3 methods in Csettings Dlg

22. Footprints – 2 Only classes are registered – e.g scenario [s3] uses classes C, J, R and U

23. Footprints – 3 • Some problems: • There might be scenarios that do not cover any requirement – e.g. [s3] • There are scenarios that belong to several requirements, e.g. [s9] • Such scenarios will get separate rows in the trace matrix and will be marked with an F (Fixed) or a P (Probable), depending on how sure we are that a certain class belongs to this scenario.

24. Footprints – 4 Based on the footprint table, we can make a requirements-to-class trace table

25. Footprints – 5 Each test scenario will leave a footprint. If we make one test scenario per requirement, then we get one footprint per requirement. We can make the footprints more fine grained and thus get more information by using methods or code chunks instead for classes. This will require more work but also more – better – traceability information.

26. Development footprints - 1 • A solution that enables the project to construct traceability information during development has been suggested by I. Omoronyia et al. • The method requires that each developer • Always identifies which requirement – e.g. use case – he is currently working on • Only works at one use case at a time

27. Development footprints - 2 The result will be similar to the scenario testing footprint table. The resulting table will show which documents, classes etc. have been accessed during work on this particular requirement – e.g. use case. Main problem: “false” accesses – e.g. a developer looks at some of the code of another requirement for info.

28. Development footprints - 3 • We can extract more info from the development process in order to understand better what has been going on in the project. The next slides shows • Types of access: C – Create, U – Update and V – View • Timeline – e.g. date or time • Person – who did what and, more important, who will have expertise on what? • Each line in the table will show

29. Development footprints - 4

30. Scenario driven traceability – 3 Problems: • Semi-automated but requires a large amount of time from system engineers to iteratively identify a subset of test scenarios and how they related to requirement artifacts. • Requirements that are not related due to non matching execution paths might be related in some other form (e.g calling, data dependency, implementation pattern similarity, etc).

31. Trace by tagging – 1 • This method is easy to understand and simple to implement. The problem is that it depends on heavy human intervention. • The principle is as follows: • Each requirement is given a tag, either manually or by the tool. • Each document, code chunk, etc. are marked with a tag which tells which requirement it belongs to

32. Trace by tagging – 2

33. Trace by tagging – 3 • There are several ways to create tags, e.g.: • Single level tags – e.g. R4. This gives a standard trace matrix • Multilevel tags – e.g. R4, R4.1 and R4.2 where R4 is the top level requirement and R4.1 and R4.2 are sub-requirements. This gives us more detailed trace information

34. Trace by tagging – 4 The quality of traceability through tagging will depend on that we remember to tag all relevant documents. It is possible to check automatically that all documents in the project database is tagged. It is, however, not possible to check that this tagging is correct.

35. Conclusion • Requirements traceability is an important aspect of requirements management • Stakeholders have different traceability information needs • Traceability can be complex for not trivial projects • Traceability meta-models provide insight on the type of traceability information required for a project • There exist several automated approaches for requirements traceability. The strength is in a synergy of different automated approaches