Requirements In Context Part 5 – Managing Data-specific Business Needs Using a Data Dictionary
The previous article in this series discussed ensuring that High-Level Requirements (HLRs), within the context of an IT-based project, were properly high level. The remainder of articles in the series will look at detail requirements and the need for them to be sufficiently detailed. The objective of this article is to demonstrate how a data dictionary (DD) can be used as a tool for capturing the appropriate level of detail representing data-specific business needs.
NOTE: This series uses the terms ‘High-level Requirement’ (HLR) and ‘Detail Requirement’ - intended to correspond to the IIBA® BABOK® V3 terms ‘Stakeholder Requirement’ and ‘Solution Requirement’.
The following questions are addressed in this article:
- What are data-specific business needs?
- How might these needs be represented in a DD?
- How does a DD differ from a data or class model?
- What details should be captured?
- What is the role of a DD in relation to detail requirements?
The remainder of the articles in this series draw examples from the Trips-R-You Flight Booking Case Study. The objective of the case study is to present an example of an integrated set of high-level and detail requirements. Accompanying the case study is the MS Excel-based Trips-R-You Data Dictionary. It contains the data-specific business needs related to those requirements.
What are Data-specific Business Needs?
The primary objective of business information systems is to support business processes. These systems do this by utilizing five basic functional capability types – user interfaces, data importing and exporting, reports, and automated functions. These capability types were discussed in Part 4 of this series, in relation to HLRs.
Function-specific business needs are addressed by one or more of these capability types. Data-specific business needs are addressed by the system being able to manage data involved in those functional capabilities. In this context, ‘manage’ means:
- Provide persistent storage - available for the different types of data needed by users of the system, irrespective of functional capabilities that source, update, or reference that data
- Validate sourced data - irrespective of functional capabilities that support its sourcing or updating
- Derive new data from data available within the system
Most business information system users think of their data as records and fields. Representing data-specific business needs in a DD involves adding or updating entries that represent either a type of record or field. Fields are intended either to hold data or reference another record. A reference allows the record to access fields of the related record type.
NOTE: The Data Dictionary used with the Trips-R-You case study, to be business-friendly, uses the terms ‘Record’ and ‘Field’. Within the context of this series of articles, those terms should be considered equivalent to the logical data terms ‘Entity’, ‘Attribute’, and ‘Relationship’.
Representing Data-specific Business Needs in a Data Dictionary
The best way to demonstrate capturing data-specific business needs in a DD is with an example. In the previous article the following ‘requirement’ was discussed:
Each Customer record must be assigned a unique identifier.
Reasons were given as to why this requirement (found in an actual signed-off HLR document) was considered to be too detailed to be an HLR. The recommendation was to ‘note’ such details for revisiting during detail requirements elicitation.
For this example, the appropriate time to revisit the note would be when discussing the functional capability (e.g. a user interface) intended to support the business process of adding a customer. The data-specific business needs that statement was trying to represent turned out to be the following:
- There needs to be Customer records.
- That type of record needs a field (agreed to be called “ID”), that will be a numeric business identifier for Customers.
- “Assigned” (within the context of the note) was confirmed by the stakeholders to mean ‘automatically generated by the system’.
- The need for identifier values to accommodate 2,000 new customers per year over the next 10 years, in addition to the existing 10,000 customers currently identified.
These needs can be captured using the Data Dictionary with one entry representing the Customer record and a second entry representing its ID field. The specific DD columns used to capture those needs are:
Current Volume and Estimated Growth Rate, sourced from business subject matter experts (SMEs), are necessary to support capacity planning - a non-functional requirement. In this case these values also provide an indication to database designers of how big the ID field needs to be.
The Source(s) property for the ID field indicates that values are expected to be derived by the system rather than manually entered. This implies that a derivation function will be needed.
The Participates in Unique Business Identifier property relates to the uniqueness need - again useful to the database designer in making decisions about primary keys.
Data Dictionary vs Data / Class Model
There is no question that a data or class model is a picture worth a thousand words (to people who understand the meaning of the boxes, lines, and symbols used). The documented representation of a graphical model, in tabular form, can be considered a basic form of DD. For comparison purposes, we will look at an example of data-specific business needs represented both as a data / class model and using the Trips-R-You Data Dictionary.
The example involves a field representing the Status of a Customer. The field is involved in several different business processes that reference or update its value. The result of discussions with stakeholders, within the context of functional capabilities supporting those processes, was that most of those processes only needed the customer’s current status. However, one needed access to previous values. And another needed to be able to set a future value. The combined data-specific business needs related to a Status field within Customer therefore are:
- A Customer needs to have a single value for Status effective at any given point in time.
- Previous values need to be kept.
- One future value can be recorded.
- The set of valid Customer Status values is owned by Customer Care and is to be maintained in the system on their behalf by users with System Admin authority (following a change management procedure).
Based on these needs, Status, along with an Effective Date, is a repeating group. Because data and class models typically do not support an entity or class containing a multi-valued field or group, a separate entity/class is added to the model, with a one-to-many relationship to it (see below). Also, where a value set needs to be ‘maintained’ in the system, via user interface or data import, the value set is also represented by its own entity/class.
These combined needs, viewed in a data or class model, might look like this:
Let’s now look at those same needs captured using two entries in the Trips-R-You Data Dictionary:
The Status DD entry above is an example of a relationship rather than an attribute. It indicates that the Status value is sourced from the CUSTOMER STATUS value set. This corresponds to how system users ‘see’ value set-based fields (e.g. as a ‘dropdown’ list).
The reason that Status can be captured as a field within Customer is that the DD includes individual columns to represent multi-value needs, including historical and/or future values. With these needs captured, a database designer is left to add any additional database tables needed and fields related to effective dates.
Details Captured in a Data Dictionary
The two examples presented above have demonstrated how different aspects of data-specific business needs, such as uniqueness or the need to support history, can be represented as specific columns within the DD’s tabular format. The general rule of a DD is, “If there isn’t a dedicated column for something, then that something is described using the ‘Comments’ column.” Too many columns make the DD difficult to use and review - too few and important aspects get buried in text.
The dedicated columns included in the Trips-R-You Data Dictionary are intended to hold details of data-specific business needs that are useful to designers, developers, testers, technical writers, and trainers. For cases where there is no specific column representing a type of need, there is still a ‘Comments / Other Business Rules’ column.
Ideally a DD tool helps deal with offering lots of property-specific columns (25-ish for the Trips-R-You template) by presenting only those applicable to a given entry type. The Trips-R-You Data Dictionary accomplishes this by greying out unneeded cells for a given row, based on further classifying record and field entry types into the following sub-types:
- Entities – Primary Record, Record Sub-group, Value Set, Field Set
- Attributes – Label, Quantity, DateTime, True/False Value, Description, File
- Relationships – Related Data, Value Set Reference, Field Set Usage
NOTE: See the Trips-R-You Data Dictionary regarding the purpose of each column and examples of entries involving each of the entity, attribute, and relationship subtypes.
Data Dictionary Information vs Detail Requirements
Utilizing a data dictionary to capture data-specific business needs is intended to replace individual detail requirements representing those needs (as demonstrated in the examples in this article). The contents of the DD still needs to be reviewed and signed off. But its tabular format, reducing the need for textual descriptions, is intended to make those tasks easier.
Individual DD entries do not need prioritizing (e.g. the MoSCoW scheme), as is the case with individual requirements. Nor would they be individually moved in or out of a project’s scope. This is because the priority and delivery of data-specific business needs are based on the functional capabilities that reference them. The priority of a DD entry is tied to the highest priority of the [in scope] functional capabilities that involve the entry. Similarly, an entry is in scope if utilized by at least one in-scope functional capability.
A DD would ideally be used by multiple projects. If so, entries must be change-managed. For a given project, entries that represent new or updated data-specific business needs for persistent data can be represented by a single transitional requirement (the IIBA® BABOK® V3 term), such as the following:
The system shall be able to store, update, and retrieve records, and the fields they contain, as identified in the Data Dictionary - Version N.N dated dd mmm yyyy.
The reason just one requirement is needed is that a new or updated database schema is a single deliverable. It needs to be implemented in time for the development of the functional capabilities to begin.
End of Overview
Hopefully this article has achieved its objective of demonstrating how a data dictionary can be used as a tool for representing the appropriate level of detail associated with data-specific business needs. This article has touched on some, but not all, DD concepts. If what has been demonstrated makes sense, the reader is encouraged to spend additional time with the Trips-R-You Flight Booking Case Study and examples the Trips-R-You Data Dictionary contains.
The next article in the series looks at the need for detail requirements for user interfaces and reports to be sufficiently detailed. Additional Trips-R-You templates specific to each of these capability types will be discussed.
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].