The Glossary defines important terms used by the project. 
Role:  System Analyst 
Optionality/Occurrence:  Primary artifact used to capture information about the project's business domain. Inception and Elaboration phases.
Templates and Reports: 
Examples: 
UML Representation:  Not applicable.
More Information:   
Input to Activities:    Output from Activities:   

Purpose To top of page

There is one Glossary for the system that provides a consistent set of definitions to help avoid misunderstandings. Project members initially use the Glossary to understand the terms that are specific to the project. This document is also important to people performing these roles:

  • Developers, who make use of the terms in the Glossary when designing and implementing classes, database tables, user-interfaces, and so forth
  • Analysts, who use the Glossary to capture project-specific terms so they can clearly define business rules, and to ensure that requirement specifications make correct and consistent use of those terms
  • Course developers and technical writers, who use the Glossary to construct training material and documentation using recognized terminology

Timing To top of page

The Glossary is primarily developed during the inception and elaboration phases, because it's important to agree on a common terminology early in the project.

Responsibility To top of page

The System Analyst role is responsible for the integrity of the Glossary, ensuring that:

  • it is produced in a timely manner
  • it is continuously kept consistent with the results of development

Tailoring To top of page

In some projects where business modeling and domain modeling are not performed, the Glossary is the primary artifact used to capture information about the project's business domain.

If the context and scope of the business modeling effort is much broader than that of the software engineering effort, you may need to produce a separate Glossary, specifically for business modeling. That Glossary would then be the responsibility of the Business-Process Analyst.



Rational Unified Process   2003.06.13