- The Requirements Process in Context
- A Case Study
- Project Blastoff
- Trawling for Requirements
- Quick and Dirty Modeling
- Scenarios
- Writing the Requirements
- Quality Gateway
- Reusing Requirements
- Reviewing the Requirements
- Iterative and Incremental Processes
- Requirements Retrospective
- Evolution of Requirements
- The Template
- The Snow Card
- Your Own Requirements Process
- Formality Guide
- The Rest of This Book
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 business analysts start trawling the work to learn and understand its functionality—“What’s going on with this piece of the business, and what do they want it to do?” For convenience and consistency, they partition the work context diagram into business use cases.
Each business use case is an amount of functionality needed by the work to make the correct response to a business event. (These terms will be fully explained soon.) 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 trawling techniques such as apprenticing, scenarios, use case workshops, and many others to discover the true nature of the work. These trawling techniques are described in Chapter 5, Investigating the Work.
Refer to Chapter 4 for a discussion of business events and business use cases, and an exploration of how you might use them.
Trawling means discovering the requirements. The business analysts sit with the IceBreaker technicians as they describe the work they currently do, and their aspirations for work they hope to do. The business analysts also consult with other interested stakeholders and subject-matter experts—experts on usability, security, operations, management, and so on—to discover other needs for the eventual product. The IceBreaker business analysts spent a lot of time with the meteorologists and the highway engineers.
Refer to Chapter 5, Investigating the Work, for details of the trawling activity.
Perhaps the most difficult part of requirements investigation is uncovering the essence of the system. Many stakeholders inevitably talk about their perceived solution to the problem or express their needs in terms of the current implementation. 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 or the business rule would be if it could exist without any technology (and that includes people). We will have more to say about the essence of the system in Chapter 7, Understanding the Real Problem.
We look at developing innovative products in Chapter 8, Starting the Solution.
Once they understand the essence of the work, the analysts get together with the key stakeholders to decide the best product to improve 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. We illustrate this process in Figure 2.3.
)
Figure 2.3. The blastoff determines the scope of the work to be improved. The business use cases are 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 (the PUC scenario) and requirements or user stories written from it.
Reading
Maiden, Neil, Suzanne Robertson, Sharon Manning, and John Greenwood. Integrating Creativity Workshops into Structured Requirements Processes. Proceedings of DIS 2004, Cambridge, Mass. ACM Press.
Michalko, Michael. Thinkertoys: A Handbook of Creative-Thinking Techniques, second edition. Ten Speed Press, 2006.
Robertson, Suzanne, and James Robertson. Requirements-Led Project Management. Addison-Wesley, 2005.
The IceBreaker product must not be a simplistic automation of the work as it is currently done; the best of our automated products are not mere imitations of an existing situation. To deliver a truly useful product, the analytical team must work with the stakeholders to innovate—that is, to develop a better way to do the work, and a product that supports this better way of working. They make use of innovation workshops where the team uses creative thinking techniques and innovative triggers to generate new and better ideas for the work and the eventual product.