Measuring the Work

Our discussion of function point counting is an appendix because it is, strictly speaking, outside the scope of the requirements analyst's normal responsibilities. That said, measuring the work area so as to estimate the size of the project definitely provides a benefit to any requirements analyst. So with the idea of making you interested in measuring, or making you interested in making your organization interested in measuring, here is a simplified (but not simplistic) introduction to counting function points.

"You cannot control what you cannot measure."

Source: Tom DeMarco

The requirements activity is an investigation of a piece of work, with the potential to cause a change to that work, probably by automating some of it. The work in question can be automated, manual, scientific, commercial, embedded, a combination of the above, or anything else. The reason for measuring that work is to learn how "large" it is. The bigger the work (that is, the more functionality and data it contains), the longer it takes to study it. You would expect to spend more time studying an airline reservation system than you would studying a system for taking bar orders. Why? Becausethe airline reservation system contains more functionality. Naturally it takes longer to discover and understand that functionality, and to write the requirements for it.

Function points are a measure of the amount of functionality contained within a work area. They are a neutral measure of functionality, meaning that the type of work being done does not influence them. You can count thefunction points for air traffic control, car traffic control, or car cruisecontrol. Once you know the function point count of a work area, you apply your metric to determine how long it takes to study that size of work area.

Over the years our industry has established that for most size metrics, a standard amount of work must be done to implement one unit of the metric. For example, if you use function points to determine the size of the product, then there are industry-standard figures of the number of hours (or the number of dollars) it takes to implement one function point. Thus, if you know the size of the work area, then it is a relatively straightforward matter to translate size into effort required to build the product.

For example, Capers Jones of Software Productivity Research gives us this rule of thumb:

Effort in staff months = (function points ÷ 150) x function points^0.4

Thus, for a 1,000function-point work area (this is a substantial, but not overly large area) the effort in person-hours is (1,000 ÷150) x 1,000^0.4(1,000 ÷150) x 1,000^0.4, which is 105.66 staff-months.

Jones's rule of thumb applies to the complete development effort, which includes the effort expended by everyone on the development side of the project. In the typical software project, about half the effort is spent debugging (most of which is correcting ill-gathered requirements), so it is safeto say that about one-third of Jones's number that would cover a thorough requirements effort.

On the one hand, this is a general guide; on the other hand, it is extremely useful. Using this rule of thumb, once you have counted the function points from your context model, you immediately have a fairly precise idea of the effort you need. Please take a moment to consider whether your current estimation process is accurate enough to persist with, or whether you should start to count function points.

The keyword here is "measure."

You can, of course, measure the size of your work area any way you and your organization think appropriate. The key word here is "measure." If you are not already using a measuring method, then we suggest you start with function point counting. While it is by no means the ultimate measuring method, it is widely used. Thus a lot is known about it, and a substantial body of information and statistics on function points is available.

International Function Point Users Group. IT Measurement: Practical Advice from the Experts. Addison-Wesley, 2002.

Function points are not the only way to measure the size of a work area. You can use Mark II Function Points (a variation on standard function points), Capers Jones's Feature Points (another variation), Tom DeMarco's Bang, Barry Boehm's COCOMO, or any of dozens of measuring methods. However, at the requirements stage of development, function points are convenient and, given what you know of the product at this stage, probably the most appropriate measuring method to use.

If you do not already use another method and would like to get started with function points, then please join us for the rest of this appendix.