Previous Table of Contents Next


3.1. CREATING THE ESSENTIAL MODEL

The essential model is created by extracting it from the background information. The focus of the extraction process is the real-life scenarios. Embedded in each scenario are one or more goals. These goals typically state what the scenario is trying to accomplish and often refers to objects and information in the environment. These goals, restated as actions involving one or more objects, are the tasks of the essential model. Information in the scenario about inputs and outputs, problems and solutions, and constraints should be listed with the related task. Information in the scenario about how the user currently performs these tasks, usually the bulk of the real-life scenarios, can be ignored for now. If there are multiple user roles, each role should have its own task list. It may be appropriate to design separate interfaces for each user if their tasks vary significantly.

A preliminary list of objects is generated by extracting them from the background environmental description and the essential model tasks. The relationships between the various objects should be identified. Is one object really part of another? Perhaps they should be combined. Are sets of similar objects constantly used together? Perhaps a container object should be defined. Is there something that links the objects? A drawing is often the best way to indicate the relationships between objects and highlight inconsistencies. When the list of objects is finalized, the tasks should be revised accordingly.

The use cases are generated by restating the real-life scenarios using the tasks and objects, removing all references about how the user currently performs these activities. The resulting use cases should be quite brief in comparison to the original scenarios.

The essential model should be reviewed with the person(s) responsible for establishing the functional requirements and some of the users who provided scenarios. They should focus on the use cases, comparing them the with current environment in order to identify missing tasks.

3.2. AN ESSENTIAL MODEL EXAMPLE

The real-life scenario provided by a developer when the background information was gathered is restated here for easy reference:

“We use libraries of routines that we buy from outside vendors. Each library has maybe 100–200 routines in it. To find routines that could be used in a new application, we look in the documentation and read about what they do. Usually there are some examples of how the routine is used. There is much to look through in a new library and it takes a lot of time to find ones that we might be able to use. Sometimes I’ll ask other people I work with for suggestions. Once I find something that might work, I have to find it on disk so that I can include it into my code. I think that we would share more of the code that we write, but it is too hard to document it and figure out where to put it so others can find it...”

This scenario describes a few goals: locate some routines that might be used, evaluate each, and include the useful ones in the new application. Rewriting these as tasks yield:

  Find a set of candidate routines within a library.
  Evaluate a candidate routine using its documentation.
  Include the selected routine in the application.

The objects mentioned in these tasks are:

  Library — a collection of routines.
  Routine — code that could be included in a new application.
  Application — the program being built.
  Documentation — the description of what a routine does.

A use case is constructed by recasting the real-life scenario using the tasks and objects of the essential model and discarding all references to how the activity is currently performed:

Developers build applications, in part, by including selected routines from libraries. They select the routines by finding a candidate set of routines and evaluating each of them using its documentation.

Note that this use case does not include the information needs or specific problems. This makes it easier to discern the underlying structure. The information needs and problems are listed with the appropriate tasks and will be used later in the process to evaluate the alternative metaphors and to insure that the user’s needs are met. The information needs and problems in this simple example are:

  Finding candidate routines can take a long time.
  What does a particular routine do and how is it used?
  Where is the routine located?


Previous Table of Contents Next