Glossary · Business Analysis Notes

What it is#

The BABOK Guide describes a glossary as a list of key business terms with their definitions, whose purpose is to get stakeholders to agree on the vocabulary of a particular domain. In the BABOK Guide it supports Specify and Model Requirements.

Not every word belongs in it. The BABOK Guide suggests including a term when:

it is unique to the domain;
it has more than one definition;
its meaning in this domain goes beyond everyday use;
there is a reasonable chance it will be misunderstood.

Other sources add useful angles:

Wiegers and Beatty treat terms as their own category of business rules, alongside facts, constraints and computations, and suggest storing them where data definitions live, typically the data dictionary.
DAMA-DMBOK places the enterprise business glossary among the key metadata that data stewards create and maintain, so at enterprise scale a glossary needs governance, not just a document.
Golovach makes a glossary a step of interface design: list every term that appears on screen (buttons, menus, windows, modes), define the system’s concepts, then shorten, test with real users and make sure one concept always has one name.

A glossary differs from a concept model, which also shows how terms relate, and from a data dictionary, which defines data elements, formats and allowed values.

When to use it#

Start a glossary on almost every initiative, on day one. It matters most when:

the domain has jargon, abbreviations or legal terms;
different departments or sites use different words for the same thing;
an outside team, such as a vendor or offshore developers, is joining;
requirements, business rules or contracts will be written and tested.

The BABOK Guide notes the benefits: a shared reference point, consistency, and easier writing and maintenance of requirements, rules and change strategies. It also notes the difficulties: agreement on a single definition can be hard to reach, and a glossary goes out of date as the business changes unless someone maintains it.

Keep it lightweight on small, short projects where the team already shares the vocabulary; even then, a short list of a dozen terms often pays off.

How to do it#

Seed it early from documents, interview notes, screens and reports. Note who used each term and where.
Pick candidate terms using the four inclusion criteria above.
Draft definitions that say what the thing is, how it differs from similar things, and give an example. Avoid circular definitions.
Record synonyms as aliases pointing to one preferred term, and note look-alike terms to avoid confusing.
Resolve disagreements with the people who own the concept. If two meanings are both legitimate, give them two different names.
Publish it in one place that everyone can reach, and link to it from requirements documents and the backlog.
Use it. Check requirements, rules, test cases and screen labels against it.
Maintain it: name an owner, date each entry, and review it when processes or products change.

Example#

The Workshop (a fictional chain of bike-repair workshops) is building online booking and status notifications. Interviews show that “service”, “job” and “booking” mean different things to different people. Extract from the glossary:

Term	Definition	Aliases	Not to be confused with	Example	Owner
Booking	A reservation of a time slot at a workshop for a specific bike, made before the bike arrives	appointment	Repair order	Online booking for Tuesday 10:00	Front-desk lead
Repair order	The record of work on a bike, created when the bike is dropped off	job, ticket	Booking	Order for a brake replacement	Workshop manager
Service	A fixed-price maintenance package (basic, full)	tune-up	Repair (work priced by parts and time)	Full service	Owner
No-show	A booking where the customer neither arrives nor cancels before the slot starts	—	Cancellation	—	Owner
Ready for collection	Repair status meaning all work is done, tested and paid for or invoiced	done	Repair complete (work done, not yet tested)	—	Workshop manager

Writing these down exposes a real disagreement: one manager counted late cancellations as no-shows. The owner decides, the glossary records the decision, and the deposit and reporting requirements are written using these definitions.

Common mistakes#

Defining every word → include only terms that meet the inclusion criteria.
Circular or vague definitions (“Booking: the act of booking”) → say what it is, how it differs, and give an example.
One word with two meanings left in place → split it into two terms.
A glossary nobody reads → link it from requirements and use it in reviews.
Screens that use different words → check UI labels against the glossary, as Golovach recommends.
No owner → assign one and date every entry.

Template#

Template

| Term | Definition | Aliases | Not to be confused with | Example | Source | Owner | Last reviewed |
|---|---|---|---|---|---|---|---|
| | | | | | | | |

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.23 “Glossary”.
Watermark Learning. BABOK v3 Study Tables. 2016 (study aid for the BABOK Guide), technique 10.23.
K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013, ch. 9 (terms as a category of business rules).
DAMA International. DAMA-DMBOK: Data Management Body of Knowledge, 2nd ed. Technics Publications, 2017, ch. 3 (data stewards and the business glossary).
V. Golovach. User Interface Design, v1.2 (in Russian; freely distributed), part III “Process” (interface glossary).