Since Jacobson defined use cases back in 1992 they have been subject to a vast range of interpretations. Alistair Cockburn, author of Writing Effective Use Cases states:
“I have personally encountered over 18 different definitions of use case, given by different, each expert, teachers and consultants”
I am no different: this is my personal interpretation of use case modelling and analysis. To qualify this statement though, this methodology is based on nearly a decade of requirements definition work on a number high integrity projects, including military and aerospace. That said, techniques that work in one environment may be less effective in another. I haven’t been fortunate enough to work in every industry sector. It may be, then, that you disagree with some of my techniques. This is fine; I won’t think of you as a bad person.
In a series of articles I will present a set of guidelines, or rules-of-thumb. Each of the ‘rules’ defines a good practice that I recommend when creating use cases. Each rule forms a quality control on the requirements analysis process. Ignoring a rule means there is an(other) opportunity for mistakes to creep into your requirements.
There’s no way I could capture every possible method or practice needed to create, analyse, review and maintain your use cases (well, short of writing a book on the subject). I have decided to focus on a manageable number. Ten would have been ideal; but that was too few and left out some important points. Twelve still fell short, so I decided on a “baker’s dozen” – 13 rules.
To start, though, let’s have a quick review of Use Cases.
A brief overview of use cases
Use cases are a requirements analysis technique based on the conceit that (software) systems exist to fulfil the needs and desires of their stakeholders. Stakeholders don’t use systems for the sake of it – they want to achieve something with the system that is of worth to them. That is, the system must do something useful for the stakeholder, and in a fashion they expect or desire.
A use case is partial definition of a system’s behaviour, described in terms of a goal that a stakeholder of the system (called an ‘Actor’) wants to achieve, and how they achieve it. A use case is described in terms of the interaction between the Actor and the system; specifically, it is defined in terms of the information that is exchanged between the actor and the system.
Fig 1.1 – The Basic Use Case Diagram
It is useful to think of a use case in terms of scenarios. A scenario is a particular instance of interactions. A scenario describes one possible way of interacting with the system (whilst trying to achieve that particular goal). When trying to achieve their goal, the Actor may have to make choices. Also, things have a habit of going wrong. Each variation is a different scenario. The use case, therefore, is described by every possible scenario. Obviously, attempting to document a use case by writing every scenario would be ludicrous for anything but the most trivial system. The way round this is via a Use Case Description.
A Use Case Description is a structured English definition of all the use case steps. It can be thought of as a’ blueprint’ for generating use case scenarios. It should be possible to re-create any scenario from the use case specification. In its basic form, a use case description is a series of steps showing how information is exchanged between the Actor(s) and the system until the Actor’s goal is met. This flow is always initiated by an Actor (we don’t really want software doing stuff of its own accord!) This basic form is called the Basic flow, or Main Success Scenario. In the Basic flow nothing goes wrong and the Actor does the most normal, obvious things (this is sometimes called the “Sunny Day” scenario!)
However, when the Actor must make a choice, the use case description must fork – one path for each option the Actor can make. Each of these descriptions is described in an Optional flow (sometimes called a Sub flow).
Similarly, not everything always goes right. If something can go wrong in a scenario, chances are it will at some point (probably when the Actor least expects or wants it to!). Typically, these conditions are not resolved by giving the Actor an option; they happen beyond the Actor’s control. We have to record what happens when that ‘something’ goes wrong. These descriptions are called the Exceptional flows.
Another very useful way of looking at a use case specification is in terms of its start and end conditions. We can record all the possible start conditions that the system could be in; similarly, we can identify what state we expect the world to be in after we’ve finished. The use case steps, then, map the initial conditions to the appropriate final conditions.
Finally, we throw in constraints. A constraint is a requirement on not what the system does, but how it does it. A constraint may define a performance requirement, a reliability requirement, a safety requirement, etc. Each step in the use case specification can have one or more constraints applied to it. It is difficult to document how the constraint manifests itself in the use case but it is easier to document what happens when a constraint is not met. In this case the failure is treated as an exceptional condition.