Glossary

The glossary defines organization-specific terms and concepts so that all stakeholders “speak the same language” about the organization’s needs.

A stakeholder maintains a list of unfamiliar terms and concepts. The stakeholders agree on each term’s definition to minimize ambiguity when the terms or concepts arise in discovery.

Click a title to see excerpts

Coming to Terms (Key Story)

Coming to Terms excerpts:

• The Path to Understanding
  • One stakeholder, typically in a business analyst role, should own the glossary and make it available to all stakeholders. The glossary owner updates the glossary to reflect changes initiated by and agreed upon by stakeholders. The glossary serves as a reference when stakeholders need clarification or have conflicting interpretations of a term.
• Discovering a Customer’s Terms
  • The glossary defines terms only to clarify communication between stakeholders. The glossary is not a data dictionary. It could serve as a reference for a data dictionary later, during design. A good glossary owner defies solution gravity, the temptation to implement a solution during discovery. S/he focuses on all stakeholders agreeing on the meaning of terms.
• A glossary of customer terms puts solution development on a trajectory to success.
  

Showing Customer Concepts

Showing Customer Concepts excerpts:

• Relating the Customer Terms
  • Once a purposeful architect has compiled a glossary of customer terms in discovery, how can s/he show his or her understanding of the terms? Reviewing the glossary term by term will turn a discovery meeting into an executive snoozefest, losing the attention of most stakeholders. Besides, there’s more to customer terms than their definitions.
• Concept Map Considerations
  • A concept map works hand in hand with a glossary which defines each concept in the map. The glossary serves a reference for understanding. The concept map illustrates understanding. For example, a new stakeholder reviews the concept map and asks what a concept means. S/he finds the definition of the concept in the glossary.
    

Mapping Out Complexity

Mapping Out Complexity excerpts:

• Getting Clarity on the Concepts
  • Process steps expressed with the customer’s terminology enable customer stakeholders to focus on breaking down the complexity in their own language. A glossary of customer terms defines the language used in the steps. For example, a glossary defines Lead and Contact as follows..
  • If a new term arises when breaking down a complex process, the glossary owner should get agreement on the definition and record it in the glossary. The article Coming to Terms covers glossary development...
  • A concept map shows relationships between customer terms. It can help with the complex process breakdown. For example, a concept map relates Lead to Contact through conversion:agreement on the definition and record it in the glossary. The article Coming to Terms covers glossary development.
    

Understanding Customer Requirements

Understanding Customer Requirements excerpts:

• A Model of Understanding
  • Creating models helps a lot with understanding how a customer will use a solution. Models often start with a glossary, diagrams and eventually a proof of concept.
    

Turn Customer Stakeholders into Discovery Heroes

Turn Customer Stakeholders into Discovery Heroes excerpts:

• Once you have all the documentation, you analyze the similarities and differences between the systems. At a high level, the systems have a lot in common. Yet, they have different naming conventions for accounts, contacts and opportunities, so you create a glossary with a proposed naming convention. The managers review the glossary, negotiate and agree on common terminology.