Aren’t use cases only useful for systems with graphical user interfaces?
Certainly not because the original idea came from telecom switching systems, which have both human and machine users. Whilst the “story-telling” nature of use cases does lend itself particularly well to systems that do have distinctive user interfaces, it is important to remember that use cases are still describing a dialogue between the actor and the system. The use of alternative flows still applies regardless of the nature of the software and would still help to simplify the basic flow too. Besides, we would never recommend trying to write every software requirement with use cases: If it’s easier and clearer to write declarative statements, use Supporting Information instead. At the end of the day, accuracy and clarity are still more important than the names we call the documents.
Surely a picture is worth a thousand words – why aren’t diagrams part of use cases?
In fact it is very common to include diagrams and other models with use cases, although not usually in the use-case narrative. Many analysts use story-boards or UI prototypes, activity diagrams, domain models and so on. We would recommend spending most of your effort detailing use-case narratives and test cases and if you feel you need extra help, choose any additional means you feel would help the situation. Alternatively, why not try running a parallel activity more focused on the user interface? That way, the two approaches could be used to test assumptions in both techniques. The key thing is to establish a shared understanding of the requirements with the stakeholders.
How many use cases does the average system have?
This is very hard to answer because use cases can vary in size so much. However, to give you a very rough idea, a small application might have 5 and a reasonably large application might have 15 or 20. However, this is a very rough guide. Suffice it to say, there are almost never dozens of use cases – if you find you have loads of use cases, you’re probably falling into the functional decomposition trap!
How many pages would you expect the average use case to have?
As above, not easy to answer accurately. However, it would be unusual to see fewer than 5 pages or more than 30 pages. It is also very important to realize that every use case in the same project will not necessarily be the same size; some could be very short while others are described over many, many pages. Don’t attempt to make them all the same size, there is no reason or benefit in doing so.
What sort of level of detail is normal for a use-case narrative?
This is a good question! It all comes down to risk, i.e. passing on sufficient detail and receiving adequate feedback to make sure the correct solution is developed. It would be perfectly acceptable to stop at a bulleted outline of a use case if all concerned were perfectly happy that they understood all they needed to know. For instance, the team might decide that it would be faster to put together a working prototype than to waste any more time defining something that they were confident they understood anyway. Alternatively, if the requirements have legal, statutory or safety implications, a team may prefer to provide all possible detail before continuing with realization of their use cases.
I seem to have lots of alternative flows and not much in my basic flow – is that normal?
This would not be at all unusual. We have seen many use cases where the basic flow fits onto one page but the alternative flows extend for another 20 pages. In fact, a well structured use case will often have a very short basic flow with only the barest of detail in it. The acid test is whether the basic flow alone would deliver something of value to the users if you ignored all the alternative flows. The aim is to have a crystal-clear basic flow and well organized alternative flows.
Does it take long to learn how to write good use cases?
It doesn’t take long to understand how to write use cases but your skill as an author will determine how good your use cases are. We would recommend that you first read one of the books recommended for each alpha in this practice, then just dive in and try for yourself. Once you’ve gained a little experience writing a few use cases, either attend a recommended training course or hire a mentor for a few days. We prefer this approach because it maximizes the learning experience you get from the training or mentor since you will know what questions you need answers to.
It also depends on what you do with your use cases when you’ve written them. If they are being used in an iterative project life cycle, the feedback you get after each iteration assessment should immediately help you to improve your skill. However, in principle, you should be able to start writing use cases as soon as you understand their structure and purpose.
I’ve never used the UML before. Will I still be able to start writing use cases?
This is something a lot of people worry about. Only a low level of UML knowledge is required for use case modelling and use-case diagrams are easy to create. In their simplest form, a diagram consists of stick-men (representing actors), ellipses (representing use cases) and lines with arrows (representing relationships). Note that visual modelling comprises less than 10% of the total effort of writing use cases, the rest being devoted to the creation of use-case narratives.
Can I still write use cases if we are not following an Agile methodology?
Yes you can and you should. In our opinion, use cases offer a clearer and more intuitive way of documenting requirements than any other. So, regardless of how these requirements are to be developed (or even which programming language you use), this approach will help. And whilst use cases and agile methodologies work extremely well together, there are no constraints on how use cases can be applied to other development life cycles.