An Introduction to Requirements Traceability

 I. What is requirements traceability?

Requirements traceability ensures that each business need is tied to an actual requirement, and that each requirement is tied to a deliverable. This is a valuable practice for the business analyst. According to A Guide to the Business Analyst’s Body of Knowledge, (BABOK 2.0), all requirements are “related to other requirements, to solution components, and to other artifacts such as test cases. . . . The goal of tracing is to ensure that requirements (and ultimately, solution components) are linked back to a business objective.” [1] In other words, traceability ensures that every requirement has a business purpose, and that no requirement is superfluous.

A requirement may be traced in one of four distinct ways, according to Karl Weigers in his book Software Requirements

1. “Customer needs are traced forward to requirements, so that you can tell which requirements will be affected if those needs change.

2. Conversely, you can trace backward from requirements to customer needs to identify the origin of each software requirement.

3. You can trace forward from requirements by defining links between individual requirements and specific product elements.

4. Specific product elements [may be traced] backward to requirements so that you know why each item was created.” [2]

Requirements may also be traced to other related requirements. So quite simply, requirements traceability traces relationships between requirements in a set, between business needs and corresponding requirements, and between requirements and the various deliverables of a project.

As to the granularity of tracing requirements, BABOK notes that “tracing may be performed at the individual requirement level, at the model or package level, or at the feature level as appropriate.” This decision, along with which requirements to trace, by what method, and indeed whether to trace requirements at all are all part of responsible requirements management.  

Tracing requirements, when done properly, saves time, money, and effort on the part of the analyst, the project sponsors and the parent organization. Business analysis industry experts have detailed the following benefits of requirements traceability:

1. It ensures that final deliverables directly tie to initial business needs. Forward requirements traceability offers an analyst a means to be sure that business needs are tied to actual requirements, and that actual requirements are tied to deliverables. (Therefore, each business need is tied to a deliverable.) Conversely, backward traceability ensures that if a product feature is developed that no one remembers asking for or authorizing, the analyst can determine whether it is simply a case of gold-plating or if it is indeed tied to a requirement (and corresponding business need). According to BABOK, “When business objectives are traced to detailed require¬ments such as business rules, data elements, and use cases, it is clear how they will be accomplished. Each business objective can be reviewed to make sure that it will be addressed by the appropriate solution components.” [3]

2. Done properly, it ensures that organizations do not waste time and resources repeating research. Without requirements traceability, organizations have the potential to waste a lot of money on backtracking, duplicate research, and lost business needs. In their article, “Why Software Requirements Traceability Remains a Challenge,” authors Andrew Kannenberg and Dr. Hossein Saiedian note that “inadequate traceability is an important contributing factor to software project failures and budget overruns.” [4] In his book Business Rule Concepts, Ronald G. Ross makes a similar point (writing specifically about business rule traceability, but the concept also applies to requirements traceability): “Discovering or reconstructing the pedigree of a business rule is time-consuming, error-prone, and sometimes impossible. Worse, once discovered or reproduced for a particular need . . . the history is often not retained. That means the whole process must be repeated, ad nauseum. Think of rulebook management [or requirements traceability] as a practical means to create pinpoint corporate memory, always keeping it right at your fingertips.” [5]

3. It complies with established industry standards. Kannenberg and Saiedian further point out that traceability is a key ingredient in many respected industry standards for software development, including the CMMI and ISO 9001:2000. [6]

4. 4. If offers much easier impact analysis. Requirements traceability enables intelligent impact analysis; if a stakeholder wants to change a requirement once it is in development or testing, traceable links to business needs and other requirements enable an analyst or project manager to report the full impact of the requested change.

In addition to these benefits, BABOK also notes that traceability helps “to assist in scope and change management, risk management, time management, cost management, and communication management.” [7] For all of these reasons, many experts agree that requirements traceability is an essential practice for the business analyst. 

Requirements traceability often takes the physical form of a requirements traceability matrix (RTM), which is a manual spreadsheet or table that demonstrates the interconnections between requirements and business needs, other requirements, and/or deliverables. (The columns in a table or spreadsheet, for example, might list primary requirements, while the rows might list requirements that are somehow tied to them—thus creating a visual juxtaposition of related requirements.) A traceability matrix is the most common way to demonstrate requirements traceability. An example of a requirements traceability matrix that links requirements to test cases is viewable here:
http://en.wikipedia.org/wiki/Traceability_matrix.

The matrix method is commonly considered to be appropriate only for smaller projects. According to BABOK, “It is typically used when there are relatively few requirements or when tracing is limited to high-level requirements (e.g. features or models).” [8] Author Karl Weigers agrees, noting that it’s “impossible to perform requirements tracing manually for any but very small applications. You can use a spreadsheet to maintain traceability data for up to a couple hundred requirements, but larger systems demand a more robust solution.” [9]

Further, the integrity of a matrix is inextricably tied to the dedicated time commitment of often already-overworked analysts. Weigers further asserts that “tracing requirements is a manually intensive task that requires organizational commitment. Keeping the link information current as the system undergoes development and maintenance takes discipline. If the traceability information becomes obsolete, you’ll probably never recreate it.” [10] Weigers is not alone in his assessment that the sheer commitment of time and effort makes maintaining the integrity of matrices prohibitive in larger projects; many scholars have cited similar issues with manual traceability. In fact, in his master’s thesis, one scholar cites the maintenance of the requirements traceability matrix as the reason that requirements traceability is often not implemented any more effectively at some organizations: “The generation of RTMs is tedious and error-prone, though. Thus RTMs are often not generated or maintained. . . . Automating the process can save time and potentially improve the quality of the results.” [11] (More on traceability automation follows in the next section.) Authors Kannenberg and Saiedian state the problems with manual traceability even more strongly, noting that “manual traceability methods are not suitable for the needs of the software engineering industry. . . . It is easy for manually created traceability data to become out-of-sync with the current set of requirements, design, code, and test cases.” They further note, “Manual traceability methods are also prone to errors that are not easy to catch. Errors can arise from simple typographic mistakes . . . or from carelessness by the individual capturing the data. Because traceability artifacts for large projects are often hundreds or even thousands of pages in length, such errors are difficult to detect when depending on manual methods for error checking.” [12]

The manually intensive aspect tightly links requirements matrices to version control; each time a requirements document is updated, the matrix must be thoroughly reviewed as well. Nonetheless, requirements matrices are quite useful for many organizations and analysts, depending on the size of the project and the level of granularity needed. 

Automated requirements traceability is a function of many types of requirements management software, which purport to include automated systems that catch changes and redundancies that human users may miss. This type of automation can reduce the workload in larger projects, but as Ellen Gottesdiener points out in The Software Memory Jogger, the onus remains on the analyst to diligently monitor and maintain changes. “Tools do not manage requirements; people do. Be sure that requirements management procedures are being practiced before implementing an automated requirements management tool.” [13]

For this reason, some authors, including Kannenberg and Saiedian, are critical of automated traceability tools, noting, “Regrettably, currently existing . . . traceability tools are not adequate for the needs of the software engineering industry. . . . Surprisingly, the tools that are available do not fully automate the entire traceability process; instead, they require users to manually update many aspects of the traceability data.” Nonetheless, for large projects, automated traceability is likely to provide a level of redundancy and efficiency that manual matrices cannot.

Some automated traceability applications offer rather simple techniques, such as displaying a table alongside a text document or diagram that shows which requirements link to which test cases, but not allowing these relationships to be viewed in any dynamic way. Other applications offer more sophisticated traceability techniques, such as allowing the analyst to create quick diagrams linking various requirements together (with arrows to show forward and backward traceability). The system then reads this diagram and automatically embeds links between related requirements within a rich text document. With one click, these relationships can also be viewed in a tree structure, displaying all of the requirements and their relations and dependencies within a project at once.

Whether an organization chooses to adopt a matrix or automated system, the efficacy of either method is greatly benefit from best practices. 

V. Requirements Traceability Best Practices

The following practices will enable more efficient traceability:

• Unique identifiers must be adopted for requirements and business rules. “To permit traceability, each requirement must be uniquely and persistently labeled so that you can refer to it unambiguously through the project.” [14] This is a good practice for the analyst to employ, period, but particularly so for traceability, where each requirement or business rule must have an immutable, unique identifier throughout its life cycle.

• A responsible party must take ownership of traceability. Whether using a manual method or an automated tool, a knowledgeable analyst must take ownership of the traceability process. “Gathering and managing requirements traceability data must be made the explicit responsibility of certain individuals or it won’t happen.” [15] Further, if someone who is not familiar with the system or the requirements attempts to make updates, errors will abound.

• The analyst must practice consistency in updates. This will require a significant commitment on the part of the analyst. “Whenever such changes occur, it is necessary to update the traceability data to reflect these changes. This requires discipline on the part of those making the change to update the traceability data.” [16]

• When tracing all requirements is simply time-prohibitive, the analyst may be selective based on cost. If the prospect of tracing every requirement is overwhelming, an analyst may choose to only trace the expensive ones. “One method of dealing with the high cost of traceability is to practice value-based requirement tracing instead of full tracing. This can save a significant amount of effort by focusing traceability activities on the most important requirements.” [17]Naturally, a prerequisite to this practice is intelligently prioritizing all requirements according to the time and resources involved.

• An organization must adopt consistent practices in requirements management, including traceability. If all stakeholders and team members buy into a traceability practice, take ownership of it, and become accustomed to it, it greatly increases a traceability method’s chances of success. As Kannenberg and Saiedian note, “Perhaps the best way to deal with the problem of different stakeholder viewpoints on traceability is to create an organizational policy on traceability to apply uniformly to all projects.”[18] 

Explore the following online or printed resources for further information:

• A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

• Weigers, Karl E. Software Requirements:Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

• Egyed, Alexander and Grunbacher, Paul. “Supporting Software Understanding with Automated Requirements Traceability.” International Journal of Software Engineering and Knowledge Engineering, Vol. 0, No. 0 (1994). Accessible at here. 

• Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.

Author: Morgan Masters is Business Analyst and Staff Writer at ModernAnalyst.com, the premier community and resource portal for business analysts. Business analysis resources such as articles, blogs, templates, forums, books, along with a thriving business analyst community can be found at http://www.ModernAnalyst.com  

[1]A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

[2] Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

[3] A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

[4] Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.

[5] Ross, Ronald G. Business Rule Concepts: Getting to the Point of Knowledge. Third edition. Business Rule Solutions, 2009, 36.

[6] Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.

[7]A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

[8] A Guide to the Business Analyst’s Body of Knowledge® (BABOK® Guide), Version 2.0, International Institute of Business Analysis, Toronto, Ontario, Canada, ©2005, 2006, 2008, 2009.

[9] Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

[10] Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

[11]Cuddeback, David. “Automated Requirements Traceability: The Study of Human Analysts.” Master’s thesis for California Polytechnic Institute. http://digitalcommons.calpoly.edu/theses/317/. Accessed October 20, 2010.

[12] Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.

[13]Gottesdiener, Ellen. The Software Requirements Memory Jogger. Salem, New Hampshire: GOAL/QPC, 2005. 293.

[14]Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

[15] Weigers, Karl E. Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. Redmond, Washington: Microsoft Press, 2003.

[16] Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.

[17]Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.

[18] Kannenberg, Andrew and Dr. Hossein Saiedian. “Why Software Requirements Traceability Remains a Challenge.” CrossTalk: The Journal of Defense Software Engineering. July/August 2009.