Artifact:  Glossary

Glossary	The Glossary defines important terms used by the project.
Role:	System Analyst
Templates:	HTML Others
Examples:	Glossary, from the Wylie College Process Web Site Glossary, from the Course Registration System Inception Elaboration Glossary, from the Collegiate Sports Paging System (e-business) Inception Elaboration
More Information:	Checkpoints:Glossary
Purpose Timing Responsibility Tailoring

Input to Activities: Find Actors and Use Cases Structure the Use-Case Model Find Business Actors and Use Cases Review Requirements Detail a Use Case Detail the Software Requirements Architectural Analysis Assess Viability of Architectural Proof-of-Concept Use-Case Analysis

Output from Activities: Capture a Common Vocabulary

Purpose

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

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

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

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.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process