Glossary
The
glossary is the
requirements work
product that formally defines the abbreviations, acronyms,
and important terms used on an
endeavor.
The typically objectives of the glossary are to:
- Formally document the endeavor’s:
- Abbreviations and acronyms.
- Customer organization terms (application-specific
terms).
- Developer organization terms (OPF terms, general
application-domain terms).
- Ensure the consistent use of terminology on the
endeavor.
The typical benefits of the glossary are:
- Improve communication between the organizations involved
in the endeavor.
- Improve communication among endeavor’s
personnel.
- Improve developer productivity.
- Decrease defect rate.
The typical contents of the glossary are:
- Abbreviations and Accronyms
- Customer Terms
- Developer Terms
- Appendices:
- Major Issues
- TBDs
- Assumptions
The typical stakeholders of the glossary are:
- Producers:
- Evaluators:
- Approvers:
- Maintainers:
- Users:
A glossary is typically produced during the following
phases:
A glossary typically can be started if the following
preconditions hold:
The typical inputs to the glossary include:
- Work Products:
- Stakeholders:
- This is a living document that is developed incrementally
and iteratively in parallel with other work products.
- Tailor out the predefined developer organization terms in
the template that are not relevant to the project.
- This glossary can be divided into two separate
glossaries: one of business domain terms for the development
organization and one of development terms for the customer
organization. In which case, the glossary of this website can
act as the developer term glossary.
- If decomposed into two separate glossaries, the developer
term glossary could be treated as a
process engineering work product.
- Where practical, avoid circular definitions.
The glossary is typically constrained by the following
conventions: