business analysis

(Photo by autumn_bliss)

Does your project have a glossary? If not, are you confident that the terms being used in the project have a single meaning for all stakeholders involved?

A business analyst cannot simply assume that every stakeholder will use important terms consistently. Here are a few examples of real life situations in which the lack of agreement on a common vocabulary by all stakeholders would have put the projects in jeopardy:

• “payables” having diverging meanings for two groups of stakeholders participating in a project that required drill-down and drill-up of payables entries;
• “agent” having different meanings for each of several business units involved in a datamining project that had the goal of consolidating information about different types of business partners, including agents.
• “clone” being used by the business side to indicate what the developers referred to as “version” (“clone” having a different meaning in the context of the system database).

Without a definition establishing a consensual meaning for these business terms, the projects would have quickly run into trouble. Even if a term will continue to have different meanings throughout the organization, within the boundaries of a system being built, each relevant term must have a clear, unambiguous definition.

A glossary is not the same as a data dictionary, but rather a great foundation for a data dictionary, as it limits the room for free interpretation and facilitated the development of the data dictionary, which typically include field names and data types, among other components. Here is a simplified example of a data dictionary:

Creating and maintaining a glossary is a recommended practice for business analysts whenever a project uses terms that may have multiple meanings, or there’s a risk that specialized terms from the business or the application domain will cause misunderstandings among people from different functional groups. Constantly referring people to the project’s glossary will ensure that these terms are used consistently by all parties involved.

Related resources:

• Software Requirements Resources: Glossary (from Construx)