A data dictionary is a structured list of data elements with their names, aliases, allowed values and meanings, and descriptions. In the data dictionary BABOK technique (section 10.12 of the BABOK Guide v3), its purpose is to standardise how each data element is defined so every stakeholder reads it the same way [1]. For the Certified Business Analysis Professional (CBAP) exam, know two element types: primitive and composite.
Why the data dictionary matters on the CBAP exam
The data dictionary matters because CBAP questions test whether you can pick the right model for the job, and this one is the right pick when the problem is inconsistent data definitions. The exam has 120 case-study and scenario-based multiple-choice questions in 210 minutes [2].
| CBAP fact | Detail |
|---|---|
| Questions | 120 case-study and scenario-based multiple-choice |
| Time | 210 minutes |
| Experience required | 7,500 hours in the last 10 years |
| Technique section | BABOK Guide v3, 10.12 Data Dictionary |
Last verified: October 2026, on the IIBA CBAP page and the IIBA KnowledgeHub.
Our map of all 50 BABOK techniques by knowledge area places Data Dictionary under task 7.1, next to Data Modelling (10.15) and Glossary (10.23). Expect scenarios where two teams use the same field name with different meanings, or where developers and testers disagree on what values a field may hold.
Data dictionary BABOK elements: what the guide says
The BABOK Guide describes a data dictionary through its data elements, split into primitive and composite ones. The full section text sits behind an IIBA member login, so the element names below are checked against two independent study summaries of 10.12 [3, 4].
Primitive data elements
A primitive data element is a single item that is not broken down further, such as a date of birth or an order status. Each one is described with four pieces of metadata [3]:
| Metadata | What it records | Example for "Order Status" |
|---|---|---|
| Name | A unique, meaningful name | Order Status |
| Aliases | Other names stakeholders use for the same element | Fulfilment state, Order stage |
| Values/Meanings | Data type, size and the list of allowed values with what each means | Text, 12 chars; NEW = placed, not paid; PAID; SHIPPED; CANCELLED |
| Description | Context for this project: definition, rules, notes | Set by the payment and warehouse systems; never edited by agents |
Composite data elements
A composite data element is built from primitive elements [3]. The BABOK Guide names three ways to combine them: sequences, repetitions and optional elements [4]. Study summaries use a compact notation for them [3]:
| Structure | Meaning | Notation |
|---|---|---|
| Sequence | Elements that always appear together, in order | A + B + C |
| Repetition | An element that can occur many times | { A } |
| Optional element | An element that may be absent | ( A ) |
Strengths and the main caution
Study summaries list two strengths: stakeholders share an understanding of the format and content of information, and a single repository of metadata supports wider use of data across the organisation [4]. The main caution is scope. A dictionary is built for a context such as a project, and entries nobody needs add little business value [3].
How it relates to the glossary and data models
A data dictionary defines data elements, a glossary defines business terms, and a data model shows how data objects relate. The three overlap, which is why exam questions like to mix them up.
| Technique | BABOK section | Defines | Typical audience |
|---|---|---|---|
| Glossary | 10.23 | Key terms of a business domain [5] | All stakeholders |
| Data Modelling | 10.15 | Entities, their attributes and the relationships among them [6] | Analysts, architects, developers |
| Data Dictionary | 10.12 | Each data element: name, aliases, values and meanings, description [1, 3] | Analysts, developers, testers, data teams |
One requirements author puts the link simply: the entity relationship diagram gives the high-level view, and "the data dictionary supplies the details" [7]. A typical flow is to model the entities first, then record each attribute in the dictionary, and point both at the glossary for business meaning. We will compare the dictionary and the glossary in a separate article.
A worked example: an online grocery order
The best way to learn the technique is to write a small dictionary. Assume a grocery delivery app where the support team, the warehouse and the finance system each describe orders differently.
| Name | Aliases | Type | Values/Meanings | Description |
|---|---|---|---|---|
| Order ID | Order number, Ref | Primitive | 10 digits, system generated, unique | Shown to customers on receipts and emails |
| Order Status | Fulfilment state | Primitive | NEW, PAID, PICKING, SHIPPED, DELIVERED, CANCELLED | Only the payment and warehouse systems change it |
| Delivery Slot | Time window | Primitive | Date + 1-hour window, 08:00 to 22:00 | Must be at least 2 hours after checkout |
| Substitution Allowed | Swap OK | Primitive | Y = picker may replace, N = remove item | Default Y; customer can change per line |
| Order Line | Basket item | Composite | Product SKU + Quantity + Unit Price + (Substitution Allowed) | Quantity 1 to 99 |
| Delivery Address | Ship-to | Composite | Street + City + Postcode + (Apartment) + (Courier Note) | Postcode must be inside the service area |
| Order | Basket, Purchase | Composite | Order ID + Customer ID + Delivery Slot + Delivery Address + {Order Line} + Order Status | At least one Order Line |
Three things happen once this table exists. First, the alias column shows that "Basket" means an order to support agents but an unpaid cart to the web team, a conflict worth raising early. Second, the composite rows tell testers what must be present and what may be missing. Third, the description column holds business rules, which you can trace back to a rules catalogue using business rules analysis.
Practitioners extend this layout. One consultant adds columns for current volume, growth rate, data source and whether a field is part of a unique business identifier, ending up with about 25 columns [8]. Others keep only name, optional or required, and type, with extras added when needed [9].
What happens in real practice
In practice, data dictionaries are common, but the work often moves from business analysts to data teams and tools. The evidence is uneven, so treat each figure as a signal rather than a measure.
| Signal | What it shows |
|---|---|
| Survey of 202 American Statistical Association members, 2024 [10] | 73.3% create a data dictionary to describe their data; only 22.2% create metadata consistently |
| UK permanent IT job ads citing data mapping, 6 months to 11 October 2026 [11] | 151 ads; 41 of them (27.15%) for Business Analyst roles and 18 (11.92%) for Technical Business Analysts |
| UK permanent Business Analyst ads, same period [12] | 1,519 ads; SQL in 8.82%, data quality in 3.36%, metadata in 0.79%; "data dictionary" is not tracked as a separate skill |
The pattern is clear: people build dictionaries, but fewer keep the metadata up to date. Job ads rarely name the technique; they ask for the surrounding skills, such as data mapping and SQL.
Ownership is the other shift. A data analytics consultancy describes the dictionary as a tool mainly for technical users, owned by a governance committee where the business requests changes and IT applies them [13]. The same article separates it from a data catalog, which it calls an inventory of data assets showing where data lives and who can use it [13]. In larger organisations, this is where data catalog and governance tools come in.
Keeping dictionaries current is the problem every source raises:
- A BA consultancy team warns that a dictionary must be maintained to stay useful [14].
- An analytics consultancy founder says not to start documenting until someone is named to keep it updated, and he reviews his own every two weeks [15].
- A 2026 opinion piece on data catalogs argues that a static catalog nobody maintains goes stale within weeks, and recommends pulling metadata automatically from pipelines [16].
- A requirements consultant with more than 50 years in IT says a dictionary shared by several projects must be change-managed [8].
Experts disagree on the data dictionary
Practitioners agree on what a data dictionary contains, but not on who it is for or how much it should replace.
1. It is a requirements artefact owned by the BA. Requirements consultants treat the dictionary as part of the specification. One argues that data requirements can live in a requirements-friendly dictionary instead of in user stories or use cases, with each entry given an ID, priority and status [17]. Another says dictionaries help align data requirements between systems [7].
2. It is a technical document for builders. A BA consultancy writing about business intelligence (BI) work says the dictionary is meant for a technical audience and should not be confused with a business glossary [14]. A data consultancy holds the same view [13]. This sits uneasily with the BABOK framing of shared understanding for all stakeholders [4].
3. It should merge with the glossary. An analytics consultancy founder reports that in many teams the "dictionary" is a hybrid of dictionary and glossary, which cuts upkeep, and openly invites other data experts to push back [15]. Position 2 argues the opposite: keep the two apart.
4. It is worth the upfront cost for beginners. A requirements consultancy calls dictionaries "a very useful model for beginning business analysts" because filtering the table exposes missing rules, while admitting the upfront cost in time can be high [18].
5. It belongs in a tool, not a spreadsheet. Data practitioners argue that manual dictionaries fail and metadata should be captured automatically [16]. Others still use spreadsheets because they are cheap and familiar [15, 9].
Common misconceptions
Most mistakes come from treating the dictionary as another name for a nearby technique.
- "A data dictionary is the same as a glossary." A glossary defines business terms; a dictionary defines data elements with values and structure [5, 3].
- "It is the database schema." A schema is a physical design. The BA's dictionary records business meaning and allowed values, often before any database exists [9].
- "Composite elements are just long fields." A composite is built from primitive elements as a sequence, a repetition or an optional part [4].
- "Write it once and you are done." Every practitioner source above treats maintenance and ownership as the hard part [14, 15].
- "More entries mean a better dictionary." Entries outside the context of the change add little value [3].
Practice Questions
These are original questions in the CBAP scenario style.
Question 1. During requirements review, the billing team reads "Customer Status = Inactive" as "no purchase in 12 months", while the marketing team reads it as "unsubscribed from email". Developers ask which rule to build. What should the business analyst do FIRST?
A. Add both meanings to the glossary B. Record Customer Status in a data dictionary with agreed values and meanings C. Build a data flow diagram for the customer domain D. Ask the sponsor to choose one team's definition
Answer: B. The conflict is about the allowed values and meanings of one data element, which is what a data dictionary standardises [1]. A glossary (A) defines terms but not value sets. D skips the analysis and the stakeholder agreement.
Question 2. A business analyst records "Shipping Address = Street + City + Postcode + (Apartment)". What does the part in parentheses show?
A. A repetition B. A primitive element with an alias C. An optional element D. A calculated value
Answer: C. In the notation study summaries use for composite elements, parentheses mark an optional element, braces mark a repetition, and the plus sign marks a sequence [3].
Question 3. A business analyst is defining the metadata for the primitive element "Delivery Slot". Which set of attributes matches the BABOK Guide's description?
A. Name, aliases, values and meanings, description B. Owner, priority, status, version C. Entity, relationship, cardinality, key D. Source, target, transformation, frequency
Answer: A. Those four describe a primitive data element [3]. B is requirements attribute data, C belongs to data modelling, and D describes data mapping.
Conclusion: the gap between BABOK and real data dictionaries
BABOK describes a shared, stakeholder-wide definition of data, while practice splits the work between analysts, data teams and catalog tools.
| Area | Standard | Reality | Delta |
|---|---|---|---|
| Content | Name, aliases, values/meanings, description; primitive and composite elements [3] | Teams add type, length, required, unique, source, volume [7, 8] | Added by employers |
| Audience | Shared understanding for all stakeholders [4] | Often written for technical users [14, 13] | Reduced to a technical reference |
| Maintenance | Single repository of metadata [4] | Fewer people keep metadata current than create dictionaries [10] | Under-used |
| Ownership | Business analyst within the change | Governance committees and named owners [13, 15] | Added by employers |
| Visibility in job ads | Core BABOK technique | Ads ask for data mapping, SQL, data quality instead [11, 12] | Reduced to adjacent skills |
For the exam, answer in BABOK terms: the dictionary standardises data elements, primitives carry four kinds of metadata, and composites combine primitives. At work, the technique only pays off when someone owns it, it is scoped to the change, and it is linked to the models and rules that use it.
Related topics
- Specify and model requirements: where the dictionary fits among other models.
- Requirements architecture: how models and dictionaries fit together into one view.
- Traceability of requirements: linking data elements to the requirements that use them.
- Business analysis information management: planning where artefacts like the dictionary live and who maintains them.
- Practise scenario questions in the CBAP exam simulator.
FAQ
What is a data dictionary in business analysis?
A data dictionary is a list of data elements with standard definitions, so everyone reads each element the same way. In BABOK Guide v3 it is technique 10.12. Each primitive element is described by its name, aliases, values and meanings, and description.
What is the difference between primitive and composite data elements?
A primitive data element is a single item that is not split further, such as a postcode. A composite data element is built from primitives as a sequence, a repetition or an optional part. An address made of street, city and postcode is a composite.
Is a data dictionary the same as a glossary?
No. A glossary defines key business terms for all stakeholders. A data dictionary defines data elements, including their allowed values and structure. The two should reference each other but answer different questions.
Who maintains the data dictionary?
In BABOK terms, the business analyst creates and uses it within a change. In practice, larger organisations hand ongoing ownership to data governance groups or named owners, often supported by data catalog tools.
Does the data dictionary appear on the CBAP exam?
Yes, as one of the 50 techniques in the BABOK Guide. Expect scenario questions where inconsistent data definitions are the problem, and where you must tell the dictionary apart from the glossary, data modelling and data flow diagrams.
Sources
- BABOK Guide v3, 10.12 Data Dictionary (IIBA KnowledgeHub)
- Certified Business Analysis Professional (CBAP) (IIBA)
- Mastering Data Dictionary: CBAP tutorial on the BABOK technique (Techcanvass, 2025)
- BA Techniques: Data Dictionary (Fhyzics, 2020)
- BABOK Guide v3, 10.23 Glossary (IIBA KnowledgeHub)
- BABOK Guide v3, 10.15 Data Modelling (IIBA KnowledgeHub)
- Has Anyone Seen My Data? Guest post by Karl Wiegers (The Data Pub, 2023)
- Managing Data-Specific Business Needs Using a Data Dictionary (Modern Analyst)
- What is a Data Dictionary? (Bridging the Gap, 2015)
- Data Management Survey of ASA Members (Amstat News, 2024)
- Data Mapping jobs, UK, 6 months to October 2026 (ITJobsWatch)
- Business Analyst jobs, UK, 6 months to October 2026 (ITJobsWatch)
- Data Dictionary vs. Data Catalog vs. Business Glossary (Analytics8, 2021)
- How to Use Data Dictionaries to Model and Analyze BI Requirements (NRI North America, 2019)
- Why Your Data Team Needs a Bulletproof Data Dictionary (Rooftop Insights)
- Data Catalogs Haven't Failed, You Just Implemented Them Like It's 2019 (DATAVERSITY, 2026)
- Requirements-Friendly Data Dictionary 2.0 (Modern Analyst, 2025)
- For Beginning Business Analysts: Software Requirements and Data Dictionaries (ArgonDigital)