Counting Function Points for Business Use Cases

Earlier in this appendix, we noted that you could count function points either for the work as a whole or individually for each business use case. As the latter is usually more convenient for the requirements analyst, we will explain the counting process using business use cases.

The counting procedure varies slightly depending on the primary intention of the business use case. Think of this as what the adjacent system wantsor needs that causes it to initiate the business event. If the primary intention is simply to supply data to be stored within the work (as when you pay your utility bill), then it is called an input use case. If the primary intention of the adjacent system when it triggers the business use case is to receive some output, then we call it, naturally enough, an output business use case. Time-triggered business use cases are referred toas inquiries. The stored by the work is being inquired upon, so this name makes sense.

To measure the amount of functionality of a business use caseremember you are trying to figure out how long it will take to do the requirements analysis for the business use caseyou count the data elements of the incoming and/or outgoing data flows as well as the number of classes referenced bythe business use case. We will show how this is done for each of the types of business use case.

Counting Input Business Use Cases

One of the business events we mentioned in Chapter 4 is called "Weather station transmits reading." This is a simple enough event (see Figure C.3), and its primary intention is to update some internally stored data. Outputsfrom this kind of business use case, if any, are trivial and can safely be ignored. In the model of the business use case in Figure C.3, you see the incoming flow of data called Weather Station Reading and the functionality it triggers inside the work. As a result of this functionality, two classes of data are referenced. "Referenced" in this context can mean either the class is written to or read fromit does not matter which.

Figure C.3.

Figure C.3 The primary intention of this input business use case is to alter internally stored data. It references two classes.

The model of the business use case shows all that is needed to count the function points.

Firstly, count the data elements or attributes that make up Weather Station Reading. This is easier if you have a data dictionary entry for this flow, but failing that, estimate the number. We could say it is likely to have an identifier for the weather station, the temperature, the moisture content of the road surface, the data, the time, and possibly one or two more elements. That makes seven attributes. Hold on to that number.

The business use case references two classes of data. Even without any detailed study of the work, it is easy enough to see that there is no need for any other stored data to be used by this business use case.

Next, convert those two numbers to function points. For that, use the information in Table C.1. The example business use case has seven attributes in the input flow and references two classes. The cell at the intersection of these counts gives a result of four function points.

Table C.1.

Function Point Counts for an Input Business Use Case: The correct function point counting terminology for these is "external input."

That's it for this business use case. The official function point counting practices include an additional step in which you assign a complexity measure and then use it to adjust the function point count. However, as few people bother with it and the increase in accuracy is marginal, we shall not discuss this step here.

The process outlined in this section is repeated for each of the input business use cases. These function point counts can then be aggregated to give the total count for the entire work, or you can use the counts to compare the relative expenses for analyzing each of the business use cases.

Of course, not all the business use cases are inputs.

Counting Output Business Use Cases

In an output business use case, the primary intention of the business use case is to achieve the output flow. That is, when the adjacent system triggers the business event, it wants the work to produce something. The oncoming data flow is a request for the output, and it contains whatever information is needed for the work to determine what is wanted. The work produces the significant output flow and, in so doing, makes some calculations, updates stored data, or both.

When measuring an output business use case, you count the dataelements in the output flowthat is, the individual data items, or "attributes" of the flow. It would be helpful to have a data dictionary at this stage, but simply scrutinizing the flow leads you to make an educated guess about what it contains. For example, the Amended de-icing Schedule in Figure C.4 would be expected to contain the following data elements, plus maybe one or two others:

• Road

• Road section

• Truck identifier

• Starting time

• Latest possible time

• Distance to treat

Figure C.4.

This is an output business use case. The primary goal of the adjacent system when initiating this business use case is to gain the output information.

Let's allow for some extras and say there are a total of eight data elements. It may seem a little cavalier to make guesses in this way, but when you look at Table C.2 you see the data elements in ranges of 1 to 5, 6 to 19, and 20 and higher. Thus your real need here is to determine, as best youcan, which range the data element count for the output flow falls into.

Table C.2.

Function Point Counts for an Output Business Use Case

The next step is to look at the stored data referenced by the business use case. In Figure C.3, we were kind enough to show the classes referencedby the business use case. We won't be so kind this time. However, go back tothe class model in Figure C.2. Imagine the processing. You are reschedulingto cover for a broken-down truck. All that is needed is to find the roads and road sections allocated to the broken truck, find another truck attachedto the same depot, and reallocate the roads and sections.

That's four classes: Road, Road Section, Truck, and Depot. Now refer to Table C.2. The number of attributes in the output flow is eight, and the number of classes referenced is four. The table shows seven function points for this combination.

These function points are added to the aggregate total, and you continue with the rest of the business use cases.

Counting Time-Triggered Business Use Cases

Time-triggered business use cases are almost always reports. They are produced when a predetermined time is reachedwe report sales on the last dayof the month; we send out invoices five days after the purchaseor because somebody wants to see a report or get some information from the work. The function-point-counting people know this kind of business use case as an inquiry. This is not a bad name, as the analysts start by making inquiries to the stored data.

The underlying assumption with this kind of business use case is it doesnot perform any significant calculations. If the processing involves more than just the simple retrieval of stored data, then it must be classified asan output business use case. That is, the stored data is updated and/or nontrivial calculations are involved. Your count must reflect this activity byallowing for its greater complexity.

The example shown in Figure C.5 is triggered by time. That is, every two hours the work sends a schedule to the Truck Depot showing which roads mustbe treated.

Figure C.5.

A time-triggered business use case does not involve any input from an adjacent system. This kind of business use case is also called an inquiry, a name inspired by the fact that the stored data is simply inquired upon or retrieved (not modified) and no calculations are performed. In this instance, to produce the Road Deicing Schedule, the business use case needs to retrieve all of the stored data classes.

If the business use case shown in Figure C.5 were to produce an on-demand report, then it would be possible for someone at the Truck Depot to enterparameters to get the schedule he wanted. Unless nontrivial processing occurs as a result and/or data stores are modified, this is still considered a time-triggered, or inquiry-type, business use case. For on-demand reports, you count the attributes in both the input parameter flow and the resultantoutput flow. However, if an attribute appears in both flows, it is counted only once.

To count the function points for the time-triggered business use case shown in Figure C.5, you use Table C.3. Our example business use case must reference all eight of the classes to make its predictions about ice formation. The amended schedule we saw previously had eight data attributes; the output here would have the same number.

Table C.3.

Function Point Count for an Inquiry (Time Triggered Use Case)

Note that these are unduplicated attributes. You are counting unique data attributes or elements, which you might also call data element types.

As shown in Table C.3, the combination of eight data attributes and more than three classes referenced yields six function points. Add the six function points to your aggregate total, and continue counting the other business use cases.

Counting the Stored Data

The data stored within the work area must be maintained. This upkeep naturally requires an amount of functionality, which is in turn counted by measuring the amount and complexity of the data. For this part of the count, you follow pretty much the same path as beforethe difference is that you count only the stored data. Business use cases do not figure in this count atall.

Internal Stored Data

The first of the stored data to be counted is the data held inside the workarea. Function-point-counting manuals refer to this information as internal logical files; they include the databases, flat files, paper files, or whatever else is part of your work area. Keep in mind that any files that are present for implementation reasons are not countedfor example, backups and manual files that are identical (or close) to automated files.

You use the class model of the data to count from. This time, for each entity, count its attributes. Skip any attributes that are present to serve purely technological reasons, but count foreign keys (pointers from one class to another). The count should be accurate enough to assign the class to one of the three columns shown in Table C.4.

Table C.4.

Function Point Counts for Internally Stored Data

The next count is record elements. These are either the class itself or subtypes of classes. That is, if the class has no subtypes, it isone unit of data and counts as one record element. Conversely, if there are subtypes, you must count them as record elements.

We do not have any subtypes in the IceBreaker class model, so let us invent some. Suppose that weather stations come in various types. One special type does not have a surface-moisture sensor. Consequently, predictions based on the data from this kind of weather station are made differently. Moreover, the work needs to keep special data relating to this kind of weather station. The stations also fail from time to time. When they do, the work needs to store special data relating to past predictions from this station.

The result of these changes is that we have created two subtypes of the weather station class (also known as subclasses). Figure C.6 shows the resulting model.

Figure C.6.

The Weather Station entity has two subtypes. The Failed subtype contains attributes aboutpast predictions that are used in lieu of current readings. The No moisture sensing subtype has attributes that describe adjustments needed to compensate for this weather station's lack of a moisture sensor. These subtypes are necessary because their attributes do not apply to all weather stations.

In function point terms, the Weather Station entity counts for two record elements. You count only the subtypes, and not the parent entity. For theother entities in the class model, count them as having one record element.

The next task is to count the number of attributes in each class. This is not as arduous as it might at first seem. According to Table C.4, you need only know if there are between 1 and 19 attributes to the class, or between 20 and 50, or more than 51. Given these ranges and your desire to complete this count quickly, it is permissible to make some inspired guesses regarding the number of attributes for the entity.

Pick a classsay, Truck. How many attributes does the Truck class have? Or, as you could say here, does it have more than 19? Unlikely. So let us say that the Truck class has 19 or fewer attributes and no subclasses, so itcounts as one record element. That means it needs seven function points' worth of functionality to support it.

You do the same thing for the remainder of the stored data. Most of the classes will also have a function point count of seven, as none of them should have more than 19 attributes. Weather Station is the only class to have subtypes (we gave it two hypothetical subtypes), but it would have fewer than 19 attributes, and so would account for seven function points. There areeight classes in the stored data model, so the aggregate count for the internal stored data is 56 function points.

Externally Stored Data

Most pieces of work make use of data that is stored and maintained outside of the work. For example, almost every project has to reference stored data that is owned by some other part of the organization or, in some cases, by another organization.

References to external stored data show up on the context diagram as interactions with cooperative adjacent systems. These adjacent systems receive requests for data and send back a response. The IceBreaker work, for example, uses thermal maps that are maintained by an outside body. When the scheduling business use case needs this data, it makes a request for themap of the appropriate district, and the thermal map supplier responds withthe requested information. This interaction is shown in Figure C.7.

Figure C.7.

The Thermal Mapping Supplier is an external system that maintains a database of the temperature differentials within areas. This data is too volatile for the IceBreaker work to maintain, so it elects to query this cooperative adjacent system whenever it needs the data.

Although externally stored data does not have to be maintained by the work, the need for the data adds functionality to the work. Thus it, too, is counted. You make this count the same way as you did for the internal data. However, instead of building a data model, this time let's use educated guesses to size the data.

The stored data in this situation deals with the temperatures of roads. It gives the road-surface temperature for every meter of every road. However, even though the data is repetitive, you count it as a single iteration only.

No, don't even count. As you see in Table C.5, once again you merely need to guess whether the number of attributes is 19 or fewer, 20 to 50, or more than 50. The thermal mapping database would fall into the first column. Further educated guesswork would say there are fewer than two record elementsit could have been as many as five without making any difference to the countand so this external data adds five function points to the functionality of the work.

Table C.5.

Function Point Counts for External Interface Files

You repeat this exercise for each of the classes in the externally stored data. For the IceBreaker work, there appears to be only one class in the database. This is a little unusual, but it can happen from time to time.

A small aside: Figure C.7 shows the use of externally stored data. The flows to and from the adjacent system are not counted for function point purposes, because the adjacent system is a cooperative system. That is, it provides some service in collaboration with the work area. Thus the flow to the external system consists of the parameters needed to query the database, and the resultant data flow to the work consists of data as stored by the external database. For both flows, their attributes would be the same as the stored data and are not counted. For function point counting purposes, think about the use of the adjacent system's database onlyin this case, it provides database access as if it belonged to the work area.