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.

Benefits

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.