Section 9. Functional Requirements


9. Functional Requirements

Think of the functional requirements as things the product must do or actions it must take. These requirements are the fundamental activities of the product. For example, a functional requirement may be something like this:

The product shall record the new weather stations.


This requirement states an action that, if carried out, contributes to the goal of the product. If the goal is to predict when the roads will freeze, then it is necessary to collect data from weather stations, and thus it is necessary to know the existence and location of the weather stations. When new ones are added to the network, the product must be able to record their details.

Similarly, the following requirement also contributes to the product's purpose:

The product shall issue an alert if a weather station fails to transmit readings.


This requirement is necessary if the product is to know about failures of the stations and the possibility of the product having incomplete data. However, these example functional requirements are not complete. You may also think that they are too casual and possibly ambiguous. To complete each requirement, you must take the following steps:

  • Give it an identification number.

  • Designate the product use case and the business event this piece of functionality is derived from.

  • If the rationale is not self-evident, include it.

  • Designate the originator.

  • Add a fit criterion.

  • Describe any conflicts, if they are known.

  • Include any supporting materials you consider useful.

Figure 10.6 illustrates the complete functional requirement. Let's look more closely at the description.

Figure 10.6.

A complete functional requirement written on a snow card.


Description

The description details an action that the product must takein other words, what the product must do. Take this example:

The product shall record air-temperature readings, humidity readings, precipitation readings, and road-temperature readings received from weather stations.


Note the level of detail. The requirement is written in plain English, provided it is not obviously ambiguous or open-ended. The description must be understandable and verifiable by technical and nontechnical stakeholders. It is not yet completeeach of the requirements is given a fit criterion that tightens the definition by making it testable.

Usually the requirement can be stated in one sentence. If you find yourself taking more than one sentence to describe it, then you may, in fact, be describing several requirements. If you use two verbs in the sentence, it might be that you are describing two requirements. It is good practice to write each requirement as a single sentence with a single verb. It will cause you fewer problems when you write the fit criterion and the time arrives to test the requirement.

The functional requirements are usually derived from the steps of the use case scenario. For example, the use case step

Product determines which roads are likely to freeze and when they are likely to freeze.


yields these requirements:

It is good practice to write each requirement as a single sentence.


The product shall determine the current temperature of the road adjacent to the weather station.

The product shall extrapolate temperatures for each meter of road using the thermal map.

The product shall predict the temperature for each road-meter for each ten-minute interval using the weather forecast.

The product shall record roads where ice will form within the given time parameter.


See Chapter 6, Scenarios and Requirements, for a full description of how to write scenarios.


Again, note the level of detail. It should be enough for your client (or the user or the domain experts) to verify that the product will work correctly.




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