Example of modeling requirements in a process diagram
We use process models for lots of things. One is simply to understand the processes we have and to analyze them looking for opportunities to improve. But in IT, we have another good reason: to better understand software requirements.
One goal that we are chasing these days, on my project, is tracability. Specifically: We want to know that each requirement is tied somewhere to a business process.
Three benefits:
- a requirement without a process drives the need for a process... this forces us to describe the processes, and that means understanding the needs of every user role. (Support teams love this... developers can't ignore their needs if developers have to write down support processes).
- a requirement that some developer or PM thinks is cool doesn't get implemented unless it ties to an actual business process. If the customer won't actually use a feature, we shouldn't use it.
- If the customer introduces a requirement and the developer says "we don't need to do that," the customer can easily demonstrate where the requirement comes from and why it is needed.
Of course, there is nothing more mind-numbing that reading a long list of requirements in a database, word document, or spreadsheet. Business users cannot possibly keep track of every requirement, or look at a list of 2,000 requirements and be able to tell if one of them is not connected to a business process.
It just isn't normal to expect a human being to be able to do that.
The answer that we are using: add the requirements directly to the BPMN diagrams. (Use a modeling tool, so that when you add an element to a diagram, it gets added to a database as well).
So what does this look like? I have attached an example, and some text to help you to understand what it says. I recommend this practice for anyone wanting to help the business users to understand where their requirements come from. Click the image to enlarge it.
It is easy to walk through a process diagram and ask your business users what the requirements are AT THIS STEP. Business folks understand processes, and the fact that you won't tie more than about three or four requirements to any one step in a process, no one will have a mental breakdown trying to understand the list.
| The example is a wild oversimplification of a process that a person may go through when applying for a business license online. The State of Washington has a clever little online site specifically for this purpose. Of course, the real logic is a good bit more complex. The image above is an example specifically for this blog. |
Note: there are two ways that I've attached requirements to the process above. One way is by directly connecting a requirement to a process activity. One requirement is listed above connected in this way.
The other way is by indicating a "support trigger". A support trigger is a question that arises in the mind of a user who is using this tool or process. Those questions drive calls to customer support, cause confusion, and otherwise lower the general level of customer experience.
By placing these support triggers underneath the process, and then tying requirements to them, a business customer can now demonstrate why a requirement is needed.
I hope you find this technique useful.
