Use Cases – an Introduction

There are many ways of modeling requirements in IT development these days but one of the most popular approaches involves use cases.

Firstly, just to get the record straight, they are not called ‘user cases’ which is a mistake made by many an individual who comes across them for the first time. Also, they are pronounced use cases as in loose, not lose. I seem to recall that this is because they describe a user’s single ‘use’ of the system rather than how the user ‘uses’ the system.

I have been modelling requirements using use cases for over ten years and thought it would be helpful to provide some articles introducing use cases. As ever, this is my opinion, picked up through experience, reading books and discussions with colleagues so I’m more than happy to be challenged and would encourage any debate.

 

Brief History

Use cases were originally conceived by Ivaar Jacobson and represented a distillation of his experience as a software engineer during the seventies and eighties in the form of a software development method.

The book he wrote to introduce use cases to the world even though it was written in the dim and distant past (i.e. 1992 – even I had only just graduated then!)

(Object-oriented Software Engineering: A Use CASE Approach (ACM Press))

Use cases have been widely adopted since then, having formed a central plank of the Rational Unified Process and used independently in many IT projects today. They are technology independent so there are no constraints to how they can be used.

They have evolved somewhat since then in their application and sophistication but I shall start by focussing on a very pure and simple use as was originally conceived by Ivaar Jacobson.

 

Basics

The original purpose of use cases was to express user requirements in a technology-independent form using a structured narrative form that both the non-IT literate user and the business analyst can understand. They also provided a simple but powerful structure that provides valuable information about the users of the system and how they use the system.

Up until that point, user requirements tended to be either extensive, rambling free-form documents which were unwieldy and painful to review and agree. Alternatively, they might have been avoided altogether by having a high level statement of the functionality of the system from which the system was produced and it was only when the final system was produced that the user found out whether it was anything like what they wanted – the ability to mind read was crucial for the IT professional involved in this sort of project.

There were also a number of diagramming techniques available which provided means of describing the system behaviour but they all tended to somewhat daunting for the non-IT literate user (e.g. data flow diagram, flow charts).

The typical use case model is composed of the following elements (as a minimum):

i)  the use case diagram which provides you with a high level view of the system behaviour and how the users interact (see

ii)  the use case narratives provides you a step by step description of how the user (or actor) interacts with the system

iii)  the actors. The term actor describes the role of a user and, as such, describes a category of users who ‘use’ the system in the same way

 

 

Example use case diagram

Example use case diagram

 

 

The box which is commonly referred to as the system boundary shows the dividing line between the system (inside the box) and the users of the system or actors (outside the box).

Each actor represents a category of users who use the system in the same way. Each oval with a name is a use case and will have a corresponding use case narrative which details the steps in the interaction between the actor and the system of which that use case is composed.

The use case narratives will describe the interaction between the actor and the system in a slightly stylised way and should NOT make any assumptions about how the system will be designed. They should be written from the user’s perspective, describing how they would expect to interact with the system (see Use Cases – the use case narrative for more detail)

 

For example, here is a subsection from a typical use case.

 

Simple use case narrative

Simple use case narrative

 

The first thing you will notice is the repetitive style which describes the actor’s actions and the system’s responses. It is also usual to develop a house style where the same language or phrasing is used which makes for improved readability. Typically, the user should always be referred to as the actor as this is consistent with the use case method.

Secondly, note that there are no technical details describing how the system goes about its tasks and, in particular, there is no mention of any other systems (for example, there will probably be some system responsible for security). The use case should NOT attempt to describe how the system works and should describe only the business logic and rules that are required.

In this article, I am assuming that use cases are being used to describe the behaviour of a system from a system-agnostic point of view which means that we have no preconceptions about how the IT system will work and, more importantly, we do not care – getting side tracked by such issues, especially when discussing use cases with the business users will only confuse the process of understanding the requirements.

However, use cases can be used in other circumstances where the systems are important:

  • the requirements dictate the use of one or more systems which will satisfy a specific purpose (e.g. pre-existing component is responsible for, in the example above,  validating the PIN
     
  • the use cases are being used to design the internals of the system behaviour. This approach will not be covered in these articles 

Use cases are not suited for describing the requirements for all types of IT systems.  In order to be of value there must be a high degree of user interaction. If this is not the case, other approaches should be adopted. Interestingly, an IT solution in its entirety may be suited to use case modeling but, in a system of reasonable complexity, there will be elements of it which are not suited to use case modeling. If this is the case, there is no reason why use case modeling can’t be mixed with other approaches. As always, the measure of success should be:

If  you can’t justify what you’re doing as making a valuable contribution to the ‘business to IT or IT to business’ communication then you need to seriously consider what value it is providing. (see What is business analysis?)

Also, use cases should be goal-oriented and should not necessarily describe a system feature. Each use case should be created in support of an actor performing a task of observable value. If the use case doesn’t deliver some value to the actor then it is probably incomplete. It is very important to remember this.

For more on what comes before you start use case modeling, see Use Cases – what comes before?

 

Useful Links

Here are some other definitions of use cases on the web:

Wikipedia

Useful documents – tend to go into more detail than this introductory article

Wikipedia entry on use cases

Wikipedia entry on use case diagram

More detailed introduction to use cases

 

Related Books
Writing Effective Use Cases (Crystal Series for Software Development) this is written by Alastair Cockburn who is a well regarded pracitioner, particularly with use case modelling

 
Applying Use Cases: A Practical Guide (Object Technology Series) this is a compact guide that introduces use cases in a straightforward, simple manner – ideal for the absolute beginner

Thank you for reading this article, please make comments if you have questions, disagree or wish to discuss further.

 

Share this article with your colleagues –

It's only fair to share...
Share on Facebook1Digg thisBuffer this pageShare on LinkedIn0Share on Google+0Share on VKTweet about this on TwitterShare on Tumblr0Pin on Pinterest0Share on Yummly0Flattr the authorShare on Reddit0Print this pageShare on StumbleUpon0Email this to someone

About Alex Papworth

17 Responses to “Use Cases – an Introduction”

Read below or add a comment...

  1. carmelbay says:

    I’m not seeing the examples and I logged into WordPress.com. What do I need to do?

    • Alex P says:

      Hi carmelbay

      I don’t understand your question – can you explain please?

      Alex

    • Alex P says:

      Now I understand! There were some technical problems and my images weren’t being displayed on this article.
      It should be working now, let me know if there are any more problems.

  2. Leslie says:

    Quote from the article – “The use case narratives will describe the interaction between the actor and the system in a slightly stylised way and should NOT make any assumptions about how the system will be designed. They should be written from the user’s perspective, describing how they would expect to interact with the system (see Use Cases – the use case narrative for more detail)”

    Quote from example use case –
    “The system reads the card and determines the account holder”
    ..
    “The systems checks the PIN ..”

    I would argue that neither of those steps are written from the user’s perspective, nor are they design independent.

    – how does the user know that the system is reading their card?
    – why is the system reading the card at that step .. why not after the user has entered their PIN?

    Step #2 is redundant .. the use case works if you remove it.

    The I would handle step 5, is with an exception flow. Step 5 can be removed and step 6 starts, ‘If the correct PIN for the account holder was entered ..’

    The exception flow reads ‘If an incorrect PIN for the account holder was entered ..’.

    When you say ‘In order to be of value there must be a high degree of user interaction.’ I would change this to say a high degree of actor interaction.

    HTH,

    Leslie.

    • Alex P says:

      Leslie

      thanks for the considered responses – I recognise the business analyst mindset at work here 😉

      When I said

      written from the user’s perspective

      I meant that they should be written in a simple manner which doesn’t require any technical understanding. However, the system needs to be mentioned in order to understand what response the system provides and any business rules or policy that needs to be defined.

      With regard to your point on design not being mentioned, I take your point, although I think it is a purist point of view. This is an examlpe with no context provided so there may be reasons why some of these elements are here.
      For example, it may be assumed as a constraint that the ATM has a mechanism that allows the card to be read.

      In terms of what the system does when, you may well be right in terms of the order things are done.
      Please bear in mind, however, that this is an example only.

      I plan to do a case study at some point – this will be well considered in terms of the use case content and so forth. I would value your feedback when this is being produced.

      I like your preferred style for dealing with alternate flows. It’s different to the way that I tend to write but that’s why it’s good to develop a house style and be consistent. My view is that consistency is the priority – it can be very offputting reading use cases written by different people in different styles. It doesn’t come across as very professional.

      Thanks for your input – I valued well reasoned, constructive criticicism of this nature (even if it shows up my flaws!).

Trackbacks

  1. […] cases (I wrote about these here – they are both visual and textual. You can listen to a recording of Be a Better BA webinar on […]

  2. […] use case modeling and should be used to ensure your requirements gathering goes swimmingly (see Use Cases – an Introduction for more on use case […]

  3. […] 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 […]

  4. […] case model (see Use Cases – an Introduction) Well etablished approach using a mixture of diagrams and narrative descriptions […]

  5. […] 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 […]

  6. […] use case modeling is more art than science (like much of the tricky bits of business analysis, see Use cases – an Introduction for the basics). There are many different viewpoints on what makes a good use case. Some of those […]

  7. […] entities, their relationships and attributes but does not show how these change over time (see Use Cases – an Introduction for an example of a technique for a ‘dynamic’ or functional view of a […]

  8. […] use case modelling and should be used to ensure your requirements gathering goes swimmingly (see Use Cases – an Introduction for more on use case […]

  9. […] This is our first draft list of the ‘goals of observable value’ (see more on this in Use Cases – an Introduction) that will form the functional scope of our system. In fact, it is often found that the business […]

  10. […] case model (see Use Cases – an Introduction) Well etablished approach using a mixture of diagrams and narrative descriptions […]

  11. […] Use Cases – an Introduction, it was explained how the use case, in essence, describes the interaction between an actor (or […]



Leave A Comment...

*