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:

1. 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).
    
2. 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. 
    
3. 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.

Comments

• Anonymous
  May 22, 2008
  what tool are you using for BPM modeling?

• Anonymous
  May 22, 2008
  Sparx Enterprise Architect

• Anonymous
  May 22, 2008
  Having been recently brought onto a project that is in deep difficulties, I can vouch for this as an excellent approach. One of our first tasks was to break down the requirements into a series of diagrams much like this - that were intended to let the USERS of the system see what it did. The diagrams would probably be (or at least many developers would say), too simplistic for develeopers to use - but they can't ignore them as the business has clear sight of the processes now, and has validated they are a match for their requirements. Our diagrams took nothing more than Visio, and an output of a few sheets of A4 paper chained together on the wall by PostItNote arrows - but they give great visibility

• Anonymous
  May 23, 2008
  Any other similar tools that you'd recommend in addition to Sparx that work in this manner? This is exactly the technique I plan to use with the replacement of a 20+ year old system with significant customization that works tightly with somewhat unique business processes for my industry. I really only planned on documenting critical functions in some areas for "key" processes. I also planned to link, at the process flow level - current state business issues, anticipated future state challenges (e.g., new regulations, trends), business goals, and the success metrics that would monitor the "issues" and health of the process (i.e., to ensure proper information was being captured). The triggers concept is really intriguing. To me, this puts requirements in context and will also help with prioritization. Requirements linked to resolving the most business issues, challenges, achieving business goals and providing key metrics are likely the most important. This could remove some personal preferences from the requirements prioritization process.

• Anonymous
  May 23, 2008
  IF you have only one tool that you purchase and use, Sparx Enterprise Architect should be that tool.

• Anonymous
  May 23, 2008
  One other thought... Microsoft should provide better non-VBS linkages between custom Visio properties and Access or SQL Server to allow better tagging of information to Visio process diagrams (i.e., populate a Visio custom property called "requirements" from a listing in a database - with some filtering, of course... who'd want to search through a few thousand requirements?).

• Anonymous
  May 23, 2008
  Hi Kevin, I want better tools too.  There's a good bit of work inside Microsoft on modeling tools under the moniker of Oslo, so I'm hopeful.  Until those tools are out, and mature, there's Sparx. --- N