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.
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 (http://www.seilevel.com/) and blog (http://requirements.seilevel.com/blog/).