Requirements Tracing

Chapter 2 Requirements Tracing

Chris Fetters, Thomas Hsu, and Bill Smeed

cfetters@lucent.com, hthsu@lucent.com, kcdeberg@excite.com

Requirements Tracing is defined as the ability to describe and follow the life of a requirement, in both a forward and backward direction, through the whole systems life cycle [1]. Requirement Tracing can be accomplished with varying degrees of quality. There are multiple environments in which requirement tracing can be performed. Environments may include tools to assist in the process. In this paper, some of the factors that affect the quality of tracing, some of the different environments in which tracing can be performed, and some of the tools that assist in requirement tracing will be discussed.

Table of Contents

Introduction 2

Methods to Perform Requirement Tracing 2

Levels of Practice for Requirement Tracing 3

Adapting Traceability Environments to Project-Specific Needs 5

Traceability Tools/Environments 7

Requirement Tracing Tools 9

Conclusion 11

Questions 11

References 12

Introduction

Requirements Tracing is defined as the ability to describe and follow the life of a requirement, in both a forward and backward direction, ideally through the whole systems life cycle [1]. Requirements tracing should capture all levels of requirement engineering. These levels can be defined as the technical, cognitive, and social levels. The technical level can be described as taking the customer’s interests and needs and applying them to the product’s goals, constraints, and outcomes. The cognitive level is developing an understanding between the customer and the supplier on the functionality, nonfunctionality, and possible side effects of the technical level. Finally, the social level is documenting the technical and cognitive levels in a comprehensive manger.

Methods to Perform Requirement Tracing

The ability to perform requirements tracing can be accomplished by four different types of links, utilizing both forward and backward direction tracing. The different links that can be created for requirement tracing, according to [1], are:

· Forward From The Requirements

· Backward To The Requirements

· Forward To The Requirements

· Backward From The Requirements

The link “Forward From The Requirements” can be described by assigning a requirement to one or more system components. Once this is done, then the component or components are “responsible” for the requirement. This type of link is good for evaluating impact of requirement change.

The link “Backward To The Requirements” is done when the compliance of the system or a system component is mapped back to the requirements. This type of link will show that the requirement has been tested or verified for the system.

The link “Forward To The Requirements” can be described by taking the customers needs and technical assumptions and linking them to a requirement or requirements. If the customer's needs or a technical assumption changes, then the requirements can be analyzed for impact.

The link “Backward From The Requirements” will give the ability to validate the requirement or requirements by the customers needs or technical assumptions.

When these links are examined closer they can be broken down into two different types. The first two links can be considered post-traceability links. They link requirements to design and implementation, documenting responsibility assignment, compliance verification, or impact analysis or a requirement [1]. The latter two links can be considered pretraceability links. They capture the essence or the meaning of how the requirements are created.

Levels of Practice for Requirement Tracing

Ramesh, in the article, "Factors influencing requirements traceability practice," performed a study on development organizations to evaluate requirement tracing [2]. In the study it was found that organizations fall into two main categories when they perform requirement tracing: low-end users and high-end users.

Low-end users view traceability simply as a mandate from project sponsors. It is viewed as a means to satisfy their customer's needs. High-end users view traceability as an important component of a quality system engineering process [2]. It is viewed as a means to improve their quality and engineering processes.

There are several factors that influence how requirement tracing is performed in different organizations. Along with these factors the general practices and philosophies of requirement tracing in an organization will determine what type of category the organization may fall into. Between the two categories the quality of requirement tracing will vary as expected. For this reason, the factors and some of the organization’s general practices will be explored. It should be noted, even though a company could fall into the “low-end user” category for requirement tracing does not mean that the organization has “bad” overall practices for developing software.

Factors Influencing Requirement Tracing

Three factors that influence requirement-tracing practices in organizations are environmental, organizational, and technical or also know as system development.

The environmental factor deals with technologies available to the organization. Normally this factor is the same between the high and low-end users because many organizations have similar access to tools. However, the high-end user generally customizes tools or even creates their own tools to achieve specific objectives.

The organizational factor focuses on corporate strategies of the organization. The low-end user views requirement tracing as a mandate from its customers or as something they "have to do." High-end users view requirement tracing as a means to improve the quality of their products, reduce cost, and achieve a competitive advantage.

The technical factor, also known as the system development factor, concentrates on the system development process and staff. The high-end users have a complete, well-defined process for requirement tracing and the staff of the high-end users will execute the requirement tracing process. Low-end users normally do not have a complete, spelled-out process and often employ an outside contract house to complete their requirement tracing mandates.

Practices that Affect Requirement Tracing Quality

The three factors above influence the practices and philosophies on how organizations perform requirement tracing. These practices and philosophies in turn will affect the quality of requirement tracing. Below, some of the practices and philosophies of low-end and high-end users are explored to show how the quality of requirement tracing can vary.

Goals of the organization affects the outcome of requirement tracing. The low-end user's goal is to just satisfy the customer’s requirements. The high-end user's goal is product quality and process improvement. Therefore, a conclusion can be made that low-end users do not really do much with the output of the trace where as high-end users examine and use the trace to improve.

The methodology used for requirement tracing will greatly affect the quality of requirement tracing. It was found by Ramesh that low-end users typically do not have a methodology to perform requirement tracing. They use ad-hoc methods on what data to collect, how to collect it, who collects it, and how to use it. High-end users have a set methodology, normally across products, that explains the process for what data is to be collected, how it is collected, who collects it, and how the data will be used. This allows the high-end users to get consistent and accurate data from each project for analyzing.

The data that is collected as part of the methodology for requirement tracing is important. Low-end users normally collect data uniformly across all the requirements. This is not necessarily the best approach because, “all requirements are not created equal.” High-end users will typically collect data only on the critical requirements. By doing this, resource allocation is optimized to provide the best return for the time and effort spent. When this is done, only the important information is stored and analyzed which cuts down on cost, overhead, and confusion.

High-end and low-end users use the previously described links in different ways. The main difference between the two types of users is that high-end users typically capture data that addresses where the requirements come from and low-end users normally just use the post-traceability links. The high-end users also use the pre-traceability information on technical assumptions, customer needs, and decisions made that affect the product. This method is used to obtain a better understanding of the requirements so that discrepancies between the assumptions and the requirements can be addressed. Using both types of links gives the high-end users a better ability to maintain the links between the phases of the software life cycle. Low-end users normally just use the post-traceability links.

The type of traceability documents themselves can affect quality also. Low-end users typically consider requirement tracing documentation static. This can lead to confusion if a change is made to the product. High-end users consider the documentation to be dynamic. A dynamic document reflects the product accurately during any phase of the software life cycle. However, this is not always feasible due to high overhead.

A wide range of tools exist to aid in requirements tracing. High-end users attempt to use tools that are integrated into their development environment. These tools will address the different aspects of software development. High-end users may develop supplementary in-house tools to support project specific needs. Low-end users frequently use trace tools with a relational database. Information that they collect gets entered into the database and forms a traceability matrix. Tools used by low-end users often lack functionality and normally are not part of the development environment.

Cost and schedule is always a factor in the software development process. Since low-end users view requirement tracing as expensive overhead, it tends to be one of the last activities performed and one of the first cut in a schedule crunch. Since the philosophies of high-end users are different than low-end users, they build requirement tracing into their schedule and budget, so the activity is integrated into the development process.

Human factors come into play when it comes to the quality of requirement tracing. Some of these factors include buy-in, training, fear, and rewards. High-end users will get buy-in to do requirement tracing from their staff by demonstrating its effectiveness through pilot programs. Once achieved, the staff is trained and the program is implemented globally for the organization. Rewards are often given to the staff of high-end users for a job well done. Requirement tracing is not used to hold individuals accountable so there is no fear of job security for staff of high-end users. Typically, low-end users do not perform pilot or training programs so the staff has no buy-in. Therefore, staff of low-end users will be concerned about lowering their productivity when doing requirement tracing. Since this concern is relevant for the staff of low-end users, the issue of job security arises.

Adapting Traceability Environments to Project-Specific Needs

Requirement traceability means that one could follow the life of each requirement from its origin to the product development (from customer needs translated to each requirement, from each requirement to design, from design to development and coding, from coding to verification, from verification to deployment, from deployment to on-going support and subsequence deployment). Adapting a useful and effective environment for traceability can increase the quality of the software and the efficiency of future maintenance.

What to Look for in an Traceability Environment

In order to adapt an environment, there are many considerations. The INCOSE (International Council on Systems Engineers) had a study based on the system environment, user interfaces, support and maintenance, and capabilities for managing requirements (www.incose.org/work-grps/tools/tooltax.html). The following are the key capabilities for such an environment:

· Predefined and customizable data types that capture manually or automatically by using data import facilities, parsing mechanisms or scripts.

· Predefined and user-definable queries for ad-hoc and customizable retrieval or grouping of the data.

· Comprehensive configuration management and change tracking facilities.

· Trace analysis capabilities for identifying inconsistencies, performing impact analysis, verification and status accounting.

· Various presentation formats to display the data whose output can either be directed to screen, printer facilities, or different files formats that can be imported by publishing tools.

· Teamwork support that provides facilities to mutually notify stakeholders and provides access control.

· Interface to other existing system and software engineering environments and tools as well as to publishing tools; further integration can be achieved by exploiting an applications program interface.

How to Adopt a Traceability Environment

In order to use any traceability environment, one must first define the project-specific trace data and trace strategies. To reduce the number of traceable records, the project member who defines the trace data must consider the expected trace usage, contractual obligations, laws, and experiences of similar projects. Traceability data can be classified into four main categories:

· Product data subsumes the data types required to document the requirements of the system

· Supplementary product data subsumes additional artifacts that provided explanations or justifications for the documented requirement

· Process observation data subsumes data about the process execution

· Dependency data represents typed relations between the three data categories

The project manager must also define the “trace capture strategies.” One must specify what trace data will be used in which situation. The trace data must be captured and a decision must be made as to how the required data should be recorded. The source of the traceability data support for assessing the requirement information must also be defined. To define the “trace usage strategies,” one must define in which situations recorded traceability information has to be considered. Also, the use of aggregated, simplified, or generalized information should be defined. The definition of project-specific trace strategies and data is determined by the experiences of the project manager.

Following are some guidelines for the stakeholder in trace capture and usage. Establishing project-specific traceability definitions does not guarantee that traces are correctly captured and used. To ensure correct trace recording and usage, the definitions must be communicated to the stakeholders performing the process and must be applied in the corresponding situations throughout the project. There are two solutions to achieve this. First, the data type and strategies can be defined in a project-specific traceability handbook. Each stakeholder must learn the definitions during the learning phase while defining the data and strategy. Later the handbook can be used to tell the engineers what is allowed and what is not allowed in this environment. It also can be used as a reference for the engineers who need to define more trace data or add/delete strategies in the future.

Ideally, the traceability environment should provide an integrated method guidance for stakeholders in recording and using the traces according to actual project-specific definitions. The integrated method guidance is the second major solution to achieve trace data capture and usage. The advantages to offer integrated guidance to the engineer conformant with project-specification definitions are:

1. The engineers must not necessarily be aware of the project-specific definition.

2. The training effort required is reduced.

3. It ensures trace recording during process execution.

4. It ensures that the recorded trace data is used.

5. The workload of the stakeholder is reduced.

In most organizations, there is limited knowledge of project-specific requirement traceability. There is no process to guide the engineers to adapt to an environment that allows project-specific requirement traceability. In order to establish the environment and have continuous improvement for the organization, the organization should define why they need this environment, how are they going to use it, what type of data to gather and store, how to capture the current experience, how to accumulate experiences within the environment and how to use this environment to improve productivity.

A Framework for Project-Specific Traceability

There are three main methods in this architecture for adapting and using a project-specific traceability environment to improve the quality of the product: a method definition, a process execution and a method improvement environment. The project manager or the project expert works in the method definition space to define the trace data and strategies that will be used. The application engineers capture the defined data in the process execution space. Finally, the method engineer operates in the method improvement environment to ensure on-going improvements to the definition.

trace recorded captured

definitions experiences traces

modeling trace recorded improved

concept definition experiences definitions

Definition of project-specific traceability

(executed by project manager)

Experience based Improvement

(executed by method manager)

Traceability Tools/Environments

Requirement Traceability through Documentation

Within any project or organization, the following list of generated documents can be used to provide some kind of traceability if a traceability environment is not used.

Type of Documentation	Description	Owner
Customer Requirement	Customer defines the system needs where each item should be numbered.	Customer
System Requirement	Each item defined in the Customer Requirement will be mapped to a system requirement.	System Engineer
Architecture/Design Document	For each design unit, it will map a list of system requirements that applies to that design unit.	Development Team
System Verification Document	System verification will map each test to a requirement or a list of requirements.	Verification Team

Traceability Tool – Traceability Matrix

In the verification stage, a traceability matrix can be used to track the mapping from the requirement to each test scenario. This matrix coordinates the requirements with the verification methods to be applied. The verification engineers can map all of the requirements into test cases. In order for this to work, one must follow the “one paragraph one requirement rule”. It means that a number shall be assigned to each requirement and each number shall only contain one requirement.

Customer Info Each Requirement can be Mapped

Maps into System into a test scenario

Requirement

Each Requirement can be Mapped

Into a Design Unit

Design

Verification

Sample Verification Traceability Matrix

Test Name	Test Description	………	Requirement number	Requirement Section
123	Network time		1010	1.2.6
234	System performance		1290	2.4.8
:	:		:	:
236	:		:	:

Commercial Requirement Traceability Environments

If requirements traceability is not customized it can lead to an unwieldy mass of unstructured and unusable data that will hardly ever be used. There are many commercial requirement traceability environment (tools) available in the markets. Here are some of the market-leading products:

Xtie-RT Teledyne Brown Engineering.

QSSrequireit Quality System & Software

DOORS Quality System & Software

RequisitePro Rational Software Corp.

Requirement Traceability in CMM and ISO

In ISO 9001, section 4.8 Product Identification and Traceability mentions the organization shall establish and maintain documented procedures to identify and trace a specified requirement in a product. ISO requires that a single requirement must be able to be traceable during all stages of the production, delivery and installation.

Different levels of the CMM address traceability a little differently in the key process areas. In the repeatable level (level 2), the key process area Requirement Management states, “the software plans, products and activities are kept consistent with system requirements allocated to software.” It must have enough resources and funding available to manage the requirement and support traceability with a tool. Whenever the system requirement is changed, the affected areas in the software life cycle must be kept consistent with the updated requirements. The key process area Software Quality Assurance mentions that the software product shall be verified objectively per requirement. The KPA Software Configuration Management requires that at any time, one must maintain the integrity and traceability of the configuration management throughout the software life cycle by controlling the changes to the configuration.

In level 3, the defined level of the CMM, the KPA Software Product Engineering covers the traceability in detail. It states the following to address the needs for requirement traceability:

· The software design is developed, maintained, documented, and verified according to the project’s defined software process, to accommodate the software requirements and to form the framework for coding.

· The software code is developed, maintained, documented, and verified according to the project's defined software process, to implement the software requirements and software design.

· System and acceptance testing of the software are planned and performed to demonstrate that the software satisfies its requirements.

· Consistency is maintained across software work products, including the software plans, process descriptions, allocated requirements, software requirements, software design, code, test plans, and test procedures.

The last item on the list addresses the need for software traceability mapping back to a requirement in CMM. Maintaining consistency across the software development requires commitments from the organization and the resources to maintain the consistency.

Requirement Tracing Tools

Requirements tracing, by its nature, is a process that involves linking development objects together. These objects can be customer-level requirements or engineering-level requirements, or any hierarchical combination. On a small project, the establishment and maintenance of the links between the different requirement objects can be manually managed. However, as a project grows in size, both the establishment and maintenance of those links can grow exponentially. This can make manual management exceedingly difficult, time-consuming and prone to costly errors that can result in defects not discovered until system-level testing.

Requirements managing tools that provide for requirements traceability can supply one solution to the error-prone manual process. A computerized requirements tracing tool can capitalize on a computer's ability to better maintain what would be a mundane manual process. The potential benefits of an effective and useful program can be a severe reduction in costly requirements traceability defects.

Four requirements tracing programs were reviewed: XTie-RT by Teledyne Brown Engineering, QSSrequireit by Quality Systems and Software (QSS), DOORS by Quality Systems and Software (QSS) and Rational RequisitePro by Rational Software.

XTie-RT by Teledyne Brown Engineering

The XTie-RT tool is billed as an easy-to-use tool, capable of being brought up and running within a day. Training requirements for it are not very intense and on-line help is provided. The tool has a number of useful features for the area of requirements management.

The tool is capable of extracting requirements from a specification document and entering those into a database. This is done by keyword searches, such as a search for the word "shall." The database serves as the first step toward building the requirements tracing capabilities.

The linking feature of the tools provides the ability to link information between documents. For example, a high level customer document might have a general requirement in it, such as "The software shall display warning conditions." A lower level engineering requirements document might have broken down the customer requirement into, "The software shall display low disk-space warning," and, "The software shall display out of memory conditions." Setting up parent-child-peer relationships can then link these two lower level requirements to the higher level requirement.

The tool can also support a hierarchy of linked requirements. If any of those requirements are moved around in the chain, all other dependent links are updated to reflect those new changes. This feature eliminates the laborious task of manually searching through linked requirements and updating them to reflect the changes.

QSSrequireit by Quality Systems and Software

QSSrequireit is a tool that runs completely within Microsoft Word. This provides the benefit to the user of utilizing an existing, familiar interface. This tool has a similar data capture feature that was found in XTie-RT. Data can be captured either by highlighting desired text and then marking it using the QSSrequireit toolbar, or the process can be automated by doing keyword searches on typical requirement words such as "shall." The captured data shows up as a highlighted item within Microsoft Word.

Attribute information can also be stored along with the requirements. For example, if there is a requirement, "The household shall receive audible confirmation that the main door is fully closed," one attribute that might be useful to have for this requirement is a Pass/Fail test requirement. This can be added by highlighting the requirement, expanding its attributes list, and adding it. Now this requirement can be tracked on its Pass/Fail status.

Links between documents can also be established. Using the above user requirement as an example, we may choose to link it to a system requirement contained in another document. Once this link is created, any changes made in these requirements can be traced to other affected requirements to ensure that there is no disconnect or lost requirement.

Three report types can also be generated using this tool: Requirements report, traceability report, and suspect requirement trace. The requirements report shows the marked-up requirements and their attributes. The traceability report shows the link relationships between requirements. The suspect requirement trace report shows the potential impact of a requirement change to other requirements that it is linked to.

DOORS by Quality Systems and Software

Where the QSSrequireit is designed for the smaller projects, DOORS is designed for the large-scale, long-term projects. DOORS (Dynamic Object Oriented Requirements System) provides requirements support throughout the whole lifecycle of the project. The system is designed to be used, not only by the requirement technical experts, but also by others who would like to view the information.

Within DOORS, the requirements are treated as the base measure for measuring the progress on a project. Requirements are handled within DOORS as discrete objects. Each of these objects can handle attribute information, such as textual data, dates and type information. By storing this attribute information, requirements can be customized on a requirement-by-requirement basis. This eliminates the need for a general template that cannot fit all possible cases.

DOORS recognizes the fact that throughout a project, requirements can grow. Requirements that are not well tracked or controlled may grow even faster. To combat this, DOORS works to make the tracking and controlling of requirements simple so that the scope of a requirement change is better understood at the time of the change. DOORS keeps requirement tracing simple by expressing relationships hierarchically as a set of text, pictures and tables. The developer will then have a clear hierarchy, both up and down, of the requirements that are dependant on a change. The dependant requirements can then be appropriately scrutinized and modified as necessary.

To enhance traceability, and insure that all modifications and project adjustments are clearly understood throughout the project lifecycle, DOORS provides "drag-and-drop" linking. Linking is as simple as dragging a requirement and dropping it on another one and establishing the type of link. This provides the framework for the traceability that will insure change propagation and final test coverage.

Rational RequisitePro by Rational Software

RequisitePro is designed to be used on a variety of project sizes. Like QSSrequireit, it uses Microsoft Word as the primary user interface. This provides what is likely a common interface for the user. Many requirements documents come in a word processor type of format. They are written out for reading by stringing a number of "shall" type statements together. RequisitePro will automatically parse through the document on user-specified keywords (such as "shall") and extract the requirements from the document.

RequisitePro also provides various views to enhance traceability. One of those views is the Traceability Matrix. This matrix displays requirements in a matrix format for easier coverage viewing. For example, a typical project will start with customer level requirements. The engineering team will then begin deriving system level requirements from those customer level requirements. The distinction between the two types of requirements is that one is customer readable and tend to be general ("The screen should appear quickly"). The system level requirements are testable requirements ("The screen should appear on the screen within 500ms"). The matrix will provide visual feedback about what system requirements were derived from which customer requirements. Using the matrix, it is also easy to check coverage and make sure that all of the customer requirements were broken down into system requirements. Those system requirements are then stored in a Microsoft Word document so that anyone can read them.

Another useful view provided by RequisitePro is the Traceability Tree view. This view shows the requirements in a hierarchical fashion. The benefit of this view is in graphically showing relationships between requirements. If a requirement is modified, added or deleted, the user can visually see all of the other affected requirements. The affected requirements can then be properly scrutinized and modified to accommodate the original requirement change. This helps maintain a cohesive set of requirements by eliminating orphaned requirements and also by preventing outdated requirements from being left in the set.

RequisitePro also offers cross project traceability. Often times, especially with legacy systems, a number of projects will spawn off of a central project. These new projects will share a significant number of requirements with its parent and sibling projects. RequisitePro allows traceability of requirements to span cross-project. This greatly increases requirement reuse which can in turn foster design, code, and test reuse.

Conclusion

Requirement traceability is important to the project in many ways. The CMM covers requirement traceability primarily in Software Configuration Management, but activity 10 of Software Product Engineering states the specific need for consistency and traceability between software work products. The Requirement Management KPA states the need to manage requirements so they can be easily mapped to a specified requirement in the later steps of the software development life-cycle. ISO also requires the ability to trace each requirement from the beginning to the end of the development phases.

Current traceability environments provide only weak integration with other engineering tools. Neglecting traceability or capturing insufficient and/or unstructured traces can lead to a decrease in system quality, can cause revisions leading to increased project cost and loss of time. It results in a loss of knowledge if individuals leave the project. It is essential to for a project to adopt and use a requirement traceability environment and continuously improve the quality of the project by improving the organizational knowledge about project-specific trace definitions and trace strategies.

Questions

(1). What are the two type of links that can be considered the pre-traceability links?

a) Forward From The Requirements and Forward To The Requirements

b) Forward From The Requirements and Backward To The Requirements

c) Forward To The Requirements and Backward From The Requirements

d) Forward To The Requirements and Backward To The Requirements

(2). Name the three factors that influence the requirement tracing practices in an organization?

a) environmental, organizational, and technical

b) environmental, social, and technical

c) social, organizational, and technical

d) social, organizational, and difficulty

(3) State the goal of requirement tracing for the “High-end users”?

(4) What must be defined when adopting a traceability environment?

(5) What Traceability Data needs to be gathered or defined?

(6) Which CMM Key Process Area covers the traceability in detail?

(7) List three problems one might see if the organization neglects requirement traceability?

(8) What activity can be greatly assisted by using an automated tool instead of manual updating

Answers:

(1): C

(2): A

(3): The goal of requirement tracing for the high-end user is product quality and process improvement.

(4): Project-specific trace data and trace strategies

(5): Product Data, Supplementary Product Data, Process Observation Data, and Dependency Data

(6): Software Product Engineering in Level 3

(7): Decrease System Quality, Increase Project Cost and Time, and Loss of knowledge.

(8): Maintaining links between requirement objects.

References

Matthias Jarke. Requirement Tracing. Association for Computing Machinery. Communications of the ACM. Volume 41, Issue 12, December 1998.

Balasubramaniam Ramesh. Factors influencing requirement traceability practice. Association for Computing Machinery. Communications of the ACM. Volume 41, Issue 12, December 1998.

Ralf Domges and Klaus Pohl, Adopting Traceability Environments To Project-Specific Needs, Association for Computing Machinery, Communications of the ACM, Volume 41, Issue 12, December 1998.

Carnegie Mellon University Software Engineering Institute, The Capability Maturity Model, Guidelines for Improving the Software Process, Addison Wesley, Reading, Massachusetts, March 1999

ISO 9000-1:1994, Quality systems – Model for quality assurance in design, development, production, installation and servicing.

Chapter 2