The first part in this series of articles presented an overview of requirements traceability, identified the potential kinds of traceability links you could define among a project’s artifacts, and stated several motivations for tracing requirements. This article, adapted from my book Software Requirements, 2nd Edition, describes the requirements traceability matrix.
The Requirements Traceability Matrix
The most common way to represent the links between requirements and other system elements is in a requirements traceability matrix, also called a requirements trace matrix or a traceability table. Table 1 illustrates a portion of one such matrix. When I’ve set up such matrices in the past, I made a copy of the baselined SRS and deleted everything except the labels for the functional requirements. Then I set up a table formatted as in Table 1 with only the Functional Requirement column populated. As fellow team members and I worked on the project, we gradually filled in the blank cells in the matrix.
Table 1. One Kind of Requirements Traceability Matrix
Table 1 shows how each functional requirement is linked backward to a specific user requirement (represented in the form of use cases in this example), and forward to one or more design, code, and test elements. Design elements could be objects in analysis models such as data flow diagrams, tables in a relational data model, or object classes. Code references can be class methods, stored procedures, source code filenames, or procedures or functions within the source file. You can add more columns to extend the links to other work products, such as online help documentation. Including more traceability detail takes more work, but it also gives you the precise locations of the related software elements, which can save time during change impact analysis and system maintenance.
You should fill in the information as the work gets done, not as it gets planned. That is, enter “catalog.sort()” in the Code column of the first row in Table 1 only when the code has been written, has passed its unit tests, and has been integrated into the source code baseline for the product. This way a reader knows that populated cells in the requirements traceability matrix indicate completed work, not just good intentions.
When completing the matrix column for system test cases, note that listing the test cases for each requirement does not indicate that the software has passed that test. It simply indicates that tests have been written to verify the requirement at the appropriate time. Tracking testing status is a separate matter.
Nonfunctional requirements such as performance goals and quality attributes don’t always trace directly into code. A response-time requirement might dictate the use of certain hardware, algorithms, database structures, or architectural choices. A portability requirement could restrict the language features or coding conventions the programmers use, but it won’t necessarily turn into specific code segments that enable portability. Other quality attributes are indeed implemented in code, though. Integrity requirements for user authentication lead to derived functional requirements that are implemented through, say, passwords or biometrics functionality. In those cases, trace the corresponding functional requirements backward to their parent nonfunctional requirement and forward into downstream deliverables as usual. Figure 1 illustrates a possible traceability chain involving nonfunctional requirements.
Figure 1. Traceability chain for requirements dealing with application security.
Traceability links can define one-to-one, one-to-many, or many-to-many relationships between system elements. The format in Table 1 accommodates these cardinalities by letting you enter several items in each table cell. Here are some examples of the possible link cardinalities:
-
One-to-one. One design element is implemented in one code module.
-
One-to-many. One functional requirement is verified by multiple test cases.
-
Many-to-many. Each use case leads to multiple functional requirements, and certain functional requirements are common to several use cases. Similarly, a shared or repeated design element might satisfy a number of functional requirements. Ideally, you will capture all these interconnections, but in practice many-to-many relationships can become complex and difficult to manage.
Another way to represent traceability information is through a set of matrices that define links between pairs of system elements, such as:
-
One type of requirement to other requirements of that same type
-
One type of requirement to requirements of another type
-
One type of requirement to test cases
You can use these matrices to define various relationships that are possible between pairs of requirements, such as “specifies/is specified by,” “depends on,” “is parent of,” and “constrains/is constrained by.”
Table 2 illustrates a two-way traceability matrix. Most cells in the matrix are empty. Each cell at the intersection of two linked components is marked to indicate the connection. You can use different symbols in the cells to explicitly indicate “traced-to” and “traced-from” or other relationships. Table 2 uses an arrow to indicate that a functional requirement is traced from a particular use case. These matrices are more amenable to automated tool support than is the single traceability table illustrated in Table 1.
Table 2. Requirements Traceability Matrix Showing Links Between Use Cases and Functional Requirements
Traceability links should be defined by whoever has the appropriate information available. Table 3 identifies some typical sources of knowledge about links between various types of source and target objects. Determine the roles and individuals who should supply each type of traceability information for your project. Expect some pushback from busy people whom the BA or project manager asks to provide this data. Those practitioners are entitled to an explanation of what requirements tracing is, why it adds value, and why they’re being asked to contribute to the process. Point out that the incremental cost of capturing traceability information at the time the work is done is small; it’s primarily a matter of habit and discipline.
Table 3. Likely Sources of Traceability Link Information
Tools for Requirements Tracing
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. Requirements tracing can’t be fully automated because the knowledge of the links originates in the development team members’ minds. However, once you’ve identified the links, tools can help you manage the vast quantity of traceability information.
There are numerous commercial requirements management tools that have strong requirements tracing capabilities. Two sources of information about such tools are http://www.incose.org/ProductsPubs/Products/rmsurvey.aspx and http://www.volere.co.uk/tools.htm. You can store requirements and other information in a tool’s database and define links between the various types of stored objects. Some tools let you differentiate “traced-to” and “traced-from” relationships, automatically defining the complementary links. That is, if you indicate that requirement R is traced to test case T, the tool will also show the symmetrical relationship in which T is traced from R.
Some tools automatically flag a link as suspect whenever the object on either end of the link is modified. The suspect links have a visual indicator such as a red question mark or a diagonal red line in a cell in the requirements traceability matrix. The suspect link indicators tell you to check, say, whether you need to change certain functional requirements to remain consistent with a modified use case. This feature helps ensure that you have accounted for the known ripple effects of a change.
The final article in this series will propose a process for incorporating requirements traceability practices into your project activities.
About Author :
Karl Wiegers is Principal Consultant at Process Impact, www.ProcessImpact.com. His interests include requirements engineering, project management, peer reviews, and process improvement. His most recent book is a memoir of life lessons titled Pearls from Sand: How Small Encounters Lead to Powerful Lessons (www.PearlsFromSand.com).