• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Getting Requirements from Business Processes

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.

With Issues

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.

4 Responses to Getting Requirements from Business Processes

  1. S.Tomasello January 7, 2016 at 2:48 pm #

    Couldn’t agree with you more, I always start off with the current process “As-Is”. It’s how you discover their pain points and problem areas, not to add it gives the analyst a better understanding of what functions their customers perform each day.

  2. T McGuire January 8, 2016 at 10:02 am #

    Without knowing what happens now by documenting the As Is process, how can you tell what needs to change to improve and make things better?

    The push to get things done and to be seen making progress can sometimes lead managers to say, “you’re wasting time documenting what they do now, of course we know what they do, we need to create the ‘new world now’.

    I’ve had PMs push back on documenting the As Is process because it adds ‘delay’ to their plans. But this is a challenge BAs must overcome to carry out a thorough analysis.

    Fully agree with your post.

  3. Barbara Allen January 17, 2016 at 4:15 pm #

    “Of course they know what they do now” – how many times have we heard that only to diagram it out and discover a forgotten role, a decision that was discontinued or a trigger that is missing or misnamed. I always have my ‘as-is’ at the ready for the virtual meetings, and frequently need to share it. I can’t remember a project with the ‘as-is’ hasn’t been a project-long companion. I just wish i could get them to display on my i-phone so I could have one at the ready for the impromptu cafe conversations.

    Great post, Kevin.

  4. Mary Ann Rodil January 18, 2016 at 7:50 am #

    I like this post, Kevin. Business processes are a key starting point to requirements. Processes give context to and help scope requirements. Without the process perspective, requirements ends up being an endless rambling of disconnected statements of “wants” and “needs”.

Leave a Reply

Your email address will not be published. Required fields are marked *