See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/235353253

Pre-Requirements Traceability

Chapter · January 2002

CITATIONS READS

9 2,131

3 authors, including:

Hossein Saiedian
University of Kansas
174 PUBLICATIONS   1,654 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Hossein Saiedian on 19 February 2014.

The user has requested enhancement of the downloaded file.

 Pre-Requirements Traceability
Wei Li Rayford B. Vaughn Hossein Saiedian
Department of Computer Science Elec. Eng. & Computer Science
Mississippi State University University of Kansas
Mississippi State, MS 39762 Lawrence, Kansas 66045
{wli,vaughn}@cs.msstate.edu [email protected]

Abstract
Requirements traceability (RT) is important for developing a high quality software sys-
tem, especially a large and critical system. In this paper, we discuss the requirements
traceability problem, the definition used today, and its importance. We then present a
detailed discussion of the problems existing with pre-requirements specification (pre-RS)
traceability and post-requirements specification (post-RS) traceability to show that most
of the RT problem lies in pre-RS traceability. Finally, we present a brief discussion of the
common tools and environments in use today and offer directions for future work.

Key words and phrases: Requirements traceability (RT), requirements engineering, Capa-
bility Maturity Model

1 Introduction

Requirements traceability (RT) can be viewed as “the ability to describe and follow the life
of a requirement, in both the forward and backward direction” [4]. It is used to capture the
relationships between requirements, design, and implementation of a system. RT not only can
be a useful solution to align system evolution with changing stakeholder needs, but it also
helps to find unexpected problems, innovative opportunities, and to lay the groundwork for
corporate knowledge management [10].
Techniques have been suggested in the research literature to address the RT problem. Their
use, however, is still not as widespread as the importance of RT suggests. This is likely because
there are still many issues to be addressed, for example, the lack of common definitions and
conflicting underlying problems [4].
According to the analysis made by Gotel et al [4], there are two different kinds of traceabil-
ities: pre-requirements specification (pre-RS) traceability and post-requirements specification
(post-RS) traceability (see Figure 1). Pre-RS traceability refers to those aspects of a require-
ment’s life prior to its inclusion in the RS. Post-RS traceability refers to those aspects of a re-

1
 Requirements

Evolving Versions
Requirements

Users/Clients
Requirements Design Testing Code

Pre−Requirements Post−Requirements
Traceability Traceability

Figure 1: Requirements Traceability: A Pictorial Illustration

quirement’s life that result from inclusion in the RS. This distinction fits with the four kinds of
traceability links defined by Davis [1]: forward from requirements, backward to requirements,
forward to requirements and backward from requirements. The former two are included in
post-RS traceability. They link requirements to design and implementation, documenting re-
sponsibility assignment and compliance verification, to the impact analysis of a requirement.
The latter two types are included in pre-RS traceability. They document the rationale and so-
ciopolitical context from which the requirements emerge [10]. Existing tool support primarily
focuses on post-RS traceability, but most problems attributed to poor RT are found to be due
to the lack of pre-RS traceability [4]. This is likely because post-RS traceability is much better
understood than pre-RS traceability. Only pre-RS traceability, however, can provide the most
useful information about requirements to customers and stakeholders.
In practice, requirement traceability users can be divided into two groups: low-end and
high-end traceability users [10,14]. The two groups have a clear difference between their views
toward the number of participants, complexity of the system, traceability experience level,
user definition of traceability, and the application of traceability. Investigations show there are

2
various factors that influence the traceability practice of these two groups.
The remainder of this paper is organized as follows. Section 2 discusses issues related
to the RT definition and its importance. Section 3 discusses pre-RT and post-RT traceability
problems and approaches. Section 4 provides a brief introduction to the tools used in RT and
discusses their usefulness in addressing the RT problem. Section 5 provides suggestions for
related future work.

2 Requirements Traceability Concerns

2.1 Requirements Traceability: A Definition

RT is important during the process of Software Engineering. However, RT is not perceived to

be a uniform process and there are some fundamental conflicts in practice.
The definition of “trace” in the Oxford English Dictionary is the ability to “delineate” and
“mark out” “perceptible signs of what has existed or happened” in the lifetime of a requirement
to enable one to “pursue one’s way along” this record. RT is a term originally coined by the
US Government Defense Department. It means the software producers can “prove” to their
client that: the requirements have been understood; the product will fully comply with the
requirements; and the product does not exhibit any unnecessary feature or functionality. This
simple definition is not suited for today’s software applications. This is because not only
the sizes of requirements increase very quickly, but also the stakeholders’ requirements often
change according to different viewpoints.
Other existing definitions can be divided into four general groups [4]:

• Purpose-driven: defined in terms of what RT should do;

• Solution-driven: defined in terms of how RT should be done;

• Information-driven: emphasizing traceable information;

• Direction-driven: emphasizing traceability direction.

These definitions differ both in emphasis and scope and any one cannot include all concerns.
According to the IEEE standard [8], traceability refers to “the degree to which a relationship
can be established between two or more products of the development process, especially prod-
ucts having a predecessor-successor or master-subordinate relationship to one another; for

3
example, the degree to which the requirements and design of a given system element match.”
This definition is viewed from a high-level of the software development process.
Gotel provided a definition that is most often used today: “the ability to describe and follow
the life of a requirement, in both forwards and backwards directions (for example, from its
origins, through its development and specification, to its subsequent deployment and use, and
through all periods of on-going refinement and iteration in any of these phases)” [4]. This
definition covers all the aspects mentioned above, and corresponds to the division of pre-RS
traceability and post-RS traceability.

2.2 The Importance of Requirements Traceability

RT suggests that the life of each requirement can be understood from the origin to development
and specification, subsequent deployment and use, and adaptive to ongoing refinement and
iteration. Lack of RT or capturing insufficient or unstructured traces in a system will often result
in a loss of knowledge if key individuals leave the project- a common occurrence in today’s
software development community. It can also cause miscommunication, misunderstanding
and incorrect decisions, which may decrease the overall quality of the system and increase cost
and time to delivery [2]. In addition, RT is very important for version control and configuration
management (VC/CM) of the design artifacts that are produced throughout the product lifecycle
[9]. Requirements traceability should not be viewed as an option. It is essential to ensure a
customer’s satisfaction by providing them a documented means by which to prove that all
stated requirements are met and that the job is complete [15].
There is an important relationship between RT and the Software Engineering Institute’s Ca-
pability Maturity Model (SEI CMM). Within the SEI CMM, level two of maturity model stipulates
the need for understandable traces. Higher levels also require a capability for traces to plans
resulting from a defined process. Ramesh [14] identifies two kinds of traceability user organi-
zations: low-end users and high-end users. Low-end users treat traceability as a costly defense
against criticism and liability lawsuits and view traceability as a mandate from project sponsors.
High-end users see traceability as a necessary investment in information system engineering,
and view traceability as an important component of quality systems engineering. The trace-
ability practices of the two groups are different. Low-end users use simple schemes to model
requirements dependencies, allocate requirement components to system components and link
to compliance verification procedures. High-end users employ much complex schemes. They

4
use the information in richer ways and emphasize the capture of process related traceability
information. Although there are many different variances between these two groups, some or-
ganizations may have mature traceability practice even with predominantly low-end practices
[14].
In fact, many standards for system development mandate that RT should be practiced. For
example, the US DoD Standard 2167A (now MIL-STD-498) insists “that the functional require-
ments which are identified as a part of the functional baseline be traceable directly to specific
capabilities within the allocated baseline, which must then be directly traceable to specific ca-
pabilities within the product baseline” [16]. This standard requires that system requirements
should be traceable throughout the process of development, although it is not a full implemen-
tation of RT.
There are issues associated with RT- some of them political. For example, concerns may
arise among individuals on the development team because management has the opportunity
to use the information provided by system development personnel in performance evaluations
[15]. To counter this problem team responsibility may required, which means all products must
be considered team provided, so that no individual has to be concerned with personal negative
reflection.
Another issue can be the high cost of traceability. Planning for increased workload and doc-
umentation are required to implement RT. The initial budget required may be several times that
of system development without traceability processes yet having the same size and complexity.
Training various members of an organization on the use of the needed tools/environment is
another cost to be considered. Management may view these costs as contributing to the reduc-
tion of the total lifecycle costs due to development of a higher quality product with reduced
maintenance [15] (especially for high-end users). This problem can be mitigated by training
members during the development of relatively small and less time-sensitive projects to help
them become familiar with the process and tools needed to realize RT. Before we can do this,
however, we should make clear which kind of information should be recorded and traced. This
topic is discussed below.

2.3 Recording Traceability Information

It is hard to reach a consensus on what information should be captured and used as a part of a
traceability scheme. This is mainly because traceability changes with the stakeholders’ view of

5
the system. A stakeholder could be the program sponsor (e.g. customer), the project manager,
the system analyst or designer, the test engineer, system maintenance personnel, or the end
user of the system [15]. During the software lifecycle, the stakeholders’ views of traceability of-
ten change. Some of these views overlap, some of them conflict. For the maintenance engineer,
traceability means how the change of requirements may affect the system. To the customer,
traceability could mean making sure whether or not requirements have been satisfied.
There are factors that decide the kind of project and information that should be traced,
such as the customer requires it, the project is complex, different types of documentation
and their interrelationships are required, assurance that the system built just contains the
requirement claimed, or the system is safety critical [17]. These, however, seem too trivial and
project-specific. We need a higher-level overview of the traceability information.
During the process of requirements engineering, the task should proceed along three di-
mensions: managing the convergence of stakeholders’ interests toward agreement on critical
system goals and constraints; achieving sufficient shared understanding of the issues involved
in realizing the system vision; and documenting understanding in adequate representation
formats. RT should document all these dimensions of the requirements engineering process
[10]. There is a similar description of these three dimensions in the requirement engineering
process, which consists of:

• Representation dimension: requirements are represented from informal to formal rep-

resentations, this dimension mainly concerns with technical issues; i.e. the different rep-
resentation types and their relations;

• Specification dimension: requirements are represented from incomplete to complete rep-

resentations. Two kinds of completeness are included here. One is the coverage of the
problem in the specification; the other is whether the requirement is well defined. This
dimension mainly addresses cognitive and psychological problems of requirements engi-
neering; i.e. the content of the specification independent of its representation according
to some standards or guidelines;

• Agreement dimension: requirements are represented from personal views to common

views. This dimension mainly deals with social aspects of requirements engineering. That
is to say, several viewpoints of different stakeholders, arguments, alternative solutions,
and decisions made during the requirement engineering process [13].

In the representational dimension, we must capture linkages between the documents produced
during the requirements process. From a cognitive perspective, the trace should capture con-
ceptual objects. Also the trace should capture the human cooperation in the design process
about different stakeholders’ contribution to the development process.

6
 In addition, the relations between these kinds of information (e.g. dependencies that exist
between the recorded trace objects) should be recorded. The actual process performance, such
as relating information between the process steps and the agents (human/tools) by which it
was produced, should also be traced [10,13]. Most of the tools/environments only support
some aspects of this three-dimension framework.
On the other hand, not all development projects need traceability in reality, e.g., a require-
ment prototype with a very short development cycle [17] may not need such kind of information.

3 Pre-RS Traceability vs. Post-RS Traceability

There are two basic types of RT: pre-RS traceability and post-RS traceability. These refer to re-
quirement production and requirements deployment, respectively. What kind of pre-RS trace-
ability should be dealt with has neither been well understood nor fully supported. Having
insufficient pre-RS traceability becomes the main RT problem faced by both providers and end-
users [4].
Recent research focuses on pre-RS traceability. Most approaches consider different aspects
of pre-RS traceability, for example, DOORS from QSS. Other approaches focus on a particular
aspect of pre-RS traceability, e.g., contribution structure. This approach is based on modeling
the dynamic contribution structures underlying the requirements artifacts. The structures can
be defined using information about the agents that have contributed to the production of these
artifacts, and the traceability relations between the artifacts [5]. This method has been used in
some industrial projects and has helped in identifying the right people to help rectify matters
where problems of misunderstanding were found to exist. These information are valuable for
determining work that should be allocated in future projects and requirement reuse [6].
Considering the history and functionality of existing systems is important to help avoid
repeating failures or omitting important functionalities. Many requirements engineering ap-
proaches began to consider two categories of conceptual models that consisted of a current-
state model and a desired-state model. The latter refers to the requirements for a future system.
Based on this concept, another approach captures one special kind of requirements traceability
called extended traceability. By recording concrete system usage scenarios using rich media
(for example video, speech, graphic and images) one can trace back to a concrete instance exam-
ple from the real world, and trace in a very fine-grained manner showing the relations between

7
arbitrary parts of conceptual models to arbitrary parts of real world observations [7].
A requirements engineering environment called PRO-ART (Process and RepOsitory based
Approach for Requirements Traceability) uses a different approach and provides a compre-
hensive framework for the three-dimension trace information structure. It attempts to use a
three-dimensional framework to define information to be recorded. A trace-repository for trace
retrieval is also used. During the establishment of this repository, the Information Resource
Dictionary Standard (IRDS, ISO-IEC 10027) is used to build an information resource dictionary
(IRD). Based on the IRDS, a generic trace structure for a trace repository, based on the three
dimensional structure of requirements engineering, can be set up. A tool has also been built to
facilitate the automated trace capture. Finally, traces captured by the PRO-ART environment
consist of three kinds of information: the product produced, the dependencies between prod-
uct parts and the human agent, and the tool actions by which the trace was captured [13]. The
information recorded in the central repository can give important information to requirement
engineers and support consistent change integration.

4 Tools Support for Requirements Traceability

There are many tools or environments that can be helpful in providing for traceability of re-
quirements. These include cross-referencing schemes, key phrase dependencies, templates,
RT metrics, matrix sequences, hypertext, constraint networks, and more. Some form of RT can
result from using certain languages, models and methods for development. In addition, many
commercial tools and research products embody manual and automated forms of the above
tools.
With increasing agreement that RT is a critical factor in requirements engineering, more
and more tools/environments are becoming available to support RT. The International Council
on Systems Engineering (INCOSE) has a survey on the current Requirements Management (RM)
Tools which include those based on relational database systems such as ARTS, Analyst Studio
(RequisitePro) v2000, icCONCEPT RTM, and those based on object-oriented database system
such as DOORS, RDD 100, and SLATE [11]. Most environments offer static and dynamic analysis
mechanisms to check inconsistencies and incompleteness. These environments support a set
of requirement management activities and support at least some kind of traceability analysis.
All these tools claim to support three common aspects of traceability:

8
 • Identifying inconsistencies: The tool allows the user to identify inconsistencies such as
unlinked requirements or system elements (orphans) (e.g., DOORS4.0 can identify ob-
jects/requirements with no links at all, with no outward links or with no incoming links).
These can also be conditional on other data types. For example, show all unlinked tests
that have not yet been performed;

• Visibility into existing links from source to implementation: With the requirement links
in place, the user has the ability to follow the links to see where they come from and
where they go. For example, in Analyst Studio (RequisitePro) v2000, traceability trees are
provided to view the complete path of relationships. A “Requirement Go To” feature aids
navigation;

• Verification of a requirement (was it done, how was done): Throughout the life of the
project, the requirement management tool will be used to verify that the requirements
have been met. The tool should provide the ability to document the fact that the require-
ment was fulfilled, how it was done, and who was responsible. For example, in SLATE 4.0,
notes and attributes can be used to verify that requirements have been met. In addition,
verification status can be monitored by the system to automatically trigger events based
on the state of the database. For example, if a requirement has changed or failed a test,
project personnel can be notified via email [11].

Another aspect of RT is requirement performance verification from system elements (roll up

of actuals), which means that once performance requirements have been allocated to system
elements, the requirements management tool should support the verification of those require-
ments by rolling up the actuals and reporting on variances (this is the allocated weight versus
the actual weight). Many tools cannot support this characteristic. For example, The Systems
Engineer 2 tool allows verification method assignment and tracks linkage from testing, to test
results, to bugs, to the version tested. Where testing is not required, the verification status
(e.g. demonstrated, inspected, reviewed, canceled) is manually set. This state is maintained for
each requirement [11].
There are also some specific approaches to traceability tools. For example, ARTS (Lock-
heed) uses an existing database system and provides user interfaces for managing and tracing
requirements. This tool, however, has weakness in two areas- the cost of using this commercial
tools for a large software development team is high because of the licensing expense for each

9
user and support for heterogeneous computing environments is lacking [15]. Other approaches
include the PRIME-RT framework, which is based on a contribution structure [2]; a web-based
requirements tracing system-STAR-Track [15]; and an object-oriented tool- TOOR (Traceability
of Object-Oriented Requirements) [12], etc. Although most of these tools are still considered
experimental, they give some useful suggestion towards the future direction of RT and may
soon be integrated into requirements management environments.

5 Conclusions and Future Work

We have presented a brief discussion about requirements traceability (RT) and related issues
and discussed the pre-RS traceability post-RS traceability problems. The information can be
useful for organizations that seek to transition from low-end to high-end practices. In fact,
an all-encompassing solution to the traceability problem that includes pre-RS traceability and
post-RS traceability is likely impossible. Most problems due to poor traceability are due to
inadequate pre-RS and efforts must be undertaken to improve.
Although RE has sometimes been viewed as a burden, more organizations are treating it as
necessary in building large and complex software systems, especially in those environments
where the stakeholders’ viewpoint often changes. Today, the size and scope of software sys-
tems are increasing rapidly. Projects with more than 1,000 requirements may have been treated
as large projects only a few years ago, but today they are treated as small and undertaken by
small organizations. In order to keep up with the changes related to software requirements, it
is becoming necessary to build automatic traceability models and tools. Since more and more
software environments are available today, and large projects often need dynamic reference
and link information across different platforms [14], research work must be accomplished in
this direction. Web technologies may offer a good solution in terms of integration with existing
tools and databases.

References
[1] A. Davis. The analysis and specification of systems and software requirements. In Systems
and Software Requirements Engineering. IEEE Computer Society Press, pp. 119–144, 1990.

[2] R. Domges and K. Pohl. Adapting traceability environments to project-specific needs. Com-
munications of the ACM, Vol. 41, No. 12. pp. 54–62, December 1998.

10
 [3] F. Gardner. RayTracer: traceability for software engineering. In Third Symposium on As-
View publication stats

sessment of Quality Software Development Tools, pp. 224–232, 1994.

[4] O. Gotel and A. Finkelstein. An analysis of the requirements traceability problem. In Pro-
ceedings of the First International Conference on Requirements Engineering. pp. 94–101,
1994.

[5] O. Gotel and A. Finkelstein. Contribution structures [Requirements artifacts]. In Proceed-

ings of the Second IEEE International Symposium on Requirements Engineering. pp. 100–
107, 1995.

[6] O. Gotel and A. Finkelstein. Extended requirements traceability: results of an industrial

case study. In Proceedings of the Third IEEE International Symposium on Requirements
Engineering. pp. 169–178, 1997.

[7] P. Haumer, K. Pohl, K. Weidenhaupt, and M. Jarke. Improving reviews by extended traceabil-
ity. In Proceedings of the 2nd Annual Hawaii International Conference on Systems Sciences.
pp. 10, 1999.

[8] IEEE guide for developing system requirements specifications, IEEE STD 1233-1996, 6 June
1996.

[9] I. Macfarlane, and I. Reilly. Requirements traceability in an integrated development en-

vironment, In Proceedings of the Second IEEE International Symposium on Requirements
Engineering. pp. 116–123, 1995.

[10] J. Matthias, Requirements tracing. Communications of the ACM, Vol. 41, No. 12. pp. 32–36,
December 1998.

[11] W. McMullen. Tools Survey: Requirements Management (RM) Tools.

www.incose.org/tools/tooltax.html. Accessed on June 25, 2001.

[12] F. Pinheiro and J. Goguen. An object-oriented tool for tracing requirements. IEEE Software,
Vol. 13 No. 2, pp. 52–64, 1996.

[13] K. Pohl. PRO-ART: enabling requirements pre-traceability. In Proceedings of the Second

International Conference on Requirements Engineering, 1996. pp. 76–84.

[14] B. Ramesh. Factors influencing requirements traceability practice, Communications of the

ACM, Vol. 41, No. 12. pp. 37–44, December 1998.

[15] X. Song, B. Hasling, G. Mangla, and B. Sherman. Lessons learned from building a Web-
based requirements tracing system. In Third International Conference on Requirements
Engineering. pp. 41–50, 1998.

[16] U.S. Department of Defense, Military standard: Defense systems software development,
DoD STD-2167A, February 1988.

[17] R. Watkins and M. Neal. 1994. Why and how of requirements tracing. IEEE Software, Vol.
11, No. 4, pp. 104–106, July 1994.

11