Use Case Modelling

Use Case Modelling
By Kurt Bittner and Ian Spence

A classic, first published in 2003, and still worth reading. Even though 8 years seems like a long time in technology, for the basic processes it is still up to date. At the same time this is a difficult book to review.

On the one hand it is an excellent overview of the process requirement definition in organizations following a RUP-made-to-measure process*. The book covers the full requirement definition and documentation process, and describes it well. And I know more than one company that follows this method almost to the letter. So there is no way around it if you want to check whether you are up to speed, or need to prepare for a new assignment and want to make sure that you work according to a consistent process.

But on the other hand it is an utterly boring read, even if you are deeply into the topic. It is the kind of book that is put on the compulsory reading lists at schools and universities seemingly to test the stamina and resilience of the students. If you manage to read through the whole text and reproduce some of the highlights you pass the test. There are two reasons I see why it is hard to get through. On the one hand the writing style, and on the other the order in which the chapters are presented.

The authors use a technical prose usually reserved for scholarly papers where this  helps to publish across language barriers. But for this book regular use of verbs like “to elicit” and sentences like “Functional Requirements are those actions that a system must be able to perform, without taking physical constraints into consideration” or “Non-functional requirements are best described using declarative requirements”, just take out the fun of the subject matter.

Many non-native, non-technical readers will get lost very regularly in the text. And if your manager started out as a major in arts… well just land the message gently and verbally, and use the book to point out the pictures. The downside is of course that very few managers outside of the IT domain will be able to read this and enjoy it. Even if they go from cover from cover, it will be difficult to expect them to have assimilated the process after putting down the book. I could imagine a manager thinking “if this is what documentation is about, then spare me the effort and expense”**. And of course, we want the opposite response.

The book starts by explaining and fine tuning the definitions of Use Cases and Use Case Modeling. And this is a pity, because they miss the chance to follow the sequence of the actual process they describe, which would have improved the accessibility of the book. If I bring the synopsis of the book in the order in which we carry out the steps, it would read like this:

1. Establish the vision and engage the stakeholders
Make sure you have all the stakeholders included in the project, and then work your way through documenting their expectation in their own language first. The description of the way you can do this through workshops is detailed (almost down to the brown paper and markers) and accurate. And if you have not done this before, then this book really is a good place to start. The best way to be effective during  requirement gatherings is to bring a good selection of engaged stakeholders together  in a confined space.

2. Find Actors and Use cases and document them
Based on your records of stakeholder workshop and interviews, boil the requirements down to actors and use cases that can be reviewed by the same stakeholders _and_ offer a workable description of the system-to-be for the developers. This is the bridge between technology and business that needs to be established so that expectations are managed on both sides of the divide.

3. Repeat the above until the system is clear and the documents are agreed on by the project owners through a transparent reviewing process. And in practice this often means that we need to watch our language, lest it becomes too technical or too reliant on whatever department lingo the stakeholders have developed internally for someone not involved in the project to read.

Ordering the chapters along these lines would have made the entry level for the the book more general, and I would rather have a reference book to recommend for a new project leader that they might not finish, than one where they are unlikely to get past the first chapter.

My guess is that despite the ubiquitous nature of this process in organizations, there is still room for a definitive, truly accessible and well written book on requirement definition. There are too many misunderstandings and overrated expectations of the Rational method which are unnecessary. And very much the same goes for alternatives like Agile. A thorough revision and copy edit of this book might fill this gap. Until then this will continue to be a must-read, and a must-suffer-through for information analysts, IT managers and people interested in the wonderful process that is requirements gathering.

The strength of this book is that the authors take out some of the key aspects of the Rational method and advise you to perform them well and efficiently, without  holier-than-thou adherence to methodology.

Notes
*RUP is the Rational Unified Process for software development, which is almost ubiquitous in larger organizations.

**He or she arguably might have a point, as RUP is usually made to measure because of the risk of documentation overload (just google RUP vs Agile), but that is not subject of the book or this review.