BA Technique: Glossary — Real World Example and Free Template

What Is a Glossary in Business Analysis?

A glossary is a business analysis technique that captures the key terms relevant to a specific business domain, along with their definitions and synonyms. It gives every stakeholder — from business users to developers to testers — a single, shared reference point for what a term actually means within a project.

Without a glossary, the same word can carry different meanings for different people. A "defect" might mean one thing to a QA engineer and something else to a business user. A glossary removes that ambiguity by documenting one agreed-upon definition for each term, making it easier for teams to communicate, write requirements, and avoid costly misunderstandings.

Quick Answer: When Should a Term Be Added to a Glossary?

A business analyst should add a term to the glossary when it meets any of the following conditions:

• The term is unique to the domain, or it has multiple definitions.
• The term's commonly used (everyday) meaning is different from how it's used within the domain.
• There is a reasonable chance the term could be misunderstood by stakeholders.

If a word is unambiguous and universally understood the same way, it usually doesn't need a glossary entry.

Why Glossaries Matter: Strengths

A well-maintained glossary delivers several concrete benefits to a project:

• Promotes communication and a common understanding of the business domain across all stakeholders.
• Encourages consistency by acting as a single reference source for business terms, so everyone — from requirements documents to test scripts — uses the same vocabulary.
• Simplifies the writing and maintenance of business analysis information, since analysts can reference defined terms instead of re-explaining them in every document.

Limitations to Keep in Mind

Like any technique, a glossary isn't without trade-offs:

• It requires a dedicated person or role to maintain it. A glossary that no one owns quickly becomes outdated and loses credibility.
• Getting stakeholder agreement on a single definition can be challenging. Different departments or teams often have their own interpretation of the same word, and reconciling those views takes negotiation and diplomacy.

Best Practices for Creating and Maintaining a Glossary

To get real value from a glossary, business analysts should follow a few core practices:

• Start early. Define the glossary in the early stages of a project. This accelerates understanding and knowledge transfer before requirements gathering gets underway.
• Assign an owner. Identify the person responsible for maintaining the glossary so it stays accurate and current as the project evolves.
• Control access to editing. Limit glossary editing rights to specific, designated stakeholders — while still making the glossary itself easily accessible for everyone to read.
• Write clearly. Definitions and acronyms should be written in plain, unambiguous language so that all stakeholders — technical and non-technical — can understand them without confusion.
• Keep it accessible. A glossary only adds value if stakeholders can easily find and reference it, whether that's a shared wiki page, a section in the requirements repository, or a standalone document.

Worked Example: Glossary for a GRC Management System

To see the glossary technique in action, consider a Governance, Risk and Compliance (GRC) management system built for the IT and ITES domain. The primary objective of this system is to help companies implement Governance, Quality, and Information Security Management Systems in an integrated way. One of its core features is planning and tracking projects and programs against standards such as CMMI, ISO 9001, and ISO 27001.

Below is a partial glossary a business analyst might create for this system:

Notice how this table captures not just definitions, but also synonyms (alternate terms with the same meaning) and homonyms (terms that sound or look similar but carry a different meaning — like "Matrix" vs. "Metrics"). This structure is exactly what prevents the kind of misunderstanding a glossary is designed to eliminate.

Frequently Asked Questions

What is the purpose of a glossary in business analysis? The purpose of a glossary is to define key terms relevant to a business domain so all stakeholders share a common understanding, reducing miscommunication across requirements, design, and testing.

Who should own a project glossary? A specific, designated individual — often the lead business analyst — should be identified as the glossary owner, responsible for keeping definitions accurate and up to date.

Should every stakeholder be able to edit the glossary? No. While the glossary should be easily accessible to all stakeholders for reference, editing rights should be limited to specific, designated stakeholders to preserve accuracy and consistency.

What's the difference between a synonym and a homonym in a glossary? A synonym is a different word with the same meaning (e.g., "Defect" and "Bug"). A homonym is a term that looks or sounds similar to another but means something different (e.g., "Matrix," a table, versus "Metrics," a measurement).

When should a business analyst create the glossary? Ideally in the early stages of a project, so it can support understanding and knowledge transfer from the outset rather than being retrofitted later.

Key Takeaway

A glossary is a deceptively simple but high-leverage business analysis technique. By capturing domain-specific, ambiguous, or easily misunderstood terms in one accessible, well-owned document, business analysts create a foundation of shared understanding that pays off across the entire project lifecycle — from requirements elicitation through testing and delivery.