Trawling for Requirements

Once the blastoff is completed, the requirements analysts start trawling for requirements. They learn the work being done by the business area identified by the blastoff. For convenience and consistency, they partition the work context diagram into business use cases. Each business use case is the functionality needed by the work to make the correct response to a business event. A requirements analyst is assigned to each of the business use cases (the analysts can work almost independently of one another) for further detailed study. The analysts use techniques such as apprenticing, scenarios, and use case workshops, among many others, to discover the true nature of the work. These techniques are described in Chapter 5, Trawling for Requirements, and are favored because they involve the stakeholders closely in capturing their requirements. Once they understand the work, the requirements analysts work with the stakeholders to decide the best product to help with this work. That is, they determine how much of the work to automate or change, and what effect those decisions will have on the work. Once they know the extent of the product, the requirements analysts write its requirements. See Figure 2.3.

Figure 2.3.

The blastoff determines the scope of the work to be studied. The business use cases can be formally derived from the scope. Each of the business use cases is studied by the requirements analysts and the relevant stakeholders to discover the desired way of working. When this is understood, the appropriate product can be determined and requirements written for it.

Refer to Chapter 4 for a detailed discussion of business events and use cases, and an exploration of how to use them.

Refer to Chapter 5 for details of the trawling activity.

When they are trawling to discover the requirements, the analytical team members sit with the hands-on users as they describe the work that they do and the work that they hope to do. Some of the team members act as apprentices to the users: They learn how to do the work and, along the way, develop ideas about how improve it. The requirements analysts also consult with other interested stakeholdersusability people, security, operations, and so onto discover other requirements for the eventual product.

Perhaps the hardest part of requirements gathering is discovering the essence of the system. Many stakeholders inevitably talk about their perceived solution to the problem. The essence, by contrast, is the underlying business reason for having the product. Alternatively, you can think of it as the policy of the work, or what the work would be if there were no technology (that includes people). We will have more to say about essence in Chapter 5, Trawling for Requirements.

Robertson, Suzanne, and James Robertson. Requirements-Led Project Management. Addison-Wesley, 2005.

Maiden, Neil, Suzanne Robertson, Sharon Manning, and John Greenwood. Integrating Creativity Workshops into Structured Requirements Processes. Proceedings of DIS 2004, Cambridge, Mass., ACM Press.

The IceBreaker product must not be simply the automation of the procedures that are done at the moment. To deliver a truly useful product, the analytical team should help to invent a better way to do the work, and build a product that helps with this better way of working. With this goal in mind, they hold creativity workshops where the team members use creative thinking techniques and creative triggers to generate new and better ideas for the eventual product.