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.

It is very tempting to describe use case transactions in terms of MMI elements, in an attempt to make them more understandable to the customer.  However, be aware: this is a very high maintenance solution.  The one thing that can almost be guaranteed in the design of any system is that the MMI will change.  A lot.  By writing your use case descriptions in terms of user interface elements you will be constantly going back and revising your use case text (and reviewing, and doing impact analysis… you do these, don’t you?!)

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:

COMMAND
A control input to the system
Used to control the behaviour of the system

INPUT
Normally represent a change in the environment
May be an analog or digital signal
The system may or may not respond to the change

OUTPUT
A signal to the environment from the system
Used to effect changes in the environment
May be an analog or digital signal

STATUS
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!

<<Prev     Next>>