There are many ways of modelling requirements in IT development these days but one of the most popular approaches involves use cases.
Most business analysts in their journey have had to either learn use cases or use the technique on their projects.
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 of Use Cases
What are use cases? 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 (RUP) 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.
Use Case 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):
- The use case diagram which provides you with a high level view of the system behaviour and how the users interact (see
- The use case narratives
provides you a step by step description of how the user (or actor) interacts with the system - 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
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.
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 modelling but, in a system of reasonable complexity, there will be elements of it which are not suited to use case modelling. If this is the case, there is no reason why use case modelling 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 modelling, see Use Cases – what comes before?
Useful Links
Some readers may be interested in a recommended use case training course.
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
