A list of business analysis techniques is pretty extensive and from year to year new techniques appear, or become more formalised, and are adopted by business analysts all over the world. Some techniques become more popular and are widely used and some are used rare or only when a specific need arises. But definitely there are techniques that became very popular and are used on a daily basis and even become buzz words for some people. These techniques are mainly used to create solution design and they are business process maps, use cases, user stories, wireframes and business rules. Sometimes even business analysts are confused how they should create solution design and what techniques they should use.
Mainly this confusion is about two popular techniques - use cases and process maps and even more experienced business analyst do not completely understand the difference between those two. In this article I want to shed some light on the difference between process maps and use cases.
Let’s look at use cases first. What is the purpose of use cases? First of all let’s look at the use case diagram. It shows us what the boundaries of the system are, how many use cases there are, actors and relationships between actors and use cases; relationships between use cases and use cases. So basically, the use case diagram provides us with the scope of the system or a sub-system what is highlighted as use cases strength in BABOK. Let’s take a look at the example below.
Then we want to provide more clarity on each of the use cases and we create a use case descriptions. Use case descriptions provide a sequence of step an actor has to go through to achieve a goal and also provide details re exception and alternative flows. Let’s take a look at a simple example of a use case description.
UC-01 Register account
When we did that for all 4 use cases we have a solid foundation for development of the new solution. But that’s not all. Now we have to specify business rules related to use cases. As BABOK prescribes business rules should be captured separately so if they are changes we do not need to change our use case. Let’s look at the example of business rules below:
To register account customer must provide:
Customer must use e-mail address as a login.
The length of login e-mail address field must be 80 characters. This is the total length including domain name e.g. @gmail.com.
Now let’s take a look what we have to do if we would chose a process maps technique.
Let’s start with the scope as well. As we know business process maps show sequence so we can’t use this technique to show the scope of the system. What should we do then? Well, I usually use a scope diagram. There are many ways to create a scope diagram and below I provide an example how a scope diagram may look like.
This scope diagrams shows features/functions of a system divided by actors.
So when scope grows it’s possible to add functionality categorization and e.g. fluffy icons that everyone will love. A mature scope diagram could look like that:
Some of you could say that use case diagram can show relationships between use cases e.g. include, extend and also it is possible to show that one use case could be performed by several actors. This is also possible to show on scope diagram – use colors or symbols, it’s not hard.
Now let’s draw a process for account registration feature/functionality. Account registration process will look like this:
From what we have just did we can see that a flow between steps 4 and 5 is an alternative flow 1 of the use case and flow which is labeled as Cancelled is an exception flow 1 of the use case.
Similar to use case technique we need to create business rules and track them back. In this case we track business rule back to the process steps.
So, as you can see we used different techniques and basically the result is the same. It was not really important what techniques were used unless solution design is complete. It’s just a matter of a habit so if you’re more comfortable with use cases then stick to them or if you’re more familiar with process maps then draw a map. But note that in some cases you may be requested to use a specific technique that is a corporate standard or because there is an agreement that all BAs on the project will use one template (technique) for consistency.
The only cases I would highlight as an exceptions are cases of a complex functionality with pretty complicated logic and there are many ifs, buts and other conditions. In this case I would prefer to use process maps however I’ve seen people used use cases and had many alternative and exception flows e.g. exception flow 3 of the alternative flow 3 of the exception flow 1. In this case approvers would be exhausted trying to follow the logic.
Also I wanted to draw your attention that people who are not really familiar with business analysis could use techniques as buzz words. In my practice I have seen many times when business SMEs or project managers gave directions to create use case or user stories and didn’t really understand what the difference was between the two techniques. Another reason for that request could be that these people used that technique on previous projects and they have no idea that variety of business analysis techniques is pretty big. Don’t forget that in most cases a business analyst decides what techniques to be used on a particular project or initiative based on BA’s judgment, experience and preferences.
brought to you by enabling practitioners & organizations to achieve their goals using:
enabling practitioners & organizations to achieve their goals using: