Over the years, I’ve found that one of the most effective methods for identifying and eliciting requirements is to walk stakeholders through the current state of their business processes, or to work through their current documentation. What I almost always find is that the documentation contains holes, and that no one person in the department fully understands the scope of their business process. This example (modified from an actual case I came across) is a great example.

At first glance, it looks like a straightforward process. The Regional Manager sets prices, those are sent out to local franchises, who update their store prices and inform the regional office if there’s a reason to change them. However, even in a process as simple as this one, there are some serious open questions.

What are some of the problems we can see in this example model? Remember, the first step isn’t to jump to a solution, even though there’s a fairly obvious one to jump to here. The goal of this step is to see where the process as defined has visible gaps, and no surprise, there are a few.

Issue 1: Trigger
The process map says that this price change is only executed once a quarter. Is that really the case, and is it likely to remain the case for the foreseeable future? We might want to be able to trigger the process, for instance, if an unforeseen event causes a shift in raw material prices. Many critical electronic parts are made by only a few factories, and a fire or natural disaster in one of those locations can increase prices worldwide.

Issue 2: Missing Decision
The step above shows the flow assuming that the Regional Manager approves the price set by the franchise. But what happens if the price is not approved? An easy assumption is that the Regional Manager overrides the franchise’s decision and notifies the franchise–but that may not be the case.

Issue 3: Missing Roles
The steps themselves include statements about who is performing that step–but it would make things much clearer if the performer was given a distinct swimlane within the “Regional Office” and “Franchise” pools. That way, every step would be explicitly allocated to a role, which may help us discover missing roles and missing related process steps (as handoffs are often not as clean as we would like).

Issue 4: Unmarked Ends
As developed, it’s not clear where the process ends. Is there a split when pricing changes are sent back to the regional office? Right now, it would seem so. When processes split into multiple flows and don’t rejoin, figuring out where the end really is can be a challenge. Sometimes it’s the first one to finish, but in other cases it may require that all of them finish. In this particular case, we should be able to fix this by fixing Issue 2 as well.

You may be able to find other issues with the process above. However, the examples here help to show why eliciting the current state process is one of my preferred techniques for getting requirements, and why I think it’s more useful to work from there than to jump directly into the future state process definition.

Your stakeholders know the current state process because they live and work with it every day. That means that they are not only familiar with the regular, ideal path through the process but also with the problems and errors and exceptions that are likely to occur when you execute it. More than that, odds are good that they’ve had to explain all those issues to new team members, new managers, auditors, and others. That means the odds are good that they can explain it to you as well. If you walk through a process map like this with people who are actually performing the process, and ask them questions like the one above, they shouldn’t have any difficulty providing the answers you need.

Those benefits all go away when you focus on the future state process. Instead of focusing on something that’s real to them your stakeholders start fantasizing about an ideal world where they can do their jobs without annoying people disrupting them or telling them what to do. You get a better sense of how they would like the world to work but lose a much deeper understanding of how it does–and the latter is much more useful to an experienced analyst.