Artifact: Glossary
 Glossary |
The Glossary defines important terms used in the project. |
| Worker: | System Analyst |
| Template: | Word template |
Purpose 
There is one Glossary for the system. This document is important to many developers, especially when they need to understand and use the terms that are specific to the project.
Brief
Outline
1. Introduction
Present any information the reader might need to understand the document in this section. This document is used to define terminology specific to the problem domain, explaining terms which may be unfamiliar to the reader of the use-case descriptions or other project documents. Often, this document can be used as an informal data dictionary, capturing data definitions so that use-case descriptions and other project documents can focus on what the system must do with the information. This document should be saved in a file called Glossary.
2. Definitions
The terms defined here form the essential substance of the document. They can be defined in any order desired, but generally alphabetic order provides the greatest accessibility.
1. aTerm
The definition for aTerm is presented here. As much information as the reader needs to understand the concept should be presented.
2. anotherTerm
The definition for anotherTerm is presented here. As much information as the reader needs to understand the concept should be presented
3. aGroupOfTerms
Sometimes it is useful to organize terms into groups to improve readability. For example, if the problem domain contains terms related to both accounting and building construction (as would be the case if we were developing a system to manage construction projects), presenting the terms from the two different sub-domains might prove confusing to the reader. To solve this problem, we use groupings of terms. In presenting the grouping of terms, provide a short description that helps the reader understand what aGroupOfTerms represents. Terms presented within the group should be organized alphabetically for easy access.
1. aGroupTerm
The definition for aGroupTerm is presented here. As much information as the reader needs to understand the concept should be presented
2. anotherGroupTerm
The definition for anotherGroupTerm is presented here. As much information as the reader needs to understand the concept should be presented
4. aSecondGroupOfTerms
1. yetAnotherGroupTerm
The definition for the term is presented here. As much information as the reader needs to understand the concept should be presented
2. andAnotherGroupTerm
The definition for the term is presented here. As much information as the reader needs to understand the concept should be presented.
Timing
The Glossary is primarily developed during the inception and elaboration phases, because it is important to agree on a common terminology early in the project.
Responsibility
A Worker: System Analyst is responsible for the integrity of the Glossary, ensuring that:
- The Glossary is produced in a timely manner.
- It continuously is kept consistent with the results of development.
Tailoring
In some projects the glossary will be the only artifact used to capture the business domain of the project. This is when neither business modeling nor domain modeling is performed.
If the context of the business modeling effort is much different than a following software engineering effort, you may need to produce one Glossary specific to the business modeling effort. That Glossary would then be the responsibility of the Business-Process Analyst.
