Apprenticing

Apprenticing is particularly useful for in-house work. The underlying assumption for apprenticing is that users are currently doing work, and you, as the requirements analyst, have to understand their work. This work could be clerical, commercial, graphic arts, or almost anything short of brain surgery. Keep in mind you are not attempting to reimplement the work exactly as is. We recommend that all apprentices refer to the section on essence.

Apprenticingbased on the old idea of masters and apprenticesis a wonderful way to observe the real work. In this case, the requirements analyst is the apprentice, with the user as the master craftsman. The analyst sits with the user at the user's place of work, learning the job by making observations, asking questions, and perhaps doing some of the work under supervision.

Beyer, Hugh, and Karen Holtzblatt. Contextual Design: Defining Customer-Centered Systems. Morgan Kaufmann, 1998.

It is unlikely that many users can explain what they do in enough detail for the developer to completely understand the work and thus capture all the requirements. For example, if you are away from your work, you tend to describe it in abstract terms and using generalized cases. An abstraction is useful in one sense, but it does not hold enough detail for it to work every time.

Nor can you expect users to have the presentation and teaching skills needed to present their work effectively to others. Conversely, almost everyone is good at explaining what they are doing while they are doing it. If the user is doing his job in his normal workplace, he can provide a running commentary and provide details that might otherwise be lost. Only while working can the user describe his task precisely, tell you why he is doing things, and explain what exceptions can occur. You will see this process first-hand the first time a user shows you his work-around for special cases.

"Nobody can talk better about what they do and why they do it than they can while in the middle of doing it."

Source: Beyer and Holtzblatt

To have the user describe the work, you must not take him away from it. Rather, the analyst sits alongside the user at the normal workplace and receives a running commentary on the work as it happens. Each action is explained. If the explanation is not clear, the apprentice asks questions: "Why did you do that?" "What does this mean?" "How often does this happen?" "What happens if this piece of information is not here?" Through this process, the analyst eventually sees all the cases and the actions the user takes for each.

Apprenticeship can be combined with current system modeling. As the work is observed and explained, the analyst sketches a model of each task and its connections with the other tasks. Given that several models are suitable here, you should use whichever is most comfortable to you and your user. As the models are built, the analyst feeds them back to the user to obtain confirmation that they are correct and to raise questions about any areas of uncertainty (see Figure 5.6).

Figure 5.6.

The requirements analyst learns the work while sitting at the user's desk. Sometimes models of the work are built while learning it.

The requirements analyst uses his term of apprenticeship to try out requirements and design ideas. The analyst asks the user if an idea is feasible and if it would improve the work. This communication generates in the user's mind the notion that the analyst is more than an observerthe analyst is there to help improve the work.

The requirements analyst is an interpreter as well as an observer. While observing the current work, the analyst must abstract away from what he sees. He must overcome the user's close connection to the physical incarnation of the work. In other words, the artifacts, the technology, and so on that are currently used must be seen as a product of a previous designer. Someone, some time ago, decided that was the best way to do the work. But times have changed. Today it may be possible to do things that were impossible yesterday. There may now be better waysways that take advantage of up-to-date technology, that use streamlined processes, that simplify the work or automate some or all of it.

Thus, while the apprentice is learning the work by seeing the same tasks performed many times, he is also looking past how the user does the work to discern the underlying essence of the work. We will come back to essence a little later.