- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Scenarios
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
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.
)
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 stakeholders—usability people, security, operations, and so on—to 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.
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.