Finding the Functional Requirements

Several artifacts reveal the product's functionality. One of the most obvious is the scenario. You arrive at scenarios by partitioning the context of the work using the business events that affect it. For each business event, there is a business use case and, in turn, a product use case. In Chapter 6, we described how to write a scenario for the product use case. This scenario takes the form of a series of steps that complete the functionality of the use case.

The steps in the scenario are readily recognizable to the business stakeholders, because you write them in the stakeholders' language. This means they are probably generalized to encapsulate the details of the product's functions. Think of the details of each step as its functional requirements; your task now is to expose those details by writing the functional requirements. Figure 7.2 illustrates this gradual arrival at the use case's functional requirements.

Figure 7.2.

The scenario is a convenient way to work with stakeholders and determine the needed functionality for a product use case. Each of the scenario's steps is decomposed into its functional requirements. The collection of functional requirements reveals what the product has to do to fulfill the product use case.

Let's see how this process works by using an example of a product use case scenario. In the IceBreaker road de-icing system, one of the use cases is "Produce Road De-icing Schedule." The actorthe person or thing immediately adjacent to the product, often called a userfor this use case is the Truck Depot Supervisor. He triggers the product to produce the schedule for deicing the roads in his district. See Figure 7.3.

Figure 7.3.

This use case diagram shows the product producing the road deicing schedule. It is triggered by the Truck Depot Supervisor. The Thermal Mapping Database is a cooperative adjacent system providing information to the use case upon request.

The product must do several things if it is to achieve the outcome desired by the actor. Here is a scenario to describe for this product use case:

Product use case: Produce road de-icing schedule

1. Engineer provides a scheduling date and district identifier.

2. Product selects the relevant thermal maps.

3. Product uses the thermal maps, district temperature readings, and weather forecasts to predict temperatures for each road section for the district.

4. Product predicts which roads will freeze and when they will freeze.

5. Product schedules available trucks from the relevant depots.

6. Product advises the engineer of the schedule.

The steps in this use case are sufficient, in general terms, to do the work. As discussed in Chapter 6, they can be verified with the interested stakeholders. Having a limited number of stepswe suggest between three and tenin the scenario prevents you from getting lost in the details and keeps the scenario in stakeholder-friendly language.

Three to ten steps in the scenario give a reasonable level of detail, without making it too complex for some business stakeholders.

Once you and your stakeholders have agreed on the steps, for each one ask, "What does the product have to do to complete this step?" For example, the first step in the scenario is

1. Engineer provides a scheduling date and district identifier.

The first functional requirement to come from this step is fairly obvious:

The product shall accept a scheduling date.

When you ask the stakeholders whether there is anything special about the scheduling date, they tell you that scheduling is never done more than two days in advance. This information suggests another functional requirement:

The product shall warn if the scheduling date is neither today nor the next day.

Another requirement from the first step is

The product shall accept a valid district identifier.

You discover another requirement when you inquire what is meant by "valid." The identifier is valid if it identifies one of the districts for which the engineer has responsibility. It would also be valid if it agrees with the identity of the district that is intended by the engineer. This leads us to two more functional requirements:

The product shall verify that the district is within the de-icing responsibility of the area covered by this installation.

The product shall verify that the district is the one wanted by the engineer.

The number of requirements you derive from any step is not important, although experience tells us that it is usually fewer than six. If you uncover only one requirement from each step, it suggests either the level of detail in your scenarios is too granular or your functional requirements are too coarse. If you get more than six requirements per step, either your requirements are too granular or you have a very complex use case. The objective is to discover enough functional requirements for your developers to build the precise product your client is expecting and your actor needs to do the work.

Let's consider another of the use case steps in our example:

4. Product predicts which roads will freeze and when they will freeze.

This step in the use case scenario leads us to three functional requirements:

The product shall determine which areas in the district are predicted to freeze.

The product shall determine which road sections pass through areas that are predicted to freeze.

The product shall determine when the road sections will freeze.

Now continue in the same vein, working through each of the steps from the scenario. When you have exhausted the steps, you should have written the functional requirements for the use case. Be sure to test whether you have completed the use case by walking through the requirements with a group of colleagues. You should be able to demonstrate clearly that the use case provides the correct outcome for the actor.