Today we had a discussion on the format of Use Cases. The format for a use case can vary from segmented IEEE type documents, through, UML Use Case diagrams, to simple stories. Over recent years most Agile projects have moved towards the latter as many of these use Methodologies that are predicated around the concept of the story (XP, FDD, Scrum etc.),
The aim of a Use Case is to capture a functionality from a description of how a user would use a system. A part of requirement elicitation involves asking users what they want a system to do, by describing the tasks they perform, this is often achieved by doing a theoretical walk through of their interaction with the system: proposed or existing.
These types of Use Case are analogous to scenarios and in most part their usefulness depends on the descriptive skills of the requirements engineer as well as those of the end user.
Most end users would not understand a formal SRS, many software specialists are uncomfortable with no formal documents or less formal documentation. But fear not the use case is there to bridge this gap. I find that most requirements I write these days will contain a number of types of functional description, these would typically include, but not be limited to,
- a technical use case,
- a narrative use case,
- a list of features and descriptions of those features,
- domain models; a domain class UML
- flow type diagrams; in my case rendered in the UML as activity diagrams
- message flow diagrams; again in the UML as sequence diagrams
- state diagrams where appropriate (i.e. when states do change)
- relationship diagrams, either in the UML as class associations or drawn using ERD notation.
I am aware that once the code starts to be written and the tests begin to be devised, much that was in the specification documentation becomes redundant, and rightly so. However a good Use Case can be revisited or better still a Use Case can be rewritten by revisiting the user and listening to their story again now that some functionality exists. This will serve to confirm that the newly built features do indeed perform those tasks we discovered as useful rather than meet just initial expectations abstracted from the software.
I am wary of the pedant who writes everything in a series of spreadsheet tables describing what a system WILL do. It may be ok to describe what a light switch does in this way or even specify a lighting scheme but in good software the room for equivocation can not be expressed so dryly and some specification by example is needed to reveal those aspects that are lost in noting the particular in general as opposed to finding the general in particular. As Martin Fowler said ‘Specifications are supposed to be general, to cover all cases. Examples only highlight a few points, you have to infer the generalizations yourself.’ (http://buff.ly/1wRYHjn).
I am very wary when the pedant is able to write the specification in the spreadsheet after talking to the management who are buying the system and not to the users who will be using it, or worse still when the pedant is the person selling the system; the desire to tick all the boxes is often a mask for providing what is available as opposed to looking for what is needed.
Use Case: When it gets dark I need some light to see by.
Feature: When it is dark the system WILL turn on the light.
TEST – Turn on the light.
Trigger – It is dark: TRUE
The light comes on: TRUE.
Assertion – You can see now: FALSE.
The light is shining in my eyes.
No one said the light should not shine in your your eyes all you said was that the light should turn on: PASS