- Agility Guide
- Requirements Process in Context
- The Process
- A Case Study
- Trawling for Requirements
- Prototyping the Requirements
- Scenarios
- Writing the Requirements
- The Quality Gateway
- Reusing Requirements
- Reviewing the Specification
- Iterative and Incremental Processes
- Requirements Retrospective
- Your Own Requirements Process
- In Conclusion
This chapter is from the book
This chapter is from the book
This chapter is from the book
A Case Study
We shall explain the Volere Requirements Process by talking you through a project that uses it: The IceBreaker project is to develop a product that predicts when and where ice will form on roads, and that schedules trucks to treat the roads with de-icing material. The product will enable road authorities to be more accurate with their predictions, schedule road treatments more precisely, and thus make the roads safer. The road authorities also anticipate they can reduce the amount of de-icing materials used.
Project Blastoff
Imagine launching a rocket. 10 – 9 – 8 – 7 – 6 –5 – 4 – 3 – 2 – 1 – blastoff! If all it needed was the ability to count backward from ten, then even Andorra [1] would have its own space program. The truth of the matter is that before we get to the final ten seconds of a rocket launch, a lot of preparation has taken place. The rocket has been fueled, the course plotted—in fact, everything that needs to be done before the rocket can be launched.
The blastoff meeting prepares the project and ensures its feasibility before launching the detailed requirements effort. The principal stakeholders—the client, the main users, the lead requirements analyst, technical and business experts, and other people who are crucial to the success of the project— gather to come to a consensus on the crucial project issues. For the IceBreaker project, Saltworks Systems is the developer of the product, and its employees are aiming for worldwide sales. Northumberland County Highways Department has agreed to be the company's first customer, and it is helping with the requirements. Naturally, key Northumberland people are present at the blastoff meeting.
In the blastoff meeting, the principals work together until they have achieved the blastoff's objectives. That is, they gather enough facts to ensure the project has a clearly defined scope and a worthwhile objective, is possible to achieve, and has commitment from the stakeholders.
It is usually more convenient to define the scope of the business problem first. The lead requirements analyst coordinates the group as they come to a consensus on what the scope of the work is—that is, the business area to be studied—and how this work relates to the world around it. The meeting participants draw a context model on a whiteboard to show the functionality included in the work, the items they consider to be outside the scope of the ice forecasting business, and the connections between the work and the outside world. This model is illustrated in Figure 2.2. Later, as the requirements activity proceeds, it will reveal the optimal product to help with this work.
)
Once they have reached a reasonable agreement on the scope of the business area to be studied, the group identifies the stakeholders. The stakeholders are the people who have an interest in the product, or who have knowledge pertaining to the product, and thus have requirements. The group identifies the various people who have some interest in IceBreaker: the road engineers, the truck depot supervisor, weather forecasting people, road safety experts, ice treatment consultants, and so on. They do so because if they don't identify all of the stakeholders, the requirements analysts won't find all of the requirements. The context diagram usually identifies many of the stakeholders. We look at how this identification occurs in Chapter 3.
The blastoff also confirms the goals of the project. The blastoff group comes to an agreement on the business reason for doing the project, and it derives a way to measure the advantage the new product will bring. The group also must agree that the product is worthwhile, and that the organization is capable of building and operating it.
It is sensible project management practice at this stage to produce a preliminary estimate of the costs involved for the requirements part of the project. This can be done by using the information contained in the model of the scope of the work. It is also sensible project management to make an early assessment of the risks that the project is likely to face. Although these risks may seem like depressing news, it is always better to get an idea of the downside of the project (its risk and cost) before being swept away by the euphoria of the benefits that the new product is intended to bring.
Finally, the group members arrive at a consensus on whether the project is worthwhile and viable. This is the "go/no go" decision. We know from bitter experience that it is better to cancel a project at an early stage than to have it stagger on for months or years consuming valuable resources with no chance of success. The group must carefully consider whether the product is viable and whether its benefits outweigh its costs.
Alternatively, if many unknowns remain at this point, the blastoff group may decide to start the requirements investigation. It can then review the requirements in a month or so and reassess the value of the project.