Business events and business use cases allow us to carve out a cohesive piece of the work for further modeling and study. By first understanding the effect each of the adjacent systems has on the work, we can come to understand the optimal product to build for that work. We
In some situations, you may not have any idea of the product scope. For example, suppose you are specifying business requirements so that an external supplier or outsourcer can come back to you and describe the product it can supply. To do so, you would write a scenario and then the requirements for each of the business use cases. The supplier would, in
By using business events to partition the work, you take an external view of the work. You do not rely on how it happens to be partitioned internally at the moment or on someone's idea of how it might be partitioned in the future. Instead, you partition according to the most important view of the work: how the outside world (often your customers) sees it. Figure 4.14 is an overview of this kind of partitioning.
The flow of requirements gathering. The response to each business eventthe business use caseis examined and an appropriate product determined. The analysts write the requirements for each product use case.
The idea of deriving the use cases from the business events means your requirements are grouped according to how the work responds to the business event. As a consequence,
of the response is part of the business use case, regardless of where in the work it happens to be partitioned at the moment. The result is a natural partitioning of the work. The actors are
Chapter 5. Trawling for Requirements
This chapter explores the techniques for discovering and determining both the requirements and the people involved in the process. You have two major concerns here: finding all of the requirements and finding the correct requirements. This means, inevitably, you need a variety of techniques so as to find the ones most
Let's start with a fundamental truth: Requirements come from people. Your task as a requirements analyst is to talk to people, understand them, listen to what they say, hear what they don't say, and understand what they need. Most of the time you learn requirements from people at work. Here's another fundamental truth: Requirements are not solutions. You need to learn the requirement before you can find the solution. It just won't work the other way round.
One of the
Rabbit projects need to be very aware of the section on essence. It deals with separating the idea for an implementation from the real requirements. Too often we see developers rushing for their keyboards as soon as they see the first glimmer of a solution. When you understand the essence of what is being said, your solutions will be far more appropriate, and usually more elegant. The section on electronic requirements is also central to rabbit projects.
Horse projects, due to their larger number of stakeholders, will probably make more
Elephant projects, due to their larger number of stakeholders, have a need to document their findings as they go about trawling for their requirements. Because of the more extensive set of possibilities for elephant projects, we suggest that you read all of this chapter, paying special attention to the owl recommendations.