Mastering the Requirements Process (2nd Edition) - page 83

Summary

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 arrive at the product scope by understanding the work in its context, not by presupposing that there will be a user and a computer, or by slavishly following the existing technology.

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 turn , determine which parts of those business use cases it can deliver as product use cases.

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.

Figure 4.14.

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, all 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 chosen as an outcome of this partitioning, with the end result being a work area and eventually a product that are more responsive to the outside world.

Chapter 5. Trawling for Requirements

in which we drag the net through the work area looking for requirements, and discuss some useful techniques for doing so

The term trawling comes from our partner Steve McMenamin (a source of many useful and descriptive images). We use it because it evokes the nature of what we are doing here: fishing . Not idly dangling a line while hoping a fish might come by, but rather methodically running a net through the work to catch every possible requirement. With a little experience and good techniques, the skipper of a trawler knows where to fish so that he gets the fish he wants, and not the ones that he doesn't.

" Requirements don't litter the landscape out at the customer site. "

Source: Beyer and Holtzblatt, Contextual Design

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 applicable to the stakeholders who are providing the requirements.

Agility Guide

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 cornerstones of agility is the idea of not doing more than you have to. This chapter does not present a prescription or process for determining the requirements. Instead, you are invited to read about the techniques, along with our suggestions on when and how they are used, and determine for yourself what is most appropriate for your stakeholders and your particular project.

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 extensive use of apprenticing , interviewing, and use case workshops. These techniques give rise to better documentationin particular, the scenarios that usually emerge from use case workshops.

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.