I’ve spent an awful lot of time over the last few years identifying and writing use cases.   Often, I am asked a few common questions by people associated with the project – what is a use case, how do you write them, how do you identify use cases, what’s the point of them?  This posting will answer two of those questions – what use cases are and how to identify them.

Systems That Do Something

Businesses exist in order to do something.  Whether they are service companies or manufacturing – even storage companies – they all do something.  If they are already doing it successfully, then there is probably little need for use cases.

Projects, on the other hand, happen when the business wants to do something different.  Either a piece of the business or the whole business – either changing what is already done or creating something new.  Often, on projects involving UML the project is to produce a software application, but it may also be based around changing business processes or a mix of both.

We talk of systems.  A system, in this context is the focus of the project.  It can be described in terms of what it is and what it does.  It may be a department in a business, or a piece of software.  Projects are usually intended to create a new system or change an old one.

The approach adopted implicitly on most projects is to produce a formal description of the new system – and often, to describe the old system in order to identify the differences between the two and the impact and benefits of the changes.

Usually, the project begins by gathering requirements from various stakeholders (people who have a relevant interest in the old or new systems).  A key task for the business analyst is to collect and refine the requirements and agree with the business that they represent exactly what they want of the new or modified system.  The requirements may be well structured lists of prioritised and attributed statements, or a collection of emails, scraps of paper, references to legislation or a demand to “Make It Better!”

Whatever you have, at this point we have a description of the system in terms of what the business require it to do, with what and how.  We need to turn this into a description of the new system.

There are many ways to do this including user stories, functional specifications, Yourdon, etc.  For this article, we are going to use UML – and in particular Use Cases.

Modelling System Behaviour with Use Cases

UML gives us a way to describe systems pictorially in terms of what they do and what they are – behaviour and structure. 

Use Cases are the Doing part – they describe the behaviours of a system.  To a business, the behaviour is only relevant if it interacts with the outside world in some way – and UML gives us Actors to represent the parts of the outside world (people or other systems) that interact with our system.  The UML forms are shown in the diagram below – an Actor interacting with a Use Case that sits within the System Boundary.

We need to define all of the behaviours of our system – all the things it can do.  We also need to define all of the Actors that interact with  the system.  What we have is the requirements.

The easy way to do this is to read through the requirements finding every time they mention the system doing something.  Each time, try to write a simple sentence in the form “Subject-Verb-Object” where each of the three is either a single word or a phrase.  You may need to swat up on your school grammar, here.  Ideally, form the verb phrases with “Can” – because you are simply identifying the things the system “can” do.  We are not worried yet about “must” or “could”, “when” or “if”.

Below is an example of some S-V-O sentences you might create when reading the requirements for blogging software (such as WordPress):

1. A blog author can create a posting.
2. A blog author can modify a posting.
3. A blog administrator can approve or reject a posting.
4. Anyone can read a posting.
5. Anyone can comment on a posting
6. A blog administrator can approve or reject a comment on a posting.
7. The Blog can reject Spam comments identified by Akismet.

Now that shouldn’t be too hard.  So, in the first sentence the Subject is “a blog author”, the Verb Phrase is “can create” and the Object is “a posting”.  Turn this into a Use Case Diagram like the one below – you can draw it on paper, in a drawing tool such as Visio or, ideally, use a proper UML Modelling tool: –

The others follow the same pattern, except the last one. 

The last sentence appears to have the system (the blog) itself as an actor.  Instead, we have the system interacting with Akismet (an online service for blogs) to test for SPAM comments on blog postings.  Akismet is another “system”, but one that is external to the project – so we represent it as another Actor.  Thus the Use Case Diagram becomes: –

The diagram above represents a Model of the behaviour of the system. 

Before we move on, it may be worth reviewing the requirements again to try to find any more use cases or actors that we may have missed – and add them to our diagram (and thus to the model).  One way to do this is to allocate each requirement to at least one use case (e.g. stick ‘em in a spreadsheet and add a ‘Use Case’ column).  If there are any you can’t allocate to a use case you may need another one.

A use case may interact with more than one actor – or none at all.  An actor may interact with more than one use case – as in the diagram above.  The project scope may encompass more than one System Boundary – perhaps you are modelling the processes of two different teams or two separate computer systems.

Use Case diagrams can get quite large and cluttered.  It is therefore useful to break them up into separate, smaller diagrams.  This will be significantly easier if you are using a UML modelling tool as it is easy to create new diagrams and add the use cases and actors to them.  You can also collect actors and use cases into different groups – perhaps representing different functional or system groupings.

Finally,

So that’s how you identify the use cases – the next task is to refine the model and define any relationships between them.

But not in this posting…