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.
A brief introduction to use cases
The Baker’s Dozen ‘rules’:
Rule 1: Use cases aren’t silver bullets
Rule 2: Understand your stakeholders
Rule 4: The "Famous Five" of requirements modelling
Rule 5: Focus on goals, not behaviour
Rule 6: If it’s not on the Context or Domain models, you can’t talk about it
Rule 7: Describe ALL the transactions
Rule 8: Don’t describe the user interface
Rule 9: Build yourself a data dictionary
Rule 10: The magical number seven (plus or minus two)
Rule 11: Don’t abuse <<include>>
Rule 12: Avoid variations on a theme
Rule 13: Say it with more than words
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
He specialises in C++, UML, software modelling, Systems Engineering and process development.
- Practice makes perfect, part 3 – Idiomatic kata - February 27, 2020
- Practice makes perfect, part 2– foundation kata - February 13, 2020
- Practice makes perfect, part 1 – Code kata - January 30, 2020
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.
Great tutorial - thanks !
Can you slip your web-admin an extra donut (scone?) and add a "printable" option for these articles ?
I have learned a lot from your tutorial.
A big plus for Rule 4.