A Comprehensive Approach to Requirements Traceability

1
A Comprehensive Approach to Requirements
Traceability

• Susanne A. Sherba
• November 4, 2002

2
Overview

• Definitions
• Importance of traceability
• Traceability problems
• Requirements for traceability
• Current tools
• Our approach
• Plan
• Contributions

3
Traceability Definitions (I)
Requirements traceability refers to the ability
to describe and follow the life of a requirement
, in both a forwards and backwards direction.
Gotel and Finkelstein, 1994

• Pre-requirements traceability
• Post-requirements traceability

4
Traceability Definitions (II)

• A link or definable relationship between
  entities.
• Watkins and Neal, 1994

An SRS is traceable if the origin of each of its
requirements is clear and if it facilitates the
referencing of each requirement in future
development or enhancement documentation. IEEE
Standard 830-1998
5
Importance of Traceability (I)

• Traceability gives essential assistance in
  understanding the relationships that exist within
  and across software requirements, design, and
  implementation.
• Palmer, 2000

• You cant manage what you cant trace.
• Watkins and Neal, 1994

6
Importance of Traceability (II)

• Often mandated by standards or contracts
• Benefits listed in literature include
• Improved software quality
• Prevention of knowledge loss
• Verification
• Impact analysis and change control
• Monitoring the process

7
Problems (I)

• Various stakeholders require different
  information
• Huge amount of information must be tracked and
  maintained
• Specialized tools must be used

8
Problems (II)

• Heterogeneous artifacts
• Time-consuming and expensive to capture
  relationships manually
• Difficulties related to tracing generally
  revolve around the necessity to manually add
  trace elements to requirements documents and
  subsequent work products from software
  development Palmer, 2000

9
Traceability Requirements (I)

• Traceability must be established and recorded for
  the entire software life cycle.
• The creation and maintenance of traceability
  relationships must be automated.

10
Traceability Requirements (II)

• Stakeholders must be able to create a view of
  traceability relationships based on their
  information needs.
• It should be possible to create traceability
  relationships both during and after artifact
  creation.

11
Traceability Requirements (III)

• Users should be able to create and view
  traceability relationships within the tools they
  are accustomed to using.

12
Current Approaches

• Database
• Information Retrieval
• Runtime
• Process-Centered

13
Our Approach

• Overview
• Hypotheses
• Conceptual Framework
• Implementation

14
Approach Overview (I)

• Our focus is on artifacts produced during the
  software life cycle, not the life cycle itself.

• Software development is a document-based process
  -- each step in the development involves the
  preparation, manipulation or verification (in
  some sense) of one or more documents.
• Welsh and Han, 1994

15
Approach Overview (II)

• We address life cycle concerns by providing
  support for the specification and capture of
  relationships between software artifacts.

• Software documents are logically related to each
  other according to the software process.
• Han, 1994

16
Hypotheses

• Open hypermedia and information integration
  techniques can be used to make previously
  difficult aspects of the requirements
  traceability problem feasible.
• A requirements traceability approach based on
  open hypermedia and information integration can
  help automate the creation of requirements
  traceability links to a significant degree.

17
Conceptual Framework

• Tool
• Artifact
• Relationship
• Metadata

18
Conceptual Traceability Framework
19
Open Hypermedia

• Ability to create and view relationships in the
  original tools
• Relationships displayed at any time
• Representation of complex relationships
• Filtering of relationships

20
Information Integration (I)
21
Information Integration (II)

• Manipulation of heterogeneous artifacts
• Automated creation of relationships
• Customized views of information space

22
Metadata

• Allows users to describe artifacts and
  relationships produced during their customized
  software development process
• Exact structure is still an open issue

23
Artifact Metadata

• Name
• Types (Physical and Semantic)
• Versioning
• Keywords
• Translators to apply
• User-defined attributes

24
Relationship Metadata

• Name
• Type
• Artifacts involved
• Versioning
• Keywords
• Integrators to apply
• User-defined attributes

25
Traceability Services (I)

• Scheduling
• Allows translators and integrators to be invoked
  based on set of criteria or turned on and off
• Relationship Mapping
• Allows relationship navigation from one artifact
  to another
• Evolution of Artifacts and Relationships

26
Traceability Services (II)

• Registration
• Informs users of current relationships and
  artifacts the system knows about
• Allows users to register new translators and
  integrators
• Query
• Provides customized views of the information
  space
• Export

27
Implementation Approach (I)

• To evaluate our approach, we propose to build
• A requirements traceability system that
  implements our conceptual framework
• A representative set of translators and
  integrators

28
Requirements Traceability System

• The system will provide the required traceability
  services.
• A method definition tool will allow users to
  define artifact and relationship metadata.
• We plan to use Chimera for open hypermedia
  services and InfiniTe for information integration
  services.

29
Prototype Translators and Integrators

• We propose to build a representative set of
  translators and integrators to apply to artifacts
  of a simulated software development process.
• Unified Software Development Process
• Pre-requirements artifacts
• Source code
• Issues

30
Tool Integration

• Word Processor
• E-mail
• UML diagramming tool
• Integrated Development Environment (IDE)
• Issue Tracking System
• Version Control System

31
Plan

• Evaluation
• Open Issues
• Time Line

32
Evaluation (I)

• Create artificial artifacts based on our
  simulated software development process
• Evaluate effectiveness of services and APIs

33
Evaluation (II)

• Evaluate the approach using real world data
• Possible sources
• Simulate real software development process
• Obtain actual industry data
• Data from department projects

34
Evaluation (III)

• Evaluate user interface for appropriateness and
  ease-of-use
• Based on computer science graduate students using
  the tool
• Task analysis and discount useability techniques

35
Open Issues (I)

• Structure of metadata
• Relationship and artifact taxonomies
• Create high-level taxonomies which users can
  subclass
• Issue of multiple types has not been resolved
• Physical and semantic types for artifacts

36
Open Issues (II)

• Versioning
• Only current version recognized
• With respect to the information integration
  environment
• As maintained by a version control system

37
Open Issues (III)

• InfiniTe Version 2.0 (Structure Server)
• InfiniTe Integration
• Software Tool Integration

38
Time Line
39
Contributions (I)

• We will specify and partially implement a
  comprehensive approach to requirements
  traceability that addresses gaps in the
  state-of-the-art with respect to automation, life
  cycle coverage, and heterogeneity of artifacts.

40
Contributions (II)

• We will provide an approach for detecting,
  evaluating, and viewing system evolution based on
  the evolution of artifacts and their
  relationships.

41
Contributions (III)

• We anticipate that we will expand the techniques
  and tools used in the area of information
  integration.

42
Summary

• Definitions
• Importance of traceability
• Traceability problems
• Requirements for traceability
• Current tools
• Our approach
• Plan
• Contributions

43
Questions?
44
Additional Background Slides
45
A Traceability Reference Model

• Ramesh and Jarke, 2001
• Derived from empirical studies
• Meta model plus two models
• Low-end model
• High-end model

46
Traceability Meta Model
47
Low-end Traceability Model
48
Requirements Management Sub-model
49
Process-Centered Requirements Engineering

• Klaus Pohl, 1996
• Traceability capture within a process-centered
  engineering environment

50
Repository-based Approach for PCEE
51
Traceability meta model
52
Taxonomy of Dependency Types
53
Other Traceability Tools
54
TRAM
55
ARTS
56
TOOR
57
ATS
58
DOORS
59
Rational RequisitePro
60
Information Retrieval Tools
61
TraceAnalyzer
62
Unified Software Development Process