An information system maintains data in fields within records. Equally important is the system’s ability to navigate between records. Parts 5 thru 9 of this series discussed fundamental business data field types. This article discusses a record navigation field. These fields do not themselves contain business data, but support the system’s ability to navigate from a given record instance to business data in related record instances.
NOTE: This article is Part 10 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.
Function-Oriented Data Navigation
Record navigation needs are discovered as part of detailed requirements elicitation for information system functional capabilities (see Minimum Detailed Requirements, Maximum Requirement Detail webinar). An information-related activity typically begins with finding a record instance of a specific type. When the activity involves data contained in a record related to the initial record, a record navigation field represents the need to reach that record.
For example, consider an activity that involves viewing existing ORDERs for a specific CUSTOMER. This activity would start by finding the desired customer record instance. To represent the need to access related orders, a CUSTOMER Order navigation field would be defined.
Data navigation needs can be visually represented by lines in an Entity or Class diagram. A single line typically represents navigation in two directions (e.g. a relationship line connecting CUSTOMER and ORDER implies navigation from either record to the other). See Simplified Data Models for further discussion of business activities and single-direction record navigation needs.
The advantage of using record navigation fields is that they are function-oriented – supporting business activity needs to access records from the context of an activity’s initial record context. Many properties applicable to data field types are equally applicable to navigation fields (see Fundamental Field Properties section below).
NOTE: How an information system accomplishes record navigation is a system design issue. A record navigation field may or may not end up as a physical field. If it does, the data it contains may or may not be meaningful business values. What can be seen are the meaningful business values contained in the fields of the related records.
Fundamental Field Properties
A fundamental field property specific to record navigation fields is its Target Record. E.g. CUSTOMER Order field explicitly identifying ORDER as the record navigation target from CUSTOMER records.
Additional fundamental field properties applicable to all field types discussed in this series are:
- Mandatory — Must there always be a value for this field? The answer could be ‘yes’, ‘no’, or ‘conditionally’. If conditionally mandatory, detailed requirement elicitation should include the condition(s).
- Minimum # of values — If the field can have more than one value at a time, is there a minimum number it should have? E.g. at least two forms of identification required for a customer.
- Maximum # of values – If the field can have more than one value at a time, is there a maximum number allowed? E.g. no more than 10 items checked out at the same time by a library member. The term “Many” is commonly used to indicate that there is no specified limit.
- Average # of values – Specifying an anticipated (average) number is useful to designers of screens and reports that display values, particularly if there is no stated maximum value.
- Historical values – ‘no’, ‘yes’, or an explicit number, where ‘1’ implies the need to know only the previously-current value.
- Future values – Similar to historical values but supporting the need to maintain one or more values intended to become current at a specific point in time.
- Audit Changes – Allows explicit fields (rather than whole records) to be identified for monitoring for value changes. Common in systems that deal with money.
NOTE: Within an information system, the need for auditing is different from recording history. Historical values are meant to support information needs of one or more operational business activities. Auditing is about the database management system keeping track of who changed values of specifically-identified fields and when. Accessing audit-log records is typically done only on an exception basis, with the help of operational IT staff.
A business-friendly data dictionary should support documenting property values for fields within their record context (see Managing Data-Specific Business Needs Using a Data Dictionary).
Series Take-Away Points
This series of articles has been about data fundamentals for information systems. Those fundamentals are summarized in the following take-away points.
- Information Systems have data-specific needs based on the business activities a given system is intended to support. [Part 2]
- Data-specific needs should be elicited as part of detailed functional requirements elicitation for a given business activity, using the business-friendly terms record and field. [Part 1]
- Record types for an organization’s management and support functions are generic across all industry sectors. [Part 2]
- An organization’s line of business, supported by information systems, has record types that are based on the concepts of Customer, Product, Sale, and Location. [Part 3]
- A field within the context of an information system record will have one of the following fundamental roles:
- Business Identifier [Part 5]
- Naming / Labeling [Part 6]
- Quantifying [Part 7]
- Classifying [Part 8]
- Point in Time [Part 9]
- Record Navigation [This article]
For an integrated set of examples of functional and data requirements for an information system, including records and fields documented using a business-friendly data dictionary, see the Trips-R-You Flight Booking Case Study.
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].