This is the first of a series of articles intended to help business analysts deal with the information aspect of information systems during requirements elicitation. Requirements are commonly categorized as either functional or non-functional. Given only these two choices, data requirement details are typically included as part of functional requirements. Some may be recorded separately as business rules. By focusing on data fundamentals for information systems, this series hopes that business analysts will be better able to recognize data-specific needs and document them accordingly.
Series Terminology
This series uses the terms record and field rather than the traditional logical data terms entity (or class) and attribute. Business analysts are encouraged to use these more business-friendly terms during requirements elicitation.
Information System – A collection of software capabilities that support activities within one or more functional areas of an organization. That support includes maintaining activity-related information in a database management system.
Record - A business-meaningful grouping of fields. E.g. CUSTOMER, ORDER, ADDRESS.
Field - The smallest business-meaningful unit of data within the context of a record. E.g. ORDER Number, Estimated Delivery Date, and Total fields.
NOTE: In addition to examples of records and fields presented in this article series, a unified set of examples based on eliciting detailed functional requirements for the Trips-R-You Web-Based Flight Booking Case Study can be seen documented using a business-friendly data dictionary.
Series Articles
Part 2 – Organization-Independent Records – There are functions common to all organizations, such as Budgeting, Human Resources, and Accounting. The types of records needed for an information system to support such functions are also common across organizations, e.g. BUDGET, POSITION, GL ACCOUNT. This article discusses these functions and their organization-independent records.
Part 3 – Line-of-Business-Specific Records – In this article and the next, records specific to an organization’s line(s) of business are discussed. These records support maintaining data for an organization’s Products, Customers, Sales, and sale-related Locations. These fundamental data concepts are defined and discussed within the context of line of business-independent functions (e.g. Marketing, Sales).
Part 4 – Product, Customer, Sale, and Location Records – This article discusses records based on the fundamental data concepts product, customer, sale, and location introduced in Part 3. The names given to these records varies depending on the line(s) of business an organization is in and, in particular, sales processes specific to the organization.
Part 5 – Identification Fields – This fifth article in the series moves the discussion of fundamental data concepts from record level to field level. It’s appropriate to begin with identification fields because most business activities supported by an information system begin by using an identification field value to find a specific record instance. For example, the customer identified by CUSTOMER ID field value ‘123456’.
Part 6 – Name Fields – In addition to fields that uniquely identify record instances, a record may have one or more fields to hold name data. Customer, product, and location records will each have one or more names that need to be managed. Some name values come from sources external to the organization. Some records represent things internal to an organization, such as GL ACCOUNT and WAREHOUSE records. Instance names are sourced from within the organization.
Part 7 – Quantity Fields – Business activities supported by an information system frequently involve quantitative data. Fundamental to the definition of a quantity field are its unit of measure and precision. This article discusses these concepts. For example - a quantity field’s UoM may be explicitly defined or may depend on another field that identifies the UoM for each record instance.
Part 8 – Classification Fields – This article discusses fields that involve a pre-established set of values (e.g. CUSTOMER Type, ORDER Status). Requirement elicitation involves establishing a business-meaningful name for the field plus some or all of the applicable values. Where classification values have associated details, a classification record may be needed for containing value instances.
Part 9 – Point-In-Time Fields – This article discusses points in time data concepts as a special type of quantity fields. It covers date, time (of day), combined date/time fields. Also discussed is the concept of time periods, typically defined based on a pair of point-in-time fields.
Part 10 – Record Navigation Fields – This article discusses a record navigation field. Parts 5 – 9 of this series discussed types of fields intended to hold data values for a given record instance. Navigation fields are used to represent a business need for the information system to support accessing data contained in other records related to a given record instance. This article also includes a summary of the overall series.
Related Articles By Dan Tasker
- Requirements In Context. – A 10 part series about functional requirements for an information system. Part 10 of the series describes the management of functional and data requirement details using a requirements management tool. Examples of three such tools supporting this detail are presented.
- Trips-R-You Web-Based Flight Booking Case Study – Presents both functional and data requirement examples discussed in the Requirements In Context article series. The requirements are documented using spreadsheet-based templates. The example data requirement details are documented using a spreadsheet-based business-friendly data dictionary.
Next Article: Part 2 – Organization-Independent Records
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].