Business Glossary

1. Introduction

[The introduction of the Business Glossary should provide an overview of the entire document. 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 Business Glossary.]

1.1 Purpose

[Specify the purpose of this Business Glossary.]

1.2 Scope

[A brief description of the scope of this Business Glossary; what Project(s) it is associated with, and anything else that is affected or influenced by this document.]

1.3 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Business Glossary. Each document should be identified by title, report number (if applicable), date, and publishing organization. Specify the sources from which the references can be obtained. This information may be provided by reference to an appendix or to another document.]

1.4 Overview

[This subsection should describe what the rest of the Business Glossary contains and explain how the document is organized.]

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.]

2.1 <aTerm>

[The definition for <aTerm> is presented here. As much information as the reader needs to understand the concept should be presented.]

2.2 <anotherTerm>

The definition for <anotherTerm> is presented here. As much information as the reader needs to understand the concept should be presented

2.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.]

2.3.1 <aGroupTerm>

[The definition for <aGroupTerm> is presented here. Present as much information as the reader needs to understand the concept.]

2.3.2 <anotherGroupTerm>

[The definition for <anotherGroupTerm> is presented here. Present as much information as the reader needs to understand the concept.]

2.3.3 <yetAnotherGroupTerm>

[The definition for the term is presented here. Present as much information as the reader needs to understand the concept.]

2.3.4 <andAnotherGroupTerm>

[The definition for the term is presented here. Present as much information as the reader needs to understand the concept.]

[This section contains or references specifications of Unified Modeling Language (UML) stereotypes and their semantic implications—a textual description of the meaning and significance of the stereotype and any limitations on its use—for stereotypes already known or discovered to be important in the aspect of business being modeled. The use of these stereotypes may be simply recommended or perhaps even made mandatory; for example, when their use is required by an imposed standard or when it is felt that their use makes models significantly easier to understand. This section may be empty if no additional stereotypes, other than those predefined by the UML and the Rational Unified Process, are considered necessary.]

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