Why use use cases?

This article explores when use case modelling can be used, when it shouldn’t be used and the benefits.

When to apply use case modelling

Use case modelling was originally created to provide a business or user-friendly way of modelling requirements for system behaviour (see – an Introduction to Use Cases). It applies to systems which have a high degree of user interaction.

Although less common, it can be used where there is little or no user interaction as long as there is an external system actor which has a high degree of interaction with the system under study.

Another example where this is no user interaction would be an electronic payment system. However, it should be noted that I have used them successfully in this case where there is a high degree of interaction with other systems.

The use of scenarios within use cases and each scenario delivering a ‘goal of observable value‘ is the key to determining whether to apply use case modelling. If the problem domain under study allows you to define goals of observable value from the actor’s perspective whether the actor is a person or another system, use case modelling is a suitable approach.

A quick word of warning is that use case modelling is rarely a suitable technique to use in isolation. It should be used in conjunction with other techniques to improve the level of enagagement of your stakeholders and, hence, the quality of their requirements. For example, prototyping is a good approach to use in conjunction – this and other approaches are discussed further in Requirements gathering alongside use cases.


There are several benefits to use case modelling. The first is that use case models act as a central document in any project which are understandable by all interested parties.

The absence of technology specific references and the focus on the user’s perspective makes them ideal for the business stakeholders. They can be written in sufficient detail and clarity so that they form a perfect starting point for the developers, designers and architects.

They are also an ideal starting point for testers and, in fact, make their life much easier than other documentation forms.

One of the key benefits of use cases is that they can be used by project managers in conjunction with the business to plan iterations or project phases. It is very simple to identify where business value is delivered by use case or scenario within use case and, for example, to deliver the scenarios with highest value first.

As the use case model forms a central document, it can also be used in verifying the successful delivery of the project. Initially, the use cases can be traced from the functional requirements to ensure complete requirement coverage.

Secondly, the use cases can be traced into design artefacts to ensure that the design and build is correct.

Finally, the test scripts and conditions can be verified against the use cases to ensure the testing phase is providing complete coverage.

They can be used on ‘traditional’ projects but can also be used on Agile projects.

What else is there?

There are many other modelling techniques out there but I’m not aware of any which are both readable and usable by the business community but also sufficiently precise for use by technical stakeholders.


If you have any thoughts on benefits that I’ve overlooked or are aware of any other pitfalls in using use cases,  please add a comment.

About Alex Papworth

4 Responses to “Why use use cases?”

Read below or add a comment...

  1. Leslie:

    You are right on the money about Use Cases being useful to testers … in my own work and research, I’ve also found that it is commonly used and adopted by software developers … and it seems to foster clearer communication between software developers and business analysts

    Thanks for a good article

  2. Leslie says:

    This is a link to an article that I recently wrote on use cases.

    My question is, when you say ‘Use Case Model’, do you mean the complete set of diagrams and their underling components (use cases, actors, relationships, states, etc) that make up use case model, or by model do you mean a purely textual description of the the use case?

    Perhaps you mean either.

    The reason I ask is because I agree that use cases should be supported by other forms of modeling. Do you mean that textual use cases can be supported by activity diagrams and vice-versa, or are the supporting diagrams taking a completely different view of the use case model, such as class diagrams?

    I also agree with the prototyping support and encourage use case storyboards as a method of supporting prototyping. This is great for demonstrating the UI, but when you are modeling system to system interactions, you need something different, such as class diagrams.

  3. DougGtheBA says:

    Hey Alex:

    Nice write-up. I’d have to agree with everything, as well. I would like to make a slight clarification, as well. You stated, “It is not intended for systems where there is little or no user interaction.”

    While true, I should note that use cases can also be used to define system-to-system interaction, too. In fact, you alluded to that as a starting point for developers, and I’ll echo that sentiment. I often use simple system use cases to define very basic steps between systems. Use cases used in this context are a great jumping off point to dive into a sequence diagram, yet they’re simple to document and capture the thought process of systems should interact rapidly.

    I’d also like to back Mark S up on his hought about not using them in isolation. I DO think that they provide their best value when used in conjunction with another form of requirements diagramming, prototyping or documentation Use cases are meant to document behaviors, and not everything fits nicely into them and makes good sense. A complimentary technique like diagramming or prototyping brings out the best in both.

  4. Mark S. says:

    Entirely correct — “prototyping is a good approach to use in conjunction.” And not just traditional prototyping, where development is still investing some time in translating static requirements/models, but by using *visualization* to automate immediate dynamic prototypes at time of requirements elicitation

Leave A Comment...