This Chapter of the book, describes a requirements process that authors have derived from their years of working in the requirements arena—working with clever people who do clever things, and working on projects in wonderfully diverse domains.

The Volere Requirements Process:

PROJECT BLASTOFF

The key purpose of the project blastoff is to build the foundation for the requirements discovery that is to follow, and to ensure that all the needed components for a successful project are in place. The principal stakeholders—the sponsor, the key users, the lead requirements analyst, technical and business experts, and other people who are crucial to the success of the project—gather together to arrive at a consensus on the crucial project issues.

TRAWLING FOR REQUIREMENTS

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.

QUICK AND DIRTY MODELING

One quick and dirty modeling technique the book mention is using Post-it notes to model functionality; each note can be used to represent an activity, and the notes can be rapidly rearranged to show different ways the work is done or could be done. The authors find that stakeholders relate to this way of modeling their business processes, and are always willing to participate with hands-on manipulation of the Post-its to show what they think the work should be.

SCENARIOS

Scenarios show the functionality of a business process by breaking it into a series of easily recognizable steps, written in English (or whatever language you use at work) so that they are accessible to all stakeholders. The IceBreaker analysts used scenarios to describe the business processes and present their understanding of the needed functionality. These scenarios were then revised as needed—different stakeholders took an interest in different parts of the scenario, and after a short time, the business analysts were able to have everyone understand and come to a consensus on what the work was to be.

WRITING THE REQUIREMENTS

QUALITY GATEWAY

To ensure correctness, the quality gateway tests the requirements. The IceBreaker team has set up a single point that every requirement must pass through before it can become a part of the specification. This gateway is manned by two people—the lead requirements analyst and a tester—and they are the only people authorized to pass requirements through the gateway. Working together, they check each requirement for completeness, relevance, testability, coherency, traceability, and several other qualities before they allow it to be passed to the developers.

 

 

TRUTH 1 Requirements are not really about requirements.

TRUTH 2 If we must build software, then it must be optimally valuable for its owner.

TRUTH 3 If your software does not have to satisfy a need, then you can build anything. However, if it is meant to satisfy a need, then you have to know what that need is to build the right software.

TRUTH 4 There is an important difference between building a piece of software and solving a business problem. The former does not necessarily accomplish the latter.

TRUTH 5 The requirements do not have to be written, but they have to become known to the builders.

TRUTH 6 Your customer won’t always give you the right answer. Sometimes it is impossible for the customer to know what is right, and sometimes he just doesn’t know what he needs.

TRUTH 7 Requirements do not come about by chance. There needs to be some kind of orderly process for developing them.

TRUTH 8 You can be as iterative as you want, but you still need to understand what the business needs.

TRUTH 9 There is no silver bullet. All our methods and tools will not compensate for poor thought and poor workmanship.

TRUTH 10 Requirements, if they are to be implemented successfully, must be measurable and testable.

TRUTH 11 You, the business analyst, will change the way the user thinks about his problem, either now or later.