A Glossary is a deliverable that documents terms that are unique to the business or technical domain. A glossary is used to ensure that all stakeholders (business and technical) understand what is meant by the terminology, acronyms, and phrases used inside an organization.
While creating a glossary can take a bit of time and attention, doing so will generate many benefits, such as:
- Facilitate learning about a new business domain, by keeping terminology variations and acronyms straight.
- Clarify your requirements documents, by providing clear definitions of the important terms used inside them.
- Save time in requirements meetings, since stakeholders will be using a common language.
- Encourage more effective communication among stakeholders, by resolving terminology disagreements.
- Pave the way for data modeling and database designs that accurately reflect true business requirements.
As we’ll see, creating a glossary is the first step to achieving these benefits. The second is encouraging the use of the glossary terminology. You’ll receive tips for both steps in this article.
(By the way, if you are looking to learn more about data modeling, be sure to check out our Free Data Modeling Training.)
The Key Elements of a Glossary
In its essence, a glossary is a list of terms, with accompanying definitions, and is not unlike a dictionary. However, unlike a dictionary, a glossary contains only terms that are unique to a business domain or uniquely used within that business domain.
For example, although “customer” is a commonly used word, it might also be a term in your glossary as it’s not uncommon for different business stakeholders to have different definitions of what a customer is.
Let’s look at the key elements of a glossary:
- Terms – This is the unique words or short phrases that are part of business conversations. Typically terms are nouns – or persons, places, or things.
- Definitions – Provides the exact meaning of a term in an unambiguous way and clarifies the boundaries of when the term can appropriately be used in communication.
- Alias – A word, phrase, or acronym that is used interchangeably with the primary term in your glossary.
- Related Terms – References to separate terms in your glossary which are similar to, but not interchangeable with, your primary listed terms.
Often business analysts focus on documenting lengthy glossaries that capture all possible terms used inside an organization. While hefty, these documents are rarely as useful as they feel (although they can help the business analyst tremendously in getting up to speed in a new business domain). Next let’s consider some tips for using a glossary to clarify communication.
For a quick view of why this is all so important, check out this video on the challenges created by the inconsistent use of terminology:
Using a Glossary to Clarify Communication
If we agree that the purpose of a glossary is to encourage consistent use of terminology by stakeholders and clarify requirements, then we’ll quickly realize that the glossary is only the beginning. A glossary is your reference tool and a way to capture terms, definitions, and variations as they come up in your requirements meetings.
Just as important, however, is that you encourage the consistent use of terminology. Here are a few tips for doing so:
- Use the terms consistently – absolutely consistently – in your requirements specifications, as even small variations can cause confusion. (Out of the hundreds of requirements documents I’ve reviewed, inconsistent use of terminology is one of the most common mistakes I see.)
- During requirements meetings, clarify unfamiliar or new terms before moving on. Doing so will often save lots of time resolving other requirements-related conflicts between stakeholders, as often these boil down to varying definitions between terms.
- Encourage the use of business terminology in data models by bringing forward business terminology into your ERD (Entity Relationship Diagram and Data Dictionaries. Often these documents use technical language that is confusing to business stakeholders, and technical terms can be helpfully included as aliases in your glossary.
With persistence and consistent use of glossary-based terminology, your stakeholders will start communicating more effectively, your requirements specifications will be better understood, and your data modeling will be easier.
>>Learn More About Data Modeling (Free Training)
Learn the essential Data Modeling Techniques (even if you don’t know how to code) with this free training.
