Quantity Fields

Having discussed fields intended to name record instances in Part 6 of this series, we move on to fields intended to satisfy the need to say something quantitative about a record. A quantity field requires particular attention be paid to its unit of measure (UoM) and precision.

NOTE: This article is Part 7 of Information System Data Fundamentals For Business Analysts. See Part 1 – Series Introduction for links to other articles in the series, plus definitions of the terms Information System, Record, and Field within the context of this series.

Numbers verses Quantities

There are fields whose values only contain numeric digits, such CREDIT CARD Number. There are others, such as PART Number, whose name implies that values are numbers, but in some organizations, values are allowed to include alphabetic characters. The objective of these types of field is actually to name or identify a record instance, not to quantify it.

A genuine quantity field has magnitude. A value can be numerically bigger, smaller, or the same as another value. If you double a quantity value (i.e. multiply it by 2), the resulting value is twice as big (unless of course the original value was zero). It would not make business sense to double a CREDIT CARD Number value or subtract one from another.

Unit(s) of Measure (UoM)

The following table contains types and examples of units of measure commonly used in relation to quantity fields.

NOTE: In the table above, ‘None’ represents types of quantities that are intended to be used in calculations but themselves have no unit of measure. E.g. An additional 10% discount, intended to be applied to the value contained in a PRODUCT Price field.

The unit of measure that applies to a given quantity field within a record context may be defined at:

• Organizational Level

• Record Level

• Field Level

• Record Instance Level

Organizational Level — An organization may deal in a single unit of measure for a given measurement type. For example, if the organization’s customers and suppliers are all local then dealings with them are always in one currency. In such situations, the unit of measure can be defined once, as an assumption or as a non-functional requirement. E.g. “All currency amounts represent US Dollars.”

Record Level — A record may contain a number of quantity fields that are of the same unit of measure type, and for any given instance, all of the quantities involving that UoM type will be of the same units. For example, an ORDER record with fields Net Amount, Tax, and Gross Amount all being in a given currency for a given order instance. Each of these fields can be identified as the “Currency” UoM type and a separate ORDER Currency field included to identify the specific currency that applies for a given order.

Field Level — A quantity field within a record can always involve values of the same unit of measure. E.g. TIME REPORTING Hours Worked. Even if the UoM is part of the field name, it should still be defined explicitly as a property of the field within a business data dictionary. (See  examples in Trips-R-You Case Study Data Dictionary)

Record Instance Level — In a record where a quantity field can involve a different UoM per instance, one or more additional fields will be required to identify the unit(s) that apply.  For example, a SERVICE CONTRACT record with the quantity field Charge-out Rate, where for one instance the rate can be in US Dollars per hour and for another instance Euros per day. In this example there would need to be SERVICE CONTRACT Currency field and a second SERVICE CONTRACT Time UoM field.

Precision

For most quantity fields, their precision can be specified as a number of decimal places required by the organization. E.g. integer indicating no decimal places, or cents for currency quantities, implying two decimal places. The following are examples of precision that require special attention:

Smallest Reportable Time Increment — Many time recording systems capture the time worked in hours and portions of an hour. Typically, those portions of hours are restricted to specific increments. If the portions are in units of minutes, the precision may actually be limited to increments of 15 (i.e. 0, 15, 30 or 45). If the hours being recorded allow decimal values, up to two decimal places are allowed, but the actual precision may be limited to quarters of an hour (.25, .5, .75).

Orders of Magnitude Quantities — Where a quantity field represents what an organization considers a very large amount, the precision can be defined as an order of magnitude. E.g. the value 1 intended to represent one million, or one billion. The order of magnitude quantity might also be defined to allow some number of decimal places, e.g. 1.3 indicating the value ‘one million, three hundred thousand’.

Value Sources

As with other types of data, quantity values can be provided from sources external to the organization or from internal sources. A third source, in the case of quantity fields, is derivations.

Externally-Sourced Values — Quantities that are sourced externally in real-time can be validated individually. The real-time process should be designed to deal with an invalid value, preventing the process from completing successfully if necessary. When batches of records containing quantities are received, the business needs to decide how it wants to deal with errors — either rejecting only those records that have problems or rejecting the entire batch.

Internally-Sourced Values — When a quantity is sourced internally, it is useful to identify the organizational role(s) that have responsibility for providing values. Some quantities, often price-related, are decided by product owners. Other quantities are simply part of an operational process, where staff members record values that come to them as part of the process. Where money is involved, and potentially large amounts, there is often a ‘separation of duty’ (SOD) process where a dollar value is entered by one person but required to be validated by a second person before the process is allowed to complete.

Derivable Values — Where two or more values from different quantity fields are used to produce a new value that quantifies a given record type, a quantity field should be defined within that record type to represent the derived value. E.g. ORDER Total Tax. The derivation should be described as part of that field’s definition.

NOTE: Derived fields represent values that are meaningful to the business. Designers are left to decide whether a derivable field value should be physically stored or system-derived as needed.

Both UoM and precision are important when defining a derivation. As the saying goes, “You can’t add apples and oranges.”

NOTE: Where derivations involve more than multiplying or dividing two or more decimal values, rounding can be an issue. Where and how to round is outside the scope of this article series.

Next Article – Part 8 – Classification Fields

Author: Dan Tasker

Dan is the author of over 30 requirements-related articles and other resources. His 45+ year career in Information Technology has involved organizations in a variety of industry sectors in the United States, Canada, Australia, and New Zealand. His business analysis experience includes projects involving in-house software development, software vendor solution development, and COTS software acquisition and implementation. He continues to be passionate about quality requirements and helping business analysts produce them. He can be contacted at [email protected].