<Company Name>

<Project Name>
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).] [To customize automatic fields (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]

<Project Name> <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

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

Confidential

<Company Name>,2000

ii

<Project Name> <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

Table of Contents
1. Introduction 1.1 Purpose 1.2 Scope 1.3 References 1.4 Overview 2. Definitions 2.1 actor 2.2 artifact 2.3 baseline 2.4 customer 2.5 change control board (CCB) 2.6 change management 2.7 change request (CR) 2.8 configuration manager 2.9 defect 2.10 developer 2.11 document 2.12 enhancement request 2.13 feature 2.14 I/T 2.15 iteration 2.16 quality assurance (QA) 2.17 project manager 2.18 requirement 2.19 requirement attribute 2.20 requirement type 2.21 requirements management 2.22 requirements specifier 2.23 requirements tracing 2.24 role 2.25 Rational Unified Process 2.26 scope management 2.27 stakeholder 2.28 stakeholder need 2.29 stakeholder request 2.30 software requirement 2.31 team leader 2.32 traceability 2.33 use case (class) 2.34 user 2.35 vision (document) 2.36 <aTerm> 2.37 <anotherTerm> 2.38 <aGroupOfTerms> 2.38.1 <aGroupTerm> 2.38.2 <anotherGroupTerm> 2.39 <aSecondGroupOfTerms> 2.39.1 <yetAnotherGroupTerm> Confidential <Company Name>,2000 1 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 3 4 4 4 4 4 4 4 4 4 4 4 4 5 5 iii

<Project Name> <document identifier> 2.39.2 <andAnotherGroupTerm>

Version: <1.0> Date: <dd/mmm/yy>

Confidential

<Company Name>,2000

iv

<Project Name> <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

<Project Name>
1. Introduction
[The introduction of the 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 that 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.] 1.1 Purpose [Specify the purpose of this Glossary.] 1.2 Scope [A brief description of the scope of this 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 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 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 2.2 actor Someone or something, outside the system that interacts with the system. artifact A piece of information that is used or produced by a software development process. An artifact can be a model, a description, or software. Synonym: product. baseline A reviewed and approved release of artifacts that constitutes an agreed basis for further evolution or development and that can be changed only through a formal procedure, such as change management and configuration control . customer A person or organization, internal or external to the producing organization, who takes financial responsibility for the system. In a large system this may not be the end user. The customer is the ultimate recipient of the developed product and its artifacts. See also stakeholder. change control board (CCB) The role of the CCB is to provide a central control mechanism to ensure that every change request is properly considered, authorized and coordinated.

2.3

2.4

2.5

Confidential

<Company Name>,2000

<Project Name> <document identifier> 2.6 2.7

Version: <1.0> Date: <dd/mmm/yy>

change management The activity of controlling and tracking changes to artifacts. See also scope management. change request (CR) A general term for any request from a stakeholder to change an artifact or process. Documented in the Change Request is information on the origin and impact of the current problem, the proposed solution, and its cost. See also enhancement request, defect. configuration manager The configuration manager is responsbile for setting up the product structure in the Change Management system, for defining and allocating workspaces for developers, and for integration. The configuration manager also extracts the appropriate status and metrics reports for the project manager . defect An anomaly, or flaw, in a delivered work product. Examples include such things as omissions and imperfections found during early lifecycle phases and symptoms of faults contained in software sufficiently mature for test or operation. A defect can be any kind of issue you want tracked and resolved. See also change request. developer A person responsible for developing the required functionality in accordance with project-adopted standards and procedures. This can include performing activities in any of the requirements, analysis & design, implementation, and test disciplines. document A document is a collection of information that is intended to be represented on paper, or in a medium using a paper metaphor. The paper metaphor includes the concept of pages, and it has either an implicit or explicit sequence of contents. The information is in text or two-dimensional pictures. Examples of paper metaphors are word processor documents, spreadsheets, schedules, Gantt charts, web-pages, or overhead slide presentations. enhancement request A type of stakeholder request that specifies a new feature or functionality of the system. See also change request. feature An externally observable service provided by the system which directly fulfills a stakeholder need. I/T Information Technology iteration A distinct sequence of activities with a base-lined plan and valuation criteria resulting in a release (internal or external). quality assurance (QA) The function of Quality Assurance is the responsibility of (reports to) the Project Manager and is responsible for ensuring that project standards are correctly and verifiably followed by all project staff. project manager The role with overall responsibility for the project. The Project Manager needs to ensure tasks are <Company Name>,2000 2

2.8

2.9

2.10

2.11

2.12

2.13

2.14 2.15

2.16

2.17

Confidential

<Project Name> <document identifier>

Version: <1.0> Date: <dd/mmm/yy>

scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements. 2.18 requirement A requirement describes a condition or capability to which a system must conform; either derived directly from user needs, or stated in a contract, standard, specification, or other formally imposed document. A desired feature, property, or behavior of a system. requirement attribute Information associated with a particular requirement providing a link between the requirement and other project elementsfor example, priorities, schedules, status, design elements, resources, costs, hazards. requirement type A categorization of requirementsfor example, stakeholder need, feature, use case, supplementary requirement, test requirement, documentation requirement, hardware requirement, software requirement, and so onbased on common characteristics and attributes. requirements management A systematic approach to eliciting, organizing and documenting the requirements of the system, and establishing and maintaining agreement between the customer and the project team on the changing requirements of the system. requirements specifier The requirements specifier details the specification of a part of the system's functionality by describing the requirements aspect of one or several use cases and other supporting software requirements. The requirements specifier may also be responsible for a use-case package, and maintains the integrity of that package. It is recommended that the requirements specifier responsible for a use-case package is also responsible for its contained use cases and actors. requirements tracing The linking of a requirement to other requirements and to other associated project elements. role A definition of the behavior and responsibilities of an individual, or a set of individuals working together as a team, within the context of a software engineering organization. Rational Unified Process The Rational Unified Process (RUP) is a software engineering process. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. scope management The process of prioritizing and determining the set of requirements that can be implemented in a particular release cycle, based on the resources and time available. This process continues throughout the lifecycle of the project as changes occur. See also change management. stakeholder An individual who is materially affected by the outcome of the system. stakeholder need The business or operational problem (opportunity) that must be fulfilled in order to justify purchase or use.

2.19

2.20

2.21

2.22

2.23 2.24

2.25

2.26

2.27 2.28

Confidential

<Company Name>,2000

<Project Name> <document identifier> 2.29

Version: <1.0> Date: <dd/mmm/yy>

stakeholder request A request of any typefor example, Change Request, enhancement request, request for a requirement change, defectfrom a stakeholder. software requirement A specification of an externally observable behavior of the system; for example, inputs to the system, outputs from the system, functions of the system, attributes of the system, or attributes of the system environment . team leader The team leader is the interface between project management and developers. The team leader is responsible for ensuring that a task is allocated and monitored to completion. The team leader is responsible for ensuring that development staff follow project standards, and adhere to project schedules. traceability The ability to trace a project element to other related project elements, especially those related to requirements. Project elements involved in traceability are called traceability items. use case (class) A description of system behavior, in terms of sequences of actions. A use case should yield an observable result of value to an actor. A use case contains all alternate flows of events related to producing the "observable result of value". More formally, a use case defines a set of use-case instances or scenarios. user A person who will use the system that is developed. vision (document) The user's or customer's view of the product to be developed, specified at the level of key stakeholder needs and features of the system

2.30

2.31

2.32

2.33

2.34 2.35

2.36 <aTerm> [The definition for <aTerm> is presented here. As much information as the reader needs to understand the concept should be presented.] 2.37 <anotherTerm> The definition for <anotherTerm> is presented here. As much information as the reader needs to understand the concept should be presented 2.38 <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.38.1 <aGroupTerm> [The definition for <aGroupTerm> is presented here. As much information as the reader needs to understand the concept should be presented.] 2.38.2 <anotherGroupTerm> [The definition for <anotherGroupTerm> is presented here. As much information as the reader needs to Confidential <Company Name>,2000 4

<Project Name> <document identifier> understand the concept should be presented.] 2.39 <aSecondGroupOfTerms>

Version: <1.0> Date: <dd/mmm/yy>

2.39.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.39.2 <andAnotherGroupTerm> [The definition for the term is presented here. As much information as the reader needs to understand the ]concept should be presented.]

Confidential

<Company Name>,2000