Exploring Requirements 1 by Gerald M. Weinberg

Author:Gerald M. Weinberg
Language: eng
Format: epub
Tags: programming, design, software, software testing, requirements, product creation, software development, product development, product planning, specifications
Publisher: Gerald M. Weinberg

7.2.2 Pruning the user list

Merely listing these potential users raises our consciousness of issues in the design of an Elevator Information Device. Still, we can do more with the potential user list. We've now defined almost a hundred possible user constituencies, but no design could optimally satisfy a hundred different user constituencies. What are we to do?

First, some of these constituencies overlap. A single passenger could be a blind, male, impatient, art-loving stockbroker who happens to be in the building to shop for a pet because he is lonely.

Second, the categories are not independent with respect to the ultimate design solution. A design solution emphasizing features for construction workers and athletes might trade away functions and features to aid the handicapped—and vice versa.

In order to deal with such conflicts, designers must recognize and accept the old maxim: There is no free lunch. Ultimately, they have to consciously trade off one constituency against another. One way to do this is by applying a user-inclusion strategy.

The first step in the user-inclusion strategy is listing potential users as we have done. The second step is assigning each user constituency one of three values (F, I, U), according to the way the design is to treat them:

F be very Friendly to them

I Ignore them

U be very Unfriendly to them

If we have 100 constituencies, there are 3100 different ways of assigning these letters, each representing a different choice of how users will be included in this design. This number of possible design targets is so large it has 48 digits when fully written out, yet each focus could produce a somewhat different final solution.

To take one example, assume all users are to be ignored except computer programmers, elevator designers, information designers, and composers of elevator music. This design might be an elegant tribute to our ability to produce art for art's sake, but might not serve the handicapped or satisfy the liability insurers. In any case, the solution would probably differ markedly from one that included features for terrorists, spies, muggers, loiterers, shoplifters, and vandals. In these cases, we might deliberately design user-unfriendly features.

The user-inclusion process can also focus our attention on otherwise acceptable people for whom we would want to make the system unfriendly. For instance, we might design features that prevent children or blind people from operating an elevator while the building is under construction. We can label such designs unfriendly, though perhaps a better label would be "paternalistic."

Of course, every designer defines user constituencies, but without specific user-inclusion activities, many of the choices are implicit. When implicit choices to include or exclude are made explicit late in the process, corrective action becomes expensive. The result is such products as appliances not operable by left-handed people, transports not usable by people in wheelchairs, and buildings providing happy hunting grounds for muggers and rapists.

Download

Copyright Disclaimer:
This site does not store any files on its server. We only index and link to content provided by other sites. Please contact the content providers to delete copyright contents if any and email us, we'll remove relevant links or contents immediately.