Use Cases - The New School

24557 Views
5 Comments
51 Likes

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.

Like this article:
  51 members liked this article
24557 Views
5 Comments
51 Likes

COMMENTS

Dan Tasker posted on Monday, April 20, 2020 4:58 PM
Dim - I applaud your encouraging BAs to aid in stakeholder understanding of use cases with visual models. As it happens, the article I just published does the same thing, but with slight variations on the technique. First I suggest a model at the 'flow' level, using separate colors to represent the main flow (green), alternate flows (yellow) and exception flows (red). I would also recommend separating steps into swim lanes rather than combining them (rather than using colors to represent the two different participants). See my examples in: https://www.modernanalyst.com/Resources/Articles/tabid/115/ID/5580/Detailed-Requirements-for-Fully-Automating-a-Business-Activity.aspx.
taskerdan@hotmail.com
Eniola Ogunsola posted on Monday, April 20, 2020 7:35 PM
This article is definitely the future. As more development moves agile and the focus is going to market with the MVP, the visual representation will save a lot of time and effort.
Thanks for sharing this.
eniolam@hotmail.com
Hemant B posted on Wednesday, April 22, 2020 7:56 PM
Hello Dim
This is a nice article for beginners to understand the early stages of BA, is it possible for you to create BPMN 2.0 using same requirement and educate its outcome / pros/cons .
thanks
Hemant
hbraju@gmail.com
Fabian Meier posted on Friday, May 15, 2020 4:57 AM
In my experience use cases are very powerful tools - their purpose is show the view from a *user's point of view*. The presented example is already very technical, and specifies a lot of details.

May I offer alternatives to the example in the article?

A) A few brief classic requirements (for business) & a diagram (BPMN or UML activity diagram) (for the engineers)

B) A use case with a lot less details (maybe 4-8 steps) & user interface design & a list of business rules (describing the essence of the details)

C) No use case. One single sentence describing the goal & rationale ("As a user I want to have a recovery method when I forget the password because ....") & brief description of the important parts, business rules (no flow details!) & user interface design.

In my daily work I'm using mainly C) (I'm in a very Agile Scrum Development team) - the developers will implement the details without needing all the details, they are mainly interested how the interaction with the user should be.
A) is very good when I look at the big picture - one or several use cases describe a larger functionality. I'll keep the use cases simple (readable!).

May I offer other improvements to the "classic" use case in the example?
- Instead of a summary, formulate it as a goal (remove redundancy)
- Adding how frequently this is done ("Frequency: seldom, max. once per month ... once every few years")
- Keep the main flow under 10 points
- Remove pre-conditions and post-conditions. Keep it simple.
- Integrate the alternative flows into the main flow (if possible, leave away details)
fabian_RE
MrBeen posted on Wednesday, May 15, 2024 9:40 AM
I often use both. So the user story sits on top of the diagram.
And then the acceptance criteria also refer to specific activities on the diagram. So for example AC for step 17 could specify the rules that a new password should adhere to.
In my view you don't have to pick it's a toolkit of techniques that you can pick from.
I often also start with a Use Case Diagram and then write user stories for each Use Case.
I did abandon the old style notation after 10 years of using it as the diagram notation is much clearer.
prashadlodhia
Only registered users may post comments.

 



 




Copyright 2006-2024 by Modern Analyst Media LLC