RULE 8: Don’t describe the user interface
For many users the user interface is the system. Prototypes and mock-ups of the man-machine interface (MMI) are a fantastic way of eliciting requirements and use case behaviours from your stakeholders. And when defining use case descriptions adding MMI ‘screenshots’ and images can help illuminate the behaviour of the system to your customers.
To minimise the maintenance effort of a regularly-changing user interface we must uncouple the user interface from the functionality of the system. We must separate the effects of information flowing into and out of the system – What the information content is and how the system responds to it – from the presentation of that information to the user.
The use case description defines the desired requests and responses to the system; the MMI defines how those requests and response are manifested.
An event-mapping table can be used to map functions of the MMI (or indeed any interface specification) to the system event (transaction) it invokes or is in response to. Using an event-mapping table de-couples the interface from its function.
Events are typically one of the following:
A control input to the system
Used to control the behaviour of the system
Normally represent a change in the environment
May be an analog or digital signal
The system may or may not respond to the change
A signal to the environment from the system
Used to effect changes in the environment
May be an analog or digital signal
Feedback data from the system
Contains information about the current system state
The mapping table allocates some user interface operation (which could be as simple as a drop-list selection, or as complex as a whole sequence of button pushes or mouse clicks) onto a system behaviour.
In our simple example, pushing the big green button is our UI action. We’ve mapped this onto the ‘START SYSTEM’ command. Similarly, when the system is ready, this ‘READY’ status event is mapped onto the illumination of the LED. Now, if the user decides they don’t want a ‘ready’ LED but instead want a 16 x 2 character display, we can simply re-map the ‘READY’ status event onto a displayed message (something creative like "System Ready")
In this way you only need to change the use case description when the functionality of the system changes (hopefully, far less often than the MMI!)
Doing this separation also alleviates that all-to-common problem of poorly-written requirement specifications: the User Interface Specification contains half the functional behaviour of the system; and the System Requirements Specification contains half the user interface detail!
- 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.
I like your blog. Very useful. Thanks for sharing tips. Can you share what tools you use for generating these diagrams or figures and what tools you use for use-case/UML?
Pingback: Sticky Bits » Blog Archive » The Baker’s Dozen of Use Cases–Part 10
I have not seen all other rules but I hope there is a DON'T rule which advises AGAINST going too deep into the system and its internal operations or HOW the system generates the responses.
There is no need to work on "Sequence Diagrams" while describing Use Case Dialog. That can be done in different ways after completing the use case description. At times it may be necessary to refine the Use Case Description after developing the Sequence Diagram.