Previous Table of Contents Next


2.1. BACKGROUND INFORMATION

Certain background information must be collected before the design activity can be started. The means of collection are beyond the scope of this chapter, but several user-centered approaches are described by Holtzblatt and Beyer (1993) and others. The information gathered during this phase will be used to build the essential model and in the subsequent transformations. The necessary background information includes:

  Goals — There are many kinds of goals, several of which may conflict. These include
  System and application goals — the purpose of the application and what it will be used for, in terms of the environment it will be used in.
  Business goals — how this will affect the way the company does business.
  Organizational goals — the affect on the department, business unit, and cross-organizational groups.
  End-user goals — how it will affect things such as daily work patterns, job flexibility, and career growth.
  Environmental description — A description of the computing and real-world systems in which the application will function. What is the physical environment in which the application will be used? What function does the system perform? What are the objects in the system? How does the application being designed fit into the system, i.e., what are the tasks, in terms of the system and system objects, that it will be used for? What are the inputs to and outputs from the application?
  People — A description of the various roles that people assume when they use the application: end-users, customers, administrators, managers, auditors, etc. Which tasks does each perform? What information do they need to perform those tasks? What is the range of their education, experience, and physical abilities? What other activities are they involved in, especially those that they perform concurrently with the proposed application?
  Constraints — What parts of the environment can be changed and which cannot? Consider the physical environment, people, organization, current systems and equipment, rules and regulations.
  Real-life scenarios — How are the tasks identified in the environmental description currently performed? What are the frequencies and volumes associated with each task? What obstacles and errors occur while performing the tasks and how are they dealt with? Describe any external artifacts and their use within a scenario. What improvements have been suggested?

Even when designing for a new kind of application, there are usually real-life examples of how people currently perform the tasks of interest, however, it may be necessary to augment these with additional, made-up scenarios depicting new tasks to be supported by the application.

2.2. A BACKGROUND EXAMPLE

It is common in software development groups to hear that it takes too much time and effort to develop new applications so a software tools company decides to develop a product that better supports application development. The following is a very abbreviated example of the background information that might have been collected.

Goals — Shorten application development time; fewer bugs in the resulting application; more predictable development cycle; applications more easily adapted to changing business needs.
Environmental description — This is a corporate MIS shop. The computing environment is fully networked. Many different kinds of computers are used. Programs are written in C and incorporate routines from C-based libraries purchased from outside vendors.
People — Some developers have degrees in computer science but many have degrees in other fields and have taken a few computing courses. New programs are developed in small teams consisting a systems analyst, a couple of developers, a tester, and a documentation writer. The analyst, tester, and writer are usually involved in a couple of projects. Old programs are maintained and updated in response to end-user needs, leaving less time to develop new applications.
Constraints — C will continue to be used unless a very strong argument can be made for another language.
Scenarios — “We use libraries of routines that we buy from outside vendors. Each library has maybe 100 to 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 and figure out where to put it so others can find it...”

3. THE ESSENTIAL MODEL

The purpose of the essential model (Constantine, 1995) is to define the tasks a user will do without describing how the task is actually performed. It describes the user’s intentions, not activities. The model consists of the tasks a user is to accomplish, the objects and operations that comprise those tasks, the relationships among the those objects, and one or more use cases for each task. The tasks should include information on required inputs, outputs, volumes, frequency of execution, problems and their current solutions, who performs it, and constraints, e.g., processing time.


Previous Table of Contents Next