In the world of software development Use Cases are one of many very powerful techniques often used these days. Use cases describe how a person or a system interacts with the solution being modeled/built to achieve a goal. Basically, it’s a step by step explanation of what a user can do and how the solution must respond.
As any other business analysis technique, use cases have their advantages and disadvantages. One of the main disadvantages of use cases is that this technique is not graphical – a use case diagram is but use case descriptions are not, and use case descriptions really lack of visualization especially if there are multiple alternative flows and exception flows that branch out and then loop back into the main one.
In these days of digital transformation, stakeholders are more familiar with various types of diagrams, wireframes, prototypes, data visualization and going through a convoluted text is not what they usually expect. On top of that, the human brain processes images 60,000 times faster than text, and 90 percent of information transmitted to the brain is visual. We are visual by nature.
So, let’s try to transfer a use case description into a more visual model to make this technique even more powerful.
Old school
Let’s look at how use cases are done these days. As an example let’s take a look at a password reset use case which is a pretty common functionality. So, in a nutshell, the use case looks like this: customer requests to reset a password for a username, then they receive a verification code, provide the code to the system, answer a security question (for example purposes only) and provide a new password.
The traditional use case description would look like this:
|
Use Case Section
|
Detailed Description
|
|
Primary Actor
|
Company customer
|
|
Summary
|
This use case describes the steps that customer undertakes to reset password for online account when customer forgot their password. Customer may reset password using a password reset code sent to their mobile phone number or e-mail address.
|
|
Pre-Conditions
|
Customer navigated to Log In screen
|
|
Main flow (Success Scenario)
|
|
1. Customer selects an option to reset password
2. The system request customer to provide username
3. Customer provides username
4. The system verifies account status and checks registered alternative contact details (if mobile number/alternative e-mail registered in account profile)
5. The system requests customer to provide code dispatch options (e.g. if a code will be sent to mobile phone or e-mail address)
6. Customer provides code dispatch options
7. The system sends password reset code to customer
8. The system check if code resend option must be available
9. The system requests customer to provide the code
10. Customer provides password reset code
11. The system verifies password reset code
12. The system verifies if security questions are set up
13. The system requests customer to provide answer for randomly chosen security question
14. Customer provides answer for security question
15. The system verifies answer for security question
16. The system requests customer to provide new password
17. Customer provides new password (including confirmation)
18. The system updates password
19. The system unlocks customer account (if account is locked)
20. The system authorises (logs in) customer
21. The system notifies customer that the password was successfully changed
|
|
Alternate flows
|
Title
|
Description
|
|
Alternate flow 1
|
If at the step 11 of the main flow the system verified that password reset code does not match then:
1. The system verifies if password reset code must be expired
2. The system informs customer that password reset code does not match
3. Use case resumes to the step 8 of the main flow
|
|
Alternate flows of the alternate flow 1
|
Title
|
Description
|
|
Alternate flow 1 of the alternate flow 1
|
If at the step 1 of the alternate flow 2 the system verified that password reset code must be expired then:
1. The system expires password reset code
2. The system verifies if password reset code resend option must be locked or not
3. The system notifies customer about not matched and expired password reset code and provides code resend option
4. Customer requests to resend the code
5. Use case resumes to the step 7 of the main flow
|
|
Exception flow 1 of the alternate flow 1 of the alternate flow 1
|
If at the step 2 of the alternate flow 1 of the alternate flow 2 the system verified that password reset code resend option must be locked:
1. The system locks code resend option
2. The system notifies customer that password reset code did not match and is expired and password reset code resend option is locked for a period of time
3. Customer receives notification
4. Use case ends
|
|
Alternate flow 2
|
If at the step 12 of the main flow the system verified that security question are not set up then:
1. Use case resumes to the step 16 of the main flow
|
|
Alternate flow 3
|
If at the step 15 of the main flow the system verified that answer for security question is invalid:
1. The system verifies if password reset option must be locked or not
2. The system notifies customer about incorrect answer for security question
3. Use case resumes to step 13 of the main flow
|
|
Exception flows of the alternate flow 3
|
Title
|
Description
|
|
Exception flow 1 of the alternate flow 3
|
If at a step 1 of the alternate flow 4 the system verified that password reset option must be locked then:
1. The system locks password reset option
2. The system notifies customer about incorrect answer for security question and permanently locked password reset option
3. Customer receives notification
4. Use case ends
|
|
Alternate flow 4
|
If at the step 10 of the main flow customer requests to resend password reset code (if customer is allowed to request to resend the code)
1. The system expires current code
2. Use case resumes to the step 7 of the main flow
|
|
Alternate flow 5
|
If at the step 10 of the main flow customer requests to resend password reset code via a different channel (if customer is allowed to request to resend the code and if customer has alternative e-mail or mobile phone registered in their account):
1. The system expires current code
2. Use case resumes to the step 5 of the main flow
|
|
Alternate flow 6
|
If at the step 4 of the main flow the system checked that customer has no mobile phone and alternative e-mail address registered in their account then:
1. Use case resumes to step 7 of the main flow
|
|
Exception flows
|
Title
|
Description
|
|
Exception flow 1
|
If at the step 4 of the main flow the system verified that customer account is disabled, account login is invalid or reset password option is locked:
1. The system notifies customer about disabled account, invalid account login or locked reset password option
2. Customer receives disabled account, invalid account notification
3. Use case ends
|
|
Exception flow 2
|
1. Customer requests to cancel reset password process at:
· steps 3, 6, 10, 14 or 17 of the main flow
· Step 4 of the alternate flow 1 of the alternate flow 1
2. The system cancels reset password process
3. Use case ends
|
|
Post-Conditions
|
Title
|
Description
|
|
Main flow
|
Customer is logged in and is informed that account password was successfully changed
|
|
Exception flow 1
|
Customer is informed about disabled account, invalid account login or locked reset password option
|
|
Exception flow 1 of the alternate flow 1
|
Customer is informed that password reset code is invalid and is expired and password reset code resend option is locked for a period of time
|
|
Exception flow 1 of the alternate flow 3
|
Customer is informed that answer for security question was incorrect and reset password option is permanently locked
|
|
Exception flow 2
|
Reset password process is cancelled
|
|
Other Notes
|
Note that SNSW account lock-out due to fraudulent activities is out if scope of this document.
|
As you can see there are so many alternative flows, exception flows and even alternative flow of alternative flow. This description looks very complicated and no one really will want to read it.
New school
Now let’s see how it is possible to visualize the above use case description.
Let’s present it as a process flow. I drew processes map using BPMN so I will use BPMN elements – tasks, conditional flows, events. As this use case contains only two actors , I won’t use any swimlanes bur rathher will use color coding instead. Also, I will make the diagram flow from top to bottom.
The process flow will look like this:
As you can see, the visual representation is also complex but is much more visually appealing. You can easily follow how alternative and exception scenarios flow. I bet the stakeholders would rather slide through the flows than go thorough complex ifs and buts.
I also used BPMN’s default flows when I described complex scenarios like alternative/exception flows of alternative flows.
With numbering I did the following thing – I numbered the main flow first and then for alternative flows I put letter A and flow number and then step number e.g. for step 1 of alternative flow 1 it was A1.1. For complex scenarios like alternative/exception flows of alternative flows I did like this e.g. E1A1.1 means that it is step 1 of exception flow 1 of alt. flow 1. I did this for this particular example so that it was easy to compare but in reality, numeration does not need to be that complex.
Also, if there is a need for another participant then just use another color, add description, include actors’ summary etc. The sky is the limit.
Conclusion
Basically, we represented the same system design in a different manner that is easy to follow and understand. This will help not just your business SMEs to review and approve a design but also will make happy campers out of your technology stakeholders like developers and testers.
And always remember - there are no hard and fast rules on how to use business analysis techniques; you can always tailor them to suit your needs.
Author: Dim Zakharov
Dim Zakharov is an expert in business analysis and has extensive experience in process improvements, service design, product management, business architecture and IT projects delivery. Dim has been working on business and digital transformation projects within complex government and commercial environments delivering integrated solutions end to end in various business domains.