Use cases have become a core part of the requirements analyst’s arsenal. Used well they can bring dramatic increases in customer satisfaction and a whole host of other subtle benefits to software development.
The use case itself is very simple in concept: describe the functionality of the system in terms of interactions between the system and its external interactors. The focus of the use case is system usage, from an external perspective.
Despite this apparent simplicity, requirements analysts frequently struggle to write coherent, consistent use cases that can be used to facilitate development. Often, the use case analysis becomes an exercise in confusion, incomprehension and the dreaded ‘analysis paralysis’.
This article aims to aid use case writers by presenting a set of rules to follow when performing use case analysis. The rules are designed to avoid common pitfalls in the analysis process and lead to a much more coherent set of requirements.
The Baker’s Dozen ‘rules’:
These 13 guidelines are by no means exhaustive (for example, what about ‘Abstract’ actors; or System Integrity use cases?) and I’m sure there are dozens more I could add to the list (by all means, let me know your golden rules) The aim of writing this article was to give beginners to use case modelling a simple framework for creating useful, effective use cases – something I think is sorely missing.
The Baker’s Dozen can be (neatly) summed up by the following principles:
- Understand the difference between analysis and design.
- Understand the value of a model – know why to create the model, not just how.
- Understand the difference between precision and detail.
- Keep it simple; but never simplistic
Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.
He specialises in C++, UML, software modelling, Systems Engineering and process development.