If you are familiar with ArgonDigital, then you are aware that we are big proponents of using visual models to help understand requirements. I even wrote a blog post about the case for visual models, which you can find here.
But once you have your models, how do you go from the model to requirements? Let’s look at a process flow, and see how we can do this.
Here is my process flow for this example. In it we are looking at how a user can add an item to a cart for an online store. There is a corresponding level 1 flow for this process as well; however, to keep us focused, I’m not showing it here.
I create my Requirements Mapping Matrix (RMM). The RMM is an RML objectives model that maps information in models to requirements and business rules. I tend to use Excel for my RMM, but any tool that can give you a table will work. I add columns for the various levels of the process flows. I also have columns for a requirements ID and then a column for the requirements themselves. So my RMM looks something like this:
Now I’m ready to begin! I look at my process flow, and I look at the first step. What requirements do I have for this step? As I think about my requirements, I write them down in my RMM. Each requirement is its own line in the RMM, and I repeat the process step information as many times as necessary. Once I have all of the requirements for the first step, I move on to the next step. I repeat this process: derive requirements for each step, write them down in my RMM, and move on. As I continue this process, my RMM starts to look like this:
I continue on until I have gone through every step of the process flow. Then I move on to the next process flow.
This process gives me a very systematic way of working through all of my information, and a way to trace and track my requirements. Now, not every process step will have requirements. And that is OK. But what is important is that I’ve given that process step 30 seconds of thought, and made the educated determination that there are no requirements for that process step. It is also harder to miss requirements, because I’m looking at each process step individually, and giving each step some time to think about what the requirements are.
The beauty of this process is I can stop at any time, and go to a meeting. Or stop for the day. Or do another task. But it is easy for me to see where I stopped and where I need to start once again.
You can easily add business rules to the RMM as well. Business rules tend to hide in decision boxes, thus by going through this systematic way of deriving requirements, and I can identify and document business rules as well.
The process flow model is not the only model you can use in the RMM. You can easily add other models as well. Just add a column, and add the model information. For example, and one of my favorites, is add Feature Tree information to the RMM. This helps map all of your requirements to the various features that your system will have.
Once you have your RMM completed, you can now use it to analyze if your requirements are complete. Do you have requirements for all of your process flow steps? For those steps that do not have requirements, is that OK? Do all of your features have requirements? What are you missing? This gives you a very clear way to go back and fill in the holes.
The RMM is also a great tool to use during requirement reviews. Since I create mine in Excel, I can then filter my requirements. During a requirements review session, I print out the process flows and give them to my stakeholders and SMEs. I use my projector to display the RMM, and filter my RMM by process flow. I can even go as low as a process flow step. This helps limit the information your stakeholders and SMEs are looking at; it also helps keeps them focused on the requirements you need reviewed.
