Responsibility

Trawling is instigated by the requirements analyst. But the analyst does not work alone: Users and other stakeholders collaborate to gather the requirements, as shown in Figure 5.1.

Figure 5.1.

The trawling activity is central to the requirements process. It uses the outputs of the project blastoff activity as its starting point for collecting the requirements from the stakeholders. Prototyping runs as a parallel activity. Note that the requirements gathered at this stage are potential requirements; they still have to be tested by the Quality Gateway.

The requirements analyst and the users collaborate to gather the requirements.

We build products to help us do work. For our purposes, it doesn't matter whether the work is processing insurance claims, analyzing blood samples, designing automotive parts, predicting when ice will form on roads, keeping track of a "things to do" list, controlling a telephone network, downloading music or podcasts, monitoring a household, or one of many other human activities. There are things to do and data to store, and, for one reason or another, you have been asked to build a product that helps with this work.

So let's look at how we go about gathering requirements.

The Requirements Analyst

The analyst is a translator: He has to understand what both the users and the other stakeholders are saying about the work, and then translate that knowledge into requirements for a product. But there is more to it. The requirements analyst acts as a catalyst, injecting something new into the work. In other words, the requirements are not simply the passive interpretation of an existing piece of work, but rather contain inventions that will make the work easier, better, more interesting and more pleasant. Along the way, the requirements analyst must fill several roles:

• Observe and learn the work, and understand it from the point of view of the user. As you work with your users, you study their work and question them about what they are doing, and why they are doing it. Each piece of information you hear is treated at several levels simultaneously.

• Interpret the work. A user's description of some work should be treated as factual. After all, the user is the expert on that part of the work. However, the analyst must filter the description to strip away the current technology and thereby reveal the essence of the work, not its incarnation.

• Invent better ways to do the work. Once the requirements analyst sees the essence, he interprets what the product must do to satisfy that part of the work. At the same time, in conjunction with other stakeholders, he derives a product to improve the work.

• Record the results in the form of a stakeholder-understandable requirements specification and analysis models. The analyst must ensure that he and the stakeholders have the same understanding of the product, and stakeholders agree this is the needed product.

Not so easy as it first appears.

This is a long chapterthere is a lot to know about trawlingand we know that not all trawling techniques are applicable to all projects. The owl gives you guidance on whether the technique is applicable to your situation. By all means, read this entire chapterbut realize that you don't need to.

Several techniques are available to help with the task of trawling for requirements. As is the case with any technique, no single one works all the time, so your task is to select the technique that best fits the situation. In our discussions of the techniques, we indicate when and why one would be useful. But don't just take our word for ittry to connect each technique to your own situation, and consider where and when each would be most advantageous.

Conscious requirements are those requirements that are uppermost in the stakeholders' minds; they are often symptomatic of something that the stakeholders want to improve. Unconscious requirements are those that the stakeholders often fail to mention because they know so much about them, and assume everyone else has the same knowledge. Undreamed-of requirements are things that are useful, but the stakeholders don't realize are possible.

Consider your stakeholders. They are very conscious of some requirements and bring them up early. Other requirements are "unconscious" requirementsthings that are so ingrained into the stakeholders' work that they have forgotten they exist. The techniques that capture the conscious requirements may not necessarily work for the unconscious ones. Then there are the "undreamed-of" requirementsthose functions and features the stakeholders are unaware they could have. Undreamed-of requirements exist because the stakeholders do not realize they are possible, perhaps because of a lack of technological sophistication, or perhaps because they have never seen their work in the way that you will show it to them. Whatever the reason, part of your responsibility is to bring these requirements to the surface.

It is cheaper and more effective to uncover and capture all of the requirements during the trawling activity. Those that are not discovered during trawling will eventually be unearthed, probably when the users start operating the product. At the latter stage, it is much more expensive to make the changes necessary to accommodate the newfound requirements.