Requirements Traceability

Requirements Traceability

Elias Canhadas Genvigir (Federal University of Technology – Paraná – UTFPR , Brasil) and Nandamudi Lankalapalli Vijaykumar (National Institute for Space Research – INPE, Brasil)
DOI: 10.4018/978-1-60566-731-7.ch008
OnDemand PDF Download:
No Current Special Offers


This chapter presents a research about the Software Requirements Traceability. The main elements of traceability, definitions, problems and prospects are presented. The chapter is organized by topics and its beginning is a review about requirements engineering, its categories (Elicitation, Analysis and Negotiation, Documentation, Validation, and Management) and its role in software development. Afterwards, the requirements management and its elements (Identification, Change Management and Traceability) are described. Traceability is discussed; its aspects and problems are exploited as well as its classifications, techniques, links, metrics and models. Finally the Conclusion presents the main points that can be explored in future researches.
Chapter Preview

1 Introduction

Software production activity, also known as software development process, has been improving due to the demands in quality increase of those products.

The demand for more quality, cost decrease added to introduction of new technologies naturally forces to process improvement. Those facts are not new and this occurs in several other production areas that employ different techniques to increase their development processes. In particular for software the research area involved with the process improvement is the Software Engineering (Bauer, 1969; IEEE, 1990; IEEE, 2004).

The very first model ever employed in the software development process, that proposed work segmentation, is the waterfall model. It was able to allow a structured overview about the software development and its structure was the foundation stone to propose new processes as new necessities were required.

There are other development models such as prototyping, incremental, evolutionary, and spiral.

It is interesting to observe a common point in all these models: all of them start with Requirements Engineering. Generally speaking, Requirements Engineering is the process to identify stakeholders and their needs, and documenting these in such a way that makes analysis, communication, and subsequent implementation feasible and at the same time leading to a product of quality and reliability (Nuseibeh & Easterbrook, 2000).

The fact that Requirements Engineering being the first activity within the software production process can be better explored by analyzing the following statements:

The main goal of Requirements Engineering is to define the purpose of the system proposed and to define its external behavior” (Antoniou et al., 2000).

“The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended” (Nuseibeh & Easterbrook, 2000).

The first statement refers to the definition of purpose, which is an inherent characteristic during the initial activities both in projects and research methodologies (Basili et al., 1994; Solingen & Berghout, 1999).

The second refers to meet the intended purpose. If a software development's basis is to come up with a solution to a given problem, then it is of a fundamental importance the knowledge of the exact dimension of the problem to be solved. Requirements are initially discovered in projects and to understand them is a basic condition for the next phases.

Thus, one can get an idea of the importance with respect to requirements and why the Requirements Engineering occurs in the initial phases within the development process.

Requirements engineering activities can be divided into five categories: Elicitation, Analysis and Negotiation, Documentation, Validation, and Management. These definitions alternate among different authors (Jarke & Pohl, 1994; Sawyer et al., 1998; Graham, 1997; Kotonya & Sommerville, 2000; Sommerville, 1995) but the concepts are similar:

Key Terms in this Chapter

Stakeholders: Individuals or organizations involved or affected by the system and who have an influence on the requirements. They could be end-users, managers, suppliers and customers.

Requirements Engineering: The process of identification, analysis, documentation and management of requirements so that they are useful for implementation, consistent with the needs of stakeholders and to provide the software product quality.

Traceability Links: The main resource used to maintain and represent the traceability relationships. A link establishes an explicit relationship between two artifacts.

Techniques: Technical and managerial procedures that aid in the evaluation and improvement of the software development process.

Requirements Traceability: The ability to define traces between requirements and other artifacts throughout the development process; and to follow those traces in any direction.

Models: A set of elements describing something built for some purpose that is subject to a particular form of analysis.

Requirements Management: A parallel process to support other requirements engineering activities such as identification, change management and requirements traceability throughout the development process.

Complete Chapter List

Search this Book: