Using a Requirements Mapping Matrix to organize and identify requirements
Written by Joy Beatty, co-author of Visual Models for Software Requirements (ISBN: 9780735667723).
Joy Beatty here. As business analysts, if we hand developers nothing more than a list of thousands of “system shall” requirements statements, the project is doomed to fail before even a line of code is written.
Figure 1 Unorganized list of “system shall” statements
Because there are many models you can use to better describe the requirements visually (in fact you’ll find 22 Requirements Modeling Language (RML) models in Visual Models for Software Requirements ), it can be a daunting task to try to figure out where to start in adding new models to your requirements repertoire. However, one requirements model you can use on almost any project at almost any point in the project is a Requirements Mapping Matrix (RMM).
The RMM is a visual model that can help organize information (for example, thousands of “system shall” requirements) to find missing links, missing information, and unnecessary information you can cut. RMMs are used to map elements of models to one another as needed. We most commonly use RMMs to map business objectives, Process Flow steps (multiple levels of them), features, requirements, and business rules to one another. However, you can map anything, like Process Flow steps to user interface screens or requirements to test cases.
| Such a list, as in Figure 1, is impossible to consume for analysis, development, or testing. Any large volume of requirements should be modeled visually to ensure they are complete and all necessary. |
Figure 2 shows an example of an RMM that maps three levels of Process Flow steps to features to requirements. |
Figure 2 Example RMM |
Traceability matrices are similar to RMMs, but because you can map more than two objects to one another in an RMM, we find RMMs are more flexible and therefore provide more value than typical traceability matrices. How to use RMMs to identify requirements RMMs help you identify requirements throughout the project. For example, if you put your Process Flow steps in the matrix, then you can look at one step at a time and think about requirements to support that step. After each step, then move to the next step, and so on. For example, in Figure 1, we would consider the “Enter search criteria” step of our L3 Process Flow and try to identify all possible requirements for that step by focusing only on that individual step. We would do the same for the “Review search results” step. If you already have requirements identified, you can still put them in an RMM and map them to Process Flow steps. Then, you look for missing requirements and steps. If you have steps that do not have many requirements, you might be missing requirements. If you have requirements that do not map to a step, then you either are missing a step in a Process Flow, or you have a requirement that doesn’t support a business process and might not be needed. Figure 3 shows an example of a Process step that might be missing requirements and a requirement that is not mapped to a Process Flow step. |
|
Figure 3 Missing requirements and Process Flow steps |
Based on the work of cognitive psychologist George A. Miller, we know that it is hard for people to analyze more than 7+/-2 things at a time. Therefore, if you have more than approximately five to nine requirements mapped to a single Process Flow step, you need to create another grouping to further organize requirements, like features. Then you’d have Process Flow steps mapped to features mapped to requirements.
Using RMMs to control scope
Mapping requirements or Process Flows to business objectives can help you cut unnecessary scope. If you can determine that processes do not need to be supported because they don’t contribute to the business objectives, then you can cut all the requirements that map to those processes. Or you can simply ensure that all requirements map to business objectives in this matrix.
RMMs can even be used to filter requirements
When created in the right tool, RMMs allow you to filter your requirements down to a relevant set for review or analysis. For example, if you are meeting with stakeholders about a process to “Update product catalog,” you can apply filters to show only the process steps and requirements for that Process Flow to focus the conversation.
If you can only make one change to your requirements approach…
If you need to take small steps to improve your requirements effort – maybe because you can’t make big changes in your organization right now or maybe you are pretty far into specifying your project’s requirements already – then the RMM is an easy model to implement as a first step. Remember, if you do not have Process Flows, you can map requirements to other things – user interface screens and business objectives. In fact, even if the requirements are complete, the RMM can still be used to map requirements to design, code, or test cases to ensure full coverage as in Figure 4.
Figure 4 Example RMM mapping requirements to code and test cases
Further, you do not have to have a requirements management tool in place to create RMMs, you can use Microsoft Excel. However, there are tools that simplify work with RMMs by allowing you to drag and drop the mapping links.
RMMs are just one of many RML models that you can use to improve your software requirements. If you want to learn more about Seilevel’s ideas for creating software requirements and other visual models you might be able to use immediately, visit our web site (https://www.seilevel.com/) and blog (https://requirements.seilevel.com/blog/).