Simple requirements changes often have far-reaching impacts, necessitating that many parts of the product be modified. It’s hard to find all the system components that might be affected by a requirement modification. Assessing the impact of a proposed change is easier if you have a road map that shows where each requirement or business rule was implemented in the software.
This is the first article in a three-part series, adapted from my book Software Requirements, 2nd Edition, that addresses the subject of requirements tracing (or traceability). Requirements tracing documents the dependencies and logical links between individual functional requirements and other system elements. These elements include other requirements, business rules, architecture and other design components, source code modules, test cases, help files, and documentation. Traceability information facilitates impact analysis by helping you identify all the work products you might have to modify to implement a proposed requirement change.
Tracing Requirements
Traceability links allow you to follow the life of a requirement both forward and backward, from origin through implementation. To permit traceability, each requirement must have a unique and persistent label so you can refer to it unambiguously throughout the project. Write the requirements in a fine-grained fashion, rather than having large paragraphs containing many individual functional requirements that lead to an explosion of design and code elements.
Figure 1 illustrates four types of requirements traceability links. Customer needs are traced forward to requirements, so you can tell which requirements will be affected if those needs change during or after development. This also gives you confidence that the requirements specification has addressed all stated customer needs. Conversely, you can trace backward from requirements to customer needs to identify the origin of each software requirement. If you represented customer needs in the form of use cases, the top half of Figure 1 illustrates tracing between use cases and functional requirements.
The bottom half of Figure 1 indicates that, as requirements flow into downstream deliverables during development, you can trace forward from requirements by defining links between individual requirements and specific product elements. This type of link assures that you’ve satisfied every requirement because you know which components address each one. The fourth type of link traces specific work products backward to requirements so that you know why each item was created. Most applications include code that doesn’t relate directly to user-specified requirements, but you should know why someone wrote every line of code.
Suppose a tester discovers unexpected functionality with no corresponding written requirement. This code could indicate that a developer implemented a legitimate implied requirement that the analyst can now add to the specification. Alternatively, it might be “orphan” code, an instance of gold plating that doesn’t belong in the product. Traceability links can help you sort out these kinds of situations and build a more complete picture of how the pieces of your system fit together. Conversely, test cases that are derived from—and traced back to—individual requirements provide a mechanism for detecting unimplemented requirements because the tester won’t find the expected functionality.
Traceability links help you keep track of parentage, interconnections, and dependencies among individual requirements. This information reveals the propagation of change that can result when a specific requirement is deleted or modified. If you’ve mapped specific requirements into tasks in your project’s work-breakdown structure, those tasks will be affected when a requirement is changed or deleted.
Figure 2 illustrates many kinds of direct traceability relationships that can be defined on a project. Of course, you don’t need to define and manage all these traceability link types—no one will. On many projects you can gain eighty percent of the desired traceability benefits for perhaps twenty percent of the potential effort. Perhaps you only need to trace system tests back to functional requirements or use cases. Decide which links are pertinent to your project and can contribute the most to successful development and efficient maintenance. Don’t ask team members to spend time recording information unless you have a clear idea of how you expect to use it.
Motivations for Tracing Requirements
I’ve had the embarrassing experience of writing a program and then realizing I had inadvertently omitted a requirement. It was in the spec—I just missed it. Overlooking a requirement is more than an embarrassment if it means that a customer isn’t satisfied or a delivered product is missing a security, safety, or compliance function. At one level, requirements tracing provides a way to demonstrate compliance with a contract or specification. At a more sophisticated level, requirements tracing can improve the quality of your products, reduce maintenance costs, and facilitate reuse. Following are some potential benefits of implementing requirements traceability:
• Certification. Traceability information can be used when certifying a safety-critical product to demonstrate that all requirements were implemented (although it doesn’t confirm that they were implemented correctly or completely!). Of course, if the requirements are incorrect or key requirements are missing, even the best traceability data won’t help you.
• Change impact analysis. Without traceability information, there’s a high probability of overlooking a system element that would be affected if you add, delete, or modify a particular requirement.
• Maintenance. Reliable traceability information facilitates making changes correctly and completely during maintenance, which improves your productivity. When corporate policies or government regulations change, software applications often require updating. A table that shows where each applicable business rule was implemented in the functional requirements, designs, and code makes it easier to make the necessary changes properly.
• Project tracking. If you diligently record the traceability data during development, you’ll have an accurate record of the implementation status of planned functionality. Missing links indicate work products that have not yet been created.
• Reengineering. You can list the functions in a legacy system you’re replacing and record where they were addressed in the new system’s requirements and software components. Defining traceability links is a way to capture some of what you learn through reverse engineering of an existing system.
• Reuse. Traceability information facilitates reusing product components by identifying packages of related requirements, designs, code, and tests.
• Risk reduction. Documenting the component interconnections reduces the risk if a key team member with essential knowledge about the system leaves the project.
• Testing. The links between tests, requirements, and code point you toward likely parts of the code to examine for a bug when a test yields an unexpected result. Knowing which tests verify which requirements can save time by letting you eliminate redundant tests.
Many of these are long-term benefits, reducing overall product life-cycle costs but increasing the development cost by the effort you expend to accumulate and manage the traceability information. View requirements tracing as an investment that increases your chances of delivering a maintainable product that satisfies all the stated customer requirements. Although difficult to quantify, this investment will pay dividends anytime you have to modify, extend, or replace the product.
The second article in this series discusses the requirements traceability matrix, and the final part proposes a procedure for making requirements traceability work on your projects.
Check out Links in the Requirements Chain, Part 2.
Check out Links in the Requirements Chain, Part 3.
Jama Software has partnered with Karl Wiegers to share licensed content from his books and articles on our web site via a series of blog posts, whitepapers and webinars. Karl Wiegers is an independent consultant and not an employee of Jama. He can be reached at http://www.processimpact.com. Enjoy these free requirements management resources.
