Funding IT / KM

1
Institutt for datateknikk og informasjonsvitenskap

• Inah Omoronyia and Tor Stålhane
• Requirements Traceability

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

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

5
Habitat of Traceability Links 1
6
Habitat of Traceability Links 2
Pre- vs. Post-Requirements Specification
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.

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

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.

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
12
Traceability meta-models 2
Low-end traceability
13
High-end traceability
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