Alternatives to Functional Requirements


We have just taken you through most of a chapter that tells you how to write functional requirements and implies that this is a good thing to do. However, some alternatives to writing functional requirements do exist. The point being made here is not that you have an alternative to understanding the correct functionality of the product before you build it, but rather you might be able to demonstrate and communicate your understanding in a different manner.

We started writing functional requirements with product use case scenarios. If the intended product is routine and the business area well understood, you might consider simply elaborating on the scenario. Add the background processing details that you normally omit when writing a scenario for business stakeholders. Make the steps of the scenario read from the point of view of the product. If the scenario becomes too long or too elaborate, then revert to writing the functional requirements as described earlier. It is also vital that your developers and testers be confident they can write and test the product based on the enhanced scenario.

Do not follow this path if you are outsourcing construction to an external supplier or another department in your organization. In these cases, it is better to avoid the increased potential for misinterpretation by writing the functional requirements. You can always consider a mixture of enhanced scenarios and functional requirements for this type of project.

When you are making use of off-the-shelf (OTS) products or open source products, you do not need to write the requirements for anything other than the extra components needed to make the OTS/open source software work in your environment. Your scenarios should correspond to the OTS/open source capabilities. Once selected, the OTS/open source product becomes a constraint on your project (see section 4 of the Volere Requirements Specification Template), so there is no need to specify its capabilities.

Robertson, James, and Suzanne Robertson. Complete Systems Analysis: The Workbook, the Textbook, the Answers. Dorset House, 1998.


If, as a matter of course, you build process models, then consider whether they, together with their process specifications, can serve as the functional requirements. Many organizations (perhaps that should be "many requirements analysts") prefer to use process modeling as a way of arriving at an understanding of the needed functionality. They find their stakeholders relate more easily to diagrams than to text scenarios.

Your process models can use whatever notation you find most convenient. There are few bad notations but, unfortunately, many bad ways of using notations. Probably the most popular techniques are the UML activity diagram (Figure 7.5) and the data flow model of a business use case (Figure 7.6). We have found that analysts have their own preferences when it comes to these diagramsand these preferences are sometimes expressed with a religious fervorso we make no attempt to state a preference. Instead, we just ask you to consider them for yourself.

Figure 7.5.

An activity diagram showing the product use case "Truck Depot reports problem with truck."


Figure 7.6.

A data flow model of the product use case "Truck Depot reports problem with truck." This diagram is supported by process specifications for each of the processes shown, and a data dictionary to define the data flows and stores.


Class models (or data models, as they are also known) can also be rich indicators of the product's functionality. Figure 7.7 shows a class model for the IceBreaker product. Take a moment to peruse it as we discuss how some of the product's functionality can be derived from this model.

Figure 7.7.

A class model showing the stored business data needed to predict the formation of ice on roads. A truck is dispatched to treat a road when the readings from the weather station and the weather forecast indicate the road section is about to freeze.


The class model shows the classes, or entities, of data needed by the product to carry out its functionality. There is a strong link between a product's stored data and its functionality. It does not make sense to store data unless some functionality is provided to process it, and functions exist to process data. As the song goes, "You can't have one without the other."

We must mention here that the class model is a stored data modelnot a design for a database. Likewise, it does not need to show any implementation details, because they will be added by the database designers.

Let's examine each of the data classes. Weather Station is a data representation of the real-world device installed beside a road. The product has to have functionality to record the installation of the sensor and its precise location, and to time-stamp and record the Temperature Readings as the weather station transmits them. Similarly, there must be functionality to record, change, and delete the Roads and their Road Sections, and to know which sections are the responsibility of which Depots. The product must know which Trucks are attached to a depot, and which are available for scheduling. All of this information, including the scheduling, indicates functionality that must be part of the product.

The data model is not an indicator of the complete functionality. If you routinely build such a model, however, we suggest that it will serve as part of the specification of your functional requirements.




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