Rule 13: Say it with more than words
Use case descriptions are most commonly written in text format (albeit often a stylised, semi-formal style of writing). Text is a very effective method of describing the transactional behaviour of use cases – it’s readily understandable without special training; most engineers can produce it (although the ability to write basic prose does seem beyond the capability of many!); and it is flexible enough to deal with complex behaviours – for example, variable numbers of iterations through a loop – without becoming cumbersome.
Use the most appropriate notation for the behaviour you are describing
However, this flexibility can come at the price of precision. Sometimes, for example in many control systems, you have to state precisely what the response of the system will be. Words, in this case, are not adequate (that said, I have seen requirements engineers attempt to describe the overshoot behaviour of a closed loop control system in English prose!)
This rule therefore should be: find the most appropriate notation to describe the transactions between the actors and the system; with a corollary that sometimes the right notation is multiple notations. Use tables, charts, diagrams, activity diagrams, flowcharts, mathematical models, state charts, or combinations of these, to describe the behaviour. Don’t get caught up in the dogma of use cases that says the use case description must be text. For most systems I have found that combinations of methods work best – some transactions are best described using semi-formal text; some by state machines; others by tables. The skill is recognising the type of transactions you are describing and picking the appropriate method.
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.
Dear Glennan C:
You are expanding the scope of a Use Case Description and including Activity Diagrams, statemachines etc.
If your restrict the scope to "System Options" and "Actor Selections" and exchange of related data. There will be a lot more clarity and precision of what should be exchanged between the System and Actor to reach the Goal of each Use Case. The internal processing within the system can be worked out later.
You may ask for and review proposed definitions of Use Case and Use Case Description.
putchavn@yahoo.com