Business Analysis Glossary: Why Bother?

I’ve read in numerous places how important it is for Business Analysts to understand business terms and speak the same language as stakeholders. Equally important is the need to ensure that different groups of stakeholders have a common understanding of what a business term means. The importance of this never really struck me until I had an experience with 2 stakeholders who defined the same term differently even though they worked in the same department.

The term in question was a certain type of allowance being paid to staff, known as “Transport Subsidy”. This amount was initially defined to be a fixed amount paid based on the staff’s grade in the organization. 

The meal subsidy was however, under review and the requirement at the time was to increase it.

After a meeting with the two key stakeholders in the HR Department, I noticed that both stakeholders had a different understanding of the increment to be made to the Transport Subsidy. The first stakeholder defined the change as an increment to be calculated by adding a fixed value per staff grade to the original value while the other stakeholder defined the increment as a new type of allowance whose value was to be derived by taking a percentage of the original Transport Subsidy. Arriving at a common definition was important because this definition would determine what formula to use for the computation and the accounting entries that the system would generate for such transactions.

The term “Transport Subsidy Increment” should for example, be defined in a glossary because: 

  1. It is unique to the domain
  2. It is prone to misunderstanding because how the value is calculated can be easily misunderstood if not spelt out
  3. The definition can become different once you take it outside the context of the domain in question.

Analysts are required to understand stakeholder vocabulary as well as bring everyone to a common understanding of what relevant business terms mean. This can quickly become challenging when the analyst is in a new business domain and new terms are flying around.

You may wonder what the definition of business terms has to do with system functionality. I’d say everything. People’s expectations are often derived from their understanding of what they believe the system should do (their requirements). To identify these requirements, stakeholders must be able to define, understand and more importantly, agree on the elements that constitute their requirements. Conflicting views lead to conflicting expectations which in turn can have a negative impact on system acceptance.

This is why having a glossary of common business terms is essential. Having a glossary to draw on can also force stakeholders as well as the analyst to question their assumptions. Sometimes, we think we understand a concept completely until someone else comes with up an alternative definition that challenges our views.

So, whether you’re new to a project or mired in the complexities of a new domain, remember to draw on the strengths of a glossary. Someone on the team should be appointed to update and distribute the glossary. Although it can be challenging to keep the glossary up-to-date and for stakeholders to agree on every single definition contained in the glossary, the effort spent is well worth the benefit of developing accurate requirements driven by a shared understanding of business terms.