This is part 4 of the Getting Requirements Right post series, and in this post we’re going to explore Use Cases and how to better use them.

A lot has been 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 a good value to a business customer. 

I would like to show you a way to get the most out of Use Cases and deliver the required capabilities to the business faster. The approach applies to many situations where there is a need for changes to business processes and supporting business applications. 

Where to start?

The User Stories discussed in the previous post  are a good starting point. The User Stories determine 

  • Roles (actors) and actors’ actions 
  • The data actors deal with
  • Pre-conditions
  • Post-conditions (acceptance criteria) 
  • At least the ”happy” (basic) path. 

Of course, the User Story is not a replacement for a Use Case as it lacks certain details required to produce a full Use Case Specification. 

Let’s imagine that the project kick-off meeting has taken place, User Stories have been captured and project scope is quite understood. 

The objectives of your project manager are simple: deliver on time and within project budget. Your task is to develop Use Cases, deliver them with good quality and within the agreed timeframe. 

To get your part of the work done, you can:

Use the completed User Stories to capture the existing business context (business processes and used software tools) Develop a Use Case Model outlining all Use Cases falling into the solution scope Develop each Use Case in greater detail.  Developing a use case model

To move forward quickly, use titles of the previously created User Stories to draw a Use Case summary. Focus on actors and what they want to do to achieve their objectives. 

Use the drafted Use Case summary as a communication tool for all meetings with the key stakeholders and SMEs. They will quickly point out 

  • What you missed out
  • Which stories you can combined
  • Where you made mistakes
  • What should be corrected and why
  • What the priorities are for the determined Uses Cases. 

Refine the Use Case summary as you receive feedback on Use Cases. Get approval for the Use Case Model to move forward with the rest of your assignment. 

Specifying a Use Case

Once you’ve completed the Use Case Model, you can move on to writing Use Case Specifications. At this point you should have a clear understanding of 

  • Relationships between the components of the solution
  • Order of Use Cases 
  • Dependencies of each Use Case
  • Scenarios within Use Cases
  • Applicable business rules
  • Expected inputs and outputs.

From this point your complex task becomes easier. Just follow the steps presented below to develop the Use Case Specification.

Happy path

To start with, define the “happy” path (it comes from the User Story). Then specify all alternative paths as well. Pay attention to data validation and capturing exceptions where validation checks fail. Think about data attributes (metadata) that are required to complete the scenarios. Decide what must be available for handling by the Actor and what the solution should handle during the process steps. 

User Interface

Some people say that the UI is not part of the requirements gathering. My experience shows that a rough sketch of user’s screens (user interface) helps quickly ensure that there are no loose ends. Think a bit about user experience and make sure that your layout does not require jumping all over the screen to complete an action.  

Ergonomics of Use

Try to put yourself in the user’s shoes for each screen to ensure that all the required data is visible. Check that buttons and other controls are easy to use. Make sure that then screen is not cluttered and enables to complete the required task with minimal number of clicks.

Things to keep in mind

Ask yourself whether you would feel comfortable using your creation on a daily basis. If you would not, rethink your design, re-use good part and throwaway bad once. Don’t be afraid to start from the blank sheet. Remember - every attempt increases UI simplicity and comfort of the use.

A new solution won’t exist in isolation. Do not forget about interfaces with other solutions - it is a common mistake! 

Reconcile the developed Use Cases with descriptions of the required business processes to verify the whole solution. 


Any business analysis task has to be organised to save your valuable time. Business analysis document templates are of great help here as they allow reuse of common parts of documentation and customising it as necessary. They also serve as a kind of a checklist of required documentation and ensure that you don’t miss anything.

In the next post, which will conclude this series, we’ll take a more in-depth look at requirements, their types and examples.