Too frequently in the life of a software development project, a requirement cannot be attributed to a stakeholder, important functionality is missing, or unnecessary features appear in the final product -- all "without a trace." That is, there is no discoverable connection between the work pertaining to a specific feature and an actual requirement for that feature. Yet, the concept of traceability is inherently linked with the quality of the product to be delivered. Unfortunately, traceability is often treated as an unwanted orphan.
In fact, in my consulting experience, no single aspect of requirements engineering is both 1) so frequently cited as vital to the engineering effort and 2) so frequently ignored in practice.1 I will offer what I believe are the root causes for this neglect. Then I will propose a number of best practices to address these causes. Although traceability applies to other disciplines of the Rational Unified Process (RUP) -- and there are many more relationships to trace, such as issues, assumptions, and risks -- this article focuses mainly on the requirements discipline.
The discussion assumes a basic understanding of requirements engineering, ideally using use cases.
Let's start with some of the theory behind requirements traceability.
What is traceability?
In accordance with IEEE Standard Computer Dictionary2 traceability is defined as "The degree to which a relationship can be established between two or more products of the development process, especially products having a predecessor-successor or master-subordinate relationship to one another."
The Rational Unified Process (RUP) defines the concept of traceability more generically, as "the ability to trace a project element to other related project elements, especially those related to requirements."
As you can see "traceability" is a very generic concept, easy to understand. The problem, though, is that most people picture immediately a very simple hierarchical structure with well-defined levels, such as the master-subordinate relationship. But when reality turns out to be more complicated, ignorance (or the modern alternative: tool reliance) replaces common sense, discipline, and the adherence to a couple of ground rules. As a consequence, traceability information is not established at all or only halfheartedly, and you lose the opportunity to improve quality and to respond changes quickly. How do you prevent this from happening? In order to answer this question, we first need to understand why we want traceability. What is the benefit of having traceability?
Traceability serves two key goals:
- Ensure quality of the product by proving that the product has all capabilities that a stakeholder has asked for and by proving that the product does not exhibit any capabilities that have not been asked for by a stakeholder ("Building the right product"). The other dimension of quality is to ensure that the capabilities that have been asked for function properly ("Building the product right"). The "Validation"3 dimension traces the different abstraction or refinement levels during the development process to each other. The "Verification" traceability traces requirements, analysis and implementation work products to their respective tests. These two dimensions, "Validation" and "Verification" traceability, are illustrated in Figure 1 with reference to the core RUP disciplines.
- Support impact analysis of changes by identifying affected requirements, design, and implementation artifacts as well as their related tests.
Figure 1: Traceability dimensions
In addition to these two goals, there are some tangible side benefits, mainly related to progress reporting and the assessment of project status:4
- What is the percentage of implemented requirements?
- What is the overall percentage of successfully implemented (i.e., tested) requirements?
- What is the number of user acceptance tests that I need to rerun if I change a specific implementation?
But after we understand the benefits, how do we go about implementing traceability? The following sections focus on the traceability of requirements in terms of the "Validation" traceability concept noted above.
What are the prerequisites for traceability?
The prerequisite for tracing requirements is a clear definition of requirement types. Requirement types are classifications of requirements at different levels of detail or abstraction with the most common being "stakeholder requests," "features," "use cases," and "supplementary requirements" (for an introduction see footnote 2). Whenever you document a requirement it must belong to a specific requirement type.
In addition to the requirement type, a hierarchy -- or more generally, a set of valid relationships between requirement types -- must be defined. This relationship defines which requirement type traces to, or is traced from,5 which other requirement type. There is some complexity to be aware of:
- One requirement type can trace to more than one other requirement type. For example: A feature represents a system capability view. A use case represents a goal from the end user perspective. Use cases cover mainly functional requirements, and therefore supplementary requirements are used to capture requirements not best recorded in use case format. A feature can therefore trace to a use case or a supplementary requirement (see Figure 2).
- An instance of a requirement type can trace to multiple instances of another requirement type (and vice versa based on the trace-from relationship). For example: A specific feature can trace to many use cases, but a use case can as well be traced-from many features resulting in a many to many relationship as Figure 2 shows.7
At the root of the requirements hierarchy we have stakeholder requests that can be attributed to an individual stakeholder, whose request is assessed against the project scope.
The requirement types and their relationship together are referred to as the traceability strategy. The traceability strategy must be defined up-front and should be documented in the Requirements Management Plan (a standard RUP work product). In order for a requirement to be traceable, it must be referable -- i.e., it must be identified unambiguously over its entire lifecycle across different work products.
Figure 2: Traceability relationships
Requirements are traced explicitly and implicitly. Explicit traceability requires you to manually establish a relationship between two requirement types. Implicit traceability results from an inherent relationship between the traceable items (i.e., your requirement types) -- for example, truly hierarchical requirements or through automatically applying transformations to your work products8.
In most cases, traceability is handled explicitly.
There are different approaches to establishing explicit traceability. The logical traceability relationship between two requirements -- represented by their identifiers -- can be physically achieved in various different ways. The most common ones are:
- Within the requirements work product, in the place where a requirement is defined (e.g., in cross references).
- Within the requirements work product, in a dedicated section (e.g., in tables of cross-references).
- Externally to the requirements work product (e.g., through spreadsheets, customized databases or dedicated requirements management tools).
Option 1 is often referred to as "obtrusive traceability," as the requirement and the traceability are defined in the same place. Options 2 and 3 are referred to as "unobtrusive traceability," as the traceability is maintained separately from the requirement.
Let's quickly assess the different options: Option 1 should be outright discarded. Not only can such a document very quickly become difficult to maintain, the reader is distracted by traceability information within the text, making the documents difficult to read. Furthermore, traceability is not the only meta-information to be captured for requirements. Other information such as priority, status, or risk, need to be maintained as well. Option 2 represents a compromise and can work if the strategy ensures that trace-from traceability is only established within the document or upwards to stable documents. This makes Option 3 the most desirable traceability approach. Spreadsheets will get you a long way, but dedicated requirements management tools, such as IBM Rational RequisitePro, are specifically designed for managing this type of information.
As you can see, in most cases establishing traceability requires manual effort. Consequently a cost-benefit analysis is generally the driver for implementing the right traceability strategy.
First you need to have a requirement. A requirement can come into existence through various ways, but the individual9 who documents the requirement is responsible for writing the requirement, creating an identifier and establishing the traceability.
Given that the ground rules to establish and maintain traceability are simple, it seems hard to understand why a lot of projects abandon traceability along the way. This symptom is often justified with reasons such as "too much effort" and "benefits weren't obvious." This, though, can be explained by the following root causes:
- No workable, agreed traceability strategy has been defined for the project.
- Traceability is not viewed as an integral part of the requirements engineering.
- Effort is spent, but benefits are never realized
The following presents some best practices that will address one or more of the preceding three root causes, noted in brackets.
Establish an appropriate trace level. Don't be overly ambitious. I have seen projects that were trying to trace a level of detail that was inappropriate given their time lines and their maturity with a use-case based approach. In your first project, don't attempt to trace down to the level of the individual use case step. You must have a well thought-through traceability strategy and justification for that (large!) effort. [1]
Distribute your efforts evenly. Include establishing traceability as part of documenting the requirements. Do not make it a separate task. Often this task is deferred, and even if it is deferred for only a subset of the requirements, traceability becomes patchy and therefore useless. [2, 3]
Apply quality assurance to traceability as well. When you perform inspections or reviews, include traceability. Traceability can be wrong as well. First of all this ensures that traceability is in place, but secondly it gets validated before it gets used and therefore increases your confidence in using it. [2, 3]
Adjust and revisit your traceability strategy. A traceability strategy that was successfully employed in the past cannot be expected to remain valid forever. Projects carried out by an organization change. Types of projects are different. Different projects require different requirements types and/or different relationships defined for traceability. Moving from an in-house development project to an integration project with an external vendor is likely to introduce new deliverables. Moving from a purely traditional (declarative) requirements approach to a use-case based approach introduces new requirement types. Your traceability strategy needs to respond to these changes10. [1]
Educate your team. Traceability is a team effort. The team responsible for carrying out this discipline must be appropriately educated on the approach to traceability for the project. They need to understand and appreciate that it is as equally important to trace a requirement to its origin as it is to write a good quality requirement definition. [1, 2]
Reinforce by counter-example. If you can identify the non-team player regarding your project's traceability needs, let that employee do the impact analysis for the next change request. This may convey the message in a more appropriate way. [2, 3]
If in doubt do less, but do it right. It is better to have a traceability strategy that is adhered to than one that is incomplete. The latter requires effort but is likely of no benefit. The former is reliable to the level of detail defined in the traceability strategy and could be -- at additional cost and through a dedicated, well-planned process -- extended, if demand arises. [1]
Think it through, but don't make it a burden. Be diligent and thoughtful in establishing traceability information, but do not let the traceability discussion take over your team meetings (or "develop a life of its own"). The Pareto Law applies to the maintenance of traceability as well. But if in doubt, in cases where the argument can go both ways, establish a traceability link. This will be advantageous in complex impact analysis ensuring that you find all related elaborated requirements. [1]
Leverage your requirements structure to support traceability. Traceability should never drive the way you document requirements. But often, well structured requirements documents support traceability more naturally. For example:
The feature that "the total amount of all unpaid invoices of a customer must not exceed his credit line" could be referred to in a number of use cases, such as "(Customer) Place Order" or "(Account Manager) Adjust Credit Limit" as a use-case step. Alternatively, it could be documented in the description of the domain concept "Customer" as a constraint. Not only does this make the documentation more maintainable, you can improve the traceability as well. Instead of tracing to multiple use case steps, you can trace to a single domain concept "Customer," which would be entirely sufficient; or, with a finer level of granularity, you could trace to the attribute "total amount of all unpaid invoices"11. [1, 3]
Leverage tool support. Tools are not silver bullets. They do not remove the burden of having to decide on a traceability strategy, and they cannot validate whether your traces are correct and complete. But requirements management tools, such as IBM Rational RequisitePro, allow you to:
- Establish and maintain traceability easily across your set of defined requirements in an unobtrusive way
- Enforce the defined traceability strategy to a certain extent
- Support the propagation of a change through your requirements hierarchy by identifying requirements that may be affected by that change based on the established traceability
- Visualize and report on your traceability (see Figure 3).
These RequisitePro capabilities, therefore, reduce the overall manual effort and increase the reliability of your traceability. [1]
As you can see there are a number of counter measures you can take to make traceability easier to establish, which will improve the cost-benefit ratio and therefore make traceability possible in the first place.
Figure 3: The traceability matrix available in IBM Rational RequisitePro allows you to visualize and report on traceability.
Iterative and incremental project delivery, which anticipates and allows for considerable change during a project, greatly increases the need for traceability over traditional software development methods. Therefore, any potential higher, up-front costs are more easily recovered over the duration of a project (see Sidebar). The ability to trace your requirements correctly is an essential prerequisite towards managing compliance in your business environment. Traceability is an essential concept in the Capability Maturity Model.
In order to succeed in your traceability, decide on an appropriate traceability strategy up-front, clearly document and communicate it, and ensure through reviews that the traceability strategy is implemented and that it works. This allows you to harvest the benefits in terms of product quality and controlled change.
1 If not mandated by regulations, such as the Department of Defense (DoD) or the Food and Drug Administration (FDA).
2 Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.
3 Sometimes "Validation" traceability is also referred to as "Elaboration" traceability, as it presents the dimension in which the requirement types (or work products in general) are elaborated or refined. Unfortunately this collides with the RUP Elaboration phase.
4 Often this reporting considers as well other requirement meta information such as priority and risk to put a "percentage-complete" number into context.
5 As you can see from the terminology used ("traced to" and "traced from") we often need to explore the traceability in both directions to satisfy the goals for traceability, i.e. you want to have questions answered like "Is this feature implemented?" looking downwards (trace to) and questions like "How is the scope affected, if we cannot implement this use case?," looking upwards (trace from). The good message, though, is that you can generate one direction from the other.
6 I.e. "or" in the sense of "and/or" and not "either or."
7 Reqarding Figure 2: There is a more elegant way to model the constraint through generalisation, but the explicit constraint makes the point.
8 An example for a hierarchical relationship would be the trace from use cases to use cases steps, supported by appropriate identification. A transformation is a concept from the model-driven architecture (MDA) approach to translating one model into another. This is, though, more practically relevant to the design and implementation disciplines. More on MDA can be found at the OMG Website: http://www.omg.org/mda/
9 In larger projects individual roles can be carried out by a number of individuals, so clarity must be established within the team.
10 An excellent analysis of the different traceability strategies with their advantages and disadvantages can be found in Spence and Probasco's whitepaper, "Traceability Strategies for Managing Requirements with Use Cases", 1998, which is still available in the latest version of RUP. I strongly recommend this paper to anyone responsible for defining the traceability needs for a project that uses a use case based approach to requirements
11 In fact, you may gain some level of implicit traceability (based on names), through the definition of the appropriate domain concepts such as "customer" and "open amount" := "total amount of all unpaid invoices." You can then trace to the use cases through the usage of these domain concepts.
12 See Rational Business Driven Development for Compliance, IBM Redbook, SG24-7244-00, 18. October 2006 (draft).
- Ian Spence and Leslee Probasco, "Traceability Strategies for Managing Requirements with Use Cases," 1998, a white paper that is still available in the latest version of RUP
- Dean Leffingwell, "Features, Use Cases, Requirements, Oh My!," in The Rational Edge, December 2000.
- Leffingwell and Widrig, Managing Software Requirements, Addison Wesley, 1999.
- For more details on Model Driven Architecture, see http://www.omg.org/mda/
- Rational Business Driven Development for Compliance, IBM Redbook, SG24-7244-00, 18. October 2006 (draft).
Special thanks go to my colleague Martin Elliffe for his helpful comments and suggestions.
Thomas Behrens is CTO and head of the requirements engineering theme of Alpheus (www.alpheus.com). He has been leading large requirements projects in the telecommunication and financial services domains. Building on being one of the first users of IBM Rational Rose, he has since expanded his expertise in the IBM Rational tools and processes, especially related to the requirements discipline. He has 16 years of experience in the software industry in various roles, starting as a software developer for embedded systems. Thomas is a certified IBM Instructor. He holds a degree in computer science from the Armed Forces University, Munich, Germany.
Comments (Undergoing maintenance)
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
