How Much Is This Going to Cost?


At this point in the blastoff, you have a lot of information on which to base your estimates of cost and effort. The needed effort is usually proportional to the amount of functionality contained within the work area. This relationship makes sense: The more functions done by the work area, the more effort needed to study it and devise a solution. At this stage you do not know the size of the producthow much functionality it will containbut you do know the size of the work area. That is, at least you do if you measure it.

The easiest way to measure the size or functionality of the work area is to count the number of adjacent systems on the context model as well as the number of inputs and outputs. While more accurate ways to measure size have been devised, counting the inputs and outputs is fast and gives you a far better idea of size than merely guessing. If your context has more than 30 inputs and outputs, then it falls into the "average cost per input/output" range of estimating. Simply put, your organization has an average cost for gathering the requirements for one input or output. You can determine this cost by going back to previous projects, counting the number of inputs and outputs on the context, and dividing this number into the total cost of that requirements investigation.

A more accurate estimate comes from determining the number of business events that affect the work. We discuss this approach fully in Chapter 4, Event-Driven Use Cases. For the meantime, if you accept that the business events can be derived from the context model, then their number is the determining factor in the cost of the requirements effort. It is, of course, necessary to know the cost to your organization of analyzing the average business event. You can learn this cost by looking at previous projects or, if necessary, running a benchmark. Multiply the cost per event by the number of events to give a reasonably accurate price you will pay for requirements gathering.

More accurate still is function point counting. At this stage you need to have an idea of the data stored by the work, and this information can usually be identified in a short time if your team includes some experienced data modelers. Function point counting measures the amount and the complexity of the data processed by the workthe inputs and the outputs from the context modelalong with data stored within the work. Enough is known about function points to enable you to find figures for the average cost per function point of requirements investigation.

A brief overview of function point counting appears in appendix C, Function Point Counting: A Simplified Introduction.


Garmus, David, and David Herron. Function Point Analysis: Measurement Practices for Successful Software Practices. Addison-Wesley, 2001.


The key consideration is not so much that you use a particular estimating system at this stage, but rather that you use a system based on measurement, not hysterical optimism. Too much risk is courted by not measuring. If you do not make even the most basic of measurements, then any predictions you do make will be based on nothing more than guesswork. Guesswork and optimism usually lead to unrealistic project schedules, and these in turn force developers to cut corners and scrimp on quality. Inevitably, the project gets into trouble when the shortcuts turn out to cause longer delivery times (it always happens), and the users lose confidence in the integrity of the product and its developers. There is too much evidence of the downside of not measuring, and too much known about measuring, to have any excuse for not doing it.




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