| Tutorial on Traceability |
TABLE OF CONTENTS
Requirements traceability is intended to ensure continued alignment between stakeholder requirements and various outputs of the system development process (Balasubramaniam, 2001). Traceability gives essential assistance in understanding and communicating the relationships that exist within and across system development requirements, design and implementation." These relationships allow designers to show that a design meets requirements and help in the early recognition of requirements that are not satisfied by the design. During design, traceability allows designers to track what happens when a change request is implemented before a system is redesigned. Traceability is helpful if it can link designs to justifications, important decision and assumptions and context within which design solutions are arrived at (Ramesh, 1997).
Therefore, with complete traceability more accurate costs and schedules of changes can be determined, rather than depending on the engineer to know all of the areas affected by these changes.
This process is complicated by the many different stakeholders involved in the system development lifecycle. Many problems in traceability stem from their differing goals and priorities of interest (Ramesh, 1993).
User Perspective of Traceability
Developer Perspective of Traceability
Types of Traceability Link
Fundemental Problems with Traceability
There is a clear need for reference models and guidelines for use in systems development. Comprehensive models would ensure traceability throughout all phases of the system development process.....
Difficulties
Several military standards required the development of requirements traceability documents.
Basic issues are as follows:
Levels of Traceability
Reference Models
Reference models are organized according to an underlying metamodel; they are difficult to construct because they are an abstraction of best practice, condensed from numerous case studies over an extended period of time.
Reference Models for Traceability....
Importance of requirements traceability -- the U.S. Department of Defense spends approximately 4% of its IT costs on traceability. Too often traceability procedures and processes are haphazard, standards provide little guidance, and the models and mechanisms are poorly understood. Accordingly, the market for traceability tools is booming even though current tools support rather simple traceablity models are services.
Types of Traceability Link
Traceability mechanisms support the capture and usage of trace data (i.e., to document, parse, organize, edit, interlink, change, and manage requirements and traceability links between them.
The semantics of a given linkage as viewed by different stakeholders may differ. For instance, consider the following relationship maintained in a traceability table:
REQUIREMENT ---- LINKED-TO ---- DESIGN object.
An end user may view the relationship as a means to idejntify a design component that is generated by a requirement. A designer may view the same linkage as providing information on the requirement/constraint that restricts the design object(s). The semantics associated with a linkage is guided by the reasoning that the user will be performing with the linkage.
The meta-model framework consists of:
Meta-Model
STAKEHOLDER
has role in manages
OBJECT documents SOURCE
The dimensions of traceability information are as follows:
In the model, OBJECTS represent the inputs and outpus of the system development process. Examples of OBJECTS include: Requirements, Assumptions, Designs, System Components, Decisions, Rationale, Alternatives, Critical Sucess Factors.
These represent the conceptual objects among which traceability is maintained.
OBJECTs are created by specific tasks (e.g., design and analysis tasks).
Traceability across various objects is represented by TRACES-TO links (e.g., a DEPENDS-ON link between two objects, perhaps a REQUIREMENT and an ASSUMPTION, can be treated as a specialization of TRACES-TO.
STAKEHOLDERS represent the agents involved in the system development and maintenance life cycle activities.
All OBJECTS are documented by SOURCES, which may be physical media, such as documents, references to people or undocumented policies and procedures.
Examples of SOURCES include REQUIREMENTS SPECIFICATIONS, DOCUMENTS, MEETING MINUTES, DESIGN DOCUMENTS, .... etc. STAKEHOLDERS manage SOURCES.
We need to represent the rationale behind creation, modification, and evolution of conceptual OBJECTS.
Low-End Users of Traceability
About 1,000 requirements (viewed as a mandate from the project sponsors or for compliance with standards). -- User definition of traceability : documents transformation of requirements to design. -- Main applications of traceability : requirements decomposition, requirements allocation, compliance verification, change control.
Typical low end users view requirements traceability as providing a link from REQUIREMENTS to the actual system COMPONENTS that satisfy these requirements. Before this can happen, however, REQUIREMENTS must be derived from higher-level system requirements.
Original and derived REQUIREMENTS and ALLOCATED to the system COMPONENTS. An "allocation table" is the common mechanism use to maintain this information. This simple two-way mapping between requirements and system components is used to ensure that there are COMPONENTS in the system that satisfy all requirements.
In the compliance verification phase of systems development, low-end users employ the requirements database to develop system compliance verification procedures.
Typically, low-end users lack support for capturing rationale for requirements issues and how they are resolved. Similar information is also missing from the design and analysis phases of development.
High-End Users of Traceability
About 10,000 requirements (viewed as a major opportunity for customer satisfaction and knowledge creation throughout the system lifecycle).
High-end users of traceability use much richer traceability schemes than low-end users and also employ traceability information in must richer ways. Problems associated with the latter can be classified as follows:
Systems are created to satisfy organizational, stakeholder, operational and strategic needs.
System objectives must be justified by organizational needs. As part of the negotiation process among stakeholders, many trade-offs are made in deciding the scope and functionality of the system based upon their impact on critical sucess factors (CSFs) (or in GE nomenclature, measures of effectiveness).
Not all requirements are of equal significance or criticality. (see, .... pg. 70).
The specification, elaboration, decomposition, derivation and modification of OBJECTS (e.g., requiremnts, designs) generate issues or conflicts (due to differing interpretations, assumptions, interests, viewpoints and stakeholder objectives). Traceability pathways of rationale enable accountability (e.g., what changes have been made; why and how they were made), particularly to stakeholders not directly involved in creation of the requirement.
Information about how to resolve these issues must be maintained throughout the system lifecycle to the ensure customer requirements are understood and satisfied.
For example, various alternatives that address the resolution of issues are normally considered. Arguments for and against each alternative may be proposed.
A complete and detailed capture of rationale may be impractical due to the lack of tools. However, simple descriptions of rationale on which requirements or design are based may be recorded along with the assumptions behind them.
This term refers to the activity that creates artifacts, including implementation. Key elements are REQUIREMENTS that drive DESIGN, which in turn are based on mandates such as standards, policies or methods. Requirements are allocated to components.
Components are also organized into hierarchies and networks -- we would like some form of traceability to record relationships among components.
Compliance and verification procedures (CVPs) are developed to ensure that each requirement is satisfied (If a requirement cannot be tested, then by definition, it is no longer a requirement).
Formally, a traceability system can be defined as a semantic network in which nodes represent objects among which traceablity is established through links of different types/strengths. This dependency-directed approach of maintaining consistency of design dates back at least to the work of Stallman and Sussman (Stallman, 1977).
Product-Related Links for Traceability Context
These links describe properties and relationships of design objects, independent of how they were created.
Process-Related Links for Traceability Context
These links describe the history of actions taken in the process itself.
Note. Low-end traceability users tend to be characterized by relying mostly on the product-oriented links (i.e., types (1) and (2)). High-end traceability have a higher share of link types belonging to (3) and (4).
These links are accomplished through connectivity of requirements to sets of system components that satisfy them. These links may be indirectly derived. For example, a design component may be linked to requirements the former satisifies. The design component, in turn, may become a system component....
The majority of present traceability tools offer tabular representations of dependency structures in a relational database formalism (i.e., they are well sorted to low-user users that require little differentiation between link types; simple allocation and dependency analysis).
Limitations
Limitations : Types of Dependency and Inferencing Services
Trade-off : effort needed to capture complex traceability information versus the subsequent value of having this information in each situation of the development process. These observations indicate that a new generation of traceability mechanisms will be needed to address:
The relational representation used in most existing tools does not lend itself naturally to the simultaneous representation of traces at multiple levels of granularity.
Aggregation hierachies in semantic data models offer an adequate formal means for dealing with the granularity problem.
There is a strong need for more semantics in traceability data models, possibly facilitated by recent extensiblity features in object-relational database technology.
In large projects, the traceability knowledge base can become very large. As the information needs of participants can vary widely, navigating the entire knowledge base to retrieve relevant information can be very difficult, even with sophisticated browsing capabilities. The ability to access relevant information using ad hoc queries can be very helpful.
Inferencing techniques help to maintain the integrity of a knowledge base of interdependent components that get incrementally defined and modified. This ability can be aided by mechanisms for aggregation, classification and generalization of traceability information.
The ability to make deductive inferences from traceability knowledge base is very helpful in reducing the overhead and increasing the usefulness of the traceability knowledge base. Moreover, mechanisms to maintain and manage dependencies among various components of requirements traceability can be supported with deductive database capabilities for query processing, deductive rules and integrity enforcement.
Requirements traceability can be represented in a variety of ways, from formal representation (e.g., mathematical transformations from one form to another) to very informal represenstations (e.g., a textual description of design rationale in a notebook). There are pros and cons of both representations.
A strength of formal representations is their ability to support automated reasoning. But formal representations of requirements traceability is difficult as most design situations lack well-defined formal models.
To complicate matters, design is very much a collaborative process, with requirements traceabilit knowledge consisting of deliberations among individuals engaged in the process. Attempts to represent informal knowledge through formal tools and notations can result in thin descriptions, with the consequence that much of the meaning embedded in such information is lost (Anderson, 1991).
Informal representations of requirements address many of these problems. These so-called "thick descriptions" enable the user of requirements traceability to grasp subtleties, tacit and mutual knowledge and glean descritions of work practices that are not otherwise made explicit. Moreover, imformal repreesentations can be used by a wide set of users. On the downside, indexing, retrieval and use of informal representations/languages in large projects can be impracticable. Although understandable by humans, informal representations are not amenable to automated reasoning.
Effective schemes for the capture and use of requirments traceability should seek to combine (i.e., a tight integration of formal and informal methods for requirements traceability) the advantages of both forms of representations.
REFERENCES
WEB RESOURCES ON TRACEABILITY
Developed in September 2001 by Mark Austin
Copyright © 2001, Mark Austin, Institute for Systems Reseach, University of Maryland