One of my favorite tools to use during any project, but particularly for software projects, is the Requirements Traceability Matrix (RTM). I’ve discussed this in presentations I’ve given on the framework I use for performing business analysis (and project management to a lesser degree), but I wanted to take some time to take about using the RTM in detail.
The purpose of the RTM is to make sure that all requirements map to business needs and that all of the requirements get fulfilled and accepted. People have done this sort of thing for years (decades… and longer) using punch lists and other techniques, but the RTM has a specific structure.
I’m going to describe its usage in terms of the framework I use but you can use any series of steps with any names you’d like. The most basic set of steps you can probably identify is Business Need, Requirement, Implementation, Acceptance. The framework I use consists of these steps: Intended Use, Conceptual Model, Requirements, Design, Implementation, Test, Acceptance. The conceptual model part has to do with describing the As-Is state of an existing system, but if a new system is being constructed there might not be an existing system to work from, and there may or may not be a need for a conceptual model.
Here’s a graphical representation of what a Requirements Traceability Matrix might look like, based on the workflow I use:
The idea is that every item in every column (step of the workflow) maps to at least one item in the previous and subsequent columns. That is, every item in the conceptual model maps to a business need (the intended use), every requirement maps to an item in the conceptual model, every element of the design maps to a requirement, every element of the implementation maps to a design element, every test item maps to an implementation item, and every acceptance item maps to a test item. The relationships can be one-to-many and many-to one in either direction, but the relationship is typically one-to-many going left to right.
An exception to the idea that items always have to map in both directions is that non-function requirements elements do not necessarily have to map back to items in the conceptual model or intended use. That said, the use of specific hardware and software elements may be driven by identifiable business needs, but other aspects may not be. For example, deploying operations to Amazon Web Services may be part of an explicit organizational strategy, but ensuring that a solution is modular, flexible, and maintainable may be just good practice. You can think of these ideas however you’d like.
You may notice a few dashed lines going back to question marks in the diagram. These show that if you identify something that’s needed part way through the process that doesn’t obviously map to an existing item in the previous step of your workflow, then that may indicate that you need to add something to that previous step.
Finally, the items at the bottom represent free-floating project methodology requirements, if they exist. They’re kind of like non-functional requirements in that they don’t address what the solution does (functional requirements), or what the solution is, but how the steps should be carried out. For example, we wrote procedures for collecting data at land border crossings at one of the companies I worked for. Another example may involve writing automated tests for implementation items when using test-driven development (TDD).
Let’s talk about all of the steps one by one.
The intended uses, essentially the identified business needs, describe the high-level operations the organization needs to accomplish in order to serve its customers. Examples include making decisions on whether or not to provide insurance coverage for a given customer, allowing a customer to place an online order, and allowing customers to request slots in a schedule.
The conceptual model is an abstract representation of a system. It may include entities, stations, operations, and transformations. The representation may take almost any form. In my work these representations have included diagrams, equipment lists, and equations.
The requirements describe the elements and operations that most be addressed in the solution. They describe the concepts that must be represented and the means of controlling the relevant operations.
The design describes the proposed elements that will make up the solution.
The implementation items are the specific pieces of work, in terms of objects, repositories, and processes, that need to be made real to construct the planned solution.
The test items are intended to address each element of the implementation.
The acceptance items are approved when each of the tests are shown to have been passed.
Once we understand what goes into a requirements traceability matrix (which is sometime shortened to requirements trace matrix), we can think about how we actually implement and use one.
The simplest way is to write it out in text, for example in Microsoft Word. They can be written in outline form but the key to linking items is to give some sort of alphanumerical label to each item so they can refer to each other.
A large VV&A project I did involved a 200-plus page document in three sections that had a trace matrix as part of its content. We embedded tables for each of the three identified intended uses, and each table mapped all of the implementation items to the requirements. There was no step for conceptual model and all of the test information was included in a separate, standalone bug-tracking system. The acceptance criteria were addressed in several different ways.
Remembering that testing involves both verification and validation, we see that there might be many different test items linked to the various implementation elements. Verification is meant to determine whether things work operationally. Do elements of the user interface cause the expected actions to occur when they are activated? Do calculations provide the expected results given specified inputs? Can certain types of users access certain screens? These kinds of tests are easier to automate and have more objective criteria for correctness. Validation is more subtle. It is meant to determine whether the implemented solution properly and sufficiently addresses the business need (the reason the solution was implemented in the first place). The criteria for validation might be very subjective, and might have to be determined by expert judgment.
It’s also easy to imagine doing an RTM in Excel, using an outline format, though it might be difficult to make such a resource available simultaneously to a large group of users. A relational database implementation with a dedicated user interface may also work, and that’s what I’m thinking about specifying.
I’m also thinking specifically about how to use Jira in a way that is compatible with the idea of an RTM, since I’m working my way through a Udemy course on Jira right now. I’ll let you know how that goes in subsequent posts.