A classification field allows the recording of a meaningful fact about a record instance, with that fact drawn from a pre-established set of values. Online access to values applicable to a given instance might be through a drop-down or pop-up list, or as labelled check boxes or radio buttons. The organization may be interested in just the values, or there may be additional information about each value that the system needs to manage.
NOTE: This article is Part 8 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.
Self-defining Classification Field
A self-defining classification field is one where the fact it represents, within the context of its record instance, either applies or doesn’t apply. The value maintained by the information system is some form of true/false, such as Yes/No or Checked/Unchecked. The field’s label is expected to provide the business meaning for the classification. E.g. PASSENGER Has Valid Passport, PRODUCT Is Gluten Free.
It’s recommended that a self-defining classification field label represents the preferred business true condition (e.g. does hold a valid passport, is gluten free). This avoids users having to deal with a double negative. E.g. PASSENGER No Valid Passport would involve some form of a false (negative) response to indicate that a passenger does have a valid passport.
Meaningful-value Classification Field
A meaningful-value classification field, within the context of a record, is intended to contain one or more values from a pre-established set. The values in that set are expected to be meaningful/understandable withing the context of the organization. For example, a CUSTOMER Type field for classifying an organization’s customers as ‘Individual’, ‘Small’, ‘Medium’, or ‘Large’.
If the business need is simply for classification values to be selected based on the set of possible values, the classification field can be defined within its context record. The field definition should include example values or, where possible, the full set. If only example values are available, where or how the full set can be obtained should be identified. If, during detailed requirements elicitation, no stakeholder knows a viable source, it should be raised as a project issue to be resolved.
Classification Records
If there is additional information that needs to be associated with each classification value, then a classification record should be defined that contains a field for the classification value plus fields supporting the additional information. The original context record, instead of including a classification field, should have a record navigation field that points to one or more classification record instances. See Part 10 – Record Navigation Fields.
For example, for the CUSTOMER Type field described above: If the classification was based on defined ranges of number of employees, there would need to be something like a CUSTOMER TYPE record for managing instances of classification values accompanied by values specifying lower and upper employee number limits. E.g. the ‘Medium’ classification value being defined as a customer having between 15 and 100 employees. Instead of the CUSTOMER Type field defining a set of valid classification values, that field supports each customer instance’s ability to navigate to the appropriate CUSTOMER TYPE record instance.
NOTE: How a classification value set is maintained within an information system is a design (or system architecture) issue. The business need is only for instances of the context record to be classified based on a pre-established value set. If those values involve associated information, the business need is for that additional information to be maintained for each value.
Value Set Naming
Some information system value sets have a natural, business-friendly term that can be used to name the classification field. Examples include Color, Size, and Gender. When there is no natural term that is representative of a set of classification values, the field (or classification record) is likely to be named using a generic term such as type, class, or category (e.g. CUSTOMER Type, PRODUCT Category, SERVICE Class).
Whether a value set has a natural or generic name, it’s important that the field or record definition includes sufficient sample values to make the business need clear.
Derivable Classifications
When a classification value (or applicable classification record instance) can be derived using system-definable business rules and system-managed data, those rules should be described as an additional part of the classification field definition.
For example, for the CUSTOMER Type classification field with associated classification record discussed above: If a CUSTOMER Number Of Employees field has also been defined, the CUSTOMER TYPE record associated with each customer could be derived using the customer type from/to employee number fields. The details of the CUSTOMER Type field should include an indication that its values are derivable. That derivation, including the fields involved, should be part of the classification field definition.
Next Article – Part 9 – Point In Time 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].