# Project Glossary Template

## Cover Page

- ``Project Name``
- `Glossary`
- `Version`1.0``

## Revision History

| Date | Version | Description | Author |
| --- | --- | --- | --- |
| ``dd/mmm/yy``|``x.x``|`<details>`|`<name>` |

## Ownership & Collaboration

- Document Owner: System Analyst
- Contributor Roles: Business Process Analyst, Requirements Reviewer
- Automation Inputs: Domain term list, glossary references
- Automation Outputs: `glossary.md` sorted alphabetically

## 1 Introduction

> Explain the glossary’s purpose, scope, references, and structure.

### 1.1 Purpose

> State why the glossary is maintained and how it will be used.

### 1.2 Scope

> Identify associated projects, releases, or domains.

### 1.3 References

> List supporting documents or external dictionaries.

### 1.4 Overview

> Describe how terms are organized (e.g., alphabetical, grouped by domain).

## 2 Definitions

> Provide alphabetical definitions. Group terms when helpful for readability.

### 2.1 `<Term>`

> Definition and notes.

### 2.2 `<AnotherTerm>`

> Definition and notes.

### 2.3 `<GroupOfTerms>`

> Describe the group and why these terms are clustered.

#### 2.3.1 `<GroupTerm>`

> Definition within the group context.

#### 2.3.2 `<AnotherGroupTerm>`

> Definition within the group context.

### 2.4 `<SecondGroupOfTerms>`

> Optional second grouping.

#### 2.4.1 `<YetAnotherGroupTerm>`

> Definition details.

#### 2.4.2 `<AndAnotherGroupTerm>`

> Definition details.

## 3 UML Stereotypes (Optional)

> Document project-specific UML stereotypes, semantics, and usage constraints.

## Appendices (Optional)

> Include data dictionaries, acronym lists, or traceability tables if required.

## Agent Notes

- Include synonyms and ownership for each term to aid automated lookup.
- Retire obsolete terms by moving them to a dedicated subsection.
- Verify the Automation Outputs entry is satisfied before signaling completion.
