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.