This is the second part of the Requirements and Use Cases post, and continues right where I finished with that one. In the first part I laid down some basic thoughts about requirements as I see them, and this post builds on that. If you did not read it, please do that first.

2. Use Cases

Use cases are an interesting part of the UML. They predate the UML by years and for me they are a bit “sticking out”. The actual UML notation while can give a nice diagram does not really provide much information, most of that info is in the textual description of the Use Case – which is the actual hard part of the Use Case business.

People like the “potatos” nonetheless, they look easy, a stick-man here, a potato there, connect them with arrows, and we have a new requirement, lets go code. Yes, I did it too when I started to use them. Unfortunately, while the resulting diagrams would have made nice posters if I only put them in a frame, the practical value was zero. So here is a few common mistakes I met in the last few years.

1. the potatoes and stick men are the focus of the Use Case model, and the textual part is almost completely ignored – a really useful and thorough book is Alistair Cockburn‘s Writing Effective Use Cases.

2. the Use Case model is used as a process flow, with one potato for every step in the process, and <<precedes>> and <<invokes>> associations, or simple associate arrows guiding you through the whole flow. This is evident, how much info does a bubble with a one line description of a 25 step long process give?

Real life example. Sorry.

3. the Use Case model is used for the wrong requirements.
4. the Use Case model is used in the wrong phase of the project.

The 1) and 2) are evident, I would talk about the last two points, 3) and 4).

3. The Use Case model is used for the wrong requirements

So here we can tie the different requirement types with the Use Case model. If we look at either Wiegers’ or the BABOK requirement types, we can see that there are only a few kinds of requirements that can be modeled with Use Cases.
The first thing that is evident that Business Requirements cannot be modeled with Use Cases. Neither can Quality of Service Requirements, Assumptions and constraints and Implementation requirements be modeled with Use Cases – or, if you go with Wiegers’ grouping, no Business Rule, Quality Attribute, External Interface or Constraint can be modeled.
With a quick note that the existence of External Interfaces can be implied by Actors representing external systems.
The only requirements that can be modeled with Use Cases are the User requirements, and part of the Functional Requirements. A Use Case called “Recovering User Data within 2 seconds” is not exactly a Use Case.

4. the Use Case model is used in the wrong phase of the project.

As Business Requirements cannot be modeled with Use Cases, and Business Requirements are on the top of the chain – they are the very first requirements to discover – it is evident that the “start requirement gathering by drawing a Use Case model” approach is wrong.
And still, I have met it a few times – what is more worrying though is that it does not mean that Use Cases are used to model the Business Requirements. It simply means that Business Requirements are skipped.
As a result we don’t really know why we started the project apart from a hazy “we need a new system”, what is the exact goal to achieve, and how to measure if we are there.
What we will know is that there are a lot of functional requirements, an ever growing list, and we will finish the project if every single one of them is implemented.

It is not the fault of the Use Case, or the UML or such, but if the first requirement we see is a Use Case and it is called “Reserve Hotelroom” then we should suspect that maybe a few steps and requirements are already missing.