Artifact: Glossary

Glossary	The Glossary defines important terms used in the project.
Worker:	System Analyst
Template:	Microsoft Word Template HTML Template
Examples:	Course Registration System Collegiate Sports Paging System (e-Business)
More Information:	Checkpoints: Glossary
Purpose Brief Outline Timing Responsibility Tailoring Annotated Outline (hyperlinks into HTML template in a new window)

Input to Activities: Architectural Analysis Detail a Business Use Case Detail a Use Case Detail the Software Requirements Find Actors and Use Cases Find Business Actors and Use Cases Find Business Workers and Entities Prioritize Use Cases Review Business Object Model Review Business Use-Case Model Review Requirements Structure the Business Use-Case Model Structure the Use-Case Model Use-Case Analysis

Output from Activities: Capture a Common Vocabulary Prioritize Use Cases Review Business Use-Case Model Review Requirements

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

(hyperlinks into HTML template in a new window)

1.       Introduction        

    1.1     Purpose    

    1.2     Scope    

    1.3     References    

    1.4     Overview    

2.       Definitions

    2.1     <aTerm>    

    2.2     <anotherTerm>    

    2.3     <aGroupOfTerms>    

        2.3.1         <aGroupTerm>          

        2.3.2         <anotherGroupTerm>          

    2.4     <aSecondGroupOfTerms>    

        2.4.1         <yetAnotherGroupTerm>          

        2.4.2         <andAnotherGroupTerm>          

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.

Copyright  ⌐ 1987 - 2000 Rational Software Corporation

Rational Unified Process