Data Dictionary · Business Analysis Notes

What it is#

The BABOK Guide describes a data dictionary as a standard set of definitions for data elements, both on their own and in combination. It is sometimes called a metadata repository, and it usually accompanies an entity-relationship diagram or another data model: the model shows the structure, the dictionary explains each piece.

It covers two kinds of elements:

Primitive data elements — single values that are not broken down further. For each one you record a name, any aliases, the allowed values and what they mean, and a description.
Composite data elements — groups built from other elements. They can be a sequence (A followed by B), a repetition (A appears several times) or contain optional parts.

A compact shorthand, long used in structured analysis, makes composites easy to read: = means “is composed of”, + means “and”, { } marks a repeating group and ( ) marks an optional element.

In the BABOK Guide the technique supports Specify and Model Requirements: recording the definitions, relationships, origin, format and use of the data a change affects.

Wiegers and Beatty treat business terms as a separate category of business rules and suggest keeping them in the data dictionary, so the dictionary can also anchor your business-rule catalog.

When to use it#

Use it when:

several people build, test or report on the same data;
you are migrating data, integrating systems or building reports, where a single misread field breaks results;
fields have coded values (statuses, types) whose meanings must be stable;
you want consistent data across the organization.

Skip it, or keep it minimal, for a throwaway prototype. If the business still disagrees about what a word means, settle that first with a glossary or concept model.

Plan for the cost. The BABOK Guide notes that a dictionary takes real effort to build and maintain, goes out of date without regular care, and adds little value across the enterprise unless the metadata is designed with several uses in mind.

How to do it#

Start from what exists: the data model, screens, forms, reports and interface files.
List the elements and group them by entity or screen.
Define each primitive element: name, aliases, business description, type and format, length, allowed values with their meanings, default, whether it is mandatory, where the value comes from, and who owns it.
Define composites using the shorthand, so the structure of records and messages is explicit.
Link to rules. Valid values and derivations are often business rules; reference the rule rather than repeating it.
Review with data owners, developers and testers. Ask testers to try to misread each definition.
Publish one version in one place, put it under change control, and update it with every change to the data.

The training materials add a useful screen-oriented variant: for each field, record the screen section, display mode (grid or view/edit), input type, whether it is mandatory and the source of its values. It turns the dictionary into a direct brief for interface design.

Example#

The Workshop, a fictional chain of bike-repair workshops, is building online booking. Part of its dictionary:

Text

Booking      = Booking ID + Customer ID + Workshop ID + Time Slot Start
               + Bike Type + Contact Channel + Booking Status + (Customer Note)
Repair Order = Repair Order ID + Booking ID + {Repair Line} + Repair Status
Repair Line  = Spare Part ID + Quantity + (Labour Minutes)

Element	Aliases	Description	Format	Allowed values	Mandatory	Source
Booking ID	booking number	Unique identifier of a booking	“B” + 7 digits	—	Yes	System
Booking Status	—	Stage of the booking’s life cycle	Code	REQUESTED, CONFIRMED, CANCELLED, NO_SHOW, CONVERTED (became a repair order)	Yes	System
Time Slot Start	appointment time	Start of the reserved slot, workshop local time	Date-time, 30-minute steps	Within the chosen workshop’s opening hours	Yes	Customer
Bike Type	—	Kind of bike, used to estimate repair time	Code	ROAD, MTB, CITY, E_BIKE, CARGO	Yes	Customer
Contact Channel	—	Channel for repair-status messages	Code	SMS, EMAIL	Yes	Customer
Customer Note	problem description	Customer’s own words about the fault	Text, max 500 chars	—	No	Customer

When the team later argues whether a cancelled booking counts as a no-show, the dictionary already answers: they are different codes with different meanings.

Common mistakes#

Definitions that repeat the name (“Booking Status: the status of the booking”) → say what it means, when it changes and who changes it.
Codes without meanings → list every allowed value with its business meaning.
Several copies in spreadsheets → keep one controlled version and link to it.
Documenting only database columns → include elements in screens, reports and interface messages.
No owner → name a business owner for each group of elements.
Writing it once → update it as part of every change that touches data.

Template#

Template

| Element | Aliases | Description | Type / format | Length | Allowed values and meanings | Default | Mandatory | Source | Owner | Related rule |
|---|---|---|---|---|---|---|---|---|---|---|
| | | | | | | | | | | |

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015, technique 10.12 “Data Dictionary”.
Watermark Learning. BABOK v3 Study Tables. 2016 (study aid for the BABOK Guide), technique 10.12.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 9 (terms as a category of business rules).
Business analysis training materials (data dictionary template).