Artifact: Glossary
| 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: | - Template: Glossary |
| Examples: | - CREG Glossary - Elaboration Phase - CREG Glossary - Inception Phase - CSPS Glossary - Inception Phase - CSPS Glossary - Elaboration Phase |
| UML Representation: | Not applicable. |
| More Information: | - Checklist: Glossary |
| Input to Activities: - Architectural Analysis - Assess Viability of Architectural Proof-of-Concept - Detail a Use Case - Detail the Software Requirements - Find Actors and Use Cases - Review Requirements - Structure the Use-Case Model - 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.