Skip to main content

Author: Michael Mainridge

Are We Speaking the Same Language?

Business stakeholders and solution teams may use different terminology when it comes to requirements. 

Creating requirements tailored exclusively for one group or the other is likely to result in confusion and unfulfilled expectations.  There are some actions we can do as business analysts to help ensure stakeholders have a shared understanding of terminology which has downstream benefits.

Shared Terminology

Most organizations use terminology that span from its founding days up to the current day.  Terminology is added along the way which may replace terms but may have a different scope in meaning.  Depending on when solutions are created, each may adopt technical terms in vogue at the time. 

Some terminology is unique to an industry or even within the company.  Some terms can have different meanings depending on the department which causes confusion.  Mergers and acquisitions compound the situation.  The result is business and technical lexicons which vary across the organization.

Besides understanding the current terminology for your project, business analysts can work with business and solution team stakeholders to create a shared comprehension of what terminology will be used in the project.  This may come in the form of a dictionary, taxonomy or ontology.  I found it helpful to decide on one primary term and its definition, but also include:

  • Aliases (This can be the translation between stakeholder groups or previous terms)
  • Alias Differences (In case there are differences in meaning or relationships)
  • Relationships to other terms (Ontologies allow multiple structured relationships)
  • Allowed values (if appropriate)
  • Data Definition (Usually populated during later requirements elicitation)
  • Examples


Taking this approach while identifying high level requirements sets a foundation to build upon as more detailed requirements are elicited.  While stakeholders may resist doing this because “they want to get started”, this has payoffs for everyone.  Some of the benefits are:

  • More accurate requirements
  • Less time revisiting the same topics
  • Possible reduced development time
  • Improved QA testing (especially if Gherkin structured language is used)
  • Provides a foundation for data architecture
  • Better tracking and backlog visibility

Requirements Architecture

When you have a shared understanding of the terms and their meaning, this allows a business analyst to define the requirements architecture more efficiently and effectively.   Per the BABOK 3.0, the purpose of requirements architecture is to ensure the requirements collectively support one another to fully achieve the objectives. It is difficult to do this when terminology can be perceived differently.

Countless times I have tried to find a backlog item, but it contained terminology that was tailored to one person’s interpretation of the requirement.  When I create a requirement, I think about how someone would try to find it and recognize the contents.  If terminology is agreed upon early, I can name the requirement in a way that is identifiable by all stakeholders. 

Using the agreed upon terms also simplifies creating diagrams and models. It may reduce the number and complexity of the artifacts.  This makes requirement reviews and approval simpler.

A defined shared understanding helps with scope and expectations.  If the business is using a term that is broader in scope than the solution providers understand, this results in missed expectations and may not be discovered until User Acceptance Testing.  The opposite situation results in an unnecessary scope increase. 

Similarly, this also helps when breaking requirements into manageable backlog items.  Knowing the meaning of a term can prevent adding requirements which overlap or have gaps.  The potential for requirements reuse can be identified more easily because terms have been standardized.

 If I can’t get shared agreement, I use the most likely used term and include aliases.  When a requirement is business facing, I refrain from including technical terminology that would be confusing to business stakeholders. 

The preferred terminology may change during a project.  I have often wished requirements management tools would allow variable place holders that tie back to a dictionary, taxonomy, or ontology.  If the term or related information changed, I would only have to edit the change in one source.


During a project’s inception, the project team should determine the stakeholders and their responsibilities on the project.  They need to identify where requirements are stored, who needs access, and the attributes that need to be stored.  This leads to a plan for how business analysts share business analysis information. 

A shared terminology and a structured requirements architecture facilitate visibility into the scope of the project.  Stakeholders can identify where a specific requirement fits in by searching using the agreed terms.   It may reduce the need for meetings or extra communication for the business analyst.

This is helpful for the business because they can plan for feature releases, SME availability and UAT resources.  It helps the IT managers plan for personnel, hardware, security and other aspects.  If regulatory oversight is involved, the compliance team would need to be involved early on and would thus gain the benefits mentioned.


Since companies have a variety of lexicons, there are significant benefits to creating a shared understanding of terminology.  Business analysts can create requirements more accurately and efficiently.  Teams can benefit by not rehashing the same discussions.  Developers and Quality Analysts are more likely to build and test what the stakeholders intended.  A jointly determined lexicon is the foundation for creating a structured requirements architecture.  This promotes visibility to stakeholders so they can find requirements and plan for them.