Use cases or business process maps, what technique to use?

Featured
Nov 06, 2016
10521 Views
0 Comments
32 Likes

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.

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.

Use Case Diagram

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

Use Case Section
Detailed Description
Primary Actor
Unregistered customer
Summary
This use case describes the steps that unregistered customer undertakes to register account.
Pre-Conditions
Customer is landed on a main page of a website/portal
Main flow (Success Scenario)
     1. Customer selects a register account option
     2. The system requests customer to provide registration details
     3. Customer provides registration details
     4. The system verifies registration details
     5. The system creates account
     6. The system sends registration link to the provided e-mail address
     7. The system requests customer to provide activate account by providing (following) registration link
Alternate flows
Title
Description
Alternate flow 1
If at a step 4 of the main flow the system verified that details provided invalid registration details then:
1. The system notifies customer about invalid details and provides reasons why new account cannot be registered
2. Use case resumes to the step 2 of the main flow
Exception flow Title
Description
Exception flow 1 1. Customer requests to cancel the registration process at the step 3 of the main flow
2. The system cancels account registration process
3. Use case ends
Post-Conditions
Title
Description
Main flow
Customer is informed that account has been created and activation is required
Exception flow 1
Account registration process is cancelled
Other Notes
N/A

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:

Rule ID
Category
Description
Use case steps
BRU-01
Registration

To register account customer must provide:

  • Login
  • Password (including password confirmation)
Main flow step 2
BRU-02
Registration

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.

Main flow step 2
BRU-03
Registration
Login e-mail address must be unique and during account registration if e-mail address provided by customer is already used in the system then the customer must be notified about it.
Alternative flow step 1

Now let’s take a look what we have to do if we would chose a process maps technique.

Business process maps

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.

Rule ID
Category
Description
Process steps
BRU-01
Registration

To register account customer must provide:

  • Login
  • Password (including password confirmation)
Step 3
BRU-02
Registration

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.

Step 3
BRU-03
Registration
Login e-mail address must be unique and during account registration if e-mail address provided by customer is already used in the system then the customer must be notified about it.
Steps 4, 5

 

Conclusion

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.



Author: Dmitry Zakharov, Certified Business Analyst Practitioner (CBAP®).

Dmitry Zakharov is a Business Analyst with over 14 years of experience on various digital transformation programs. He is an expert in business and functional analysis, design and delivery of cost effective, high-performance information technology solutions. Dmitry is recognised as Certified Business Analysis Professional (CBAP®) by International Institute of Business Analysis (IIBA™).

E-mail: zakharovsyd@gmail.com
Like this article:
  32 members liked this article
Featured
Nov 06, 2016
10521 Views
0 Comments
32 Likes

COMMENTS

Only registered users may post comments.




Latest Articles

The Crucial Art of Pre-Project Problem Analysis
Aug 13, 2017
0 Comments
Business analysis is a broad discipline and we have a whole range of tools and techniques at our disposal. We may get involved within projects, but al...

Featured Digital Library Resources 
Copyright 2006-2015 by Modern Analyst Media LLC