IT is not just about technology, in fact the bits I am most interested in are how technology is developed and used by people. And, despite being a relatively new kid on the block – compared to other industries and professions – I like to think that we have some interesting history and stories to tell. Here is one of those stories…how I first became aware of Use Cases.
Dateline 1989, Lytham-St.Annes, Lancashire, UK
First a little bit of ancient history, well circa. late 1980’s/early 90’s!
I started my IT career as a trainee analyst/programmer, mostly working on mainframe applications*, early third-generation languages and relational databases. More exotic client-server technology and GUIs (Graphical User Interfaces) were starting to become more common in commercial end-user IT systems.
(*Ed. you may need to ask your fathers about the IBM 360 and ‘green-on-black’ monitors).
As I was cutting my teeth in this environment I first came across a notation and technique to capture business and system requirements, Use Cases, introduced by Swedish Computer Scientist Ivar Jacobson in 1992. Many other thinkers and writers in this field have developed Use Cases further, and inclusion in a suite of modelling tools called the Unified Modelling Language (UML).
The creators of UML are known as the ‘Three amigos’, collectively one (several!) of my IT heroes.
Ever since I read about Use Cases I have used them extensively in my professional life and education, irrespective of the target technology in the solution domain – like a general purpose software engineering language, that’s both useful and understandable by the practitioner and the Customer.
Lost in Translation
In his early writings Jacobson had referred to usage cases and usage scenarios, but something was lost in translation – literally. The Swedish term anvandningsfall could not be translated satisfactorily into English, so we ended up with Use Cases, which still causes some confusion today. Ironically Use Cases (all modelling techniques) are designed to foster clear thinking and consensus.
Use (pronounced ‘Ewes’ or ‘Yoose’) Cases have two main elements:
(1) A simple way to represent graphically how someone or something interacts with the system that you are interested in. This technique is normally used to scope-out, decompose (split into smaller manageable chunks), and to understand requirements, typically for a new computer system or business process.
(2) A more structured template to capture the scenario in words, including, for example; the goals to be achieved; who benefits when the interaction has been successful; alternate and exceptional paths; business rules, and; low level steps or tasks. I will not go into more detail here, but have a look at usability.gov and agile modelling resources.
Simple Model Notation
The beauty of this notation is that it is very simple but can provide a flexible and powerful technique to tell stories, illustrate abstract ideas, and contain (without restraining) the potential complexity that can sometimes prevent forward momentum. Here briefly are the elements of the notation:
An actor is a human role or an external non-human system that interacts with the Use Case.
Normally a Use Case has a simple verb-noun name that describes what happens or the intended outcome. Ideally it provides a distinct, meaningful and self-contained unit of work, rather than a generic, composite or woolly set of tasks such as ‘manage’.
Use Cases can be defined at different levels of abstraction from very high level strategic or enterprise-wide business needs (cloud) to low-level system details (sea bed/clam shell) depending on their purpose and intended audience. These different levels were created by Alistair Cockburn.
A labelled box represents the boundary of the total system of interest, maybe a business or IT system or a project.
The lines that join actors to Use Cases – or Use Cases to other Use Cases – represent some meaningful interaction or association, not specific information or control flows. Other UML notations allow the detailed interactions to be modelled.
Here are some simple examples:
The Use Cases Browse Items and Purchase Items are not meant to imply a sequence of events, they are treated as separate Use Cases. However, it is also valid to draw an additional line to show that Purchase Items may conditionally extend Browse Items. But, what if the decision to purchase comes from some other activity or trigger, not browsing a catalogue, but a recommendation or a ‘bundled’ product, say? This example hints at the sort of thought process you may go through to create a Use Case model, but also the roots of Use Cases in the world of Object-orientation and design patterns – but that’s a conversation for another day!
By convention the primary actor is on the left with secondary/supporting Actor(s) on the right. OK, I’ve broken my own rule about using the word ‘Manage’, but it’s here as a deliberate high level container or context level view of all the separate transaction or functions that are part of a having and using a bank account.
These are very simple examples, but I hope you can see that with a little imagination and creativity – oops, more words that have no place in an IT blog(!) – one can start to understand and document stakeholder needs in an IT, software or change project.
(c) 2015-16 IT elementary school Ltd.