The Baker’s Dozen of Use Cases

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.

UI prototyping the use case

 

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. 

 

UI to Event mapping

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

Posted on December 7th, 2010
» Feed to this thread
» Trackback

3 Comments a “The Baker’s Dozen of Use Cases”

  1. Prasanth says:

    Hi
    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?

    Thanks
    prasanth

  2. Sticky Bits » Blog Archive » The Baker’s Dozen of Use Cases–Part 10 says:

    [...] as we should decouple user interface details from the use case description (see Rule 8) so should we decouple the data transactions.  Describing the data requirements of a [...]

  3. Putcha V. Narasimham says:

    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.

Leave a Reply