The Glossary: A Gateway to Clear Requirements and Communication

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.data modeling wordle

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, we cover glossaries in more detail in Data Modeling for Business Analysts – a virtual class covering the most critical data modeling techniques you need to know.)

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.

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

We’ve published a 10-article series on getting started with data modeling, where we are covering the most frequently asked questions business analysts have about applying data modeling techniques.

Click here to check out the articles

And also be sure to check out Data Modeling for Business Analysts, a virtual course where you’ll learn a structured approach for incorporating data modeling into your software development projects, even if you don’t have technical skills.

Free Training - Quick Start to Success

(Stop the frustration and earn the respect
you deserve as a business analyst.)

Click here to learn more

By signing up, you agree to our Privacy Policy.