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 plottedin fact, everything that needs to be done before the rocket can be launched.

[1] Andorra is a tiny principality in the Pyrenees mountains between France and Spain. It became famous in the 1960s for having a defense budget of $4.50, a tale that has become the stuff of legend. Today Andorra's defense budget is zero.

Blastoff is also known as "project initiation," "kickoff," "charter," "project launch," and many other things. We use the term "blastoff" to describe what we are trying to achievegetting the project launched and flying.


The blastoff meeting prepares the project and ensures its feasibility before launching the detailed requirements effort. The principal stakeholdersthe 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.

Refer to Chapter 3 for a detailed discussion of project blastoff.


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 isthat is, the business area to be studiedand 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.

Figure 2.2.

The context model is used to build a consensus among the stakeholders as to the scope of the work that needs to be studied. The eventual product is used to do part of 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 project blastoff deliverables are the first of eight sections of the Volere Requirements Specification Template.


The relevant part of the Volere Requirements Process model (appendix A) is Project Blastoff (Diagram 1).


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 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.


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.

DeMarco, Tom, and Tim Lister. Waltzing with Bears: Managing Risk on Software Projects. Dorset House, 2003.

Yourdon, Ed. Death March (second edition). Prentice Hall, 2003.


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.




Mastering the Requirements Process
Mastering the Requirements Process (2nd Edition)
ISBN: 0321419499
EAN: 2147483647
Year: 2006
Pages: 371

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net