There is a lot written about use cases and their application in business analysis. A good understanding of the business context is required to develop use cases which will deliver good value to a business customer.

This article discusses an approach to get the most of use cases and deliver the necessary solution to the business. The approach is applicable to many situations where changes to business processes and supporting business applications are made.

Where to start?

Let’s consider that the project kick-off meeting has taken place, project scope is roughly understood, and the stakeholders are mainly identified. The objectives of your project manager are delivery time and project budget. Your task is to develop use cases, quickly and with good quality to satisfy those objectives.

To get your part of the work done, you need to understand the existing business context (business processes and available software components), then develop a Use Case Model outlining all use cases in the project scope (see diagram below), and finally develop each use case in greater detail. What is the best way to tackle this task?

Firstly, understand high level business requirements (business needs) and where they come from. They define project scope and solution scope. After that you will know the initial solution boundaries. Secondly, determine functional areas within the solution. These areas will be used to group use cases and business requirements down the track. It is useful to do this for your communication with stakeholders at different levels. Finally, use the understanding of the functional areas to allocate use cases to each functional area.


What are the benefits?

Why should you do it this way? Because you end up with:

  • a holistic picture of the solution to be produced,
  • defined areas of the specific functionality required,
  • known links between the functional areas,
  • identified dependencies between use cases,
  • visible points of connection to external entities,
  • a good foundation for requirements prioritisation.

If you map this view to stakeholders and business processes they are involved in, you will have one extra benefit - the full map of changes (business processes, software and new skills) to be implemented!

Developing a use case model

To move forward quickly, use the previously created diagram as a communication tool for all meetings with the key stakeholders and SMEs. They will quickly point out where mistakes are made, what should be corrected and why, and what the priorities for the determined uses cases are.

As a rule, you can get this job done in two iterations. To make it happen, study any external requirements (aka market rules) carefully to get a clear view of the real requirements that must be satisfied. Guide your stakeholders through these requirements and listen to their interpretations. See how these external requirements transform into internal business rules. Know the existing information environment of the company well.

Refine the diagram as you receive feedback and then get approval for the Use Case Model to move forward with the remainder of your assignment.

Specifying use cases

Once you have the use case model, you can move on to writing use case specifications. At this point you have a clear understanding of how all the components of the solution are interconnected, you know the order of use cases and their linkages, you know what inputs and outputs are expected and where, and which business rules are applied where it is required.

From this point your complex task becomes easier. Just follow the structure presented in the following diagram to develop a use case specification:


Mock up the user interface to ensure that the required data is visible and controls are positioned on the screen with ergonomics and positive user experience in mind. Try to put yourself in the user’s place for each screen. Would you feel comfortable using your creation on a daily basis? If you wouldn’t, rethink your design.

Do not forget about interfaces – it is a common mistake as we are usually focused on describing how a user interacts with the solution but not how the solution interacts with its environment.

Moving into development

This part will be pretty straightforward if you’ve developed use cases using the structure in this article. You have everything you need to support software developers in creating/improving and eventually testing a software application. You have everything to support your project manager in the implementation of changes to business processes within project scope.

You can facilitate communication for uplifting the skills of the staff involved in the modified business processes. Finally, you can facilitate communication of the changes to peripheral users of the solution who do not execute the tasks described in the use cases. Awareness of new features and changes to the business processes should be distributed across the organisation you work for. This is good practice of organisational change.

Flow-on benefits

Firstly, as this approach allows you to work efficiently, you’ll be able to work successfully under pressure and will be considered a BA with solid skills.

Secondly, you’ll develop useful skills – systems thinking, the ability to see a holistic picture, the ability to break down a large scope into manageable pieces. It takes a while to develop these abilities but believe me they are the most valuable skills in a BA’s skillset.

Thirdly, you’ll earn respect from stakeholders and SMEs because you will not waste their time and you’ll be well prepared for all meetings.

Finally, you’ll have quality documentation and it will serve as a good foundation for any other project touching the delivered solution or its components.