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!
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.ConclusionBasically, 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. Credit Dim Zakharov/Samuel Olanrewaju