Rational Unified Process - Complete Reference

[1.3](#Definitions, Acronyms and Abbreviations)[Definitions, Acronyms and Abbreviations](#Definitions, Acronyms and Abbreviations)

1.5 Overview

[2.](#General Use-Case Modeling Guidelines)[General Use-Case Modeling Guidelines](#General Use-Case Modeling Guidelines)

[2.1](#General Style)[General Style](#General Style)

[2.2](#Use of the <<Communicates>> relationship)[Use of the <<Communicates>> relationship](#Use of the <<Communicates>> relationship)

[2.3](#Use of the <<Include>> and <<Extend>> relationships)[Use of the <<Include>> and <<Extend>> relationships.](#Use of the <<Include>> and <<Extend>> relationships)

[2.3.1](#Use of the <<Include>> relationship)[Use of the <<Include>> relationship.](#Use of the <<Include>> relationship)

[2.3.2](#Use of the <<Extend>> relationship)[Use of the <<Extend>> relationship.](#Use of the <<Extend>> relationship)

[2.4](#Use of Actor-Generalization)[Use of Actor-Generalization](#Use of Actor-Generalization)

[2.5](#Use of Interaction Diagrams)[Use of Interaction Diagrams](#Use of Interaction Diagrams)

[2.6](#Use of Activity Diagrams)[Use of Activity Diagrams](#Use of Activity Diagrams)

[3.](#How to Describe a Use Case)[How to Describe a Use Case](#How to Describe a Use Case)

[3.1](#Actor Guidelines)[Actor Guidelines](#Actor Guidelines)

[3.1.1](#Each concrete Use Case will be involved with at least one Actor)[Each concrete Use Case will be involved with at least one Actor](#Each concrete Use Case will be involved with at least one Actor)

[3.1.2](#Intuitive and Descriptive Actor Name(s))[Intuitive and Descriptive Actor Name(s)](#Intuitive and Descriptive Actor Name(s))

[3.1.3](#Consistent Use of Actor Name(s))[Consistent Use of Actor Name(s)](#Consistent Use of Actor Name(s))

[3.2](#Use Case Name)[Use Case Name](#Use Case Name)

[3.3](#Use Case Brief Description)[Use Case Brief Description](#Use Case Brief Description)

[3.3.1](#At least 1 paragraph)[At least 1 paragraph](#At least 1 paragraph)

[3.3.2](#(Optional) An example)[An example (Optional)](#(Optional) An example)

[3.4](#Consistent use of the imperative: Will)[Consistent use of the imperative: Will](#Consistent use of the imperative: Will)

[3.5](#Use of Glossary Terms)[Use of Glossary Terms](#Use of Glossary Terms)

[3.6](#Use of Action Terms)[Use of “Action” Terms](#Use of Action Terms)

[3.6.1](#Define where the system is responsible for presenting the Action Option)[Define where the system is responsible for presenting the Action Option](#Define where the system is responsible for presenting the Action Option)

[3.6.2](#Consistent use of the term throughout the Use Case)[Consistent use of the term throughout the Use Case](#Consistent use of the term throughout the Use Case)

[3.7](#Separate paragraphs for Actor and System behavior)[Separate paragraphs for Actor and System behavior](#Separate paragraphs for Actor and System behavior)

[3.8](#Alternate and Sub-Flows)[Alternate and Sub-Flows](#Alternate and Sub-Flows)

[3.9](#preconditions postconditions)[Preconditions and Postconditions](#preconditions postconditions)

[3.10](#Use of placeholders for missing detail (TBD))[Use of placeholders for missing detail (TBD)](#Use of placeholders for missing detail (TBD))

[3.11](#Definition of and Reference to Supplementary Specifications)[Definition of and Reference to Supplementary Specifications](#Definition of and Reference to Supplementary Specifications)

[3.12](#Crosscheck with UI Prototype/ Design)[Crosscheck with UI Prototype/ Design](#Crosscheck with UI Prototype/ Design)

[3.13](#Exception Flows)[Exception Flows (Optional)](#Exception Flows)

[3.13.1](#What can go wrong?)[What can go wrong?](#What can go wrong?)

Use-Case Modeling Guidelines

1. Introduction

1.1 Purpose

The purpose of this set of guidelines is to ensure consistency of the Use-Case model. It provides guidance in how to document a Use-Case as well as general help on related topics often found problematic for Requirement Specifiers and System Analysts.

1.2 Scope

These guidelines may be used as is, or tailored, to meet the needs of most projects.

1.3 Definitions, Acronyms and Abbreviations

See Rational Unified Process Glossary.

1.4 References

None

1.5 Overview

This set of guidelines is organized into two sections, the first describes our preferred way of modeling the Use-Cases, the second part provides guidelines for the content of the Use-Case model and for naming the elements within the model.

2. General Use-Case Modeling Guidelines

2.1 General Style

The Use Cases will be written using the template provided with the Rational Unified Process, with certain style and layout modifications to suit applicable project documentation standards. Click here to see the HTML version of this template.

2.2 Use of the <<Communicates>> relationship

The association between an Actor and a Use-Case is called a Communicates relation. It is recommended that this association is made uni-directional. By using this modeling strategy we will distinguish between :

q Active Actor The Actor is considered active in an Actor-Use Case pair when the Actor is initiating (or triggering) the execution of the Use-Case. The arrow on the communicates relation points to the Use-Case.

q Passive Actor The Actor is considered passive in an Actor-Use Case pair when the Use-Case is initiating the communication. Passive Actors will typically be external systems or devices that our system needs to communicate with. The arrow on the communicates relation points to the Actor.

This recommendation is made because the notion of active and passive actors adds value to the reader of the Use-Case model.

2.3 Use of the <<Include>> and <<Extend>> relationships

In the first instance, it is recommended that you avoid the use of these relationships. This recommendation is made because the misuse of these relationships has much more potential to clutter and confuse than they have to help simplify the Use-Case Model. The best practice is to avoid this type of decomposition initially, and consider using these relationships at a later stage in the process. These relationships can be used to:

Factor out behavior that is in common for two or more use cases.

Factor out behavior from the base use case that is not necessary for the understanding of the primary purpose of the use case, only the result of it is important.

To show that there may be a set of behavior segments of which one or several may be inserted at an extension point in a base use case.

But they should only be used where they add value by helping to simplify and manage the use-case model.

2.3.1 Use of the <<Include>> relationship

The include-relationship describes a behavior segment that is inserted into a use-case instance that is executing the base use case. It is a mechanism similar in nature to a sub-routine, and is most often used to factor out common behavior.

2.3.2 Use of the <<Extend>> relationship

The extend-relationship is a more difficult relationship to take advantage of, primarily because the extension use-case is not known to the base use case. As a general comment, there are few places where this relationship is useful in most business systems. Keep in mind however, that there are always exceptions to the rules, and that this mechanism can be useful in certain circumstances.

2.4 Use of Actor-Generalization

In general, Actor-Generalization can be used to better define the different roles played by the users of the system to be developed. This is useful in applications with different “categories” of end-users. In this way, only relevant functionality will be presented to each category of users, and we are able to control the access rights based on this grouping.

Rule of thumb : Each use-case will only be initiated by one Actor. This “rule” may be overridden, in which case the use-case description must justify the decision.

Example from the University’s Business Domain: Librarian and Professor are examples of two existing roles (actors) in the University Domain. These roles have some common tasks and some tasks that are unique to their role in the Business. The preferred way of modeling this is shown below. Image Detail Above in Content

2.5 Use of Interaction Diagrams

In some cases, it is beneficial to include - in addition to the textual flow of events - an Interaction diagram to illustrate the “high level” flow of events of the use case. It is recommended you draw a sequence diagram for this in Rational Rose. Include only the communication between the actors and the boundary objects (covering both the input and the output messages) and treat the system as a black box. Use boundary objects with logical names as defined in the use case flow of events, without assigning them to classes at this point.

It is not necessary for every use case to have a corresponding interaction diagram: It is an optional deliverable.

2.6 Use of Activity Diagrams

Where an activity diagram adds value in helping to define, clarify and complete the flow of events in the use case, it is recommended these are modeled in Rational Rose. A good rule of thumb is to consider Activity Diagrams for complex use-cases (containing several alternate and / or exceptional flows). The activity diagram shows a decision tree of the flows in the use-case.

It is not necessary for every use case to have a corresponding activity diagram: It is an optional deliverable.

For additional guidelines on Activity Diagram in the Use-Case Model, see the Rational Unified Process.

3. How to Describe a Use Case

3.1 Actor Guidelines

3.1.1 Each concrete Use Case will be involved with at least one Actor

Is each concrete use case involved with at least one actor? If not, something is wrong; a use case that does not interact with an actor is superfluous, and you will either remove it or identify the corresponding actor.

In some cases, more than one actor may play a part in the use case interaction. Be sure to check that the use of multiple actors in the one use case is valid (see Actor Generalization).

3.1.2 Intuitive and Descriptive Actor Name(s)

Do the actors have intuitive and descriptive names? Can both users and customers understand the names? It is important that actor names correspond to their roles. If not, change them.

You should refer to the Use Case Model to ensure that you are using the correct actor name for every actor in your use case.

3.1.3 Consistent Use of Actor Name(s)

The use case specification will be written using actor name(s) consistently. Care will be taken to ensure actor naming is clear and unambiguous.

Do not refer generically to “the actor”; instead use the actual name used to uniquely identify or define the actor. The actor name can be thought of as the role being played in a set of system interactions.

3.2 Use Case Name

The use-case name will be unique, intuitive, and explanatory so that it clearly and unambiguously defines the observable result of value gained from the use case.

A good check for the use-case name is to survey whether customers, business representatives, analysts and developers all understand the names and descriptions of the use cases. Remember: You are defining an observable result of value from the actors perspective.

Each use-case name will describe the behavior the use case supports. The name will combine both the action being performed and the key element being “actioned”. Most often, this will be a simple Verb/ Noun combination. The use case should be named from the perspective of the actor that triggers the use case. Examples include: “Register for a course”, “Select a course to teach”.

3.3 Use Case Brief Description

3.3.1 At least 1 paragraph

The use case will contain a brief description. This description will be at least 1 paragraph and no more than 3 paragraphs in length. The description will cover an explanation of the key purpose, value proposition and concepts of the use case.

3.3.2 An example (Optional)

Where it adds value, a short example “story” can be included with the brief description that helps to provide further context. This example will usually follow the Basic Flow, and where helpful will include data values.

3.4 Consistent use of the imperative: Will

System requirements within the use cases will be written using the imperative. The term “Will” has been chosen in favor of “Shall” and “Must” to describe requirements consistently. The use of passive terms that imply the requirement is optional or undefined such as “should”, “possibly”, “etc”, “might” or “may” will be avoided.

3.5 Use of Glossary Terms

All Business Terms used in a use case will be defined in the project’s Glossary. If a Business Term exists in a use case that does not exist in the glossary, the term needs to either:

Be added to the glossary, including a brief description (max. one paragraph).

Be changed in the use case to reflect the correct Business Term defined in the glossary.

3.6 Use of “Action” Terms

3.6.1 Define where the system is responsible for presenting the Action Option

The use case will explicitly state where the system is responsible for presenting an action as an available option for the actor to select. In most cases, the available options should be presented as part of the basic flow, and be referenced as the entry point in the first statement in the corresponding alternative flow.

3.6.2 Consistent use of the term throughout the Use Case

The use of terms such as New, Modify, Cancel, Delete, OK, and Print will be consistent throughout the use case: The same logical action will not be referred to using different terminology. Special care will be taken to ensure that the Action Terms used in the Alternative Flows match those used in the basic flow.

3.7 Separate paragraphs for Actor and System behavior

Each time the interaction between the actor and the system changes focus (between the actor and the system), the next segment of behavior will start with a new paragraph. Begin first with an actor and then the system.

The sentence must begin with ‘The <actor-name> will xxxxx’, or ‘The system will xxxx’. Always state the actor name correctly, in full, rather than any abbreviation.

3.8 Alternate and Sub-Flows

Each Alternate and Sub-Flow will explicitly and clearly define all of the possible entry points into the flow, and will conclude with all of the possible exit points from the flow.

The alternate flow will also state explicitly the exit point and where the actor continues to next - whether it is returning to a specific step in the basic flow, or ending.

Where the flow of events becomes cluttered due to complex behavior, or where a single flow exceeds a physical printed page in length, sub-flows can be used to improve clarity and manage the complexity. Sub-flows will be written by moving a self-contained, logical group of detailed behavior to a sub-flow, and referencing this behavior in summary form within the flow of events.

3.9 Preconditions and Postconditions

The use case specification will include a set of conditions (also referred to as assumptions) that are expected to be true before the use case begins (preconditions) and after the use case has ended (postconditions). Note that the use case may end in a number of ways, and each “postcondition” should be described accordingly.

3.10 Use of placeholders for missing detail (TBD)

Where information is not yet defined or not yet decided, the use case will include a reference to the issue or element and will include the placeholder: TBD.

3.11 Definition of and Reference to Supplementary Specifications

Where there are additional requirements that cannot be described naturally during the flow of events, these will be defined as supplementary requirements. For those that are specific to a use case, these will be defined in the Special Requirements section of the use case specification.

For those requirements that are applicable system-wide, especially those of a non-functional nature, will be defined in one or more separate supplementary specification documents.

Examples includes:

Reliability:

The system must be available 24 x 7.
The system must run for 48 hrs MTBF.

Performance:

The system must provide an online response that does not exceed 5 seconds under the expected normal load conditions.

3.12 Crosscheck with UI Prototype/ Design

The use case contents will be cross-checked against the UI Prototype/ Design to ensure no system requirements are missing from the use case or the UI Prototype/ Design. Where changes are required to the use case, these will be actioned: Changes to the UI Prototype will be noted as a discussion for future action.

3.13 Exception Flows (Optional)

The following guidelines are provided in assisting in the discovery of Exception Flows:

3.13.1 What can go wrong?

For each step in the use case, consider what can go wrong. Each unique exception can be captured as an Exception Flow. In some cases, a single Exceptions Flow will be used commonly across the use case, e.g. “Timeout”. The key information to be captured is what the business requirement is when the exception occurs, i.e. what should the actors experience be?

Differences Between UML 1.x and UML 2.0

Topics

Overview
Activity Diagram
Communication Diagram
Composite Structure Diagram
Component
Sequence Diagram

Overview

This page describes some differences from UML 1.x and UML 2.0 that are relevant to RUP context. It is not intended to cover all UML ([UML04]) Infrastructure and Superstructure Specifications, but to give an overview of relevant UML capabilities instead. Also, refer to [RUM05] and [ERI04] for more information.

Note that “UML 1.x” refers to UML 1.0 to UML 1.5 versions.

The most significant diagrammatical changes in the UML 2.0 feature set are in the behavioral diagrams, specifically the activity diagram and the set of interaction diagrams (see Activity Diagram, Sequence Diagram and Communication Diagram below).

Composite Structure Diagram and Structured Class are also new UML 2.0 features (see Composite Structure Diagram below).

Activity Diagram

Introduction

The modeling of activities has undergone a complete revision in UML 2.0. It is fair to say that, at least for casual use, the effect and appearance might be very similar, although depending on the formality of modeling in UML 1.5 (and earlier versions), it is possible that the strict interpretation and the execution result of a model constructed according to UML 1.x rules would not be the same in UML 2.0. Therefore we caution the modeler that even when a UML 1.x activity model appears to be acceptable to UML 2.0 without change, it might not execute in the same way - particularly in the case of more complex models involving concurrency. Refer to [UML04] for more information.

As [UML04] defines it, an activity (which will be shown in an activity diagram) is the specification of behavior as the coordinated sequencing of subordinate units whose individual elements are actions. We may have informally referred to the individual executable steps in a UML 1.x activity diagram as activities or activity states or, correctly, as action states: now these steps in a UML 2.0 activity are called actions - and these actions are not decomposed further within the activity. The connotation of state has disappeared in UML 2.0 because an activity is no longer a kind of state machine, as it was in UML 1.x. In UML 2.0, activities are composed of nodes, of which actions are one kind; others, described further below, are control nodes and object nodes.

Flow Semantics

Activities now have Petri Net-like semantics, based on token flow, where the execution of one node affects the execution of another through directed connections called flows. Tokens, containing objects or a locus of control, flow between nodes across these connections. A node is allowed to begin execution when specified conditions on its input tokens are met, and when it completes execution, it offers tokens on its output flows, so that downstream nodes may begin execution. The flows connecting nodes are further refined into control and data or object flows and, as you might expect, control tokens move across control flows and object or data tokens pass across object flows.

This contrasts with UML 1.x, where the nodes were states (or pseudo states) with transitions between them, which limited the modeling of flows.

Concurrency Modeling

The modeling capability of UML 2.0 allows unrestricted parallelism: whereas in UML 1.x, the entire state machine (activity) performed a run-to-completion step, the UML 2.0 capability, in its most complete form, permits multiple invocations of an activity to be handled by a single execution with multiple streams of tokens moving through the nodes and flow connectors of the activity. This puts the onus on the modeler to be aware of race conditions and interactions. Also, see the section Semantic Differences below for another example of the effect on concurrency modeling of token flow semantics.

Notation

Action and Control Nodes

The diagram below illustrates many of the UML 2.0 elements, and is presented in the usual way for UML 2.0, with a rectangular frame and a name in a compartment at the upper left. Compare this diagram with the UML 1.x version shown below it. They are similar in appearance (allowing for the differing orientation and color conventions used-these have no semantic significance), and this model has the same execution result in UML 1.x and UML 2.0. Note that the control nodes - decision, merge, fork, join, initial and final - look like their UML 1.x equivalents, and the control flows are shown with an arrowed line, a visual analog to the UML 1.x transition arrow.

This shows an activity diagram that illustrates the various node types: initial, action, decision, fork, join, merge and activity final. It also shows control flow.

Example UML 2.0 activity diagram

This diagram shows the equivalent UML 1.x version.

Example UML 1.x activity diagram

UML 2.0 has an additional control node type called Flow Final (shown below in a diagram taken from [UML04]) that is used as an alternative to the Activity Final node to terminate a flow. It is needed because in UML 2.0, when control reaches any instance of Activity Final node, the entire activity (including all flows) is terminated. Flow Final simply terminates the flow to which it is attached. This was not an issue in UML 1.5 because of the run-to-completion semantics, but with the unrestricted parallelism of UML 2.0, you might not want all flows stopped and all tokens destroyed.

This diagram illustrates the flow final control node.

Flow final control node

Object Nodes

UML 2.0 activity modeling also supports object nodes. An object node is an activity node that indicates that an instance of a particular classifier, possibly in a particular state, might be available at a particular point in the activity (for example, as output from, or input to an action). Object nodes act as containers to and from which objects of a particular type (and possibly in a particular state) might flow. New notation, called a pin, has been introduced for object nodes in UML 2.0. Pins represent inputs to an action or outputs from an action and are drawn as small rectangles that are attached to the action rectangles, as shown below.

This diagram shows the pin notation for object nodes, with an output pin connected to an input pin by an object flow.

Pin notation

The arrows represent object flows. These are solid lines, unlike the dashed lines used for transitions to and from object flow states in UML 1.x. When the output pin on an action has the same name as the input pin on the connected action, the output and input pins may be merged to give a standalone pin. This again gives a visual analog to object flow in UML 1.x.

This diagram shows the alternative standalone pin notation.

Standalone pin notation

Structured Activity Nodes

A structured activity node is an executable activity node that may have an expansion into subordinate activity nodes. The subordinate nodes belong to only one structured activity node, but they may be nested. It may have control flows connected to it and pins attached to it. A structured activity node is drawn as a dashed round cornered rectangle enclosing its nodes and flows, with the keyword <<structured>> at the top.

Activity Partitions

An activity partition is a way of grouping the nodes and flows of an activity according to some shared characteristic. In UML 1.x, the idea of swimlanes (which were regarded as partitions) was used in activity diagrams to group actions according to some criterion - for example, in business modeling, by performing organization. UML 2.0 extends this partitioning capability to multiple dimensions for activity diagrams and provides additional notation so that, for example, individual actions can be labeled with the name of the partition to which they belong. The diagram below shows an example of multidimensional swimlanes as they would appear according to UML 2.0, where actions are grouped according to location and responsibility.

An illustration of the UML 2.0 style of activity partitions, with two dimensional swimlanes.

Activity partitions example using two-dimensional swimlane

Semantic Differences

The token flow semantics and the unrestricted parallelism of UML 2.0 activity models require the modeler accustomed to UML 1.x to exercise caution when constructing new models or converting existing models, to ensure the execution result is that intended. For example, in the processPassenger example above, the passenger checking in might be a frequent flyer member, in which case, the agent needs to award the passenger frequent flyer miles, as shown below in a UML 1.x model fragment.

This diagram shows a UML 1.x model fragment with a guarded concurrent transition.

Using guarded concurrent transition

Placing the guard on the optional concurrent transition means that, in UML 1.x, the transition never starts, and the behavior is as if the transition were not shown in the model; accordingly, when the other two transitions complete, execution continues after the join. In UML 2.0, if the passenger is not a frequent flyer, no token will ever reach the join along that flow and the model will stall because the join waits for tokens on all its flows before continuing. The model should be constructed as shown below, with the condition treated in the same way as the baggage handling flow. It is permissible to place guards directly on concurrent flows as long as you are sure no downstream join depends on them.

This diagram shows a UML 2.0 version of the previous diagram, using decision and merge nodes instead of the guarded concurrent flow.

Using decision and merge nodes instead of the guarded concurrent flow

Communication Diagram

The UML 1.x collaboration diagram has been renamed to communication diagram in UML 2.0. There are no semantic differences from previous versions. The communication diagram is based on the former collaboration diagram and still is one type of interaction diagram.

Notation

A communication diagram focuses on the interaction between lifelines. It is shown as a graph whose nodes are rectangles representing parts of a structured class or roles of a collaboration. A rectangular frame around the diagram with a name in a compartment in the upper left corner is used, which is a notational change from previous UML versions.

The nodes correspond to the lifelines in an interaction. Lines between parts represent connectors that form communication paths. Multiplicities may be shown on connectors. Messages between parts are shown by labeled arrows near connector lines. A communication diagram is used to model interactions that represent the implementation of an operation or use case.

Example of a communication diagram:

Example of Communication Diagram for an Ordering system.

Example of Communication Diagram for an Ordering system

Component

In UML 2.0, a component is notated by a class symbol without the two protruding rectangles, as defined in UML 1.4. A <<component>> stereotype is used instead. Optionally, a component icon that is similar to the UML 1.4 icon can still be used in the upper-right corner of the component symbol.

UML 2.0 defines a component as being a structured class, which means that the collaboration between elements in its internal structure (parts) can be modeled to better describe its behavior. Parts are connected through connectors. Ports can be used to increase encapsulation level of a component through its provided and required interfaces. Refer to Concepts: Component and Concepts: Structured Class for more information.

Earlier versions of UML defined a special modeling element called subsystem, which was modeled as a package with interface. Also, components were used to structure the model in the physical architecture. In UML 2.0, components are used in a broad sense, across all parts of the model. Thus, there is no need for a special element to model subsystems anymore. Separate compartments for subsystem realization and subsystem specification in UML 1.x have become separate stereotypes (<<realization>> and <<specification>>, respectively) applied to components in UML 2.0. Another new component stereotype is <<subsystem>>, indicated to model large-scale components.

RUP suggests using components to model subsystems (refer to Guidelines: Design Subsystem for more information).

Composite Structure Diagram

Architectures can have specific collaboration between its elements, with parts and connectors not necessarily known at design time. A typical class diagram (as well as other static diagrams) wouldn’t be sufficient to clearly represent the roles, responsibilities, relationships and rules that apply on those elements.

To address these issues, UML 2.0 has added the composite structure diagram. It can depict the internal structure of a structured class (for example, component or class), including the interaction points of the structured class to other parts of the system. It shows the configuration of parts that jointly perform the behavior of the containing structured class.

Composite Structure Diagrams are used to draw internal content of Structured Classes (refer to Concepts: Structured Class for details and examples of Composite Structure Diagrams).

Sequence Diagram

UML 2.0 has several new features for sequence diagrams:

Fragments provide clearer semantics for how the behavior occurs within a sequence diagram. A combined fragment encapsulates portions of a sequence diagram, where separate flows can be modeled, showing how conditions lead to alternative paths of execution.

Interaction occurrences enable decomposition of interactions into reusable chunks. It is a useful way to share portions of an interaction between several other interactions.

In UML 1.x, one possible representation for loops was to use the loop condition written inside a Note. The Note was attached to the message or set of messages to be executed while the loop condition was true. In UML 2.0, there is a specific representation for loops.

In UML 2.0, sequence diagrams can show how objects are created and destroyed.

Execution of Occurrence shows the focus of control which an object executes at some point in time, when it receives a message.

With the new capabilities to represent fragments, interaction occurrences and loops, sequence diagrams can be used in two forms:

Instance form: describes a specific scenario in detail, documenting one possible interaction, without conditions, branches, or loops. This form is used to represent one use case scenario. Different scenarios of the same use-case are represented in different sequence diagrams. Modeling tools that support UML 1.x semantics only allow this form of representation.

Generic form: describes all possible alternatives in a scenario, taking advantage of new UML 2.0 capabilities like conditions, branches, and loops. This form can be used to represent several scenarios of the same use case in a unique sequence diagram, where it makes sense.

The figure below shows an example of a sequence diagram modeling different scenarios. The alt fragment shows two possible alternatives of message sequencing depending on if a condition is satisfied or not:

Sequence diagram showing branches, loops and conditions

Example: Sequence diagram showing branches, loops and conditions

What’s New: Rational Unified Process

From the Rational Unified Process 2003.06.01 to 2003.06.13
From the Rational Unified Process 2003.06.00 to 2003.06.01
From the Rational Unified Process 2002.05.00 to 2003.06.00
From the Rational Unified Process 2001A.04.00 to 2002.05.00
From the Rational Unified Process 2001.03.00 to 2001A.04.00
From the Rational Unified Process 2000 to 2001.03.00
From the Rational Unified Process 5.5 to 2000
From the Rational Unified Process 5.1.1 to 5.5

From the Rational Unified Process 2003.06.01 to 2003.06.13

This service release includes the following changes:

Significantly greater compliance with accessibility standards
Updates to reflect UML 2.0 notation and terminology
Collaboration Diagram was renamed Communication Diagram
Implement Dependency was renamed Manifest Dependency
Component diagrams were updated with new component shape
Added Concept: Structured Class
Added comments about and example of sequence diagram new capabilities
Added comments about and examples of activity diagram new capabilities
Design Subsystems are now represented as components

From the Rational Unified Process 2003.06.00 to 2003.06.01

This is a service release including mostly minor changes. These include:

Mandatory inputs have been defined for business modeling activities, and updated for other activities
Activity “Deploy the Product” has been removed
Updated ClearCase and ClearQuest tool mentors
New model structuring guidelines for Rational XDE Develoloper .NET Edition
New guideline for cost estimation using the Wide-Band Delphi technique
Updated formatting of artifact and activity pages

From the Rational Unified Process 2002.05.00 to 2003.06.00

General Changes

Improved User-Configuration of the Process with RUP Builder
- The process has been refactored across all disciplines to create more than 60 selectable components, with improved ability to mix and match both plug-ins and components.
- Small, medium, and large project configuration templates provide a starting point for process configuration.
Formal and Informal Resources plug-ins allows flexibility in “level of ceremony”.
Contextual views into RUP are provided, such as the “developer” role view, and “getting started” view.
Improved generation of graphics and tables that reflect the selected process configuration.
Personal Process View or My RUP Personalization
- Each RUP user can create his/her own personalized view into RUP.
- Users can add links to external and internal resources.
Tool Integration
- New and Updated Tool Mentors:
  - New tool mentors for Rational XDE, RUP Builder, and Rational Process Workbench.
  - New tool mentors for using the RUP Web site, including searching, extended help and navigation.
- Extended Help launches a view in RUP.
- Search engine provides seamless search across RUP and RDN, and other new options.
Content
- Guidelines, concepts, white papers, and checklists can now be attached to any process element, and so are now associated to the process elements where they are most relevant. The separate concept of a “Work Guideline” is gone.
Look and Feel
- The Web site’s navigation and layout has been upgraded to align with other Rational Web products.

Specific Changes and Additions to Content

Overview
- New “Getting Started” page provides answers to commonly asked questions for those new to RUP, and is presented along with relevant content as part of a specific process view in the tree browser. Note: The “Getting Started” view can be disabled by either a) for the entire project team, republishing the RUP Web site from RUP Builder and excluding the “Getting Started” process view or b) for the individual practitioner, using the “Tree Sets” feature of the tree browser to display a single process view of your choice.
RUP Lifecycle
Example Iteration Workflows provide a phase-based and time-based view into the process.
Disciplines
- Concepts pages are no longer all grouped under each discipline, but are now attached to the most relevant process element. Only those concepts and guidelines needed to understand the discipline as a whole are directly attached to the discipline.
- All technical reviewer roles, such as Business Model reviewer and Design Reviewer, have been replaced by a single Technical Reviewer role, which now performs all technical review activities across the disciplines.
Business Modeling Discipline
New support for modeling business rules, goals, and events.
Artifact: Business Object Model has been renamed to Business Analysis Model.
Requirements Discipline
- A generic “Software Requirement” has been added in support of more flexible process configuration by the project team.
- The guidance on storyboarding has been generalized by removing the dependency on use cases. (See Artifact: Storyboard).
- User Interface Design has been moved to the Analysis and Design Discipline.
- Artifact: User-Experience Storyboard has been added to the separate User Experience Plug-In to address user-experience design concerns.
Analysis and Design Discipline
- Data Modeling content has been upgraded to cover conceptual, logical, and physical database modeling.
- User Interface Design content has been moved from the Requirements Discipline and upgraded to reflect industry practices, including the new artifact Navigation Map.
Implementation Discipline
Artifact: Component has been replaced with Artifact: Implementation Element.
Improved guidance on component-based development and round-trip engineering.
New guidance on developer testing, debugging, and analysis of run-time behavior.
Test Discipline
- Separate templates for Master and Iteration Test Plans.
- New Test Strategy artifact.
Environment Discipline
Guidance on defining the organizational process environment has been broken out into a separate process packaged with RPW , leaving the RUP to focus on Project Environment only.
Improved guidance for implementing a process for a project, supported by the RUP tooling for customization and configuration of process.
New Artifact : Development Process and Activity: Tailor the process for the project, to describe the project-specific process.
All “Guidelines” type artifacts, such as “Design Guidelines” and “Business Modeling Guidelines”, have been replaced by a single more generic artifact, “Project-Specific Guidelines”.
Project Management Discipline
New Reviewer and Review Coordinator roles were added to better describe the review process.

From the Rational Unified Process 2001A.04.00 to 2002.05.00

Release 2002.05.00 is the successor to release 2001A.04.00. It adds or changes content in the following topic areas:

All RUP process variants are no longer installable from the Rational Suite installer. They can now be installed using RUP Builder, shipped with this release of RUP.
RUP Builder has been added:
Real-time specific content is componentized into its own plug-in, separately installable.
Microsoft variant is componentized into its own plug-in, separately installable.
The IBM variant is componentized into its own plug-in, separately installable.
Restructure and Extension of Test Discipline:
Changes
- Complete restructure of the Test Discipline Workflow and associated Workflow Details
- Removed Existing Workflow Details and replaced with Iteration Goal focused work elements.
- Rename and refactoring of existing Activities
- Restructure of existing Test roles
- Tester role now responsible for Test Implementation and Execution
- Overloaded Test Designer role activities and artifacts distributed to other roles
- Recast the following Activities
  - Plan Test-now multiple activities across Role
  - Design Test-now multiple activities across Role
  - Execute Test-replaced by Execute Test Suite
  - Evaluate Test-now multiple activities across Role
Additions
- Introduced the following Roles
  - Test Manager
  - Test Analyst
- Introduced the following Workflow Details
  - Define Evaluation Mission
  - Verify Test Approach
  - Test and Evaluate
  - Achieve Acceptable Mission
  - Improve Test Assets
- Introduced the following Activities
  - Agree Mission
  - Identify Test Motivators
  - Obtain Testability Commitment
  - Assess and Advocate Quality
  - Assess and Improve Test Effort
  - Identify Targets of Test
  - Identify Test Ideas
  - Define Test Details
  - Define Assessment and Traceability Needs
  - Determine Test Results
  - Define Test Approach
  - Define Test Environment Configurations
  - Identify Testability Mechanisms
  - Define Testability Elements
  - Implement Test Suite
  - Execute Test Suite
  - Analyze Execution Failure
- Introduced the following Artifacts
  - Test Automation Architecture
  - Test Data
  - Test Environment Configuration
  - Test-Ideas List
  - Test Interface Specification
  - Test Suite
  - Test Log
- Introduced improved Developer Testing Guidance
  - Test-First Design
  - various concepts and guidelines focused on Testing for Developers
Deletions
Removed the following Artifacts
- Test Model
- Test Procedure
- Test Package
- Test Subsystem
Added new Roadmap: Using Agile Practices with RUP.
Enhanced Key Concepts.
Improved navigation buttons for the Disciplines
Added new white paper “Content Management Defined”.
Added new sample configuration for Small Project.
Added new tool mentors:
- Tool Mentor: Profiling Memory Usage in Managed Code using Rational Purify and Rational Purify® Plus (Windows)
- Tool Mentor: Comparing Baselines using Rational ClearCase®
- Tool Mentor: Finding Actors and Use Cases Using Rational Rose RealTime®
- Tool Mentor: Detailing a Use Case Using Rational Rose RealTime®
- Tool Mentor: Structuring the Use-Case Model Using Rational Rose RealTime®
- Tool Mentor: Creating Use-Case Realizations Using Rational Rose RealTime®
- Tool Mentor: Managing Classes Using Rational Rose RealTime®
- Tool Mentor: Managing Collaboration Diagrams Using Rational Rose RealTime®
- Tool Mentor: Managing the Design Model Using Rational Rose RealTime®
- Tool Mentor: Managing Sequence Diagrams Using Rational Rose RealTime®

From the Rational Unified Process 2001.03.00 to 2001A.04.00

Release 2001A.04.00 is the successor to release 2001.03.00. It adds or changes content in the following topic areas:

New tool mentors created for new products:
Rational Rose RealTime Tool Mentors
Setting Up Version Control using Rational Rose RealTime with Rational ClearCase
Capturing a Concurrency Architecture using Rational Rose RealTime
Designing with Active Objects in Rational Rose RealTime
Rational ProjectConsole Tool Mentors
- Browsing Project Artifacts Using Rational ProjectConsole
- Creating a Static or Portable Copy of your Rational ProjectConsole Web Site Using Rational ProjectConsole
- Displaying Artifacts Related to Specific Objects on a Diagram Using Rational ProjectConsole
- Visiting Source Data Using Rational ProjectConsole
Rational QualityArchitect Tool Mentors
- Implementing an Automated Component Test using Rational QualityArchitect
New tool mentors for TestManager:
- Executing a Test Suite Using Rational TestManager
- Designing an Automated Test Suite Using Rational TestManager
“Core Workflow” has been changed to “Discipline” throughout.
Tree browser changes:
- The “Rational Unified Process” entry under Tool Mentors have been moved to “Process Engineer Toolkit”
- The Report Overview, Guidelines Overview, Examples Overview and Stereotypes Overview items have been moved from Artifact to Overview.
Addition of hyperlinked Tree Path at the top of each page to indicate location in RUP treebrowser
Upgraded graphics on buttons and icons.
Addition of new roadmap for Usability Engineering.
Incorporated new example Organization Web and example Project Web, based on the previous Wylie College artifact example set.
C-Sports example artifacts are now installed directly, instead of requiring a separate “unzip” installation.
The following new white papers have been added:
- RUP/XP Guidelines: Pair Programming
- RUP/XP Guidelines: Test-first Design and Refactoring
- A Comparison of RUP and XP
- The Rational Unified Process - An Enabler for Higher Process Maturity

From the Rational Unified Process 2000 to 2001.03.00

Release 2001.03.00 is the successor to release 2000. It adds or changes content in the following topic areas:

A new workflow detail - Perform Architectural Synthesis - has been added to Analysis and Design, for use during the Inception phase for construction of an Architectural Proof-of-Concept, to help with technology selection, and show that the envisioned system is feasible.
The role Architect has been renamed Software Architect, to distinguish that role from other architectural roles, for example, System Architect.
Guidelines for the use of Microsoft® Windows DNA technology have been added to the Development Component Solutions roadmaps.
Updated examples
Tailoring guidance provided for all artifacts
Updated Requirements Management Plan template
Upgraded Requirements Management activities - term “traceability item” is used to generalize to artifact beyond just “requirement types”
Guidance on how to manage requirements has been updated, including new Guidelines: Requirements Management Plan
new Small Project roadmap, Tailoring Concepts, Small Project Development Case example, and Core Workflow Essentials
Activity: Perform Configuration Audits has been reworked and enhanced
Staffing sections have been added to those roles without one
Best Practice: Visual Modeling has been fleshed out with more details
The word “worker” has been changed to “role” for clearer understanding of the different roles a team member might perform.
New tool mentors created for existing products:
- Tool Mentor: Creating Multiple Sites Using Rational ClearCase
- Tool Mentor: Evaluating Code Coverage Using Rational PureCoverage (UNIX)
- Tool Mentor: Detecting Run-Time Errors Using Rational Purify (UNIX)
- Tool Mentor: Finding Performance Bottlenecks Using Rational Quantify (UNIX)
- Tool Mentor: Archiving Requirements Using Rational RequisitePro
- Tool Mentor: Setting Up Rational Rose for a Project
New tool mentors created for new products:
- Rational Process Workbench Tool Mentors
  - Setting Up and Configuring Rational Process Workbench Tool
  - Setting Up and Managing Rational Process Workbench Workspace
  - Developing Process Models
  - Managing Process Content
  - Defining a Custom Process
  - Publish a Process

From the Rational Unified Process 5.5 to 2000

Release 2000 is the successor to release 5.5. It adds or changes content in the following topic areas:

Business Modeling Workflow
- Four new concepts pages have been added to clarify the role of business modeling in the context of e-business development.
- The page Concepts: Activity Based Costing outlines how the technique can be applied within the RUP.
- The page Concepts: Business Architecture explains our definition of what it means to architect a business.
- The page Concepts: Business Patterns gives some examples of useful patterns to apply in business modeling.
- The page Concepts: e-business Development gives our definition of the term.
- Three new workflow details have been added to the workflow diagram: “assess business status”, “describe current business”, and “explore process automation”.
- Workflow detail: Assess Business Status describes how you assess the status of the organization in which the eventual system is to be deployed (the target organization).
- Workflow detail: Describe Current Business talks about how you work to describe the current organization’s processes and structure in order to better understand needs for improvement.
- Workflow detail: Explore Process Automation talks about how you determine what can and should be automated of the business processes, how you understand how any existing systems (legacy) should fit into the organization, and how you derive system requirements from your business models.
- Five new artifacts have been added: “target-organization assessment”, “business vision”, “business glossary”, “business rules”, and “business architecture document”.
- Artifact: Target-Organization Assessment describes the current status of the organization in which the system is to be deployed. The description is in terms of current processes, tools, peoples’ competencies, peoples’ attitude, customers, competitors, technical trends, problems and improvement areas.
- Artifact: Business Vision is a general vision of the core project’s requirements, and provides the contractual basis for the more detailed technical requirements.
- Artifact: Business Glossary defines important terms used in the business engineering portion of the project.
- Artifact: Business Rules is a document capturing declarations of policy or conditions that must be satisfied.
- Artifact: Business Architecture Document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system.
Requirements Workflow
- The page Concepts: User-Centered Design explains how to better meet user needs and improve user acceptance by focusing on the goals and need of the user when designing the user interface.
- The Artifact: Stakeholder Requests and Workflow Detail: Understanding Stakeholder Needs were improved to include more focus on collecting user and stakeholder profiles.
- Expanded User Profile section in the Vision Document.
- The Guidelines: Software Requirement Specification was expanded to include material from IGS Component Broker Engagement Methodology on Defining Non-Functional Requirements.
Analysis & Design Workflow
- New artifacts:
  - Reference Architecture
  - Deployment Model
- Modified activity:
  - Architectural Analysis to reflect the development of an architectural overview, selection of a reference architecture and the development of a deployment model.
- Software Architecture Document guidelines to describe the identification of architecturally significant change cases
- A new concepts page has been added to describe Web Architecture Patterns. This is taken from the book “Building Web Applications with UML”, with the kind permission of the author Jim Conallen and the publisher Addison-Wesley.
- A new guidelines page for class design called “Building Web Applications with UML” has been added.
- A small clarification has been added to the page Milestone: Lifecycle Architecture on the role of prototyping in elaboration, and to the page Phase: Inception, on the use of prototyping during architectural synthesis in inception.
Environment Workflow
- There is a new entry in the Getting Started page, called Implementing the Process. This page and the pages it links to, will describe how you implement the RUP in different situations. For example, how to implement the RUP in a development organization; how to implement the RUP in a development project.
- The following artifacts has been added:
  - Tool Guidelines
- The following Guidelines containing new information on how to use artifacts have been added:
  - Guidelines: Classifying Artifacts
  - Guidelines: Review Levels
- The following Concepts have been added with valuable information on how to implement process and tools:
  - Concepts: Environment Practices
  - Concepts: Implementing a Process in a Project
  - Concept: Mentoring
  - Concepts: Pilot Project
- Concepts: Implementing a process in an Organization has been revised.
- The role “Toolsmith” has been renamed “Tool Specialist” The new name better reflects its responsibilities, toolsmithing is just one of several responsibilities.
- Activity: Set Up Tools, Activity: Develop Tool Guidelines and Activity: Verify Tool Configuration and Installation have been added to the Tool Specialist.
- Several tool mentors that describe how to set up tools (one tool mentor for each Rational Tool) has been added. They are all referenced from the new Activity: Set Up Tools.
- The four (4) workflow details in the Environment workflow have been updated with the new activities.
- The Development Case HTML template has been completely revised.
Test Workflow
- Artifact sets now reflect an artifact set for Test.
- Two new test artifacts:
  - Test Results - the data captured during the execution of test which is used as input for the Evaluation of Test and to calculate the key measures of test.
  - Test Evaluation Summary (formerly a report) - created during the Evaluation of Test, this artifact organizes and presents the test results and key measures of test for review and assessment, and contains recommendations for future test efforts.
- The Workflow Details for Execute Test and Evaluate Test have been revised to reflect these two new artifacts.
- The Guidelines for Test Cases contains new information and guidelines for deriving test cases from use cases.
- Modified/Clarified the following test activities:
  - Execute Test - revised this activity to focus the effort on setting-up and execution of test, including recovering from halted or incomplete test execution.
  - Evaluate Test - revised to include the analysis of the test results, logging change requests, and generating the Test Evaluation Summary.
Deployment Workflow
- This workflow has been completely re-worked and has a new introduction, workflow activity diagrams and workflow details
- New Activity Diagram
  - Deployment Workflow Activity Diagram
- New Artifacts:
  - Bill of Materials
  - Product Artwork
  - Deployment Unit
  - Product
- New Roles:
  - Graphic Artist
- New Activities:
  - Define Bill of Materials
  - Manage Acceptance Test
  - Release to Manufacturing
  - Verify Manufactured Product
  - Provide Access to Download Site
  - Create Product Artwork
Configuration and Change Management Workflow
- The Configuration Management section was updated to align with Unified Change Management concepts in the following areas.
- New Activity
  - Project Repository
  - Workspace
- Changes to Activities:
  - Establish CM Policies
  - Set Up CM Environment
  - Create Integration Workspace
  - Create Development Workspace
  - Make Changes
  - Deliver Changes
  - Update Workspace
  - Create Baselines
  - Promote Baselines
  - Create Deployment Unit
- New Tool Mentors:
  - Setting Up the Implementation Model with UCM
  - Working on UCM Activities
  - Delivering Your Work using Rational ClearCase
  - Updating Your Project Work Area using Rational ClearCase
  - Linking Configuration Management and Change Request Management
- New Concepts:
  - Unified Change Management
Project Management Workflow
- The deployment related activities are now owned by the Deployment Manager role. The Project Manager role has been made responsible for the development of the Quality Assurance Plan artifact.
Implementation Workflow
- A new artifact, Build, has been added.
- The role of System Integrator has been renamed Integrator, and this new role assumes the integration responsibilities that previously belonged to the Implementer.
- The purpose of the artifact Implementation Subsystem has been clarified, and its relationship to the artifact Design Subsystem explained.
Under the section on Phases, we have added a description of the Transition phase, and a sample iteration plan for the Transition phase. For each of the phases, we have provided, courtesy of Ensemble Systems Inc, a more detailed Microsoft® Project® template which goes to the activity level.
Artifact sets have been reorganized:
- There is now one artifact set for each core workflow
- An artifact is considered to “belong to” the core workflow in which it is primarily developed
Added new road maps:
- Developing e-business Solutions: A road map has been added that explains how to use the RUP for e-business development.
Re-organization and renaming of Iteration Workflows to Phases.
Added Analyst Studio Tool Mentor section.
Added new guideline, Guideline: Review Levels.
Improvement in the performance of the treebrowser.
Added HTML Templatesfor artifacts that currently have Microsoft® Word® and Adobe® FrameMaker® templates. Included pointers into the HTML template from the artifact pages and removed the embedded Annotated Outlines.
All Word Templates have been compressed into a zip file.
Added Collegiate Sports Paging System example to demonstrate e-business application.
All examples are now compressed into a zip file.
Now supports foreign languages and JDK1.1:
- Added instruction for translating the Rational Unified Process to other foreign languages.

From the Rational Unified Process 5.1.1 to 5.5

Release 5.5 is the successor to release 5.1.1. It adds or changes content in the following topic areas:

Improved ‘Getting Started’ content, including automatic display of getting started topics on product start-up. The automatic start-up may be disabled at the user’s discretion. This feature includes and subsumes the ‘Guided Tour’ concept which appeared in version 5.0. The ‘old’ Guided Tour is now expanded under the ‘Process Roles’ link on the ‘Getting Started’ window.
Simplification of the treebrowser.
Improved process Overview.
Re-designed core workflows, now using Workflow Detail Overviews to express workflows. The workflows are expressed as activity diagrams using workflow details to provide an easier to understand picture of how the work on the project is done.
Expanded ‘Workflow Details’; these have now become the focal point for the expression of workflows in the process.
Improved process configuration and implementation content in the ‘Environment Workflow’.
Improved cross-referencing, to improve product usability. Especially noteworthy are the links between Artifacts and Activities (see Artifact: Software Architecture Document for an example).
Expanded ‘Project Management Workflow’ content, including metrics and estimation, project planning and project control.
Removal of Rational SoDA and Rational Rose model templates from the RUP. These templates are now provided with their respective Rational Software products and are automatically installed when those products are installed. Use of these template is still described in appropriate RUP Tool Mentors.
Java Programming Guidelines have been added.
Added the concept of Roadmaps, which describes how the process can be tailored to a particular style or type of software development. There are two Roadmaps in this release: one for component-based development, and one expressing how a focus on quality manifests itself throughout the lifecycle. We expect more to be included in future releases.
Two new white papers: one covering strategies for traceability, and another describing modeling Web applications with UML.
Added Change Request Management process information in Configuration and Change Management workflow.
Updated Vision template to include more and proper emphasis on stakeholders/user and needs/requests.
New artifacts:
- Software Requirements Specification in the Requirements workflow; templates are included for use both with and without use-case modeling.
- Requirements Management Plan for setting up project requirement artifacts.
Updated document templates to include consistent formats styles, and informational guidance.
FrameMaker templates now available from the RUP Resource Center.
Expanded links and cross-references:
- between artifacts and the activities that use, produce or modify them
- between activities and the workflow details that organize them.

Working with Extended Help

Extended Help lets you view Rational Unified Process (RUP) instructions on topics that are relevant to the Rational tools you use. For example, you can start Extended Help from Rational Rose without interrupting your workflow.

In order to use Extended Help, you must install RUP. Extended Help becomes available as soon as the installation is complete.

When you select Extended Help from another Rational tool’s Help menu, the Extended Help topics appear in a tree panel beside the RUP content. The specific tree panel is identified by the title “Extended Help” and the tool name.


The Extended Help tree panel lists topics that are applicable to the tool and context in the tool that you are using.	Extended Help tree panel screenshot

The rest of this document explains how to launch and navigate Extended Help.

Using Extended Help

To use Extended Help, follow these steps.


In a Rational tool (for example, Rational Rose), click Help > Extended Help on the tool’s menu bar.	Extended Help tree panel screenshot

If you have more than one installed or published RUP Web site, an Extended Help Location Chooser dialog box appears, prompting you to choose the location from which you want to view Extended Help topics. For each RUP Web site, there is an Extended Help, and each Web site might have different topics pertaining to the tool that you are using. In the list at the top of the dialog box, select your desired location. If you want, you can select a check box that makes this the default location for the next time you view Extended Help. Another check box allows you choose to never show the dialog box again. If you choose to never show the dialog box again, the default Extended Help location will subsequently be the one that launches automatically. In this example, the user has chosen to make the selected location the default one and to never show this dialog box again.

Extended Help tree panel screenshot Extended Help tree panel screenshot


To view the topics in the More Content folder, double-click to expand that folder in the tree.	Extended Help tree panel screenshot

Content Management Using the Rational Unified Process

Michael McIntosh is a freelance writer, project methodologist, and Web consultant. Since 1987, he has trained and consulted in project management, Web development, and computer networking. Formerly with Vignette Corporation, he was instrumental in the development of Vignette’s Solution Methods (VSM) 3.0. He lives in Austin, Texas, with his wife, Julie, and son, Willie. Michael can be reached via e-mail.

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. There are additional white papers available on the IBM Web site.

Abstract

This paper presents an overview of content management, particularly as it relates to delivering content on the Web. Content management represents a collection of tools and methods that are used together to collect, process, and deliver diverse types of content. The scope of content management is broad, and its challenges are many.

Collecting and processing content intended for a Web site is a more complex and time-sensitive process than many legacy document management systems are designed to handle. Organizations have turned to the Web as a means of delivering information to, and communicating with, their customers; however, simply uploading content to a Web site does not mean it will reach the proper people or that it will meet their information needs.

Content management projects entail far more than buying or building an application that provides content workflow. The development of a content management solution is a group of related software projects-made up of database, production workflow, content delivery, and Web applications-making it a perfect candidate for an established software development framework such as RUP.

Developing Large-Scale Systems with the Rational Unified Process

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can also download this and other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

There is a considerable increase in complexity when developing large-scale systems. Not only does it require that you are capable of comprehending a more complex set of artifacts, you are also introducing overhead since you need to manage a larger set of resources. This paper describes an architectural pattern that is used to help control the added complexity overhead. The architectural pattern is referred to as a system of interconnected systems.

This paper introduces an architectural pattern for systems of interconnected systems. This construct allows recursion not only within one model, it considers each subsystem a system in its own right and the recursion is between all the artifacts sets of each of the systems. The introduced architecture is used for systems that are implemented by several communicating systems. Each involved system is described by its own set of models, separate from other systems’ models.

The examples given in this paper illustrate that the architecture for modeling systems of interconnected systems is useful in many different application areas. In fact, you may use the suggested architecture for any system where it ’s possible to view the different parts as systems of their own.

Layering Strategies

Peter Eeles is a Technical Lead in Rational’s Regional Services Organization, based in the UK. He has spent the majority of his 16 year career developing large-scale distributed systems and, in 1998, co-authored his first book, “Building Business Objects”. A regular speaker at conferences throughout Europe, Peter spends most of his time consulting in software architecture, and in helping organization adopt the Rational Unified Process. He lives in the UK with his wife, Karen, and sons Daniel, Thomas and Christopher. Peter can be reached via e-mail at peter.eeles@rational.com. .

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it.

Abstract

A number of techniques exist for decomposing software systems. Layering is one example and is described in this paper. Such techniques address two main concerns: most systems are too complex to comprehend in their entirety, and different perspectives of a system are required for different audiences.

Layering has been adopted in numerous software systems, and is espoused in many texts and also in the Rational Unified Process (RUP). However, layering is often misunderstood and incorrectly applied. This paper clarifies what is meant be layering, and discusses the impact of applying different layering strategies.

Modeling Web Application Architectures with UML

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

Web applications are becoming increasingly complex and mission-critical. To help manage this complexity, they need to be modeled. UML is the standard language for modeling software-intensive systems. When attempting to model Web applications with UML, it becomes apparent that some of its components don’t fit nicely into standard UML modeling elements. To stick with one modeling notation for the entire system (Web components and traditional middle tier components), UML must be extended. This paper presents an extension to the UML using its formal extension mechanism. The extension is designed so that Web-specific components can be integrated with the rest of the system’s model, and to exhibit the proper level of abstraction and detail for suitable for designers, implementers, and architects of Web applications.

System Variants

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

This paper discusses what variants of systems are and how to manage them. You do not need to read this to understand the RUP; on the contrary, it should be treated as an extension to the RUP. The last section briefly discusses how the RUP would be affected by the introduction of variants and variability.

This is an area in which the RUP will improve and expand in the future and this paper gives a first taste of that.

Testing Embedded Systems - Do You Have the GuTs for It?

Vincent Encontre is the Director for Embedded and RealTime, Automated Testing Business Unit, based in Rational’s new engineering center in Toulouse, France. When he’s not traveling, attending meetings, or answering zillions of emails, Vincent looks at the destiny of Rational Test RealTime as a Rational product and as reusable technologies for next generations of Rational products. Vincent has extensive experience in embedded modeling and testing technologies and best practices. Prior to Rational and ATTOL, Vincent spent 13 years at Philips, then at Verilog, designing, marketing, and supporting software engineering tools, believing these tools could help build better software faster. In his spare time, Vincent plays soccer with his three boys and a few others, and just enjoys the wonderful art de vivre from the south of France (before it’s too late…).

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other RUP white papers from the IBM Web site.

Abstract

This paper gives a general introduction to testing embedded systems followed by a discussion of how embedded systems’ issues affect testing processes and technologies, and how Rational Test RealTime provides solutions to these issues.

It presents an overview of the process of six incremental steps used to test embedded systems. Considering this process (taking into account the full spectrum from very small to very large systems), and the specific characteristics and constraints of embedded systems, we have deduced a set of requirements that an ideal technology must possess to address the testing of embedded systems. Rational Test RealTime, the new Rational offering to the embedded systems domain, exemplifies large portions of this ideal technology.

The Ten Essentials of RUP - The Essence of an Effective Development Process

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

To effectively apply a software development process such as the RUP, it’s important to first understand its key objectives, why each is important, and how they work together to help your development team produce a quality product that meets your stakeholders’ real needs.

Using the RUP for Small Projects: Expanding upon eXtreme Programming

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can also download this and other RUP white papers from the IBM Web site.

Abstract

RUP is a complete software-development process framework that comes with several out-of-the-box instances. Processes derived from RUP vary from lightweight-addressing the needs of small projects with short product cycles-to more comprehensive processes addressing the broader needs of large, possibly distributed, project teams. Projects of all types and sizes have successfully used RUP. This white paper describes how to apply RUP in a lightweight manner to small projects. We describe how to effectively apply eXtreme Programming (XP) techniques within the broader context of a complete project.

Rational Unified Process: White Papers

The RUP includes a number of white papers, listed below.

Disciplines
- Applying Requirements Management with Use Cases
- Traceability Strategies for Managing Requirements with Use Cases
Requirements
Architecture
- Layering Strategies
Design
- RUP/XP Guidelines: Test-first Design and Refactoring
- Developing Large-Scale Systems with the Rational Unified Process
Implementation
- RUP/XP Guidelines: Test-first Design and Refactoring
- RUP/XP Guidelines: Pair Programming
Assessment
- Test
  - Testing Embedded Systems
Management
Tools
- Model Structure Guidelines for Rational XDE Developer - Java Platform Edition
- Model Structure Guidelines for Rational XDE Developer - .NET Edition

If you have Internet access, some of the RUP white papers can be downloaded from the IBM Web site.

A Comparison of RUP and XP

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download this and other RUP white papers from the IBM Web site.

Abstract

Labeling RUP as heavyweight and XP as lightweight without further qualification does both a disservice by obscuring what each is and what each was intended to do. And, when done in a pejorative way, it’s simply meaningless posturing. It is the implementations of these as processes that will be either “heavyweight” or “lightweight”, and they should be as heavy or light as circumstances require them to be.

XP is not a free form, anything goes discipline-it focuses narrowly on a particular aspect of software development and a way of delivering value, and is quite prescriptive about the way this is to be achieved.

RUP’s coverage is much broader and just as deep, which explains its apparent “size”. However, at the micro level of process, RUP occasionally allows and offers equally valid alternatives, where XP does not; for example, the practice of pair programming, which is required by XP. This is not intended as a criticism of XP; simply an illustration of how XP, as its name implies, has narrowed its focus.

Applying Requirements Management with Use Cases

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. There are additional white papers available from the IBM Web site.

Abstract

Whether you are new to or somewhat familiar with requirements management and are interested in requirements process improvement, this paper offers a framework with which to develop your own approach.

The need to manage requirements is not new. If your projects are not regularly satisfying customers, meeting deadlines, and staying within budget, you have reason to reconsider your development approach. In doing so, if you determine that requirements-related problems are undermining your development efforts, you have reason to consider better requirements-management practices.

The requirements management practices summarized in this paper embody the collective experience of thousands and are the well-considered opinions of a number of individuals who have spent years working with customers in the field of requirements management. We suggest that this overview of their contributions-and the more thorough presentation of them made in the RUP-represent a best practice in requirements management.

RUP/XP Guidelines: Pair Programming

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other white papers from the IBM Web site.

Abstract

Pair programming is a well-tested, well accepted alternative to code reviews. More than that, it’s a fundamentally different way to write software. The benefits go far beyond productivity and quality, and affect such things as the robustness and morale of the team.

RUP/XP Guidelines: Test-first Design and Refactoring

By Robert C. Martin Object Mentor, Inc. mailto:rmartin@objectmentor.com www.objectmentor.com

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other white papers from the IBM Web site.

Abstract

This paper demonstrates the techniques of refactoring in the presence of test-first design and conveys a programming attitude. A program is not done when it works; a program is done when it works and when it’s as simple and clean as possible.

Reaching CMM Levels 2 and 3 with the Rational Unified Process

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

The Software Engineering Institute’s (SEI) Capability Maturity Model (CMM) provides a well-known benchmark of software process maturity. The CMM has become a popular vehicle for assessing the maturity of an organization’s software process in many domains. This white paper describes how the RUP can support an organization that is trying to achieve CMM Level-2 (Repeatable) and Level-3 (Defined) software process maturity levels.

The Estimation of Effort Based on Use Cases

Abstract

It should be possible to form estimates of size and effort that development will require, based on characteristics of the use-case model, which captures the functional requirements. So shouldn’t there be a use-case based equivalent of function points?

This white paper looks at some important techniques for estimating development effort that can be included in the RUP. A framework for estimation, based on use cases, is presented here. This framework considers the idea of use-case level, size, and complexity for different categories of system.

The Rational Unified Process - An Enabler for Higher Process Maturity

Abstract

This paper highlights the key concepts that a mature organization-a Level 3 development unit-has to demonstrate and how the RUP components match these requirements.

Both high project maturity and organization maturity are addressed. In addition, section 4 provides some good ideas on getting started with the RUP and reports on some of the major benefits observed by early adopters in various contexts.

Traceability Strategies for Managing Requirements with Use Cases

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

In many commercial applications of use-case modeling techniques the use-case model must be combined with more traditional requirements capture techniques to provide a requirements management process acceptable to all of the stakeholders involved in the project. This paper explores the traceability strategies available to organizations adopting use-case modeling techniques as part of their requirements management strategy.

From Waterfall to Iterative Lifecycle - A Tough Transition for Project Managers

A PDF version of this article is available, however, you must have Adobe Acrobat installed to view it. You can download other Rational Unified Process (RUP) white papers from the IBM Web site.

Abstract

In this paper, some of the challenges of iterative development are described from a project manager’s perspective. This document also discusses some of the common “traps” or pitfalls we’ve seen through our consulting experience, and from reports and war stories related by our colleagues.

The waterfall model made it easy on the manager and difficult for the engineering team. Iterative development is much more aligned with how software engineers work, but at some cost in management complexity.

Although iterative development is more difficult than traditional approaches the first time you do it, there’s a real long-term payoff. Once you understand how to do it well, you’ll find you’ve become a much more capable manager, and you’ll find it easier to manage larger, more complex projects. And once you get an entire team to understand and think iteratively, the method scales are much better than traditional approaches.

CSPS Creative Design Brief

**Collegiate Sports Paging Service

Creative Design Brief**

Version 1.0

Revision History


Date	Version	Description	Author
October 6, 1999	1.0	Initial version	Context Integration

Introduction
Overview
[Visually Supporting the Function of the Site (the mood)](#Visually Supporting the Function of the Site (the mood))
[Determining the Color Scheme](#Determining the Color Scheme)
[Fonts and Scrolling](#Fonts and Scrolling)
[Site Navigation and Page Layout](#Site Navigation and Page Layout)
[Graphics Standards](#Graphics Standards)
[Browsers, Frames, and Other Standards](#Browsers, Frames, and Other Standards)
[Personalization Elements](#Personalization Elements)
Conclusion

Creative Design Brief

Introduction

Purpose

This document presents standards to be used during the design of the User Interface (UI) for the Collegiate Sports Paging System.

Scope

This document encompasses all UI elements that are used in the web site.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision Document 1.0

Overview

The visual elements of the Sports Paging Service web site will fit in line with WebNewsOnLine’s current web presence. This site will add the personalization and customization required by the paging service. In general, it will maintain the look and feel of WebNewsOnLine’s current site. Some of the additions required by this service are a login screen, user profile editing, customized link list, and maintaining a history of past pages.

Visually Supporting the Function of the Site (the mood)

The mood of this site will follow the lead of the current news site. The focus of the paging service is sports news and scores, so the mode will model an online news web site. The priority is content over a flashy visual design. An overall conservative look will consist of a white background, black serif text, columns with news articles and photos, and tables with user profile information and a linked list of the paging history.

Determining the Color Scheme

A color should add to the message conveyed by the web site. A professional and conservative site should use cool and neutral colors. Bright or warm colors can be used as accents. The paging site will use the same color palette enforced in the main web site.

Figure 1 - Web site color palette

Colors will also be used to highlight important items on the paging subscriber’s homepage. Links will remain the standard blue color used throughout the site. All body text will be black, while table headings will be white on various background colors.

Fonts and Scrolling

The paging service web site’s fonts and scrolling behavior will mimic the WebNewsOnLine web site. Serif fonts are used for most of the text for readability. The width of the page is limited to fit inside a 640x480 screen without scrolling horizontally. The user scrolls up and down to view content. News articles generally are on one screen taking vertical space as needed.

The width of the page is limited to 600 pixels with about 20% of the horizontal space allocated for the sidebar on the left. The body area is given the remaining 80%. The banner section includes the logo, banner advertisements, and links to the main sections of the news web site.

Figure 2 - Page Layout Standard

The sidebar contains the sub-links for the paging service web site. These links will allow the user to go back to their home page and traverse recent articles and scores postings. The footer of the body section will include more banner advertisements.

Graphics Standards

Visitors to the paging site will be connecting at speeds from T1 lines down to 28.8 modems. The site is designed to load fast, using a minimum of photos and other graphic images. Outside of the main logo, page header and advertisements, only a few other graphic images are used on each page. There may be only one or two photos corresponding to a news article.

This site will not use any JavaScript rollovers or animation (outside of any animation included in the banner advertisements). This will ensure that download speeds are fast and that the web site is compatible with new and older browsers.

Browsers, Frames, and Other Standards

Visitors to the site will be using Netscape Navigator, Internet Explorer, and other popular web browsers. Browser versions will vary, but most will be using 3.0 versions or higher. The HTML code and layout techniques used on the site will support most browser brands that support HTML 3.0 or higher.

Frames will not be used on the sports paging web site. The entire screen is loaded from scratch when a new link is chosen. This behavior matches the web site.

A web-safe color palette has been chosen to ensure that the site looks the same on various platforms, browsers, and screen color configurations.

Personalization Elements

The top section of the subscriber’s page consists of a welcome phrase including their name. This ensures to the user they have properly logged in and the information on the screen is customized for them.

The second element is a header indicating the date and time of the last page. This is an indicator that the content on the home screen relates to the page received at that date and time.

The two primary elements of the paging service are news articles and game scores. These two are grouped in tables on the user’s home page. These tables include headlines and scores reports with links to the full news story and game report.

At the bottom of their homepage, the subscriber will find a table of links to recent pages to access historical page information. If this list grows large, a link will be added to “view all pages” which will send them to another page with the complete list of page links.

Conclusion

The visual design for the sports paging service will be the same as the web site. The look and feel can be characterized as a news and content focused site that is geared toward being readable, easy to navigate, with fast downloading. Visitors will be connecting speeds varying from very fast T1 lines to slower modems, so graphics are kept to a minimum. The HTML used is compatible with all of the popular browsers down to their 3.0 versions.

The subscriber’s home page will consist of personalized elements or units on the screen. These elements contain a welcome message, the news headlines and game score links, and last pages links. Banner ads on these screens can also be customized for subscriber preferences.

**Collegiate Sports Paging Service

Design Comps**

Version 1.0

Revision History


Date	Version	Description	Author
October 8, 1999	1.0	Initial version	Context Integration

Introduction
Overview
[Screen 1 : Login to Paging Service](#Screen 1 : Login to Paging Service)
[Screen 2 : Subscriber’s Paging Homepage](#Screen 2 : Subscriber’s Paging Homepage)
[Other Screens](#Other Screens)

Design Comps

Introduction

Purpose

This document presents design concepts (or comparables) for several major User Interface (UI) components for the Collegiate Sports Paging Service.

Scope

This document encompasses major UI designs that may be used in the web site.

Definitions, Acronyms and Abbreviations

See Glossary

References

CSPS Vision 1.0

Overview

Design comps give examples of what the basic screens will look like for a web site. They are not exact representations and only exist as graphic images (no HTML). These may also not represent every screen in the system, but are a representative group that give a picture of the overall look and feel of the site.

Figure -1 - Log on to paging service screen

This diagram of the login screen shows the general layout of the WebNewsOnLine Sports Paging Service web page. The user is presented with the fields for username and password. If they are not currently subscribers, a paragraph explains the features of the Paging Service. Along with the button to login to the service, a button is provided to subscribe for those who aren’t currently members. Links on the left side of the screen indicate the options available for sports paging. Advertisements on the top, bottom and left are customized for the paging service subscriber once they have logged in.

Screen 2 : Subscriber’s Paging Homepage

Figure -1 - Subscriber’s home page

Screen #2 is the first page the subscriber sees when they log into the service. It indicates the date and time for the current page. The news article headlines are listed along with a link to the full article text. Scores are listed with links to the full article coverage for the game. On the bottom of the page, there is a list with the recent dates and times for pages sent. Subscribers can click to view the past news headlines and scores signaled by pages. Another link takes the viewer to a list of all of their pages.

Other Screens

There will be several other screens that comprise the Sports Paging Service. Most of the content for the news articles and game summaries will link to existing content on the WebNewsOnLine web site. Another screen will allow the subscriber to edit their preferences, choosing the sports teams and athletes they of interest.

CSPS Development Case 1.0

**Collegiate Sports Paging System

Development Case**

Version 1.0

Revision History


Date	Version	Description	Author
October 1, 1999	1.0	Initial version	Context Integration

Introduction
[Overview of the Development Process](#Overview of the Development Process)
[Phases](#Iteration Workflows)
[Business Modeling](#Business Modeling)
Requirements
[Analysis and Design](#Analysis and Design)
Implementation
Test
Project Management
Deployment

Introduction

Purpose

This document presents the manner in which the RUP and ContextWISE development methodology will be used for the Collegiate Sports Paging System project for WebNewsOnLine.

Scope

This development case applies to the Inception, Elaboration, Construction, and Transition phases of the Collegiate Sports Paging System project.

Definitions, Acronyms and Abbreviations

ContextWISE is the Web-optimized methodology developed by Context Integration. It is an adaptation of the Rational Unified Process for Web-based projects.

Artifacts are deliverables produced during various activities.

References

None.

Overview

The remainder of this document describes ways in which the RUP will be adapted for this project. Where the RUP will be used as is, this is so noted.

Section 2 contains an overview of the development process, including project management and quality assurance activities. Section 3 describes the iteration workflows for the Elaboration and Construction phases. Section 4 describes Business Modeling workflows.

Overview of the Development Process

This project will consist of a full Inception phase, an Elaboration phase, a three-iteration Construction phase, and a full Transition phase. Design and code reviews will take place at key iteration milestones, and project quality reviews will be conducted at the end of each phase.

Phases

Inception

Define the Scope and Vision

We will work with the stakeholders of the system to be developed to define the vision and the scope of the project. This will be done using a facilitated session and will produce the Vision document as an artifact. An initial version of the project risks will also be developed at this point.

Outline and clarify the functionality that is to be provided by system.

We will conduct sessions to collect stakeholders’s opinions on what the system should do. We will outline the Use-Case Model at this point as a basis for subsequent design activities. A Glossary of terms specific to this project will also be developed.

Consider the feasibility of the project, and define the Software Development plan.

With input from the use-case modeling, we will translate the Vision into economic terms, updating the Business Case, factoring in the project’s investment costs, resource estimates, the environment needed, and success criteria (revenue projection and market recognition). We will also update the Risk List to refer to the identified use cases and add new identified risks. We will develop the initial Software Development plan to more fully map out the project phases.

Elaboration Workflows

To be defined later in the project.

Construction Workflows

To be defined later in the project.

Transition Workflows

To be defined later in the project.

Business Modeling

We will refine the Glossary during this activity.

Artifacts

The following artifacts are produced during this workflow:


Artifact	Tools Used	Formal Deliverable?
Glossary	Microsoft® Word®	Yes

Key Input Artifacts

None.

Workflow

The development of a Supplementary Business Specification, Business Analysis Model, and Business Use Cases will be omitted from the standard workflow.

Requirements

We will capture requirements through the development of use-cases. Use-cases define actors (individuals who interact with the system) and use-cases (descriptions of how the actors interact with the system). During the development of use-cases (which will be done through facilitated sessions), a set of non-use-case requirements will also be captured into the Supplementary Specifications document.

Artifacts

The following artifacts are produced during this workflow:


Artifact	Tools Used	Formal Deliverable?
Vision	Microsoft Word	Yes
Actors	Rational Rose	No
Boundary Classes	Rational Rose	No
Glossary	Microsoft Word	Yes
Supplementary Specifications	Microsoft Word	Yes
Use Cases (updated)	Rational Rose, Microsoft Word	No
Creative Design Brief	Microsoft Word	Yes
Navigation Map	Microsoft Word	Yes
User Interface Prototype	Microsoft® PowerPoint®, Microsoft Word	Yes

Reports

The following reports are generated during this workflow:


Report	Tools Used	Formal Deliverable?
Use-Case Survey	Microsoft Word	Yes

Key Input Artifacts


Artifact	Tools Used	Formal Deliverable?
Glossary	Microsoft Word	Yes

Maintenance of Input Requirements

None needed - keep as is.

Workflow

The development of two artifacts is added to the standard workflow - Creative Design Brief and Navigation Map. We also move the generation of the User Interface Prototype into the Inception phase.

Analysis and Design

The use-cases developed during the Requirements workflow form the basis for subsequent analysis and design. Object-oriented design and analysis techniques will be used to complete the use-cases initially developed, produce the analysis and design object models, the data model, and the software architecture document.

Artifacts

The following artifacts are produced during this workflow:


Artifact	Tools Used	Formal Deliverable?
Data Model	Rational Rose	Yes
Design Model	Rational Rose	Yes
Database Design	Rational Rose	Yes
Software Architecture Document	Microsoft Word	Yes

Reports

The following reports are generated during this workflow:


Report	Tools Used	Formal Deliverable?
Use-Case Survey	Microsoft Word	Yes

Key Input Artifacts


Artifact	Tools Used	Formal Deliverable?
Glossary	Microsoft Word	Yes
Supplementary Specifications	Microsoft Word	Yes
Use Cases (updated)	Rational Rose, Microsoft Word	No
Creative Design Brief	Microsoft Word	Yes
Navigation Map	Microsoft Word	Yes
User Interface Prototype	Microsoft PowerPoint, Microsoft Word	Yes

Workflow

This is not a real-time system, so the real-time design workflow is omitted. We are designing the database at this point, so the optional workflow is included in this phase.

Implementation

Implementation will occur by developing objects and packages based on the design models developed earlier. Once these are initially created, they will be reviewed by the development team, unit tested by the developer, and placed under configuration management for integration into subsystems and systems for integration testing.

Artifacts

The following artifacts are produced during this workflow:


Artifact	Tools Used	Formal Deliverable?
Implementation Subsystem	Microsoft® FrontPage®	Yes

Code Reviews

Formal code reviews will occur at the end of the Inception phase.

Unit Test Coverage

See the Test Plan.

Key Input Artifacts


Artifact	Tools Used	Formal Deliverable?
Data Model	Rational Rose	Yes
Design Model	Rational Rose	Yes
Database Design	Rational Rose	Yes
Software Architecture Document	Microsoft Word	Yes

Workflow

The standard workflow is used.

Project Management

Artifacts

The following artifacts are produced during this workflow:


Artifact	Tools Used	Formal Deliverable?
Risk List	Microsoft Word	Yes
Software Development Plan	Microsoft Word	Yes
Iteration Plans	Microsoft Word	Yes
Iteration Assessment	Microsoft Word	Yes
Status Assessment	Microsoft Word	Yes

Reports

None

Key Input Artifacts


Artifact	Tools Used	Formal Deliverable?
Vision	Microsoft Word	Yes
Development Case	Microsoft Word	Yes
Software Architecture Document	Microsoft Word	Yes

Workflow

The standard workflow is used.

Test

The test workflow will be driven by test cases and scripts that will be developed from the use-cases. Integration testing (which tests the functionality of the system), load and stress testing (which tests the system under various load conditions) will be deferred to the Elaboration phase.

Artifacts

The following artifacts are produced during this workflow:


Artifact	Tools Used	Formal Deliverable?
Test package	Microsoft Word	Yes
Change requests	Microsoft Word	Yes

Reports

The following reports are generated during this workflow:


Report	Tools Used	Formal Deliverable?
Test summary	Microsoft Word	Yes

Key Input Artifacts


Artifact	Tools Used	Formal Deliverable?
Implementation Subsystem	Microsoft FrontPage	Yes

Workflow

The standard workflow will be used.

Deployment

A one-month Beta test will be used to determine suitability of the system for deployment. Once any major defects are corrected, the system will be released for general use. During the inception phase, no deployment will be executed.

CSPS Glossary（术语表） 1.0

Collegiate Sports Paging System

**Glossary

Version 1.0**

Revision History


Date	Version	Description	Author
October 12, 1999	1.0	Initial version	Context Integration

Introduction
Definitions

Introduction

Purpose

The glossary contains the working definitions for all classes in the Collegiate Sports Paging System. This glossary will be expanded throughout the life of the project.

Scope

This glossary addresses all terms which have specific meanings for this project. Actors are not listed here as they are described more fully in the use case definitions.

Definitions

Content: Content consists of all of the media by which a news story or sporting event story can be delivered to a user. This may include text, graphics, video, or sound.
Pager: A pager is a device capable of receiving an alphanumeric message. A cellular phone may act as a pager, as may email. For this project, all such devices will be considered as pagers.
Subscription: A subscription is an agreement between a customer and WebNewsOnLine to deliver pages when events occur in specific sports subject areas (such as NCAA Basketball).
Web Site: The Collegiate Sports Paging System web site is a computer system that a user accesses using commercial web browser software. Subscribers will receive customized displays of content they can access.

CSPS Glossary 2.0

Collegiate Sports Paging System

Glossary

Version 2.0

Revision History


Date	Version	Description	Author
October 12, 1999	1.0	Initial version	Context Integration
November 12, 1999	2.0	Update after Elaboration iteration	Context Integration

Introduction
Definitions

Introduction

Purpose

The glossary contains the working definitions for all classes in the Collegiate Sports Paging System. This glossary will be expanded throughout the life of the project.

Scope

This glossary addresses all terms which have specific meanings for this project. Actors are not listed here as they are described more fully in the use case definitions.

References

None.

Definitions

Advertiser Profile: Information about an advertiser and their contract with WebNewsOnLine. Includes advertiser name and address, balance due less than 30 days, balance due greater than 30 days, pricing information (maintained by WebNewsOnLine advertising department), and account status (active, inactive).
Category: Information about content. Includes major status (viewed, archived) and, if content is not archived, type of story (NCAA, PAC10, etc.). Types of stories are selected from a maintained list within the system, and are referenced by subscriber’s Page-me-when profile.
Content: Content consists of all of the media by which a news story or sporting event story can be delivered to a user. This may include text, graphics, video, or sound.
Page: Sending of text information to a pager to inform subscriber of new content available on Web Site.
Page-me-when Profile: Information about subscriber’s wishes for receiving pages. Includes all categories of stories or content which, when posted to the system, will generate a page to a subscriber.
Pager: A pager is a device capable of receiving an alphanumeric message. A cellular phone may act as a pager, as may email. For this project, all such devices will be considered as pagers.
Pager Gateway: The pager gateway is a combination of hardware and software that takes text messages and delivers them (via vendor-specific interfaces) to pagers.
Personal Profile: Personal information about a subscriber. Includes name, address, email address, phone numbers, credit card number, PIN, and date of expiration, subscription start and end dates.
Preferences Profile: Information about a subscriber’s paging preferences. Includes time limits on pages (do not page between specific times of specific days).
Story: Text, graphics, video, and/or sound that describe a sporting event.
Subscription: A subscription is an agreement between a customer and WebNewsOnLine to deliver pages when events occur in specific sports subject areas (such as NCAA Basketball).
Web Site: The Collegiate Sports Paging System web site is a computer system that a user accesses using commercial web browser software. Subscribers will receive customized displays of content they can access.

CSPS Integration Build Plan 1.0

**Collegiate Sports Paging System

Integration Build Plan

Version 1.0**

Revision History


Date	Version	Description	Author
November 18, 1999	1.0	Initial version	Context Integration

Introduction
Subsystems
Builds

Introduction

Purpose

This document describes the plan for integrating the software components of the first Construction Iteration. This iteration forms the software baseline for the R1.0 release.

Scope

This Integration Build applies to all components needed to receive content, approve it, notify users via pagers, and enable users to view content.

The Test and Development Teams use this document to determine the subsystems and components that comprise each build and the ordering of the various builds.

Definitions, Acronyms and Abbreviations

See Glossary

References

CSPS Iteration Plan 1.0

Subsystems

Due to the simplicity of the system, no subsystems are needed.

Builds

This iteration will employ three builds as follows:


Build 1	This build will include the use cases Send Content and Approve Story.
Build 2	This build will add the use case Send Page.
Build 3	This build will add the use case Read Content.

CSPS Iteration Assessment 1.0

Collegiate Sports Paging System

**Iteration Assessment

Version 1.0**

Revision History


Date	Version	Description	Author
November 12, 1999	1.0	Initial version	Context Integration

Introduction
[Iteration Objectives Reached](#Iteration Objectives Reached)
[Adherence to Plan](#Adherence to Plan)
[Use Cases and Scenarios Implemented](#Use Cases and Scenarios Implemented)
[Results Relative to Evaluation Criteria](#Results Relative to Evaluation Criteria)
[Test Results](#Test Results)
[External Changes Occurred](#External Changes Occurred)
[Rework Required](#Rework Required)

Introduction

Purpose

The objective of the Iteration Assessment is to capture the result of the iteration, the degree to which the evaluation criteria were met, and lessons learned and changes to be done.

Scope

This Iteration Assessment applies to the Elaboration Iteration. The Elaboration Iteration developed the requirements and design for the initial implementation of the Collegiate Sports paging System.

The success of the Elaboration Iteration is measured against the evaluation criteria as outlined in the Elaboration Iteration Plan.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Iteration Plan 1.0
CSPS Design Comps 1.0
CSPS Use Case - Approve Story 1.0
CSPS Use Case - Edit Profile 1.0
CSPS Use Case - Pay Fee With Credit Card 1.0
CSPS Use Case - Print Advertiser Reports 1.0
CSPS Use Case - Provide Advertising Content 1.0
CSPS Use Case - Provide Feedback 1.0
CSPS Use Case - Read Content on Website 1.0
CSPS Use Case - Send Content 1.0
CSPS Use Case - Send Page 1.0
CSPS Use Case - Subscribe 1.0
CSPS Glossary 1.0

Iteration Objectives Reached

Architectural prototype developed, major risks validated, designs completed for all use cases.

Adherence to Plan

This iteration executed according to plan.

Use Cases and Scenarios Implemented

No new use cases were identified. The following use cases were completed with details uncovered during the design process:

Approve Story
Edit Profile
Pay Fee With Credit Card
Print Advertiser Reports
Provide Feedback
Read Content on Web Site
Send Content
Send Page
Subscribe

Results Relative to Evaluation Criteria


Criterion	Evaluation
Complete the analysis and design of selected use cases.	All selected use cases designed.
Develop a working architectural prototype.	Prototype available for user evaluation.
Realize risk associated with the architectural design or system performance.	Performance risk under load exposed, plan developed for dealing with load.
Each deliverable developed during the iteration will be peer reviewed and subject to approval from the team.	Peer reviews took place as planned (project documentation contains review summaries).

Test Results

During load testing, results indicate that a multi-tiered pager gateway approach will be needed to handle peak traffic loads.

Subscriber, editor, and advertising representatives approved the user interface as designed.

External Changes Occurred

All major alphanumeric pager vendors now offer an email interface for sending alphanumeric pages.

Rework Required

None.

CSPS Iteration Plan 1.0

**Collegiate Sports Paging Service

Iteration Plan**

Version 1.0

Revision History


Date	Version	Description	Author
October 6, 1999	1.0	Initial version	Context Integration

Introduction
Plan
Resources
[Use Cases](#Use Cases)
[Evaluation Criteria](#Evaluation Criteria)

Introduction

Purpose

This Iteration Plan describes the detailed plans for the Preliminary Iteration of the Project. During this iteration, the requirements of the system will be defined and the high level plan for execution of the full project will be developed. This first iteration will conduct a thorough analysis on the business case for the system and will result in a decision on whether the project will proceed.

Scope

The Preliminary Iteration Plan applies to the project being developed by Context Integration for WebNewsOnLine. This document will be used by the Project Manager and by the project team.

Definitions, Acronyms and Abbreviations

See Glossary document.

References

CSPS Vision 1.0
CSPS Requirements Management Plan 1.0

Plan

The Preliminary Iteration will develop the product requirements and establish the business case for the Collegiate Sports Paging System. The major use cases will be developed as well as the high level Project Plan. At the end of this iteration, will decide whether to fund and proceed with the project based upon the business case.

Iteration Tasks

The following table illustrates the tasks with their planned start and end dates.


Task	Start	End
INCEPTION	Fri 10/1/99	Mon 10/25/99
Begin Inception	Fri 10/1/99	Fri 10/1/99
Inception Kick-off	Mon 10/4/99	Wed 10/6/99
Add tasks to project plan for specific project technology using ContextWISE cartridges	Mon 10/4/99	Mon 10/4/99
Assemble Change Control Board	Mon 10/4/99	Tue 10/5/99
Create and baseline Change Control Plan	Tue 10/5/99	Tue 10/5/99
Obtain Sign-off	Tue 10/5/99	Tue 10/5/99
Inception Kick-off Meeting	Tue 10/5/99	Wed 10/6/99
Prepare for inception kick-off meeting	Tue 10/5/99	Wed 10/6/99
Hold Inception Kick-off Meeting	Wed 10/6/99	Wed 10/6/99
Inception Kick-off Completed	Wed 10/6/99	Wed 10/6/99
Inception Deliverables	Wed 10/6/99	Thu 10/14/99
Hold Requirements Workshop	Wed 10/6/99	Thu 10/7/99
Project Vision created, reviewed, and signed off	Wed 10/6/99	Thu 10/7/99
Preliminary Use Case Model (10-20% complete) created and placed under revision control	Thu 10/7/99	Mon 10/11/99
Preliminary Use Case Survey created, reviewed, and signed off	Mon 10/11/99	Tue 10/12/99
Preliminary Supplementary Specifications created, reviewed, and signed off	Tue 10/12/99	Tue 10/12/99
Business Case created, reviewed, and signed off	Tue 10/12/99	Tue 10/12/99
Preliminary Project Glossary created, reviewed, and signed off	Tue 10/12/99	Tue 10/12/99
Preliminary Creative Design Brief created, reviewed, and signed off	Wed 10/6/99	Thu 10/7/99
Preliminary Site Map & Use-Case Navigation Mapping created, reviewed, and signed off	Thu 10/7/99	Fri 10/8/99
Creative Design Comps created, reviewed, and signed off	Fri 10/8/99	Mon 10/11/99
Preliminary Content Plan created, reviewed, and signed off (if applicable)	Wed 10/6/99	Wed 10/6/99
User Interface Prototype (optional) created, reviewed, and signed off	Wed 10/6/99	Wed 10/6/99
Reports Prototype (optional) created, reviewed, and signed off	Tue 10/12/99	Thu 10/14/99
Develop Preliminary Technology Alternatives	Wed 10/6/99	Thu 10/7/99
Establish contact with appropriate Context Gurus	Tue 10/12/99	Wed 10/13/99
Preliminary Knowledge Transfer Plan & Schedule created, reviewed, and signed off	Wed 10/13/99	Wed 10/13/99
Validate/Invalidate Assumption from Inception proposal	Wed 10/13/99	Thu 10/14/99
Obtain Sign-off	Thu 10/14/99	Thu 10/14/99
Inception Deliverables Complete	Thu 10/14/99	Thu 10/14/99
Inception Wrap-up	Thu 10/14/99	Mon 10/25/99
Conduct Quality Check Meeting with Client	Thu 10/14/99	Thu 10/14/99
Conduct Quality Assurance	Thu 10/14/99	Fri 10/15/99
Hold Context Lessons Learned Meeting	Thu 10/14/99	Thu 10/14/99
First project estimates created, reviewed, and signed off (+75%, -60%)	Thu 10/14/99	Mon 10/18/99
Full Project Iterative Delivery Plan created, reviewed, and signed off	Mon 10/18/99	Tue 10/19/99
Create proposal for Elaboration Phase	Thu 10/14/99	Fri 10/15/99
Create Software Project Log	Fri 10/15/99	Fri 10/15/99
Prepare for Inception Checkpoint	Fri 10/15/99	Mon 10/18/99
Have team, including client project manager, complete the work release sign-off form	Mon 10/18/99	Tue 10/19/99
Deliver proposal for Elaboration Phase	Tue 10/19/99	Thu 10/21/99
Inception Checkpoint Review and Go/No Go Decision	Thu 10/21/99	Fri 10/22/99
Move appropriate deliverables from Project Homepage to IAN Artifacts	Fri 10/22/99	Mon 10/25/99
Inception Complete	Mon 10/25/99	Mon 10/25/99

The following deliverables or artifacts will be generated and reviewed during the Preliminary Iteration:


Artifact Set	Deliverable	Responsible Owner
Business Modeling Set	Glossary	Brian Egler Brian Egler Brian Egler Brian Egler
Requirements Set	Vision Document Use Case Specifications Supplementary Specification Use Case Model (and Model Survey)	Brian Egler Brian Egler Ed Post Ken Perch Ken Perch
Management Set	Preliminary Iteration Plan Project Plan Project Schedule Project Risk List Status Assessment Preliminary Iteration Assessment Configuration Management Plan	Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Ken Perch
Standards and Guidelines	Configuration Management Environment	Ken Perch

Resources

The project staffing for this iteration can be viewed as follows:

Financial Resources

The budget for this iteration is $150,000. WebNewsOnLine has secured this funding.

Use Cases

During the Preliminary Iteration, all significant use cases and actors will be identified. The basic flows and key alternative flows of each use case will be determined and documented in the Use Case Specifications. The design and implementation of use cases will begin in the next iteration.

Evaluation Criteria

The primary goal of the Preliminary Iteration is to define the system to the level of detail required to make a sound business judgment on the viability of the project from a business prospective. At the completion of the iteration, a review of the Business Case will arrive at a Go / No Go decision for the project.

Each deliverable developed during the iteration will be peer reviewed and subject to approval from the team.

Criteria for evaluation can be found in the Test Plan.

CSPS Iteration Plan 2.0

**Online Collegiate Paging System

Iteration Plan**

Version 2.0

Revision History

Introduction
Plan
Resources
[Use Cases](#Use Cases)
[Evaluation Criteria](#Evaluation Criteria)

Iteration Plan

Introduction

Purpose

This Iteration Plan describes the detailed plans for the Elaboration Iteration of the Collegiate Sports Paging System Project. During this iteration, the design of the system will be defined and the high level plan for execution of the full project will be refined.

Scope

The Elaboration Iteration Plan applies to the Collegiate Sports Paging System project being developed by Context Integration for WebNewsOnLine. This document will be used by the Project Manager and by the project team.

Definitions, Acronyms and Abbreviations

See Glossary document.

References

CSPS Iteration Plan 1.0.doc

Plan

The Elaboration Iteration will complete the analysis of requirements. The analysis and design for all use cases will be completed. The architectural prototype will be developed to test the feasibility and performance of the architecture that is required for Release 1.0.

Iteration Tasks

The following table illustrates the tasks with their planned start and end dates.


Task	Start	End
ELABORATION	Mon 10/25/99	Fri 11/26/99
Begin Elaboration	Mon 10/25/99	Tue 10/26/99
Elaboration Kick-off	Tue 10/26/99	Fri 10/29/99
Add tasks to project plan for specific project technology using ContextWISE cartridges	Fri 10/29/99	Fri 10/29/99
Elaboration Kick-off Meeting	Tue 10/26/99	Thu 10/28/99
Prepare for Elaboration Kick-off Meeting	Tue 10/26/99	Tue 10/26/99
Hold Elaboration Kick-off Meeting	Tue 10/26/99	Thu 10/28/99
Quality Assurance Plan created, reviewed, and signed off	Tue 10/26/99	Tue 10/26/99
Elaboration Kick-off Completed	Thu 10/28/99	Thu 10/28/99
Initial Web User Interface Prototypes & Style Guides	Fri 10/29/99	Tue 11/2/99
Creative Brief updated, reviewed, and signed off	Fri 10/29/99	Fri 10/29/99
Web design components created	Fri 10/29/99	Tue 11/2/99
Web UI technical elements created	Fri 10/29/99	Mon 11/1/99
Initial User Interface Prototype created, reviewed, and signed off	Fri 10/29/99	Fri 10/29/99
Initial Report Prototype created, reviewed, and signed off	Fri 10/29/99	Fri 10/29/99
User Interface Style Guide created, reviewed, and signed off	Fri 10/29/99	Fri 10/29/99
Reports Style Guide created, reviewed, and signed off	Fri 10/29/99	Fri 10/29/99
Update Software Project Log	Fri 10/29/99	Mon 11/1/99
Initial Prototype & Style Guide Completed	Mon 11/1/99	Mon 11/1/99
Documentation/Specifications, Help & Training Materials	Tue 11/2/99	Fri 11/5/99
Determine Documentation/Specification/Help & Training Material Requirements	Tue 11/2/99	Thu 11/4/99
Draft Initial User Manual/Specification/Help	Thu 11/4/99	Fri 11/5/99
Draft Documentation Completed	Tue 11/2/99	Tue 11/2/99
Detailed requirements development	Tue 11/2/99	Thu 11/4/99
Complete Elaboration Use Case Model	Wed 11/3/99	Wed 11/3/99
Use-Case-Model Survey created, reviewed, and signed off	Wed 11/3/99	Wed 11/3/99
Supplementary Specifications updated, reviewed and baselined	Tue 11/2/99	Tue 11/2/99
Project Glossary updated, reviewed, and signed off	Tue 11/2/99	Wed 11/3/99
Site Map & Use-Case Navigation Mapping updated, reviewed, and signed off	Tue 11/2/99	Wed 11/3/99
Content Plan updated, reviewed, and signed off (if applicable)	Tue 11/2/99	Wed 11/3/99
Detailed user-interface prototype created, reviewed, and signed off	Tue 11/2/99	Wed 11/3/99
Detailed reports prototype created, reviewed, and signed off	Tue 11/2/99	Wed 11/3/99
User Manual/Specification/Help and Training created, reviewed, and signed off	Wed 11/3/99	Wed 11/3/99
Obtain Sign-off	Wed 11/3/99	Thu 11/4/99
Detailed requirements development complete	Thu 11/4/99	Thu 11/4/99
Plans revised and updated	Thu 11/4/99	Fri 11/5/99
Iterative Delivery Project Plan updated, reviewed, and signed off	Thu 11/4/99	Thu 11/4/99
Software Development Plan created, reviewed, and signed off	Thu 11/4/99	Thu 11/4/99
Knowledge Transfer Plan & Schedule updated, reviewed, and signed off	Thu 11/4/99	Thu 11/4/99
Project estimates updated (accurate to +65%, -40%)	Thu 11/4/99	Thu 11/4/99
Revise Business Case	Thu 11/4/99	Thu 11/4/99
Reduce documentation staff (unless other significant documentation products will be produced)	Thu 11/4/99	Thu 11/4/99
Documentation staff reduced after completing User Manual/Specification/Help (unless other significant documentation products will be produced)	Thu 11/4/99	Fri 11/5/99
Elaboration Requirements Checkpoint	Fri 11/5/99	Mon 11/8/99
Prepare for, and hold, Elaboration Requirements Checkpoint meeting	Fri 11/5/99	Mon 11/8/99
Have team, including client project manager, complete the work release sign-off form	Mon 11/8/99	Mon 11/8/99
Elaboration Checkpoint Review and Go/No Go Decision	Mon 11/8/99	Mon 11/8/99
Elaboration Requirements & Plan Revisions Completed	Mon 11/8/99	Mon 11/8/99
Architecture	Mon 11/8/99	Wed 11/24/99
Do Technical Reviews	Mon 11/8/99	Mon 11/8/99
Technical Reviews 1	Mon 11/8/99	Mon 11/8/99
Technical Reviews 2	Mon 11/8/99	Mon 11/8/99
Architectural Analysis	Mon 11/8/99	Mon 11/15/99
Define Modeling Conventions	Mon 11/8/99	Tue 11/9/99
Define the High Level Organization of Subsystems	Tue 11/9/99	Wed 11/10/99
Identify Analysis Mechanisms	Wed 11/10/99	Wed 11/10/99
Identify Key Concepts	Wed 11/10/99	Thu 11/11/99
Create Use-Case Realizations	Thu 11/11/99	Fri 11/12/99
Review the Results	Fri 11/12/99	Mon 11/15/99
Architectural Analysis Completed	Mon 11/15/99	Mon 11/15/99
Architectural Design	Mon 11/15/99	Wed 11/17/99
Identify Design Mechanisms	Mon 11/15/99	Mon 11/15/99
Identify Design Classes and Subsystems	Mon 11/15/99	Mon 11/15/99
Identify Interfaces	Mon 11/15/99	Mon 11/15/99
Identify Resuse Opportunities	Mon 11/15/99	Tue 11/16/99
Reverse-engineer components and databases	Tue 11/16/99	Tue 11/16/99
Define the Low-level Organization of Subsystems	Tue 11/16/99	Wed 11/17/99
Include Architecturally Significant Model Elements in the Logical View	Wed 11/17/99	Wed 11/17/99
Check-points: Design Model	Wed 11/17/99	Wed 11/17/99
Architectural Design Completed	Wed 11/17/99	Wed 11/17/99
Describe Concurrency (if applicable)	Wed 11/17/99	Mon 11/22/99
Define Concurrency Requirements	Wed 11/17/99	Thu 11/18/99
Identify Processes	Thu 11/18/99	Thu 11/18/99
Identify Process Lifecycles	Thu 11/18/99	Thu 11/18/99
Identify Inter-Process Communication Mechanisms	Thu 11/18/99	Fri 11/19/99
Allocate Inter-Process Coordination Resources	Fri 11/19/99	Fri 11/19/99
Map Processes onto the Implementation Environment	Fri 11/19/99	Fri 11/19/99
Distribute Model Elements Among Processes	Fri 11/19/99	Mon 11/22/99
Concurrency Documented	Mon 11/22/99	Mon 11/22/99
Use-Case Analysis	Mon 11/8/99	Thu 11/11/99
Supplement the Descriptions of the Use Cases	Mon 11/8/99	Mon 11/8/99
For each use case find classes from use case behavior	Tue 11/9/99	Tue 11/9/99
For each use case distribute use case behavior to classes	Tue 11/9/99	Tue 11/9/99
For each resulting class Describe Responsibilities	Wed 11/10/99	Wed 11/10/99
For each resulting class Describe Attributes & Associations	Wed 11/10/99	Wed 11/10/99
For each resulting class Qualify Analysis Mechanisms	Wed 11/10/99	Wed 11/10/99
Unify Analysis Classes	Wed 11/10/99	Thu 11/11/99
Evaluate the Results	Thu 11/11/99	Thu 11/11/99
Use-Case Analysis Complete	Thu 11/11/99	Thu 11/11/99
Use-Case Design	Thu 11/11/99	Fri 11/12/99
Describe Interactions Between Design Objects	Thu 11/11/99	Thu 11/11/99
Simplify Sequence Diagrams using Subsystems (optional)	Thu 11/11/99	Thu 11/11/99
Describe Persistence-related behavior	Thu 11/11/99	Thu 11/11/99
Refine the Flow of Events Description	Thu 11/11/99	Thu 11/11/99
Unify Classes and Subsystems	Thu 11/11/99	Thu 11/11/99
Evaluate the Results	Thu 11/11/99	Fri 11/12/99
Use-Case Design Completed	Fri 11/12/99	Fri 11/12/99
Class Design (optional)	Fri 11/12/99	Wed 11/17/99
Create Initial Design Classes	Fri 11/12/99	Fri 11/12/99
Identify Persistent Classes	Fri 11/12/99	Fri 11/12/99
Define Class Visibility	Fri 11/12/99	Mon 11/15/99
Define Operations	Mon 11/15/99	Mon 11/15/99
Define Methods	Mon 11/15/99	Mon 11/15/99
Define States	Mon 11/15/99	Mon 11/15/99
Define Attributes	Mon 11/15/99	Tue 11/16/99
Define Dependencies	Tue 11/16/99	Tue 11/16/99
Define Associations	Tue 11/16/99	Tue 11/16/99
Define Generalizations	Tue 11/16/99	Tue 11/16/99
Handle Non-Functional Requirements in General	Tue 11/16/99	Wed 11/17/99
Evaluate the Results	Wed 11/17/99	Wed 11/17/99
Class Design Completed	Wed 11/17/99	Wed 11/17/99
Design Database	Wed 11/17/99	Mon 11/22/99
Map Persistent Design Classes to the Data Model	Wed 11/17/99	Wed 11/17/99
Optimize the Data Model for Performance	Wed 11/17/99	Thu 11/18/99
Optimize Data Access	Thu 11/18/99	Fri 11/19/99
Define Storage Characteristics	Fri 11/19/99	Fri 11/19/99
Define Reference Tables	Fri 11/19/99	Fri 11/19/99
Define Data and Referential Integrity Enforcement Rules	Fri 11/19/99	Fri 11/19/99
Distribute Class Behavior to the Database	Fri 11/19/99	Mon 11/22/99
Review the Results	Mon 11/22/99	Mon 11/22/99
Database Design Complete	Mon 11/22/99	Mon 11/22/99
Review the Design	Mon 11/22/99	Mon 11/22/99
Design Model Survey updated, reviewed, and signed off	Mon 11/22/99	Mon 11/22/99
Use-Case-Model-Realization Report created, reviewed, and signed off	Mon 11/22/99	Mon 11/22/99
Software Architecture document created, reviewed, and signed off	Mon 11/22/99	Mon 11/22/99
Create Architecture Prototype(s)	Mon 11/22/99	Tue 11/23/99
Deployment Diagram (for hw and network) created, reviewed, and signed off	Mon 11/22/99	Mon 11/22/99
Architecture test cases created, reviewed, and signed off	Mon 11/8/99	Thu 11/11/99
Prepare for Architecture Checkpoint	Tue 11/23/99	Tue 11/23/99
Hold Architecture Checkpoint meeting	Tue 11/23/99	Wed 11/24/99
Architecture complete	Wed 11/24/99	Wed 11/24/99
Security	Mon 10/25/99	Tue 10/26/99
Web Security Plan created, reviewed, and signed off	Mon 10/25/99	Tue 10/26/99
Transition Planning	Mon 11/8/99	Tue 11/9/99
Initial Contingency and Disaster Recovery Plan created, reviewed, and signed off	Mon 11/8/99	Mon 11/8/99
Change Management Assessment	Mon 11/8/99	Tue 11/9/99
Hold change management assessment session	Mon 11/8/99	Tue 11/9/99
Change Management Assessment created, reviewed, and signed-off	Mon 11/8/99	Tue 11/9/99
Quality Assurance & Test Planning	Mon 11/8/99	Tue 11/9/99
Software Test Plan created, reviewed, and signed off	Mon 11/8/99	Mon 11/8/99
Software Test Cases for Construction-Iteration 1 created, reviewed, and signed off	Mon 11/8/99	Tue 11/9/99
Elaboration Wrap-up	Wed 11/24/99	Fri 11/26/99
Conduct Quality Check Meeting with Client	Wed 11/24/99	Wed 11/24/99
Hold Context Lessons Learned Meeting	Wed 11/24/99	Wed 11/24/99
Validate/Invalidate Assumption from Elaboration proposal	Wed 11/24/99	Wed 11/24/99
Iterative Delivery Project Plan updated, reviewed, and signed off	Wed 11/24/99	Wed 11/24/99
Software Development Plan updated, reviewed, and signed off	Wed 11/24/99	Thu 11/25/99
Knowledge Transfer Plan updated, reviewed, and signed off	Thu 11/25/99	Thu 11/25/99
Design Guidelines created, reviewed, and signed off	Wed 11/24/99	Wed 11/24/99
User Manual/Specification/Help updated	Wed 11/24/99	Wed 11/24/99
Project estimates updated (accurate to +40%, -5%)	Thu 11/25/99	Thu 11/25/99
Software Project Log updated	Thu 11/25/99	Thu 11/25/99
Obtain Sign-off	Thu 11/25/99	Thu 11/25/99
Have team, including client project manager, complete the work release sign-off form	Thu 11/25/99	Thu 11/25/99
Elaboration Checkpoint Review and Go/No Go Decision	Thu 11/25/99	Thu 11/25/99
Move appropriate deliverables from Project Homepage to IAN Artifacts	Thu 11/25/99	Fri 11/26/99
Elaboration Complete	Fri 11/26/99	Fri 11/26/99

The following deliverables or artifacts will be generated and reviewed during the Elaboration Iteration:


Artifact Set	Deliverable	Responsible Owner
Business Modeling Set	Glossary (expand & update)		Brian Egler
Requirements Set	Vision Document (update) Use Case Specifications (update) Supplementary Specification (update) Use Case Model and Model Survey (update) User-Interface Prototype (forms only)		Brian Egler Brian Egler Ed Post Ken Perch Mark Grimes
Design Set	Analysis Model (Logical View) Design Model (Logical, Component & Process Views) Software Architecture Document		Ken Perch Ken Perch Ken Perch
Implementation Set	Integration Build Plan Architectural Prototype - Software Baseline Test Drivers, Stubs, Data, & Scripts Test Procedures Test Evaluation Report		Mary Durham Ken Perch Mike Hunziker Chris Curvey Mary Durham
Management Set	Iteration Plan Project Plan (update) Project Schedule (update) Project Risk List (update) Status Assessment Iteration Assessment Test Plan		Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham
Standards and Guidelines	Design Guidelines User-Interface Guidelines		Ken Perch Mark Grimes

Resources

Staffing

The project staffing for this iteration can be viewed as follows:

Financial Resources

The budget for this iteration is $180,000. WebNewsOnLine has secured this funding.

Use Cases

Use cases to be developed during this iteration are:

Approve Story
Edit Profile
Pay Fee With Credit Card
Print Advertiser Reports
Provide Feedback
Read Content on Web Site
Send Content
Send Page
Subscribe

Evaluation Criteria

The primary goal of this iteration is to complete the analysis and design of selected use cases and to develop a working architectural prototype.

Risk associated with the architectural design or system performance will be realized by the end of the iteration.

Each deliverable developed during the iteration will be peer reviewed and subject to approval from the team.

The internal project team and the Subscriber, Advertiser, and Editor representatives will review the User-Interface Prototype and the Architectural Prototype.

CSPS Iteration Plan 3.0

**Online Collegiate Paging Service

Iteration Plan**

Version 3.0

Revision History

| | | | | | — | — | — | — | | Date | Version | Description | Author || October 6, 1999 | 1.0 | Initial version | Context Integration | | October 27, 1999 | 2.0 | Updated at start of Elaboration | Context Integration | | November 20, 1999 | 3.0 | Updated at start of first Construction iteration | Context Integration |

Introduction
Plan
Resources
[Use Cases](#Use Cases)
[Evaluation Criteria](#Evaluation Criteria)

Iteration Plan

Introduction

Purpose

This Iteration Plan describes the detailed plans for the first Construction Iteration of the Collegiate Sports Paging System Project. During this iteration, the four most critical use cases will be developed.

Scope

The first Construction Iteration Plan applies to the Collegiate Sports Paging System project being developed by Context Integration for WebNewsOnLine . This document will be used by the Project Manager and by the project team.

Definitions, Acronyms and Abbreviations

See Glossary document.

References

CSPS Use Case - Approve Story 1.0
CSPS Use Case - Edit Profile 1.0
CSPS Use Case - Read Content on Website 1.0
CSPS Use Case - Send Content 1.0
CSPS Use Case - Send Page 1.0
CSPS Supplementary Specification 1.0

Plan

The Construction Iteration will complete the four most critical use cases in the Collegiate Sports Paging System.

Iteration Tasks

The following table illustrates the tasks with their planned start and end dates.


Task	Start	End
Construction Kick-off	Mon 11/29/99	Tue 11/30/99
Bring Full development team on board	Mon 11/29/99	Mon 11/29/99
Bring Full Testing staff on board	Mon 11/29/99	Mon 11/29/99
Construction Kick-off Meeting	Mon 11/29/99	Tue 11/30/99
Prepare for construction kick-off meeting	Mon 11/29/99	Mon 11/29/99
Hold Construction Kick-off Meeting	Mon 11/29/99	Tue 11/30/99
Celebrate project construction start w/entire team	Tue 11/30/99	Tue 11/30/99
Construction Kick-off Completed	Tue 11/30/99	Tue 11/30/99
First iteration	Tue 11/30/99	Thu 12/16/99
Do Technical Reviews	Tue 11/30/99	Tue 11/30/99
Technical Reviews 1	Tue 11/30/99	Tue 11/30/99
Technical Reviews 2	Tue 11/30/99	Tue 11/30/99
Test Planning	Tue 11/30/99	Tue 11/30/99
Software test plan for next iteration created, reviewed, and signed off	Tue 11/30/99	Tue 11/30/99
Software test cases for next iteration created, reviewed and signed off’	Tue 11/30/99	Tue 11/30/99
Software test plan and test cases for current iteration updated	Tue 11/30/99	Tue 11/30/99
Iteration Planning	Tue 11/30/99	Tue 11/30/99
Integration Build Plan created, reviewed, and signed off	Tue 11/30/99	Tue 11/30/99
Detailed Software Construction Plan for current interation including miniature milestones created, reviewed, and signed off	Tue 11/30/99	Tue 11/30/99
Update test plan, focusing on this iteration	Tue 11/30/99	Tue 11/30/99
Refine test cases for this iteration	Tue 11/30/99	Tue 11/30/99
Create test environment	Tue 11/30/99	Tue 11/30/99
Create software build instructions (make files) for current iteration	Tue 11/30/99	Tue 11/30/99
Beginning-of-iteration planning completed	Tue 11/30/99	Tue 11/30/99
Develop First Iteration	Tue 11/30/99	Thu 12/16/99
Code & Test Use Case Approve Story	Tue 11/30/99	Wed 12/8/99
Do Detailed Design	Tue 11/30/99	Wed 12/1/99
Review & Refine Architecture Design	Wed 12/1/99	Wed 12/1/99
Review & Refine Database Design	Wed 12/1/99	Thu 12/2/99
Develop Code or Modify Generated Code (if applicable)	Thu 12/2/99	Fri 12/3/99
Research and Resolve Development Tool Bugs (if applicable)	Fri 12/3/99	Tue 12/7/99
Conduct Code Review	Tue 12/7/99	Tue 12/7/99
Unit Testing	Tue 12/7/99	Wed 12/8/99
Add code to configuration management	Wed 12/8/99	Wed 12/8/99
Code & Test Use Case Edit Profile	Tue 11/30/99	Wed 12/8/99
Do Detailed Design	Tue 11/30/99	Wed 12/1/99
Review & Refine Architecture Design	Wed 12/1/99	Wed 12/1/99
Review & Refine Database Design	Wed 12/1/99	Thu 12/2/99
Develop Code or Modify Generated Code (if applicable)	Fri 12/3/99	Tue 12/7/99
Research and Resolve Development Tool Bugs (if applicable)	Tue 12/7/99	Tue 12/7/99
Conduct Code Review	Tue 12/7/99	Tue 12/7/99
Unit Testing	Wed 12/8/99	Wed 12/8/99
Add code to configuration management	Wed 12/8/99	Wed 12/8/99
Code & Test Use Case Send Page	Tue 11/30/99	Thu 12/16/99
Do Detailed Design	Tue 11/30/99	Thu 12/2/99
Review & Refine Architecture Design	Thu 12/2/99	Thu 12/2/99
Review & Refine Database Design	Thu 12/2/99	Thu 12/2/99
Develop Code or Modify Generated Code (if applicable)	Thu 12/9/99	Fri 12/10/99
Research and Resolve Development Tool Bugs (if applicable)	Fri 12/10/99	Tue 12/14/99
Conduct Code Review	Tue 12/14/99	Wed 12/15/99
Unit Testing	Wed 12/15/99	Wed 12/15/99
Add code to configuration management	Thu 12/16/99	Thu 12/16/99
Code & Test Use Case Read Content on Website	Tue 11/30/99	Thu 12/16/99
Do Detailed Design	Tue 11/30/99	Thu 12/2/99
Review & Refine Architecture Design	Thu 12/2/99	Thu 12/2/99
Review & Refine Database Design	Thu 12/2/99	Thu 12/2/99
Develop Code or Modify Generated Code (if applicable)	Fri 12/10/99	Tue 12/14/99
Research and Resolve Development Tool Bugs (if applicable)	Tue 12/14/99	Wed 12/15/99
Conduct Code Review	Wed 12/15/99	Wed 12/15/99
Unit Testing	Wed 12/15/99	Thu 12/16/99
Add code to configuration management	Thu 12/16/99	Thu 12/16/99
First Iteration Developed	Thu 12/16/99	Thu 12/16/99
Integration Testing	Wed 12/8/99	Fri 12/10/99
Integration with system	Wed 12/8/99	Thu 12/9/99
Conduct Integration Test	Thu 12/9/99	Thu 12/9/99
Document Problems	Thu 12/9/99	Thu 12/9/99
Modify Code As Applicable	Thu 12/9/99	Fri 12/10/99
Conduct Regression Test	Fri 12/10/99	Fri 12/10/99
Obtain Sign-off	Fri 12/10/99	Fri 12/10/99
Integration Test Complete	Fri 12/10/99	Fri 12/10/99
Installation	Fri 12/10/99	Mon 12/13/99
Install program created, reviewed, and signed off	Fri 12/10/99	Fri 12/10/99
Install Software for User Acceptance Testing	Fri 12/10/99	Fri 12/10/99
User Manual/Specification/Help updated	Fri 12/10/99	Mon 12/13/99
Training Materials updated (if applicable)	Mon 12/13/99	Mon 12/13/99
Obtain Sign-off	Mon 12/13/99	Mon 12/13/99
Installation Complete	Mon 12/13/99	Mon 12/13/99
User Checkpoint	Mon 12/13/99	Mon 12/13/99
Prepare for User Checkpoint	Mon 12/13/99	Mon 12/13/99
User Checkpoint Meeting and Demonstration	Mon 12/13/99	Mon 12/13/99
Have team, including client project manager, complete the work release sign-off form	Mon 12/13/99	Mon 12/13/99
First iteration code complete	Mon 12/13/99	Mon 12/13/99
User Acceptance Testing	Mon 12/13/99	Tue 12/14/99
Initiate User acceptance testing	Mon 12/13/99	Tue 12/14/99
Prepare for User sign-off meeting	Tue 12/14/99	Tue 12/14/99
Have team, including client project manager, complete the work release sign-off form	Tue 12/14/99	Tue 12/14/99
First Iteration User Acceptance Test Complete	Tue 12/14/99	Tue 12/14/99
Wrap-up First Iteration	Tue 12/14/99	Thu 12/16/99
Conduct Quality Check Meeting with Client	Tue 12/14/99	Tue 12/14/99
Hold Client Business-focused Lessons Learned Meeting	Tue 12/14/99	Tue 12/14/99
Hold Client Technical-focused Lessons Learned Meeting	Tue 12/14/99	Tue 12/14/99
Hold Context Lessons Learned Meeting	Tue 12/14/99	Wed 12/15/99
Iterative Delivery Project Plan updated, reviewed, and signed off	Wed 12/15/99	Wed 12/15/99
Software Development Plan updated, reviewed, and signed off	Wed 12/15/99	Wed 12/15/99
Knowledge Transfer Plan updated, reviewed, and signed off	Wed 12/15/99	Wed 12/15/99
Project estimates updated (accurate to +30%, -20%)	Wed 12/15/99	Wed 12/15/99
Move appropriate deliverables from Project Homepage to IAN Artifacts	Wed 12/15/99	Thu 12/16/99
First Iteration Wrap-up Completed	Thu 12/16/99	Thu 12/16/99

The following deliverables or artifacts will be generated and reviewed during the first Construction Iteration:


Artifact Set	Deliverable	Responsible Owner
Design Set	Implementation Model		Ken Perch
Implementation Set	Integration Build Plan Test Drivers, Stubs, Data, & Scripts Test Procedures Test Evaluation Report Components		Mary Durham Mike Hunziker Chris Curvey Mary Durham Justin Woddis
Management Set	Iteration Plan Project Plan (update) Project Schedule (update) Project Risk List (update) Status Assessment Iteration Assessment Test Plan		Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham

Resources

Staffing

The project staffing for this iteration can be viewed as follows:

Financial Resources

The budget for this iteration is $150,000. WebNewsOnLine has secured this funding.

Use Cases

Use cases to be implemented during this iteration are:

Approve Story
Edit Profile
Send Content
Read Content on Web Site
Send Page

Evaluation Criteria

The primary goal of this iteration is to implement the defined set of use cases.
Each deliverable developed during the iteration will be peer reviewed and subject to approval from the team.
Formal test plans will be the basis for evaluating the success of this iteration.

CSPS Iteration Plan 4.0

**Online Collegiate Paging Service

Iteration Plan

Version 4.0**

Revision History

Introduction
Plan
Resources
[Use Cases](#Use Cases)
[Evaluation Criteria](#Evaluation Criteria)

Introduction

Purpose

This Iteration Plan describes the detailed plans for the Transition Iteration of the Project. During this iteration, the WebNewsOnLine staff will be prepared to maintain the Collegiate Sports Paging System.

Scope

The Transition Iteration Plan applies to the Collegiate Sports Paging System project being developed by Context Integration for WebNewsOnLine . This document will be used by the Project Manager and by the project team.

Definitions, Acronyms and Abbreviations

See Glossary.

References

None

Plan

The Transition Iteration prepares the WebNewsOnLine staff to support and maintain the system going forward.

Iteration Tasks

The following table illustrates the tasks with their planned start and end dates.


Task	Start	End
Hold Transition Kick-off Meeting	Mon 2/14/00	Tue 2/15/00
Production Preparation	Tue 2/15/00	Wed 2/16/00
Release Procedures	Tue 2/15/00	Tue 2/15/00
“Release checklist created, reviewed, and baselined”	Tue 2/15/00	Tue 2/15/00
Release approval signed by all parties and put under change control	Tue 2/15/00	Tue 2/15/00
Operations Procedures	Tue 2/15/00	Wed 2/16/00
“Detailed Contingency and Disaster Recovery Plan created, reviewed, and baselined”	Tue 2/15/00	Tue 2/15/00
Complete Operations Training materials	Tue 2/15/00	Tue 2/15/00
Train Operations Team	Tue 2/15/00	Wed 2/16/00
Obtain Sign-off	Wed 2/16/00	Wed 2/16/00
Release & Operations Procedures Completed	Wed 2/16/00	Wed 2/16/00
Production Environment	Wed 2/16/00	Wed 2/16/00
“Production hardware acquired, installed and configured”	Wed 2/16/00	Wed 2/16/00
Network configuration completed	Wed 2/16/00	Wed 2/16/00
Production data loaded	Wed 2/16/00	Wed 2/16/00
Integration with legacy/external systems completed	Wed 2/16/00	Wed 2/16/00
Full system testing	Wed 2/16/00	Mon 2/21/00
Conduct Functionality testing	Wed 2/16/00	Wed 2/16/00
Conduct Performance testing	Wed 2/16/00	Thu 2/17/00
Conduct Load Testing	Thu 2/17/00	Fri 2/18/00
“Modify System for Functionality, or Performance as necessary”	Fri 2/18/00	Mon 2/21/00
“Conduct Regression Testing for Functionality, Performance & Load “	Mon 2/21/00	Mon 2/21/00
Full System Testing Completed	Mon 2/21/00	Mon 2/21/00
Final Acceptance Testing	Mon 2/21/00	Tue 2/22/00
Perform User Acceptance Test (1)	Mon 2/21/00	Mon 2/21/00
Performance Tuning	Mon 2/21/00	Tue 2/22/00
Perform User Acceptance Test (2)	Tue 2/22/00	Tue 2/22/00
User Acceptance Testing Complete	Tue 2/22/00	Tue 2/22/00
Business User Training	Tue 2/22/00	Wed 2/23/00
User training materials completed	Tue 2/22/00	Wed 2/23/00
“User Training environment (training data, etc.) created”	Wed 2/23/00	Wed 2/23/00
Business User Training Complete	Wed 2/23/00	Wed 2/23/00
Transition Wrap-up	Wed 2/23/00	Wed 2/23/00
Conduct Quality Check Meeting with Client	Wed 2/23/00	Wed 2/23/00
Review Transition Wrap-up Checklist for Completion	Wed 2/23/00	Wed 2/23/00
“Have team, including client project manager, complete the work release sign-off form”	Wed 2/23/00	Wed 2/23/00
Move appropriate deliverables from Project Homepage to IAN Artifacts	Wed 2/23/00	Wed 2/23/00
Transition Complete - System in production	Wed 2/23/00	Wed 2/23/00

The following deliverables or artifacts will be generated and reviewed during the Transition Iteration:


Artifact Set	Deliverable	Responsible Owner
Implementation Set	Test Evaluation Report		Mary Durham
Management Set	Iteration Plan Project Plan (update) Project Schedule (update) Project Risk List (update) Status Assessment Iteration Assessment		Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham Mary Durham

Resources

Staffing

The project staffing for this iteration can be viewed as follows:

Financial Resources

The budget for this iteration is $20,000. WebNewsOnLine has secured this funding.

Use Cases

All use cases have been implemented.

Evaluation Criteria

The primary goal of this iteration is to hand the system off to WebNewsOnLine staff. Success will be measured by final user acceptance and operations acceptance.

**Collegiate Sports Paging Service

Navigation Map

Version 1.0**

Revision History


Date	Version	Description	Author
October 8, 1999	1.0	Initial version	Context Integration

Introduction
Overview
[Navigation Map](#Navigation Map)
[A Finalized Web Site Map](#A Finalized Web Site Map)

Introduction

Purpose

This document presents a graphical depiction of how navigation within the web site will move the user to various User Interface (UI) elements within the web site.

Scope

This document encompasses all major UI navigations that may be used in the web site.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Iteration Plan 1.0

Overview

The Navigation Map presents a graphical representation of the manner in which a user may navigate between the various screens available within the system.

Figure -1 - Navigation Map

This simple navigation hierarchy shows the progression from one screen to another. The login screen is the gateway to the service, providing access to current subscribers as well as directing potential subscribers to information about the service and the page that allows them to subscribe. Once the user has reached their homepage, they have access to the news articles and game summaries for the links sent to them on their pager. They can also edit their subscription preferences and view historical pages.

A Finalized Web Site Map

This web site map primarily indicates the pages that are a part of the service and the links between them. A more developed map will be drawn as the web site is developed. This finalized map will include visual pages and non-visual components that service pages the user sees. It will also describe refined paths the user may take through the web site.

CSPS Release Notes 1.0

Collegiate Sports Paging System

Release Notes

Version 1.0

Revision History


Date	Version	Description	Author
February 2, 2000	1.0	Version 1.0 Release	Context Integration

Introduction
[About This Release](#About This Release)
[Compatible Products](#Compatible Products)
Upgrading
[New Features](#New Features)
[Known Bugs and Limitations](#Known Bugs and Limitations)

Introduction

Disclaimer of warranty

WebNewsOnLine makes no representations or warranties, either express or implied, by or with respect to anything in this document, and shall not be liable for any implied warranties of merchantability or fitness for a particular purpose or for any indirect, special or consequential damages.

Copyright 1999, WebNewsOnLine. All rights reserved.

GOVERNMENT RIGHTS LEGEND: Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the applicable license agreement and as provided in DFARS 227.7202-1(a) and 227.7202-3(a) (1995), DFARS 252.227-7013(c)(1)(ii) (Oct 1988), FAR 12.212(a) (1995), FAR 52.227-19, or FAR 52.227-14, as applicable.

“WebNewsOnLine” and WebNewsOnLine’s products are trademarks of WebNewsOnLine. References to other companies and their products use trademarks owned by the respective companies and are for reference purpose only.

Purpose

The purpose of the Release Notes is to communicate the major new features and changes in this release of the Collegiate Sports Paging System. It also documents known problems and work-arounds.

Scope

This document describes the Collegiate Sports Paging System 1.0.

Definitions, Acronyms and Abbreviations

See Glossary.

References

None.

About This Release

The V1.0 release of the Collegiate Sports Paging System provides the ability for a subscriber to receive pages when news of interest to them occurs. A personalized web site is available for them to view stories on which they have received pages, as well as general collegiate sports news.

Compatible Products

This product has been tested on the following platforms (or with the following products):

Microsoft Internet Explorer V4.0
Netscape Navigator V4.6

Upgrading

Most browser software provides backward compatibility, so upgrading should pose no particular barriers. If the HTML version in use is to be upgraded, however, testing must take place in order to ensure that older browser versions can still view content.

New Features

This is a new release, all features are new.

Known Bugs and Limitations

General Note

There are no known bugs in this release, though the HTML has been optimized for Netscape Navigator.

CSPS Risk List

Collegiate Sports Paging System

Risk List

Version 1.0

Revision History


Date	Version	Description	Author
October 4, 1999	1.0	Initial version	Context Integration

Table of Contents

Topics

Introduction
Risks

Introduction

Purpose

This document describes the risks known to the Collegiate Sports Paging System project.

Scope

This risk lists addresses the entire Collegiate Sports Paging System project.

Definitions, Acronyms and Abbreviations

See Glossary document.

References

None.

Overview

The risks known at the publication date of this document are listed below, along with mitigation strategies for each risk.

Risks

Technical Risk : Capacity and Capability

Risk Magnitude: Most Damaging

Description: Areas of risk include the inability to deliver a solution that meets capacity requirements or to issue a page to a paging device. While the technology to provide such capability exists, the ability to send as many as 500,000 pages within 5 minutes will need to be proven.
Impacts: System not functional, probably resulting in loss of subscribers.
Indicators: Failed or delayed delivery of messages within established time frame of 5 minutes.
Mitigation Strategy: Context has provided similar pager capability for other projects, therefore this area of technical risk is relatively low. Context Integration must provide an estimate of time required to process and push information to subscribers based on average and maximum projected workloads, which are currently 200,000 to 500,000 subscribers. Context Integration will develop a scalable system. will provide hardware resources necessary to meet processing requirements. Context can not guarantee the ability of each paging gateway service to deliver service levels within the desired specifications.
Contingency Plan: Attempt to locate a service that can, at peak processing time, accept and send up to 500,000 page requests.

Scheduling Risk: Deployment of System Delayed Beyond March, 2000

Risk Magnitude: Most Damaging

Description: WebNewsOnline’s failure to deploy its system within the established schedule is considered by the management as failure and can result in cancellation of the project.
Impacts: Project will be cancelled.
Indicators: Failure to deploy before March, 2000.
Mitigation strategy: The project timeline must be carefully calculated and, if time-constrained, the deliverable schedule shall drive the reduction of scope or scale (as an example, WebNewsOnLine may elect not to implement some of the defined functionality in the first release in order to achieve the target delivery date).
Contingency plan: None.

Technical Risk: Interoperability with existing Platform

Risk Magnitude: Low
Description: WebNewsOnline’s existing web site is IIS-based; it will be necessary to provide a means of immediately capturing each newly published article and transferring it to the for parsing and evaluation of targeted subscribers.
Impacts: The amount of coding to provide interfaces could increase.
Mitigation Strategy: Context Integration will need to work with the technical staff to determine the level of integration that is available with the existing content editing system.
Contingency plan: Develop an NT-based process that detects newly published IIS-resident documents and transfers them to the server.

CSPS Risk List

Collegiate Sports Paging System

Risk List

Version 2.0

Revision History


Date	Version	Description	Author
October 4, 1999	1.0	Initial version	Context Integration
October 26, 1999	2.0	Updated at end of Inception phase. Interoperability risk is gone, capability risk remains high.	Context Integration

Table of Contents

Topics

Introduction
Risks

Introduction

Purpose

This document describes the risks known to the Collegiate Sports Paging System project.

Scope

This risk lists addresses the entire Collegiate Sports Paging System project.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Glossary 1.0

Overview

The risks known at the publication date of this document are listed below, along with mitigation strategies for each risk.

Risks

Technical Risk : Capacity and Capability

Risk Magnitude: Most Damaging

Description: Areas of risk include the inability to deliver a solution that meets capacity requirements or to issue a page to a paging device. While the technology to provide such capability exists, the ability to send as many as 500,000 pages within 5 minutes will need to be proven.
Impacts: System not functional, probably resulting in loss of subscribers.
Indicators: Failed or delayed delivery of messages within established time frame of 5 minutes.
Mitigation Strategy: Context has provided similar pager capability for other projects, therefore this area of technical risk is relatively low. Context Integration must provide an estimate of time required to process and push information to subscribers based on average and maximum projected workloads, which are currently 200,000 to 500,000 subscribers. Context Integration will develop a scalable system. will provide hardware resources necessary to meet processing requirements. Context can not guarantee the ability of each paging gateway service to deliver service levels within the desired specifications.
Contingency Plan: Attempt to locate a service that can, at peak processing time, accept and send up to 500,000 page requests

Scheduling Risk: Deployment of System Delayed Beyond March, 2000

Risk Magnitude: Most Damaging

Description: WebNewsOnline’s failure to deploy its system within the established schedule is considered by the management as failure and can result in cancellation of the project.
Impacts: Project will be cancelled.
Indicators: Failure to deploy before March, 2000.
Mitigation strategy: The project timeline must be carefully calculated and, if time-constrained, the deliverable schedule shall drive the reduction of scope or scale (as an example, WebNewsOnLine may elect not to implement some of the defined functionality in the first release in order to achieve the target delivery date).
Contingency plan: None.

CSPS Risk List

Collegiate Sports Paging System

Risk List

Version 3.0

Revision History


Date	Version	Description	Author
October 4, 1999	1.0	Initial version	Context Integration
October 26, 1999	2.0	Updated at end of Inception phase. Interoperability risk is gone, capability risk remains high.	Context Integration
November 20, 1999	3.0	Updated at end of Elaboration - risks unchanged.	Context Integration

Table of Contents

Topics

Introduction
Risks

Introduction

Purpose

This document describes the risks known to the Collegiate Sports Paging System project.

Scope

This risk lists addresses the entire Collegiate Sports Paging System project.

Definitions, Acronyms and Abbreviations

See Glossary document.

References

CSPS Glossary 1.0.doc

Overview

The risks known at the publication date of this document are listed below, along with mitigation strategies for each risk.

Risks

Technical Risk : Capacity and Capability

Risk Magnitude

Most Damaging

Description

Areas of risk include the inability to deliver a solution that meets capacity requirements or to issue a page to a paging device. While the technology to provide such capability exists, the ability to send as many as 500,000 pages within 5 minutes will need to be proven.

Impacts

System not functional, probably resulting in loss of subscribers.

Indicators

Failed or delayed delivery of messages within established time frame of 5 minutes.

Mitigation Strategy

Context has provided similar pager capability for other projects, therefore this area of technical risk is relatively low. Context Integration must provide an estimate of time required to process and push information to subscribers based on average and maximum projected workloads, which are currently 200,000 to 500,000 subscribers. Context Integration will develop a scalable system. will provide hardware resources necessary to meet processing requirements. Context can not guarantee the ability of each paging gateway service to deliver service levels within the desired specifications.

Contingency Plan

Attempt to locate a service that can, at peak processing time, accept and send up to 500,000 page requests

Scheduling Risk: Deployment of System Delayed Beyond March, 2000

Risk Magnitude

Most Damaging

Description

WebNewsOnline’s failure to deploy its system within the established schedule is considered by the management as failure and can result in cancellation of the project.

Impacts

Project will be cancelled.

Indicators

Failure to deploy before March, 2000.

Mitigation strategy

The project timeline must be carefully calculated and, if time-constrained, the deliverable schedule shall drive the reduction of scope or scale (as an example, WebNewsOnLine may elect not to implement some of the defined functionality in the first release in order to achieve the target delivery date).

Contingency plan

None.

CSPS Software Architecture Document 1.0

**Collegiate Sports Paging System

Software Architecture Document**

Version 1.0

Revision History


Date	Version	Description	Author
November 30, 1999	1.0	Initial Version

Introduction
[Architectural Representation](#Architectural Representation)
[Architectural Goals and Constraints](#Architectural Goals and Constraints)
[Use-Case View](#Use-Case View)
[Logical View](#Logical View)
[Process View](#Process View)
[Deployment View](#Deployment View)
[Implementation View](#Implementation View)
[Size and Performance](#Size and Performance)
Quality

Introduction

Purpose

This document provides a comprehensive architectural overview of the system, using a number of different architectural views to depict different aspects of the system. It is intended to capture and convey the significant architectural decisions which have been made on the system.

Scope

This Software Architecture Document applies to the Collegiate Sports Paging System which will be developed by Context Integration.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Requirements Management Plan 1.0
CSPS Iteration Plan 1.0
CSPS Supplementary Specification 1.0
CSPS Use Case - Approve Story 1.0
CSPS Use Case - Edit Profile 1.0
CSPS Use Case - Pay Fee With Credit Card 1.0
CSPS Use Case - Print Advertiser Reports 1.0
CSPS Use Case - Provide Advertising Content 1.0
CSPS Use Case - Provide Feedback 1.0
CSPS Use Case - Read Content on Website 1.0
CSPS Use Case - Send Content 1.0
CSPS Use Case - Send Page 1.0
CSPS Use Case - Subscribe 1.0

Architectural Representation

This document presents the architectural as a series of views; use case view, process view, deployment view, and implementation view. These views are presented as Rational Rose Models and use the Unified Modeling Language (UML).

Architectural Goals and Constraints

There are some key requirements and system constraints that have a significant bearing on the architecture. They are:

The existing WebNewsOnLine website provides most of the content for display. An interface to this system must be capable of handling large traffic volumes.
The existing WebNewsOnLine legacy Finance System at will eventually be used for billing advertisers (though this is a later release requirement). As such, advertising usage information must be able to be sent to the system.
All functions must be available through either of the two commercially available web browsers.
Any and all credit card or other financial transactions must be transmitted in a secured manner.
All performance and loading requirements, as stipulated in the Vision Document [1] and the Supplementary Specification [7], must be taken into consideration as the architecture is being developed.

Use-Case View

A description of the use-case view of the software architecture. The Use Case View is important input to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture.

The use cases in this system are listed below. Use cases in bold are significant to the architecture. A description of these use cases can be found later in this section.

**- Approve Story

Click on Banner Ad**- Edit Profile
Modify Story **- Pay Fee With Credit Card
Print Advertiser Reports**- Provide Feedback - Read Content on Web Site- Read Public Content
Reject Story **- Post Content
Send Page
Subscribe**

The following diagrams depict the use cases in the system.

Figure 1 - Potential Subscriber Use Cases

Figure 2 - Subscriber Use Cases

Figure 3 - Advertiser Use Cases

Figure 4 - Current System Use Cases

Figure 5 - Pager Gateway Use Cases

Figure 6 - Editor Use Cases

Significant Use Case Descriptions

Approve Story

This Use Case takes place when an editor approves a story for inclusion in the Collegiate Sports Paging System. Some stories will automatically propogate from the existing WebNewsOnLine system, but some stories will require editor intervention (either because their subject is not clear or the categories to which the story belongs are not clear). This flow is also used to approve advertising content being posted.

Edit Profile

This Use Case occurs when a subscriber wishes to change their profile information or when a new subscriber wishes to enroll.

Pay Fee With Credit Card

This use case occurs when a new subscriber wants to pay their annual subscription fee by specifying a credit card number and PIN. This may also occur when an existing subscriber wants to renew.

Print Advertiser Reports

This use case occurs when an advertiser accesses the Collegiate Sports Paging System to obtain reports of how their advertising content has been viewed. Advertiser selects format (Microsoft® Word®, Microsoft® Excel®, or HTML) for the report.

Provide Feedback

This use case occurs when a system user (advertiser, subscriber, or potential subscriber) wishes to comment on the service or the web site.

Post Advertising Content

This use case occurs when an advertiser wants to post advertising content (banner ads) on the web site and specify which subscriber profiles should be used for display.

Read Content on Web Site

This use case occurs when an active subscriber connects to the system to view targeted information. Pages are dynamically built to show the user headlines for which they have been paged, as well as general sports categories to which they subscribe.

Send Content

This use case occurs when content is posted to the existing WebNewsOnLine website. Some stories will be tagged for transmission to the Collegiate Sports Paging System, and will be sent for possible paging and display.

Send Page

This use case occurs when new content is posted to the Collegiate Sports Paging System. This includes finding subscribers to be notified, formatting the page message, and sending the page via email.

This use case occurs when a potential subscriber wants to subscribe to the service. It notifies the user of contract terms and, if accepted, invokes the use case to edit a profile (specifying categories to which the user wants to subscribe, pager information, credit card info, etc.).

Logical View

Overview

A description of the logical view of the architecture. Describes the most important classes, their organization in service packages and subsystems, and the organization of these subsystems into layers. Also describes the most important use-case realizations, for example, the dynamic aspects of the architecture. Class diagrams may be included to illustrate the relationships between architecturally significant classes, subsystems, packages and layers.

The logical view of the Collegiate Sports Paging System is comprised of 5 main packages:

Presentation
- contains classes for each of the forms that the actors use to communicate with the System. Boundary classes exist to support maintaining of profiles, posting of advertising, printing of advertising reports, approving stories, providing feedback, subscribing, and paying fees with credit cards
Application
- contains classes for major processing functionality within the system. Control classes exist to support advertising administration, content management, profile management, subscription processing, paying fees with credit cards, and providing feedback.
Domain
- contains packages containing classes to support Content, Profile, Subscription, and Support.
Persistence
- contains classes to persist specific objects within the system. At this point in the design, only Profiles are persisted, though Content objects may be persisted at some future point (a selection of a packaged content management system may obviate the need for this).
Services
- contains classes to provide system-level classes for maintenance purposes - at this time, all maintenance is manual.

Logical View

Presentation Package

Application Package

Domain Package

Content Package

Profile Package

Support Package

Persistence Package

Process View

This section describes the system’s decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organize the section by groups of processes that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous.

At this point in the design, a single process is envisioned to provide server-level functions for the Collegiate Sports Paging System. Threads for application functions will be part of this process (application functions are listed in the previous section). The process diagram of the system can be viewed as follows:

Deployment View

This section describes one or more physical network (hardware) configurations on which the software is deployed and run. At a minimum for each configuration it should indicate the physical nodes (computers, CPUs) that execute the software, and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the physical nodes.

The CSPS Server is a UNIX server. The Client machine is any device capable of running a Web browser (most likely a PC, but not necessarily) and of connecting to the CSPS via the Internet. The Pager Gateway is an externally-maintained device provided by paging services.

Implementation View

All server software resides within a single layer. The browser client provides a secondary access layer.

Size and Performance

The software as designed will support 200,000 concurrent users. Scaling beyond this level may be achieved by providing multiple levels of Pager Gateway, or by simply providing additional Pager Gateway systems within the same tier.

Quality

The software as described above supports the existing WebNewsOnLine graphical standards, interfaces with the existing WebNewsOnLine server, and provides a self-describing user interface.

CSPS Software Development Plan

The Elaboration Phase will analyze the requirements and will develop the architectural prototype. At the completion of the Elaboration Phase all use cases selected for Release 1.0 will have completed analysis and design. In addition, the high risk use cases for Release 2.0 will have been analyzed and designed. The architectural prototype will test the feasibility and performance of the architecture that is required for Release 1.0. The Architectural Prototype Milestone marks the end of the Elaboration Phase. This prototype signifies verification of the major architectural components that comprise the R1.0 Release.

CSPS Status Assessment 12.22.99

**Collegiate Sports Paging System

Status Assessment

Version 1.0**

Revision History


Date	Version	Description	Author
November 22, 1999	1.0	Weekly assessment	Context Integration

Introduction
Resources
[Top 10 Risks](#Top 10 Risks)
[Technical Progress](#Technical Progress)
[Major Milestone Results](#Major Milestone Results)
[Total Project/Product Scope](#Total Project/Product Scope)
[Action Items and Follow-Through](#Action Items and Follow-Through)

Introduction

Purpose

This status assessment reviews the current status of the project with respect to resources, budget, schedule, risk, technical issues, and management issues. Any actions arising from this assessment will be summarized in this document.

Scope

This assessment reviews all aspects of the Collegiate Sports Paging System.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Requirements Management Plan 1.0
CSPS Iteration Plan 1.0
CSPS Creative Design Brief 1.0
CSPS Supplementary Specification 1.0
CSPS Iteration Plan 3.0
CSPS Risk List 3.0

Resources

Personnel/Staffing

Elaboration staff will be leaving the project as they are no longer needed. Departing staff include Brian Egler, Business Analyst, and Mark Grimes, Creative Designer. Staff whose contribution will increase are Justin Woddis, Implementer, various implementation subcontractors reporting to Justin, and Chris Curvey, Tester.

Financial Data

The project is delivered on a fixed-price basis. As such, no financial data need be reported.

Top 10 Risks

The project risks and their mitigation strategies can be found in the Risk List.

Technical Progress

During this iteration, the following artifacts were produced:

User-Interface Prototype
Analysis Model
Design Model
Software Architecture Document
Integration Build Plan
Architectural Prototype - Software Baseline
Test Drivers, Stubs, Data, & Scripts
Test Procedures
Test Evaluation Report
Iteration Plan
Status Assessment
Iteration Assessment
Test Plan
Design Guidelines
User-Interface Guidelines

The following artifacts were updated:

Glossary
Vision Document
Use Case Specifications
Supplementary Specification
Use Case Model and Model Survey
Project Plan
Project Schedule
Project Risk List

Major Milestone Results

The following table lists iteration milestones and their status at the end of this iteration.


Milestone	Planned	Actual	Comments
Use case design complete	11/3/1999	11/4/1999	One-day slip for documentation
Software Architecture document complete	11/22/1999	11/21/1999	No major issues raised with use cases during architectural design
Test Plans Complete	11/9/1999	11/10/1999	Mapped to use cases

Total Project/Product Scope

No scope changes occurred during this period.

Action Items and Follow-Through

The following action items were carried forward from last week or initiated this week:


Item	Assigned	Due	Status
Validate color scheme for UI with advertiser rep.	Mark Grimes	11/19/1999	Closed - minor change made to UI design guidelines
Investigate multi-tiered gateway approach	Ken Perch	11/25/1999	Open

CSPS Supplementary Specification（补充规约） 1.0

**Collegiate Sports Paging System

Supplementary Specification**

Version 1.0

Revision History


Date	Version	Description	Author
October 10, 1999	1.0	Initial version	Context Integration

Introduction
Functionality
Usability
Reliability
Performance
Supportability
[Design Constraints](#Design Constraints)
[Online User Documentation and Help System Requirements](#Online User Documentation and Help System Requirements)
[Purchased Components](#Purchased Components)
Interfaces
[Licensing Requirements](#Licensing Requirements)
[Legal, Copyright, and Other Notices](#Legal, Copyright, and Other Notices)
[Applicable Standards](#Applicable Standards)

Introduction

Purpose

The purpose of this document is to define requirements of the Collegiate Sports Paging System. This Supplementary Specification lists the requirements that are not readily captured in the use cases of the use-case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system.

Scope

This Supplementary Specification applies to the Collegiate Sports Paging System which will be developed by Context Integration.

The Collegiate Sports Paging System will allow subscribers to be notified via alphanumeric pager (or cellular phone or email) of events in specific areas of interest, then to access content via an individualized web interface.

This specification defines the non-functional requirements of the system; such as reliability, usability, performance, and supportability as well as functional requirements that are common across a number of use cases. (The functional requirements are defined in the Use Case Specifications.)

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Requirements Management Plan 1.0

Functionality

Functional requirements are captured via the defined use cases.

Usability

Ease of use

The system will not require user training beyond that of using a web browser. This will be verified by usability tests during the beta period.

Reliability

Availability

To be defined in subsequent phases.

Performance

Subscriber volume

The system will be able to support 200,000 subscribers, and provide a scaling mechanism to handle 500,000 subscribers.

Paging latency

When a news story is posted to the system, pages must be transmitted to the pager gateway within 5 minutes.

Supportability

Subscriber software

The subscriber shall be able to utilize the system through commercially available browser software. No custom software will be required to reside on the subscriber’s PC.

Design Constraints

WebNewsOnLine Look and Feel

: The system shall conform with existing WebNewsOnLine web site design standards.

WebNewsOnLine existing system connection

: The system shall communicate with the existing WebNewsOnLine web site for the purpose of receiving story content.

Online User Documentation and Help System Requirements

Each major function provided by the system will have its own online help function.

Purchased Components

To be defined in subsequent phases.

Interfaces

User Interfaces

See Creative Design documents:

CSPS Creative Design Brief 1.0
CSPS Design Comps 1.0
CSPS Navigation Map 1.0

Hardware Interfaces

To be defined in subsequent phases.

Software Interfaces

To be defined in subsequent phases.

Communications Interfaces

To be defined in subsequent phases.

Licensing Requirements

No client licenses are required.

Legal, Copyright, and Other Notices

Applicable Standards

To be defined in subsequent phases.

CSPS Supplementary Specification 2.0

**Collegiate Sports Paging System

Supplementary Specification**

Version 2.0

Revision History


Date	Version	Description	Author
October 10, 1999	1.0	Initial version	Context Integration
December 2, 1999	2.0	Update following Elaboration phase	Context Integration

Introduction
Functionality
Usability
Reliability
Performance
Supportability
[Design Constraints](#Design Constraints)
[Online User Documentation and Help System Requirements](#Online User Documentation and Help System Requirements)
[Purchased Components](#Purchased Components)
Interfaces
[Licensing Requirements](#Licensing Requirements)
[Legal, Copyright, and Other Notices](#Legal, Copyright, and Other Notices)
[Applicable Standards](#Applicable Standards)

Introduction

Purpose

Scope

This Supplementary Specification applies to the Collegiate Sports Paging System which will be developed by Context Integration.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Requirements Management Plan 1.0
CSPS Creative Design Brief 1.0
CSPS Design Comps 1.0

Functionality

Functional requirements are captured via the defined use cases.

Usability

Ease of use

The system will not require user training beyond that of using a web browser. This will be verified by usability tests during the beta period.

Reliability

Availability

The system will be available 24 hours per day, 7 days per week.

Performance

Subscriber volume

The system will be able to support 200,000 subscribers, and provide a scaling mechanism to handle 500,000 subscribers.

Paging latency

When a news story is posted to the system, pages must be transmitted to the pager gateway within 5 minutes.

Supportability

Subscriber software

The subscriber shall be able to utilize the system through commercially available browser software. No custom software will be required to reside on the subscriber’s PC.

Design Constraints

WebNewsOnLine Look and Feel

The system shall conform with existing WebNewsOnLine web site design standards.

WebNewsOnLine existing system connection

The system shall communicate with the existing WebNewsOnLine web site for the purpose of receiving story content.

Online User Documentation and Help System Requirements

Each major function provided by the system will have its own online help function.

Purchased Components

None.

Interfaces

User Interfaces

See Creative Design documents (references 4, 5, and 6).

Hardware Interfaces

No custom hardware interfaces are required.

Software Interfaces

The system will interconnect with the existing WebNewsOnLine system to receive content.

Communications Interfaces

The system requires no custom communications interfaces.

Licensing Requirements

No client licenses are required.

Legal, Copyright, and Other Notices

Applicable Standards

To be defined in subsequent phases.

CSPS Test Evaluation Report 1.0

**Collegiate Sports Paging System

Test Evaluation Summary

Version 1.0**

Revision History


Date	Version	Description	Author
November 17, 1999	1.0	Initial version	Context Integration

Introduction
[Test Results Summary](#Test Results Summary)
[Test Coverage](#Test Coverage)
[Code Coverage](#Code Coverage)
[Suggested Actions](#Suggested Actions)
Diagrams

Introduction

Purpose

This Test Evaluation Report describes the results of the tests in terms of test coverage (both requirements-based and code-based coverage) and defect analysis (i.e. defect density).

Scope

This Test Evaluation Report applies to the first Construction Iteration of the project. The tests conducted are described in the Test Plan for the first Construction Iteration. This Evaluation Report is to be used for the following:

assess the acceptability and appropriateness of the performance behavior(s) of the prototype,
assess the acceptability of the tests, and
identify improvements to increase test coverage and / or test quality.

Definitions, Acronyms and Abbreviations

See Glossary.

References

CSPS Vision 1.0
CSPS Requirements Management Plan 1.0
CSPS Iteration Plan 1.0

Test Results Summary

The test cases defined in the Test Model were executed following the test strategy as defined in the Test Plan. The test defects have been logged and any medium, high, or critical priority defects are currently assigned to the owner for fixing.

Test coverage (see the Test Coverage section in this document) in terms of covering the use cases and test requirements defined in the Test Plan was 100% complete.

Code coverage was measured using Rational Visual PureCoverage and is described in the Code Coverage section in this document.

Analysis of the defects (as shown in the Diagrams section in this document) indicates that the majority of found defects tend to be minor problems classified as low or medium in severity. The other significant finding was that software components comprising the interface to the Pager Gateway contained the highest number of defects.

Test Coverage

All test cases not relating to advertising content, as defined in the Test Model, were attempted. Of the tests cases executed, 5 tests failed.

The test coverage results are as follows:

Ratio Test Cases Performed = 80/80= 100%
Ratio Test Cases Successful = 75/80 = 93.75%

The area of tests with the highest failure rate was the Pager Gateway Interface, which failed under high volume testing.

Further detail on test coverage is available using Rational RequisitePro and the Test Case matrix.

Code Coverage

Rational Visual PureCoverage was used to measure code coverage of the tests.

Ratio LOC executed = 94,399 / 102,000 = 93%

Approximately, 93% of the code was executed during the testing. This coverage exceeded the target of 90%.

Suggested Actions

The following actions are recommended to improve performance to an acceptable level:

Implement a multi-tiered Pager Gateway system to provide increased scalability. This will require additional hardware to be installed by WebNewsOnLine.

Diagrams

CSPS Test Plan 1.0

Collegiate Sports Paging System

Test Plan

Version 1.0

Revision History


Date	Version	Description	Author
October 26, 1999	1.0	Initial version	Context Integration

Introduction
[Requirements for Test](#Requirements for Test)
[Test Strategy](#Test Strategy)
Resources
[Project Milestones](#Project Milestones)
Deliverables
[Appendix A: Project Tasks](#Appendix A: Project Tasks)

Introduction

Purpose

This Test Plan document for the Collegiate Sports Paging System supports the following objectives:

Identify existing project information and the software components that should be tested
List the recommended Requirements for Test (high level)
Recommend and describe the testing strategies to be employed
Identify the required resources and provide an estimate of the test efforts
List the deliverable elements of the test project

Background

The Collegiate Sports Paging System provides alphanumeric paging to subscribers when events occur within collegiate sports categories to which they subscribe. Subscribers can then connect to a personalized web site where they can view the stories for which they were paged, as well as other collegiate sports news.

The system is comprised of 3 major subsystems contained on an Application Web Server and interacts with the existing WebNewsOnLine web site as well as paging gateways. The subsystems include:

Content management - this subsystem accepts content, marks categories, and displays headlines for subscribers. It also manages advertising content that is targeted to specific groups of subscribers (based on their subscription profiles).
Paging - this subsystem activates when new content is loaded onto the system. It is responsible for determining who should be paged and sending messages to the paging gateways.
Reporting - this subsystem tracks and reports on advertising viewing.

The system architecture can be depicted as follows:

Scope

The Collegiate Sports Paging System will be unit tested and system tested. Unit tests will address functional quality, while system testing will address issues of scalability and performance.

The interaction of the subsystems will be tested as follows:

Content Management to Paging
Content Management to Reporting

The following systems interfaces will be tested:

Collegiate Sports Paging System to existing WebNewsOnLine Web Server
Collegiate Sports Paging System to paging gateways

The most critical testing will be that of load and performance testing. This will be addressed as follows:

We will create a test scenario that will generate increasing numbers of pages up to 200,000.
We will also create a test scenario that has new content arriving at the system at the rate of one item every 20 seconds.
Lastly, we will simulate increasing concurrent subscriber loads up to 200,000.

Project Identification

The table below identifies the documentation and availability, used for developing the test plan:


Document (and version / date)	Created or Available	Received or Reviewed	Author or Resource	Notes
Vision Document	n Yes o No	n Yes o No	Context Integration
Supplemental Specification	n Yes o No	n Yes o No	Context Integration
Use Case Reports	n Yes o No	n Yes o No	Context Integration
Project Plan	n Yes o No	n Yes o No	Context Integration
Design Specifications	o Yes n No	o Yes o No
Prototype	n Yes o No	n Yes o No	Context Integration
Project / Business Risk Assessment	n Yes o No	n Yes o No	Context Integration

Requirements for Test

The listing below identifies those items (use cases, functional requirements, non-functional requirements) that have been identified as targets for testing. This list represents what will be tested.

Database Testing

Verify that subscriber information can be entered and retrieved.

Verify that content and categories can be inserted and displayed.

Verify that advertiser profiles and account information can be entered and displayed.

Verify that subscriber-specific usage information is tracked.

Functional Testing

Verify that subscribers see the information for which they have requested paging.

Verify that pages go to subscribers when content arrives.

Verify that automatic content insertion works.

Verify that editor approval causes non-automatic content to be inserted.

Verify that subscribers who have lapsed subscriptions do not receive pages.

Verify that content marked as archived is not re-displayed to subscribers.

Verify that obsolete content is deleted.

Verify that advertiser reports are accurate.

Verify that advertiser reports can be received in Microsoft® Word®, Microsoft® Excel ®, or HTML.

Business Cycle Testing

None.

User Interface Testing

Navigate through all use cases, verifying that each UI panel can be easily understood

Verify all online Help functions

Verify that all screens conform to the WebNewsOnLine standards.

Performance Profiling

Verify response time of interface to Pager Gateway system.

Verify response time of interface from existing WebNewsOnLine web server.

Verify response time when connected using 56Kbps modem.

Verify response time when connected locally (on the same LAN).

Load Testing

Verify system response with 200 concurrent subscribers.

Verify system response with 500 concurrent subscribers.

Verify system response with 1,000 concurrent subscribers.

Verify system response with 5,000 concurrent subscribers.

Verify system response with 10,000 concurrent subscribers.

Verify system response with 50,000 concurrent subscribers.

Verify system response with 100,000 concurrent subscribers.

Verify system response with 200,000 concurrent subscribers.

Stress Testing

None.

Volume Testing

Verify pages sent out within 5 minutes when single content element arrives.

Verify pages sent out within 5 minutes when content arrives every 20 seconds.

Security and Access Control Testing

Verify that non-subscribers cannot access subscriber-only information.

Verify that non-editors can not approve content.

Verify that advertisers see only their own advertising content.

Failover/Recovery Testing

None.

Configuration Testing

Verify operation using Netscape V4.x browser.

Verify operation using Microsoft® Internet Explorer® V5.x

Installation Testing

None.

Test Strategy

Testing Types

Data and Database Integrity Testing


Test Objective:	Ensure database access methods and processes function properly and without data corruption.
Technique:	- Invoke each database access method and process, seeding each with valid and invalid data (or requests for data). - Inspect the database to ensure the data has been populated as intended, all database events occurred properly, or review the returned data to ensure that the correct data was retrieved (for the correct reasons)
Completion Criteria:	All database access methods and processes function as designed and without any data corruption.
Special Considerations:	- Processes should be invoked manually. - Small or minimally sized databases (limited number of records) should be used to increase the visibility of any non-acceptable events.

Function Testing


Test Objective:	Ensure proper target-of-test functionality, including navigation, data entry, processing, and retrieval.
Technique:	Execute each use case, use case flow, or function, using valid and invalid data, to verify the following: - The expected results occur when valid data is used. - The appropriate error and warning messages are displayed when invalid data is used. - Each business rule is properly applied.
Completion Criteria:	- All planned tests have been executed. - All identified defects have been addressed.
Special Considerations:	None.

User Interface Testing


Test Objective:	Verify the following: - Navigation through the target-of-test properly reflects business functions and requirements, including window to window, field to field, and use of access methods (tab keys, mouse movements, accelerator keys) - Web objects and characteristics, such as menus, size, position, state, and focus conform to standards.
Technique:	Create or modify tests for each window to verify proper navigation and object states for each application window and objects.
Completion Criteria:	Each window successfully verified to remain consistent with benchmark version or within acceptable standard
Special Considerations:	Not all properties for custom and third party objects can be accessed.

Performance Profiling


Test Objective:	Verify performance behaviors for designated transactions or business functions under the following conditions: - normal anticipated workload - anticipated worse case workload
Technique:	Use Test Procedures developed for Function or Business Cycle Testing. Modify data files (to increase the number of transactions) or the scripts to increase the number of iterations each transaction occurs. Scripts should be run on one machine (best case to benchmark single user, single transaction) and be repeated with multiple clients (virtual or actual, see special considerations below).
Completion Criteria:	Single Transaction or single user: Successful completion of the test scripts without any failures and within the expected or required time allocation (per transaction) Multiple transactions or multiple users: Successful completion of the test scripts without any failures and within acceptable time allocation.
Special Considerations:	Comprehensive performance testing includes having a “background” workload on the server. There are several methods that can be used to perform this, including: - “Drive transactions” directly to the server, usually in the form of SQL calls. - Create “virtual” user load to simulate many (usually several hundred) clients. Remote Terminal Emulation tools are used to accomplish this load. This technique can also be used to load the network with “traffic.” - Use multiple physical clients, each running test scripts to place a load on the system. Performance testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. The databases used for Performance testing should be either actual size, or scaled equally.

Load Testing


Test Objective:	Verify performance behaviours time for designated transactions or business cases under varying workload conditions.
Technique:	Use tests developed for Function or Business Cycle Testing. Modify data files (to increase the number of transactions) or the tests to increase the number of times each transaction occurs.
Completion Criteria:	Multiple transactions or multiple users: Successful completion of the tests without any failures and within acceptable time allocation.
Special Considerations:	Load testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. The databases used for load testing should be either actual size, or scaled equally.

Volume Testing


Test Objective:	Verify that the target-of-test successfully functions under the following high volume scenarios: - maximum (actual or physically capable) number of clients connected (or simulated) all performing the same, worst case (performance) business function for an extended period. - maximum database size has been reached (actual or scaled) and multiple queries and report transactions are executed simultaneously.
Technique:	Use tests developed for Performance Profiling or Load Testing. Multiple clients should be used, either running the same tests or complementary tests, to produce the worst case transaction volume or mix (see stress test above) for an extended period. Maximum database size is created (actual, scaled, or filled with representative data) and multiple clients used to run queries and report transactions simultaneously for extended periods.
Completion Criteria:	All planned tests have been executed and specified system limits are reached or exceeded without the software or software failing.
Special Considerations:	What period of time would be considered an acceptable time for high volume conditions (as noted above)?

Security and Access Control Testing


Test Objective:	Application-level Security: Verify that an actor can access only those functions and data for which their user type is provided permissions. System-level Security: Verify that only those actors with access to the system and applications are permitted to access them.
Technique:	Application-level: Identify and list each actor type and the functions or data each type has permissions for. Create tests for each actor type and verify each permission by creating transactions specific to each user actor. Modify user type and re-run tests for same users. In each case verify those additional functions and data are correctly available or denied. System-level Access (see special considerations below)
Completion Criteria:	For each known actor type, the appropriate function and data are available, and all transactions function as expected and run in prior function tests
Special Considerations:	Access to the system must be reviewed or discussed with the appropriate network or systems administrator. This testing may not be required as it maybe a function of network or systems administration.

Configuration Testing


Test Objective:	Verify that the target-of-test functions properly on the required hardware and software configurations.
Technique:	Use Function Test scripts Open or close various non-target-of-test related software, such as the Microsoft applications Excel® and Word®, either as part of the test or prior to the start of the test. Execute selected transactions to simulate actor’s interacting with the target-of-test and the non-target-of-test software Repeat the above process, minimizing the available conventional memory on the client.
Completion Criteria:	For each combination of the target-of-test and non-target-of-test software, all transactions are successfully completed without failure.
Special Considerations:	What non-target-of-test software is needed, is available, accessible on the desktop? What applications are typically used? What data are the applications running (that is, large spreadsheet opened in Excel, 100 page document in Word)? The entire systems, netware, network servers, databases, and so forth should also be documented as part of this test.

Tools

The following tools will be employed for this project:


	Tool	Version
Defect Tracking	Project HomePage
Project Management	Microsoft® Project®

Resources

This section presents the recommended resources for the Collegiate Sports Paging System test effort, their main responsibilities, and their knowledge or skill set.

Workers

This table shows the staffing assumptions for the project.


Human Resources
Worker	Minimum Resources Recommended	Specific Responsibilities and Comments
Test Manager, Test Project Manager	1 ( Collegiate Sports Paging System project manager)	Provides management oversight Responsibilities: - Provide technical direction - Acquire appropriate resources - Management reporting
Test Designer	1	Identifies, prioritizes, and implements test cases Responsibilities: - Generate test plan - Generate test model - Evaluate effectiveness of test effort
Tester	4 (provided by WebNewsOnLine)	Executes the tests Responsibilities: - Execute tests - Log results - Recover from errors - Document change requests
Test System Administrator	1	Ensures test environment and assets are managed and maintained. Responsibilities: - Administer test management system - Install and manage worker access to test systems
Database Administration / Database Manager	1 (provided by WebNewsOnLine)	Ensures test data (database) environment and assets are managed and maintained. Responsibilities: - Administer test data (database)
Designer	2	Identifies and defines the operations, attributes, and associations of the test classes Responsibilities: - Identifies and defines the test class(es) - Identifies and defines the test packages
Implementer	4	Implements and unit tests the test classes and test packages Responsibilities: - Creates the test classes and packages implemented in the test model.

System

The following table sets forth the system resources for the testing project.

The specific elements of the test system are not fully known at this time. It is recommended that the system simulate the production environment, scaling down the accesses and database sizes, if and where appropriate.


System Resources
Resource	Name and Type
Database Server
-Network/Subnet	TBD
-Server Name	TBD
-Database Name	TBD
Client Test PCs
-Include special configuration -requirements	TBD
Test Repository
-Network/Subnet	TBD
-Server Name	TBD
Test Development PCs	TBD

Project Milestones


Milestone Task	Effort	Start Date	End Date
Plan Test
Design Test
Implement Test
Execute Test
Evaluate Test

Deliverables

Test Model

For each test executed, a test result form will be created. This will include the name or ID of the test, the use case or supplemental specification to which the test relates, the date of the test, the ID of the tester, required pre-test conditions, and results of the test.

Test Logs

Microsoft Word will be used to record and report test results.

Defect Reports

Defects will be recorded using the Project HomePage using the Web.

Appendix A: Project Tasks

The following table lists the test related tasks.

CSPS Use Case : Approve Story 1.0

**Collegiate Sports Paging System

Use Case Specification: Approve Story**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Approve Story](#Approve Story)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Approve Story

Brief Description

This Use Case takes place when an editor approves a story for inclusion in the Collegiate Sports Paging System. Some stories will automatically propogate from the existing system, but some stories will require editor intervention (either because their subject is not clear or the categories to which the story belongs are not clear). This flow is also used to approve advertising content being posted.

Flow of Events

Basic Flow

The system places a story in the editor’s “to-do” workflow.
The editor views the story.
The editor categorizes the story and marks it approved.
The system includes the story and triggers initiation of paging messages.

Alternate Flows

Reject Content
The editor views the story.
The editor marks the story as rejected
The system notifies the originator of the content that the story has been rejected
Modify Content
Editor selects “Modify Story”
System displays titles of all stories available
Editor selects specific title
System displays characteristics of story
Editor updates characteristics
Editor selects “Save”
System re-posts story, triggering paging activity as needed
Approve Advertising Content
The editor views the advertising content
The editor marks it approved.
The system includes the advertising content for display
The system marks the preliminary billing record as approved
Reject Advertising Content
The editor views the advertising content
The editor marks it rejected and provides a reason for rejection
The system notifies the advertiser (via email) of the rejection and the reason
Story not viewable

If the story has been deleted by another editor and is not currently viewable, the use case terminates.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Editor must be logged in.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Approve Story 2.0

**Collegiate Sports Paging System

Use Case Specification: Approve Story**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update with detail from Elaboration	Context Integration

[Approve Story](#Approve Story)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Approve Story

Brief Description

Flow of Events

Basic Flow

The system places a story in the editor’s “to-do” workflow queue. If more than one editor is defined, a round-robin approach is used to attempt to balance load. Editors may be marked as unavailable (if, for instance, they are on vacation or sick or out of the office), in which case they will not be included in the round-robin process.
The editor views the story.
The editor categorizes the story by selecting from system-provided categories. There may be more than one category assigned to the story. At least one category must be assigned to the story.
The editor then marks the story as approved.
The system includes the story in the list of available content for paging initiation.
The system triggers initiation of paging messages.

Alternate Flows

Reject Content
The editor views the story.
The editor marks the story as rejected and describes the reason for rejection.
The system notifies the originator of the content that the story has been rejected and includes the reason provided by the editor.
The system deletes the story.
Modify Content
Editor selects “Modify Story”
System displays titles of all stories available
Editor selects specific title
System displays characteristics of story
Editor updates characteristics, either deleting some categories, adding other categories, or both.
Editor selects “Save”
System re-posts the story to the list of available content for paging initiation.
The system triggers initiation of paging messages.
Approve Advertising Content
The editor views the advertising content
The editor marks it approved.
The system includes the advertising content in the list of available advertising for display
The system creates a preliminary billing record, using information stored about the advertiser (billing rate indicator, advertiser name and billing address), content identification, date, and total due.
The system marks the preliminary billing record as approved
Reject Advertising Content
The editor views the advertising content
The editor marks it rejected and provides a reason for rejection. This may include account overdue, content inappropriate or not within scope of contract, or duplicate content (advertising content is already on file and being displayed).
The system notifies the advertiser (via email) of the rejection and the reason.
The system deletes the content.
Story not viewable

If the story has been deleted by another editor and is not currently viewable, the use case terminates.

Special Requirements

None.

Preconditions

Editor must be logged in.

Postconditions

When this use case is complete, content is available. For advertising content, the content will be eligible for display immediately. For story content, the paging process can begin immediately.

Extension Points

None.

CSPS Use Case : Edit Profile 1.0

**Collegiate Sports Paging System

Use Case Specification: Edit Profile**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Edit Profile](#Edit Profile)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Edit Profile

Brief Description

This use case occurs when a subscriber wishes to change their profile information or when a new subscriber wishes to enroll.

Flow of Events

Basic Flow

User selects “Edit Profile”
System displays categories of profile (personal, preferences, pager information, “page me when” selections).
User selects category
System displays detail
User updates detail, presses “OK”
System validates data as required, updates subscriber profile.

Alternate Flows

If this is a new subscriber, the use case “Pay Fee with Credit Card” is invoked following step 5 above.

Special Requirements

Special requirements will be determined during the next iteration.

This needs to be secured as credit card information may be in the profile.

Preconditions

Preconditions will be determined during the next iteration.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Edit Profile 2.0

**Collegiate Sports Paging System

Use Case Specification: Edit Profile**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration phase	Context Integration

[Edit Profile](#Edit Profile)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Edit Profile

Brief Description

This use case occurs when a subscriber wishes to change their profile information or when a new subscriber wishes to enroll.

Flow of Events

Basic Flow

User selects “Edit Profile”
System displays categories of profile ([personal](ex_gloss2.md#Personal Profile), [preferences](ex_gloss2.md#Preferences Profile), pager information, “[page me when](ex_gloss2.md#Page-me-when Profile)” selections).
User selects category.
If more than one profile exists for a category (for instance, a subscriber may have more than one pager), a list of possible profiles within the category is presented.
User selects specific profile within category.
System displays detail of specific profile.
User updates detail, presses “OK”
If information changed includes credit card information, system validates new information with external credit card system. If information contains pager information, pager PIN format is validated along with email address for sending pages.
System updates subscriber profile.

Alternate Flows

If validation of credit card information fails, user is presented with a message indicating failure, and is presented with their profile for update once again.

If this is a new subscriber, the use case “Pay Fee with Credit Card” is invoked following step 9 above.

Special Requirements

This needs to be secured as credit card information may be in the profile.

Preconditions

None.

Postconditions

For a new subscriber, when this use case is complete, the subscriber is immediately eligible to receive pages.

Extension Points

None.

CSPS Use Case : Pay Fee with Credit Card 1.0

**Collegiate Sports Paging System

Use Case Specification: Pay Fee with Credit Card**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Pay Fee With Credit Card](#Pay Fee With Credit Card)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Pay Fee With Credit Card

Brief Description

This use case occurs when a new subscriber wants to pay their annual subscription fee by specifying a credit card number and PIN. This may also occur when an existing subscriber wants to renew (see alternate flow 1)

Flow of Events

Basic Flow

Subscriber selects “pay fee with credit card”
System prompts subscriber for credit card number, expiration date, and (optionally) PIN
System sends credit card info to external system for charge validation and application
Upon receipt of validation, system updates subscriber record to indicate new expiration date

Alternate Flows

Subscriber renews subscription

When this occurs, the flow runs as follows:

Subscriber selects “pay fee with credit card”
System displays current credit card information
User either accepts information as is or updates appropriately
System sends credit card info to external system for charge validation and application
Upon receipt of validation, system updates subscriber record to indicate new expiration date

Invalid credit card information

Special Requirements

Special requirements will be determined during the next iteration.

Issue - interface specifications for external credit card system need to be verified.

Preconditions

Preconditions will be determined during the next iteration.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Pay Fee with Credit Card 2.0

**Collegiate Sports Paging System

Use Case Specification: Pay fee with credit card**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration	Context Integration

[Pay Fee With Credit Card](#Pay Fee With Credit Card)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Pay Fee With Credit Card

Brief Description

Flow of Events

Basic Flow

Subscriber selects “pay fee with credit card”
System checks to see if user is a current subscriber. If the user is a new subscriber, a new subscriber ID is generated by the system (using any algorithm that will generate a unique number - this may, for instance, be a continually incrementing number within the system).
System checks to see if current subscriber credit card information is on file. If it is, user is presented with indicator of credit card on file (using the last four digits of the card number), and asked if this card should be used.
If user declines current card information on file, system prompts subscriber for credit card number, expiration date, and (optionally) PIN
System verifies that expiration date on credit card has not already passed.
System sends credit card info to external system for charge validation and application
Upon receipt of validation, system updates subscriber record to indicate new expiration date

Alternate Flows

Subscriber renews subscription

When this occurs, the flow runs as follows:

Subscriber selects “pay fee with credit card”
System displays current credit card information
User either accepts information as is or updates appropriately
System sends credit card info to external system for charge validation and application
Upon receipt of validation, system updates subscriber record to indicate new expiration date
Invalid credit card information

If the information provided by the subscriber is not validated by the external system, an error message will be displayed and the subscriber record will NOT be updated (so that the last steps in the above flows will not be executed). If the credit card has expired, an error message will be displayed and the subscriber record will not be updated.

Special Requirements

None.

Preconditions

User is identified as a subscriber and has a subscriber ID associated with them. For first-time subscribers, a preliminary subscriber entry is made.

Postconditions

None.

Extension Points

None.

CSPS Use Case : Post Advertising Content 1.0

**Collegiate Sports Paging System

Use Case Specification: Post Advertising Content**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Provide Advertising Content](#Provide Advertising Content)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Post Advertising Content

Brief Description

This use case occurs when an advertiser wants to post advertising content (banner ads) on the web site and specify which subscriber profiles should be used for display.

Flow of Events

Basic Flow

Advertiser selects “Post Content”
System validates account billing information to ensure new content will be accepted
System prompts for content
Advertiser uploads content in GIF format
System displays potential categories for ad display (based on subscriber profile options)
Advertiser selects categories for which this ad should be shown
System displays potential frequencies and prices for the ad
Advertiser selects desired frequency for this ad
System creates preliminary billing record for this ad
System places content in editor’s “to-do” workflow for approval

Alternative Flow

Invalid Account Information

Advertiser selects “Post Content”
System validates account billing information to ensure new content will be accepted
Account information is invalid, advertiser is prompted to contact .

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

User is connected and validated as an advertiser.

Advertiser account exists.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Post Advertising Content 2.0

**Collegiate Sports Paging System

Use Case Specification: Post Advertising Content**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Updated after Elaboration phase	Context Integration

[Provide Advertising Content](#Provide Advertising Content)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Post Advertising Content

Brief Description

This use case occurs when an advertiser wants to post advertising content (banner ads) on the web site and specify which subscriber profiles should be used for display.

Flow of Events

Basic Flow

Advertiser selects “Post Content”
System validates account billing information to ensure new content will be accepted. This consists of verifying that the advertiser account is in good standing (no outstanding balance over 30 days).
System prompts for name of content.
Advertiser uploads content in GIF format.
System stores GIF in a staging area and records location and name of file.
System acknowledges successful saving of content.
System displays potential categories for ad display. Categories are maintained as a reference list within the system.
Advertiser selects categories for which this ad should be shown.
System displays potential frequencies and prices for the ad. Frequencies are maintained as a reference list, prices are based on advertiser’s contract with WebNewsOnLine. Pricing codes are maintained as part of the [advertiser profile](ex_gloss2.md#Advertiser Profile).
Advertiser selects desired frequency for this ad
System creates preliminary billing record for this ad based on number of categories selected, frequency, and advertiser’s profile.
System places content in editor’s “to-do” workflow queue for approval. If more than one editor is defined, a round-robin approach is used to attempt to balance load. Editors may be marked as unavailable (if, for instance, they are on vacation or sick or out of the office), in which case they will not be included in the round-robin process.

Alternative Flow

Invalid Account Information
Advertiser selects “Post Content”
System validates account billing information to ensure new content will be accepted
Account information is invalid, advertiser is prompted to contact WebNewsOnLine. System presents central phone number for advertising department (stored in system).

Special Requirements

None.

Preconditions

User is connected and validated as an advertiser.

Advertiser account exists.

Postconditions

When this use case is complete, advertising content can be displayed.

Extension Points

None.

CSPS Use Case : Print Advertiser Reports 1.0

**Collegiate Sports Paging System

Use Case Specification: Print Advertiser Reports**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Print Advertiser Reports](#Print Advertiser Reports)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Print Advertiser Reports

Brief Description

This use case occurs when an advertiser accesses the Collegiate Sports Paging System to obtain reports of how their advertising content has been viewed.

Flow of Events

Basic Flow

Advertiser selects “Print Reports”
System displays all advertising content provided by advertiser
Advertiser selects one or more pieces of content on which to report
System displays a list of reports for this advertiser
Advertiser selects one or more reports to generate
Advertiser selects format (Microsoft® Word®, Microsoft® Excel®, or to browser window)
System creates first report and prompts user to save or view
Advertiser saves or views report, selects “Next Report”
System creates next report and prompts user to save or view
Bullets 8) and 9) are repeated until no more reports remain

Alternate Flows

None

Special Requirements

Special requirements will be determined during the next iteration.

Issues - what do we do with obsolete content? How long will we allow reports to be run on content no longer available on the web site? Do we need to encrypt this transmission?

Preconditions

User is connected and validated as an advertiser.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Print Advertiser Reports 2.0

**Collegiate Sports Paging System

Use Case Specification: Print Advertiser Reports**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration	Context Integration

[Print Advertiser Reports](#Print Advertiser Reports)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Print Advertiser Reports

Brief Description

This use case occurs when an advertiser accesses the Collegiate Sports Paging System to obtain reports of how their advertising content has been viewed.

Flow of Events

Basic Flow

Advertiser selects “Print Reports”
System displays all advertising content provided by advertiser
Advertiser selects one or more pieces of content on which to report
System displays a list of reports for this advertiser. Available reports for each advertiser are based on advertiser contract with WebNewsOnLine, and are part of [advertiser profile](ex_gloss2.md#Advertiser Profile) on file.
Advertiser selects one or more reports to generate
Advertiser selects format (Microsoft® Word®, Microsoft® Excel®, or to browser window)
System creates first report and prompts user to save or view
If advertiser selects “Save”, a message is sent to the browser to initiate a download of the report file. User interacts with browser to select location for saving the report, and the browser saves the downloaded file.
If advertiser selects “View”, the report is displayed in the browser.
If more reports are available in this session, advertiser then selects another report or terminates the viewing session.
System creates next report and prompts user to save or view
Bullets 4) through 11) are repeated until no more reports remain

Alternate Flows

None

Special Requirements

Encryption of the information is not required (issue from Inception phase).

Obsolete content will be purged after 3 months.

No reports may be run on purged content.

Preconditions

User is connected and validated as an advertiser.

Postconditions

None.

Extension Points

None.

CSPS Use Case : Provide Feedback 1.0

**Collegiate Sports Paging System

Use Case Specification: Provide Feedback**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Provide Feedback](#Provide Feedback)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Provide Feedback

Brief Description

This use case occurs when a system user (advertiser, subscriber, or potential subscriber) wishes to comment on the service or the web site.

Flow of Events

Basic Flow

User selects “Provide Feedback”
System looks up central user support phone numbers.
System displays phone numbers to call and gives the user the option to send email immediately
User selects email option
System looks up email address of customer service and passes it to the browser.
System launches email browser client
User enters message, presses “Send”
Browser mail client sends mail.

Alternative Flows

None

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Preconditions will be determined during the next iteration.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Provide Feedback 2.0

**Collegiate Sports Paging System

Use Case Specification: Provide Feedback**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration	Context Integration

[Provide Feedback](#Provide Feedback)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Provide Feedback

Brief Description

This use case occurs when a system user (advertiser, subscriber, or potential subscriber) wishes to comment on the service or the web site. This option will be made available to users at main display pages only.

Flow of Events

Basic Flow

User selects “Provide Feedback”
System looks up central user support phone numbers.
System displays phone numbers to call and gives the user the option to send email immediately
User selects email option
System looks up email address of customer service and passes it to the browser.
System launches email browser client
User enters message, presses “Send”
Browser mail client sends mail.

Alternative Flows

None.

Special Requirements

None.

Preconditions

None.

Postconditions

None.

Extension Points

None.

CSPS Use Case : Read Content on Web Site 1.0

**Collegiate Sports Paging System

Use Case Specification: Read Content on Web Site**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Read Content on Web Site](#Read Content on Web Site)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Read Content on Web Site

Brief Description

This use case occurs when an active subscriber or unregistered user connects to the system to view information.

Flow of Events

Basic Flow

System scans “archived” list of content. For any stories older than 2 days, the story is moved back into the general category
System displays banner ads, general content categories, and specific stories for which pages have been sent.
Subscriber views stories
For any paged stories, the stories are marked as viewed and placed into an “archived” category

Alternate Flows

User is not registered subscriber

System displays banner ads and general content categories
System provides the option for the user to subscribe
User views stories

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

None.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Read Content on Web Site 2.0

**Collegiate Sports Paging System

Use Case Specification: Read Content on Web Site**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Updated after Elaboration	Context Integration

[Read Content on Web Site](#Read Content on Web Site)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions

Read Content on Web Site

Brief Description

This use case occurs when an active subscriber or unregistered user connects to the system to view information.

Flow of Events

Basic Flow

System scans “archived” list of content. Content subscribed to remains in a user’s “unread” category until the story has been viewed. Once the story has been viewed, the story is marked as “archived” for that subscriber. After two days in the “archived” category, the story is removed from the subscriber’s “archived” category. For any stories older than 2 days, the story is moved back into the general category and the reference count attribute of the content object is decremented.
When a story is no longer referenced by any subscribers’ “unread” or “archived” category (reference count is 0), the system deletes the story.
System displays banner ads, general content categories, and specific stories for which pages have been sent.
Subscriber views stories.
For any paged stories, the stories are marked as viewed and placed into the “archived” category.

Alternate Flows

User is not registered subscriber
System displays banner ads and general content categories
System provides the option for the user to subscribe
User views stories
Content is obsolete

If this content has a pending view count of 0 and the last date viewed is more than 2 days ago, the content is deleted.

Special Requirements

None.

Preconditions

None.

Postconditions

None.

CSPS Use Case : Send Content 1.0

**Collegiate Sports Paging System

Use Case Specification: Send Content**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Send Content](#Send Content)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Send Content

Brief Description

This use case occurs when content is posted to the existing WebNewsOnLine web site. Some stories will be tagged for transmission to the Collegiate Sports Paging System, and will be sent for possible paging and display.

Flow of Events

Basic Flow

The use case begins when a content editor places content on WebNewsOnLine web site.
WebNewsOnLine system checks categorization and/or headline of content just posted.
System checks reference information to determine whether this content category is known by the Collegiate Sports Paging System.
For categories that are known by the Collegiate Sports Paging System, stories are transmitted to the Collegiate Sports Paging System along with category information.
Content is placed into the Collegiate Sports Paging System storage for possible paging.

Alternate Flows

Content is not categorized

If the content is not categorized, the story is placed in the editor’s “to-do” workflow.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Editor must be logged in.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Send Content 2.0

Collegiate Sports Paging System

Use Case Specification: Send Content

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration	Context Integration

[Send Content](#Send Content)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Send Content

Brief Description

This use case occurs when content is posted to the existing WebNewsOnLine web site. Some stories will be tagged for transmission to the Collegiate Sports Paging System, and will be sent for possible paging and display.

Flow of Events

Basic Flow

Content editor places content on WebNewsOnLine web site (existing system, mechanisms for posting defined by existing system). This currently includes indicating major content category (professional sports, high school sports, collegiate sports, or other).
WebNewsOnLine system checks reference information to determine whether this content category is known by the Collegiate Sports Paging System.
For categories that are known by the Collegiate Sports Paging System, stories are transmitted to the Collegiate Sports Paging System along with category information.
Content is placed into the Collegiate Sports Paging System storage for possible paging.

Alternate Flows

Content is not categorized

If the content is not categorized, the story is placed in the editor’s “to-do” workflow queue. If more than one editor is defined, a round-robin approach is used to attempt to balance load. Editors may be marked as unavailable (if, for instance, they are on vacation or sick or out of the office), in which case they will not be included in the round-robin process.

Special Requirements

None.

Preconditions

Editor must be logged in.

Postconditions

When this use case is complete, the “Send Page” use case is invoked.

Extension Points

None.

CSPS Use Case : Send Page 1.0

Collegiate Sports Paging System

Use Case Specification: Send Page

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

[Send Page](#Send Page)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Send Page

Brief Description

This use case occurs when new content is posted to the Collegiate Sports Paging System.

Flow of Events

Basic Flow

System checks categories for the new content
System checks subscriber lists to determine whether any subscribers wish to be paged for this category of content
System generates a text message based on the headline
System constructs a series of email messages
System sends email messages to subscribers (who will receive these as an alphanumeric page)

Alternate Flows

None.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Content is posted, headline is available, categorization is available.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

CSPS Use Case : Send Page 2.0

**Collegiate Sports Paging System

Use Case Specification: Send Page**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration	Context Integration

[Send Page](#Send Page)
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Send Page

Brief Description

This use case occurs when new content is posted to the Collegiate Sports Paging System.

Flow of Events

Basic Flow

The flow is initiated when an editor posts content to the system or when new content is received from the existing WebNewsOnLine system.
System checks categories for the new content.
System checks [subscriber profiles](ex_gloss2.md#Page-me-when profile) to determine whether any subscribers wish to be paged for this category of content
System generates a text message based on the headline
System constructs a series of email messages
System sends email messages to subscribers (who will receive these as an alphanumeric page)

Alternate Flows

If no headline exists, a system default message is inserted into the email message. The default message is maintained on the system by WebNewsOnLine staff, and there is only one message on the system at any time.

Special Requirements

None

Preconditions

Content is posted, headline is available, categorization is available.

Postconditions

None.

Extension Points

None.

**Collegiate Sports Paging System

Use Case Specification: Subscribe**

Version 1.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration

Subscribe
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Brief Description

This use case enables a potential subscriber to subscribe to the Collegiate Sports Paging System service.

Flow of Events

Basic Flow

Potential Subscriber selects “Subscribe” option.
System looks up current contract terms and available service options
System displays contract terms and service options
Potential subscriber acknowledges terms and selects service options
System records currently selected service options
System displays categories of profile (personal, preferences, pager information, “page me when” selections).
User selects category
System displays detail of category
User updates detail, presses “OK”
System validates data as required, updates subscriber profile.

Alternative Flows

User rejects contract terms

If the potential subscriber does not acknowledge the contract terms, the use case terminates.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

None.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

**Collegiate Sports Paging System

Use Case Specification: Subscribe**

Version 2.0

Revision History


Date	Version	Description	Author
October 9, 1999	1.0	Initial version	Context Integration
December 1, 1999	2.0	Update after Elaboration	Context Integration

Subscribe
[Flow of Events](#Flow of Events)
[Special Requirements](#Special Requirements)
Preconditions
Postconditions
[Extension Points](#Extension Points)

Brief Description

This use case enables a potential subscriber to subscribe to the Collegiate Sports Paging System service.

Flow of Events

Basic Flow

Potential Subscriber selects “Subscribe” option.
System looks up current contract terms and available service options
System displays contract terms and service options
Potential subscriber acknowledges terms and selects service options
System records currently selected service options
System displays categories of profile (personal, preferences, pager information, “page me when” selections).
User selects category
System displays detail of category
User updates detail, presses “OK”
System validates data as required, updates subscriber profile.

Alternative Flows

User rejects contract terms

If the potential subscriber does not acknowledge the contract terms, the use case terminates.

Special Requirements

None.

Preconditions

None.

Postconditions

New subscriber is recorded in the system and may receive pages immediately.

Extension Points

None.

**Collegiate Sports Paging System

Use Case Model Survey

Version 1.0**

Revision History


Date	Version	Description	Author
October 13, 1999	1.0	Initial version	Context Integration

Table of Contents

Introduction
[Actor Catalog](#Actor Catalog)
[Approve Story](#Approve Story)
[Edit Profile](#Edit Profile)
[Pay Fee With Credit Card](#Pay Fee With Credit Card)
[Print Advertiser Reports](#Print Advertiser Reports)
[Provide Feedback](#Provide Feedback)
[Post Advertising Content](#Post Advertising Content)
[Read Content on Web Site](#Read Content on Web Site)
[Send Content](#Send Content)
[Send Page](#Send Page)
Subscribe

Use Case Model Survey

Introduction

Purpose

This report describes the use-case model comprehensively, in terms of how the model is structured into packages and what use cases and actors there are in the model.

Scope

This Use Case Model Survey applies to the Collegiate Sports Paging System, which will be developed by Context Integration. This system will allow subscribers to be notified of events relating to collegiate sports events or teams to which they subscribe, and will enable them to view the content they have subscribed to.

Definitions, Acronyms and Abbreviations

See Glossary.

References

None.

Actor Catalog


Name	Description
Subscriber	A Subscriber is an individual who pays WebNewsOnLine to deliver customized content and alphanumeric pages when events of interest occur. Subscribers specify, though a profile, which categories of content they are interested in.
Advertiser	The Advertiser is an entity who pays WebNewsOnLine for displaying advertising content to subscribers and potential subscribers. Advertisers also post advertising content to the Web site.
Editor	The Editor is a WebNewOnLine employee who categorizes, modifies, approves, or rejects content and advertising content.
Paging Service	The Paging Service is a system which transmits alphanumeric pages to paging devices.
Pager Gateway	The Pager Gateway is a system which gathers pages to be sent to subscribers, formats them, and transmits them to the paging service.
Current WebNewsOnLine System	This system currently provides online, non-customized news and sports content.
Potential Subscriber	A Potential Subscriber is an individual who does not currently subscribe to the Collegiate Sports Paging System, but who may elect to do so.

Approve Story

Brief Description

Flow of Events

Basic Flow

The system places a story in the editor’s “to-do” workflow.
The editor views the story.
The editor categorizes the story and marks it approved.
The system includes the story and triggers initiation of paging messages.

Alternate Flows

Reject Content
The editor views the story.
The editor marks the story as rejected
The system notifies the originator of the content that the story has been rejected
Modify Content
Editor selects “Modify Story”
System displays titles of all stories available
Editor selects specific title
System displays characteristics of story
Editor updates characteristics
Editor selects “Save”
System re-posts story, triggering paging activity as needed
Approve Advertising Content
The editor views the advertising content
The editor marks it approved.
The system includes the advertising content for display
The system marks the preliminary billing record as approved
Reject Advertising Content
The editor views the advertising content
The editor marks it rejected and provides a reason for rejection
The system notifies the advertiser (via email) of the rejection and the reason
Story not viewable

If the story has been deleted by another editor and is not currently viewable, the use case terminates.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Editor must be logged in.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Edit Profile

Brief Description

This use case occurs when a subscriber wishes to change their profile information or when a new subscriber wishes to enroll.

Flow of Events

Basic Flow

User selects “Edit Profile”
System displays categories of profile (personal, preferences, pager information, “page me when” selections.
User selects category
System displays detail
User updates detail, presses “OK”
System validates data as required, updates subscriber profile.

Alternate Flows

If this is a new subscriber, the use case “Pay Fee with Credit Card” is invoked following step 5 above.

Special Requirements

Special requirements will be determined during the next iteration.

This needs to be secured as credit card information may be in the profile.

Preconditions

Preconditions will be determined during the next iteration.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Pay Fee With Credit Card

Brief Description

Flow of Events

Basic Flow

Subscriber selects “pay fee with credit card”
System prompts subscriber for credit card number, expiration date, and (optionally) PIN
System sends credit card info to external system for charge validation and application
Upon receipt of validation, system updates subscriber record to indicate new expiration date

Alternate Flows

Subscriber renews subscription

When this occurs, the flow runs as follows:

Subscriber selects “pay fee with credit card”
System displays current credit card information
User either accepts information as is or updates appropriately
System sends credit card info to external system for charge validation and application
Upon receipt of validation, system updates subscriber record to indicate new expiration date

Invalid credit card information

Special Requirements

Special requirements will be determined during the next iteration.

Issue - interface specifications for external credit card system need to be verified.

Preconditions

Preconditions will be determined during the next iteration.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Print Advertiser Reports

Brief Description

This use case occurs when an advertiser accesses the Collegiate Sports Paging System to obtain reports of how their advertising content has been viewed.

Flow of Events

Basic Flow

Advertiser selects “Print Reports”
System displays all advertising content provided by advertiser
Advertiser selects one or more pieces of content on which to report
System displays a list of reports for this advertiser
Advertiser selects one or more reports to generate
Advertiser selects format (Microsoft® Word®, Microsoft® Excel®, or to browser window)
System creates first report and prompts user to save or view
Advertiser saves or views report, selects “Next Report”
System creates next report and prompts user to save or view
Flows 8) and 9) are repeated until no more reports remain

Alternate Flows

None

Special Requirements

Special requirements will be determined during the next iteration.

Issues - what do we do with obsolete content? How long will we allow reports to be run on content no longer available on the web site? Do we need to encrypt this transmission?

Preconditions

User is connected and validated as an advertiser.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Provide Feedback

Brief Description

This use case occurs when a system user (advertiser, subscriber, or potential subscriber) wishes to comment on the service or the web site.

Flow of Events

Basic Flow

User selects “Provide Feedback”
System looks up central user support phone numbers.
System displays phone numbers to call and gives the user the option to send email immediately
User selects email option
System looks up email address of customer service and passes it to the browser.
System launches email browser client
User enters message, presses “Send”
Browser mail client sends mail.

Alternative Flows

None

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Preconditions will be determined during the next iteration.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Post Advertising Content

Brief Description

This use case occurs when an advertiser wants to post advertising content (banner ads) on the web site and specify which subscriber profiles should be used for display.

Flow of Events

Basic Flow

Advertiser selects “Post Content”
System validates account billing information to ensure new content will be accepted
System prompts for content
Advertiser uploads content in GIF format
System displays potential categories for ad display (based on subscriber profile options)
Advertiser selects categories for which this ad should be shown
System displays potential frequencies and prices for the ad
Advertiser selects desired frequency for this ad
System creates preliminary billing record for this ad
System places content in editor’s “to-do” workflow for approval

Alternative Flow

Invalid Account Information

Advertiser selects “Post Content”
System validates account billing information to ensure new content will be accepted
Account information is invalid, advertiser is prompted to contact .

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

User is connected and validated as an advertiser.

Advertiser account exists.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Read Content on Web Site

Brief Description

This use case occurs when an active subscriber or unregistered user connects to the system to view information.

Flow of Events

Basic Flow

System scans “archived” list of content. For any stories older than 2 days, the story is moved back into the general category
System displays banner ads, general content categories, and specific stories for which pages have been sent.
Subscriber views stories
For any paged stories, the stories are marked as viewed and placed into an “archived” category

Alternate Flows

User is not registered subscriber

System displays banner ads and general content categories
System provides the option for the user to subscribe
User views stories

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

None.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Send Content

Brief Description

This use case occurs when content is posted to the existing WebNewsOnLine web site. Some stories will be tagged for transmission to the Collegiate Sports Paging System, and will be sent for possible paging and display.

Flow of Events

Basic Flow

Content editor places content on WebNewsOnLine web site
For collegiate sports content, system checks categorization and/or headline
For categories that are known by the Collegiate Sports Paging System, stories are transmitted along with category information
Story is placed into the Collegiate Sports Paging System for possible paging

Alternate Flows

Content is not categorized

If the content is not categorized, the story is placed in the editor’s “to-do” workflow.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Editor must be logged in.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Send Page

Brief Description

This use case occurs when new content is posted to the Collegiate Sports Paging System.

Flow of Events

Basic Flow

System checks categories for the new content
System checks subscriber lists to determine whether any subscribers wish to be paged for this category of content
System generates a text message based on the headline
System constructs a series of email messages
System sends email messages to subscribers (who will receive these as an alphanumeric page)

Alternate Flows

None.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

Content is posted, headline is available, categorization is available.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

Brief Description

This use case occurs when a potential subscriber wants to subscribe to the service.

Flow of Events

Basic Flow

System looks up current contract terms and available service options
System displays contract terms and service options
Potential subscriber acknowledges terms and selects service options
System records currently selected service options
System invokes “Edit Profile” use case

Alternative FLows

User rejects contract terms

If the potential subscriber does not acknowledge the contract terms, the use case terminates.

Special Requirements

Special requirements will be determined during the next iteration.

Preconditions

None.

Postconditions

Postconditions will be determined during the next iteration.

Extension Points

Extension points of the use case will be identified during the Elaboration Phase.

**Collegiate Sports Paging System

Vision

Version 1.0**

Revision History


Date	Version	Description	Author
October 6, 1999	1.0	Initial version	Context Integration

Table of Contents

Introduction
Positioning
[Stakeholder and User Descriptions](#Stakeholder and User Descriptions)
[Product Overview](#Product Overview)
[Product Features](#Product Features)
Constraints
[Quality ranges](#Quality Ranges)
[Precedence and Priority](#Precedence and Priority)
[Other Product Requirements](#Other Product Requirements)
[Documentation Requirements](#Documentation Requirements)

Introduction

The purpose of this document is to collect, analyze and define high-level needs and features of the Collegiate Sports Paging System. It focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist. The details of how the Collegiate Sports Paging System fulfils these needs are detailed in the use-case and supplementary specifications.

Purpose

The purpose of this document is to define the high-level requirements of the in terms of the needs of the end users.

Scope

This Vision Document applies to the Collegiate Sports Paging System, which will be developed by Context Integration. This system will allow subscribers to be notified of events relating to collegiate sports events or teams to which they subscribe, and will enable them to view the content they have subscribed to.

Definitions, Acronyms and Abbreviations

See Glossary document.

References

None.

Positioning

Business Opportunity

WebNewsOnLine currently provides news via the World Wide Web as well as in print. It currently holds a very strong position in the Collegiate Sports category, and is looking for ways to expand its revenue base. In the words of Maria Scirpo, CEO:

We will leverage WebNewsOnLine’s strength in local and collegiate sports coverage by offering a subscription paging service. Subscribers, for a fee of $15/year, can pick college divisions, teams or even individual athletes that they wish to track. For instance, a subscriber could track the NCAA Pac Ten basketball teams (e.g., Cal, Stanford, UCLA, etc). Every time a story was produced about this division, the subscriber would receive an alpha-numeric page.

After receiving the page, the subscriber can, at their leisure, access the web site. There, on a customized home page, besides the standard stories and links, would be url’s corresponding to each alpha-numeric page received by the subscriber. Behind these url’s will be stories, audio and video relating to the page.

This service will be promoted at college campuses and via various alumni association magazines.

Benefits envisioned from this approach include:

It will play to WebNewsOnLine’s strengths in covering collegiate sports (i.e., already has most of this content available)
A subscription of $15/year means that only 200,000 subscribers will be needed to net $3m/year in revenues. This breakeven point was thought to be very achievable.
An entirely new source of advertisers will be willing to pay for ad space associated with this service. For instance, it is thought that local car dealerships, restaurants, boutiques, etc., will be willing to pay to have the eyes of this very affluent and targeted set of users. For instance, several Napa vineyards have already expressed interest in buying space for subscribers to the Pac Ten.

Problem Statement


The problem of	Keeping current on collegiate sports events
affects	Mobile business people
The impact of which is	That they are unable to follow their alma mater (or other collegiate sports in which they are interested) without spending significant time searching for news in their specific interest area.
A successful solution would	Notify them when news in their interest area occurs, and provide them a place to get the news they have requested.

Product Position Statement


For	Mobile business people
Who	Want to follow specific collegiate sports events or groups
The Collegiate Sports Paging System	is a software product
That	Notifies subscribers when news related to their interest area occurs and is available
Unlike	The current state of the art which requires that they check online news on a regular basis to find news in their interest area.
Our product	Notifies subscribers when news in their interest area occurs, allowing them to check news only when there is content to be read.

Stakeholder and User Descriptions

Market Demographics

The target market for this system is comprised of a mobile, interested, intellectual, upscale segment of society-but mobile is the key word, whether it means people who have moved from Cincinnati to Atlanta, or people who are mobile in terms of their lifestyles or their occupations.

Stakeholder Summary


Name	Represents	Role
Subscriber	End consumers of the content provided by WebNewsOnLine.	Create profiles, receive pages, read custom content, and subscribe using credit cards.
Advertiser	Firms who pay to advertise to target customers on the web site.	Select target customer groups, provide advertising content, receive reports of advertising viewing.
Editor	WebNewsOnLine’s content provision channel.	Place content on web site, categorize content.

User Summary


Name	Description	Stakeholder
Subscriber	Selects categories for pager notification, reads content on web site, reads targeted advertising on web site.	Self-represented.
Advertiser	Obtains advertising delivery information from the system to follow-up or track hits.	Self-represented.
Editor	Places content onto the web site, identifies categories in which the content belongs.	Self-represented

User environment

Individuals will receive pages via alphanumeric pagers or cellular phones when an event occurs in there area of interest. At their leisure, they will connect to the web site and view their content. Usage patterns are not predictable at this point, though higher volumes are anticipated during collegiate sports playoffs such as March Madness.

Users will be expected to have a device capable of receiving an alphanumeric page or message, and are expected to have a browser-enabled device for viewing content. If they have devices capable of viewing video or audio clips, this content will also be available to the user.

Advertisers will be expected to have a browser-enabled device for checking advertising usage.

Editors will require a browser-enabled device for categorizing content and/or viewing system status.

Stakeholder Profiles

Subscriber


Description	Individual who pays to receive pages and custom content related to specific collegiate sports categories.
Type	Primary user
Responsibilities	Primary consumer of the services and content offered by .
Success Criteria	Ability to define a profile of news, and be notified of breaking news in specified interest areas.
Involvement	Provides reviews of beta versions of software, provides ongoing feedback after release.
Deliverables
Comments / Issues	None.

Advertiser


Description	Individual who provides targeted content for viewing by specified market segment, and who checks viewing patterns of the advertising content.
Type	Expert user.
Responsibilities	Review requirements and User Interface designs.
Success Criteria	Ability to specify target market segment to view specific content, and to verify that the content has been viewed.
Involvement	Requirements Reviewer.
Deliverables	Usage/viewing reports.
Comments / Issues	None.

Editor


Description	Individual who provides content to the web site and categorized it.
Type	Expert user.
Responsibilities	Needs to be able to quickly and easily post and categorize content, and to verify content and categories on the web site.
Success Criteria	Ability to post content within 5 minutes of content availability.
Involvement	Requirements Reviewer.
Deliverables	None.
Comments / Issues	Performance during peak usage periods may be an issue.

User Profiles

See previous section

Key Stakeholder / User Needs


Need	Priority	Concerns	Current Solution	Proposed Solutions
Specify profile	High	Level of granularity	None (read all news to find items of interest)	Allow multiple levels of selection for paging
Receive pages when news occurs	High	Volume levels and response time	None	Use tiered architecture to allow scalability
Read news targeted to areas in profile	Medium	None	None (read all news)	Provide links on web page to specific targeted news items
Target advertisements	High	Ability to segment market population	Select advertising channels to indirectly target market segments	Map advertising content delivery to profile attributes
Verify advertising delivery to gauge effectiveness	Medium	None	None	Provide reports to advertisers on number of views of advertising content

Alternatives and Competition

At this time, there is no direct competitor for this service. ESPNET Sportzone provides targeted news but does not page subscribers when particular news breaks.

Product Overview

Product Perspective

This product will leverage WebNewsOnLine’s existing lead in collegiate sports news, but will present a user interface via a separate system. Graphically, the system may be viewed as follows:

Summary of Capabilities

Table 1 - Collegiate Sports Paging System Features


Customer Benefit	Supporting Features
Subscriber can specify which news they which to receive	Profile capability within system
Subscriber can read only that news in which they have interest	Customized dynamic web pages for each subscriber, with links to stories on which they have been paged
Advertisers can target content	Advertising delivery based on subscriber profiles
No new content required	Link to existing web-based sports content

Assumptions and Dependencies

Existing content is assumed to be available for viewing on the web site. Integration of current content with the new web site is required in order for collegiate sports information to be made available in a timely manner.

Cost and Pricing

Subscription rates are initially target at $15 per subscriber per year. With only 200,000 subscribers this will generate $3M in revenues per year, which is more than enough to cover incremental cost of the system. Advertisers will pay additional fees (initially targeted at 5% higher than normal) for access to defined target populations.

Licensing and Installation

N/A. All custom software is server-based and owned by WebNewsOnLine.

Product Features

These will be provided during the Elaboration phase of the project.

Constraints

The system must be available by March 2000.

The system must not cost more than $2M per year to operate.

The system must utilize existing sports content on WebNewsOnLine’s web site.

Quality Ranges

None specified.

Precedence and Priority

The system must be available by March 2000.
The system must utilize existing sports content on WebNewsOnLine’s web site.
The system must not cost more than $2M per year to operate.

Other Product Requirements

Applicable Standards

The system must comply with existing web standards (HTML, Java, TCP/IP, etc.).

System Requirements

None specified.

Performance Requirements

The system must send a page to a subscriber within 5 minutes of new content being posted to the site.

The system must be able to handle 200,000 subscribers.

Environmental Requirements

None specified.

Documentation Requirements

User Manual

None required - the system must be sufficiently easy to use that a user manual is not required.

Online help

Context-specific and general help will be available for all functions within the system.

Installation Guides, Configuration, Read Me File

An installation manual will be provided. In addition, a formal Knowledge Transfer plan will be developed to ensure that staff are capable of maintaining the system moving forward.

Labeling and Packaging

Not applicable.

Examples: CSPS Use Case Specifications - Elaboration Phase

The following are the use case specifications for the Collegiate Sports Paging Systems (CSPS) as baselined at the end of the Elaboration phase.

Approve Story
Edit Profile
Pay Fee with Credit Card
Print Advertiser Reports
Post Advertising Content
Provide Feedback
Read Content on Web site
Send Content
Send Page
Subscribe

Examples: CSPS Use Case Specifications - Inception Phase

The following are the use case specifications for the Collegiate Sports Paging Systems (CSPS) as baselined at the end of the Inception phase.

Approve Story
Edit Profile
Pay Fee with Credit Card
Print Advertiser Reports
Post Advertising Content
Provide Feedback
Read Content on Web site
Send Content
Send Page
Subscribe

Revision History

Date	Version	Description	Author
08/Jan/1999	1.0	Initial Release	Simon Jones
10/Feb/1999	2.0	Extending plan	Simon Jones

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Software Configuration Management](#2. Software Configuration Management)

[2.1 Organization, Responsibilities, and Interfaces](#2.1 Organization, Responsibilities and Interfaces)

[2.2 Tools, Environment, and Infrastructure](#2.2 Tools, Environment and Infrastructure)

[3. The Configuration Management Program](#3. The CM Program)

[3.1 Configuration Identification](#3.1 Configuration Identification)

[3.1.1 Identification Methods](#3.1.1 Identification Methods)

[3.1.2 Project Baselines](#3.1.2 Project Baselines)

[3.2 Configuration and Change Control](#3.2 Configuration and Change Control)

[3.2.1 Change Request Processing and Approval](#3.2.1 Change Request Processing and Approval)

[3.2.2 Change Control Board (CCB)](#3.2.2 Change Control Board (CCB))

[3.3 Configuration Status Accounting](#3.3 Configuration Status Accounting)

[3.3.1 Project Media Storage and Release Process](#3.3.1 Project Media Storage and Release Process)

[3.3.2 Reports and Audits](#3.3.2 Reports and Audits)

[4. Milestones](#4. Milestones)

[5. Training and Resources](#5. Training and Resources)

[6. Subcontractor and Vendor Software Control](#6. Subcontractor and Vendor Software Control)

[Appendix A - ClearCase Administration Procedures](#6. Subcontractor and Vendor Software Control)

Configuration Management Procedures

1. Introduction

1.1 Purpose

The purpose of this document is to define the Configuration Management procedures to be followed by all software projects at Wylie College.

1.2 Scope

The document covers Configuration Management procedures applicable to all Wylie College projects. Each project will also have its own Configuration Management Plan that describes additional procedures, defines project milestones, etc.

1.3 Definitions, Acronyms, and Abbreviations

Wylie College uses the Rational Unified Process Glossary, and definitions from the section “UCM Concepts” in [UCM].

1.4 References

[UCM] Using Unified Change Management with Rational Suite. Rational Software Corporation.

[CC-1] Managing Software Projects with ClearCase. Rational Software Corporation.

1.5 Overview

Wylie College follows Configuration Management activities as described in the Rational Unified Process. Wylie College has also standardized on Rational’s tools for Unified Change Management (UCM).

UCM implementation will be as described in ClearCase UCM reference materials, except as noted in this document.

2. Software Configuration Management

2.1 Organization, Responsibilities, and Interfaces

Wylie College IT department staff perform the Configuration Manager role for all projects. Each project at Wylie College will have one or more persons assigned to the Change Control Manager role.

2.2 Tools, Environment, and Infrastructure

Wylie College has standardized on the Rational Suite tools (Rational ClearQuest and Rational ClearCase LT) and UCM. Wylie College has an existing set of PVOBs, one for each Product Family. A Product Family is a group of inter-related projects which share a significant amount of common code. Current Product Families, and their PVOBs at Wiley College are:

Business Applications - includes most of the ongoing projects by Wiley College
Scientific Computing - used to store research and educational projects run by the teaching staff.

VOBs are backed up on a daily basis by the Configuration Manager. The backup and restore tools and procedures, as well as other administration details, are covered in the [Appendix: ClearCase Administration Procedures.](#Appendix A ClearCase Administration Procedures)

At the start of a project, the project’s Configuration Manager creates a UCM Project within the appropriate Product Family’s PVOB, and one or more component VOBs. See [UCM] for details. All component VOBs are expected to follow the standard product directory structure. See the Course Registration CRegMain VOB for an example.

All projects are expected to use the following ClearCase policies (see [CC-1] “Considering Which Development Policies to Enforce”):

recommended baselines
re-base before deliver
dynamic views for integration views, and snapshot views for developer views
no deliveries from streams with pending checkouts
default script for Do ClearQuest Action after Delivery - that is, the activity is transitioned to a “Complete” type state.

The following are activities and tool mentors from Workflow Detail: Create Project CM Environments, that provide guidance on setting up your CM environment:

Role	Rational Unified Process Activities	Rational Tool Mentors	Notes/Tailoring
Configuration Manager	Set Up CM Environment	Linking Configuration Management and Change Request Management Using Rational ClearQuest and Rational ClearCase Setting Up Policies Establishing a Change Request Process Defining Change and Review Notifications	Most of this activity has been performed already, in defining this CM Plan and in defining the PVOBs for each Product Family.
Software Architect	Structure the Implementation Model	Setting Up the Implementation Model Setting Up the Implementation Model with UCM	This must be done within the framework of the standard product directory structure. The Software Architect provides the input for this Implementation Model, but the actual setup is typically done by the Configuration Manager.
Integrator	Create Integration Workspaces	Creating an Integration and Building Workspace
Any Role	Activity: Create Development Workspace	Creating a Development Workspace

3. The Configuration Management Program

3.1 Configuration Identification

3.1.1 Identification Methods

UCM Projects are named with the official abbreviated name for the project. For example, CReg for Course Registration System.

VOB naming is up to the project’s discretion.

Each artifact identified as having a review level of “Formal/Internal” or “Formal/External” in the project’s Development Case must be controlled in a project VOB by the end of the phase in which it is first created. Once controlled, the procedures described in this document are applicable.

Project baselines will be named <project_name>_<iteration>_<date> where date is fomatted as MM_DD_YY. For example, CReg_C1_03_07_99.

Baseline statuses will be as defined for default UCM.

3.1.2 Project Baselines

Baselines must be established at the end of each iteration. Additional baselines may be established at the discretion of the project manager.

3.2 Configuration and Change Control

3.2.1 Change Request Processing and Approval

Wylie College follows the Rational Unified Process workflow details: Manage Change Requests and Change & Deliver Configuration Items, with the following refinements.

Artifact: Work Order is merged with Artifact: Change Request (CR). Status of work orders is thus managed by tracking the status of CRs.

A UCM activity maps to Artifact: Change Request (CR). The term CR will be applied for the remainder of this document to refer to a UCM Activity. Wylie College follows the default UCM ClearQuest schema.

The activities and states used by Wylie College to manage CRs are as described in Concepts: Change Request Management.

The required fields for a CR are imposed by the ClearQuest schema, and so do not need to be documented here.

The following defines the applicable activities and tool mentors.

Role	Rational Unified Process Activities	Rational Tool Mentors	Notes/Tailoring
Any Role	Activity: Submit Change Request Activity: Update Change Request	Submitting Change Requests
Change Control Manager	Activity: Review Change Request Activity: Confirm Duplicate or Rejected CR	Reporting Review and Work Status	Wylie College does not require the use of a Configuration Control Board. Change Requests are reviewed and approved by one member of the project, the Change Control Manager, who is usually also the Project Manager, Team Lead, or Software Architect.
Project Manager	Activity: Schedule and Assign Work		Artifact: Work Order is merged with Artifact: Change Request (CR). Assignment of work is performed by assigning the CR. See Concepts: Change Request Management for details.
Any Role	Activity: Make Changes	Using UCM Change Sets
Any Role	Activity: Deliver Changes	Delivering Your Work	“Any Role” (who made the changes) must ensure that the applicable review procedures have been followed, and the review has passed, prior to delivering any changes. The applicable review procedures are specified in the Development Case.
Integrator	Activity: Verify Changes in Build

3.2.2 Change Control Board (CCB)

As noted above, Wylie College does not use Change Control Boards (also referred to as Configuration Control Boards).

3.3 Configuration Status Accounting

3.3.1 Project Media Storage and Release Process

Wylie College follows the Workflow Detail: Manage Baselines & Releases as described below.

Role	Rational Unified Process Activities	Rational Tool Mentors	Notes/Tailoring
Integrator	Activity: Create Baselines	Creating Baselines
Integrator	Activity: Promote Baselines	Promoting Project Baselines
Any Role	Update Workspace	Updating Your Project Work Area Using Rational ClearCase
Configuration Manager	Create Deployment Unit		Product releases are burned onto two sets of CDs - one set for offsite storage, and the other for the IT library. This is the responsibility of each project’s Configuration Manager. Each product release CD must include a snapshot of the development, test, and integration environment at the time of the release, including executables, source code, test software, COTS libraries, plug-ins, support tools, test tools, etc.

3.3.2 Reports and Audits

Details of the required reports are described by the Wylie College Measurement Plan. An overview of activities and tool mentors from Workflow Detail: Monitor & Report Configuration Status is provided below.

Role	Rational Unified Process Activities	Rational Tool Mentors	Notes
Configuration Manager	Activity: Report on Configuration Status	Reporting Defect Trends and Status Viewing the History of a Defect

4. Milestones

Milestones are described in each individual project’s Configuration Management Plan.

5. Training and Resources

The following Rational University Courses are recommended by role.

Course	Roles
Developing Software with Rational ClearCase and UCM for Windows	Any Role
Administering ClearCase	Configuration Manager (ClearCase Administrator)

6. Subcontractor and Vendor Software Control

Wylie College does not currently subcontract software development. However, we do incorporate Commercial Off The Shelf (COTS) products into our systems which must be carefully controlled. Each product release must include in the release notes the versions of all COTS products on which the system has been tested. When possible, installation CDs for these COTS products should be filed with the IT librarian.

Appendix A ClearCase Administration Procedures

TBD. Issues to be covered include:

Revision History

Date	Version	Description	Author
08/Jan/1999	1.0	Initial Release	Simon Jones
10/Feb/1999	2.0	Extending plan	Simon Jones

Table of Contents

1.3 Definitions, Acronyms, and Abbreviations

2. Requirements Management

2.1 Organization, Responsibilities, and Interfaces

2.2 Tools, Environment, and Infrastructure

3. The Requirements Management Program

3.1 Requirements Identification

3.2 Traceability

3.2.1 Criteria for Product Requirements

3.2.2 Criteria for Use Case Requirements

3.2.3 Criteria for Test Cases

3.3 Attributes

3.3.1 Attributes for Use Case Requirements

3.3.2 Attributes for Test Cases

3.4 Reports and Measures

3.5 Requirements Change Management

3.6 Disciplines and Activities

4. Milestones

5. Training and Resources

Requirements Management Plan

1. Introduction

1.1 Purpose

The Requirements Attributes Guidelines identifies and describes the attributes that will be used for managing the requirements for all software projects at Wylie College. In addition, this document outlines the requirements traceability that will be maintained on projects during development.

The attributes assigned to each requirement will be used to manage the software development and to prioritize the features for each release.

The objective of requirements traceability is to reduce the number of defects found late in the development cycle. Ensuring all product requirements are captured in the software requirements, design, and test cases improves the quality of the product.

1.2 Scope

The attribute and traceability guidelines in this document apply to the product requirements, software requirements, and test requirements for all Wylie College software projects.

1.3 Definitions, Acronyms, and Abbreviations

1.4 References

The following references may be found on or from the Wylie College Software Process website.

Wylie College Configuration Management Plan.

Rational Unified Process.

Wylie College Development Case

2. Requirements Management

2.1 Organization, Responsibilities, and Interfaces

Covered by the individual project’s Software Development Plan.

2.2 Tools, Environment, and Infrastructure

Rational RequisitePro will be used to manage requirements attributes and traceability. Other infrastructure details are covered on the Wylie College Software Process Website.

3. The Requirements Management Program

3.1 Requirements Identification

Each project will identify and manage the following requirement types:

Artifact (Document Type)	Requirement Type	Description
Vision	Product requirements	Product features, constraints, quality ranges, and other product requirements.
Use-Case Model	Use Case	Use cases, documented in Rational Rose
Test Plan	Test Cases	Cases describing how we will verify that the system behaves as expected.

3.2 Traceability

3.2.1 Criteria for Product Requirements

The product requirements defined in the Vision Document will be traced to the corresponding use case or supplementary requirements in the Use Case Specifications, and the Supplementary Specification.

Each product requirement traces to 1 or more use case requirements and supplementary requirements.

3.2.2 Criteria for Use Case Requirements

The use case requirements defined in the Use Case Specifications and the Supplementary Specification will be traced to the corresponding test cases specified in the Test Plan.

Each use case requirement traces to 1 or more system test cases.

3.2.3 Criteria for Test Cases

The test cases specified in the Test Plan are traced back to the product requirements (from the Vision) and use case requirements which are being verified by the particular test case.

A test case may trace back to 1 or more product and use case requirements. In the case where the test case is verifying a derived requirement or the design, the test case may have no traceability back to the original product requirements or use case requirements.

3.3 Attributes

3.3.1 Attributes forUse Case Requirements

The use case requirements and the Supplementary Specification will be managed using the attributes defined in this section. These attributes are useful for managing the development effort, determining iteration content, and for associating use cases with their specific Rose models.

Status

Set after the analysis has drafted the use cases. Tracks progress of the development of the use case from initial drafting of the use case through to final validation of the use case.


Proposed	Use Cases which have been identified though not yet reviewed and approved.
Approved	Use Cases approved for further design and implementation.
Validated	Use Cases which have been validated in a system test.

Priority

Set by the Project Manager. Determines the priority of the use case in terms of the importance of assigning development resources to the use case and monitoring the progress of the use case development. Priority is typically based upon the perceived benefit to the user, the planned release, the planned iteration, complexity of the use case (risk), and effort to implement the use case.


High	Use Case is a high priority relative to ensuring the implementation of the use case is monitored closely and that resources are assigned appropriately to the task.
Medium	Use Case is medium priority relative to other use cases.
Low	Use Case is low priority. Implementation of this use case is less critical and may be relayed or rescheduled to subsequent iterations or releases.

Effort Estimate

Set by the development team. Because some use cases require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority. The Project Manager uses these effort estimates to determine the project schedule and to effectively plan the resourcing of the tasks.

Estimate effort in Person Days (assume 7.5 hours in a workday).

Technical Risk

Set by development team based on the probability the use case will experience undesirable events, such as effort overruns, design flaws, high number of defects, poor quality, poor performance, etc. Undesirable events such as these are often the result of poorly understood or defined requirements, insufficient knowledge, lack of resources, technical complexity, new technology, new tools, or new equipment.

Wylie College projects will categorize the technical risks of each use case as high, medium, or low.


High	The impact of the risk combined with the probability of the risk occurring is high.
Medium	The impact of the risk is less severe and/or the probability of the risk occurring is less.
Low	The impact of the risk is minimal and the probability of the risk occurring is low.

Target Development Iteration

Records the development iteration in which the use case will be implemented. It is anticipated that the development for each release will be performed over several development iterations during the Construction Phase of the project.

The iteration number assigned to each use case is used by the Project Manager to plan the activities of the project team.

The possible values will be of the form <letter>-<iteration number> where the letter is I, E, C, T for inception, elaboration, construction and transition respectively. For example:


E-1	Scheduled for Elaboration Phase, Iteration 1
C-1	Scheduled for Construction Phase, Iteration 1
C-2	Scheduled for Construction Phase, Iteration 2
C-3	Scheduled for Construction Phase, Iteration 3

Assigned To

Use cases are assigned to either individuals or development teams for further analysis, design, and implementation. A simple pull down list will help everyone on the project team better understand responsibilities.

Rational Rose Model

Identifies the Rose use case model associated with the use case requirement.

3.3.2 Attributes for Test Cases

Test Status

Set by the Test Lead. Tracks status of each test case.


Untested	Test Case has not been performed.
Failed	Test has been conducted and failed.
Conditional Pass	Test has been completed with problems. Test assigned status of Pass upon the condition that certain actions are completed.
Pass	Test has completed successfully.

Build Number

Records the system build in which the specific test case will be verified.

Tested By

Individual assigned to perform and verify the test case. This simple pull down list will help everyone on the project team better understand responsibilities.

Date Tested

Planned test date or actual test date.

Test Notes

Any notes associated with planning or executing the test.

3.4 Reports and Measures

TBD

3.5 Requirements Change Management

See the Wylie College Configuration Management Plan.

3.6 Disciplines and Activities

See the Wylie College Development Case.

4. Milestones

This is described in each project’s Software Development Plan.

5. Training and Resources

This is described in each project’s Software Development Plan.

Revision History

Date	Version	Description	Author
08/Jan/1999	1.0	Initial Release	Simon Jones
10/Feb/1999	2.0	Extending plan	Simon Jones

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Software Configuration Management](#2. Software Configuration Management)

[2.1 Organization, Responsibilities, and Interfaces](#2.1 Organization, Responsibilities and Interfaces)

[2.2 Tools, Environment, and Infrastructure](#2.2 Tools, Environment and Infrastructure)

[3. The Configuration Management Program](#3. The CM Program)

[3.1 Configuration Identification](#3.1 Configuration Identification)

[3.1.1 Identification Methods](#3.1.1 Identification Methods)

[3.1.2 Project Baselines](#3.1.2 Project Baselines)

[3.2 Configuration and Change Control](#3.2 Configuration and Change Control)

[3.2.1 Change Request Processing and Approval](#3.2.1 Change Request Processing and Approval)

[3.2.2 Change Control Board (CCB)](#3.2.2 Change Control Board (CCB))

[3.3 Configuration Status Accounting](#3.3 Configuration Status Accounting)

[3.3.1 Project Media Storage and Release Process](#3.3.1 Project Media Storage and Release Process)

[3.3.2 Reports and Audits](#3.3.2 Reports and Audits)

[4. Milestones](#4. Milestones)

[5. Training and Resources](#5. Training and Resources)

[6. Subcontractor and Vendor Software Control](#6. Subcontractor and Vendor Software Control)

Configuration Management Plan

1. Introduction

1.1 Purpose

The purpose of this document is to define the Configuration Management procedures to be followed by the Course Registration System project..

1.2 Scope

The Course Registration System follows the Wylie College Configuration Management Plan, which applies to all Wylie College projects. In addition, this document defines additional procedures, project milestones, etc. that apply specifically to the Course Registration System project, and not necessarily to other projects at Wylie College.

1.3 Definitions, Acronyms, and Abbreviations

Refer to the Glossary [1].

1.4 References

Applicable references are:

Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V1.0, 1998, Wylie College IT.
Wylie College Configuration Management Plan, WyIT420, V1.0, 1999, Wylie College IT.

1.5 Overview

The Course Registration System project follows the Wylie College Configuration Management Plan. This plan contains project specific CM plan information, primarily by reference to other project plans.

2. Software Configuration Management

2.1 Organization, Responsibilities, and Interfaces

See the Software Development Plan.

2.2 Tools, Environment, and Infrastructure

Tools and environment are as specified in the Wylie College Configuration Management Plan.

The project uses the Creg UCM Project, which is part of the Wylie College PVOB.

We currently use a single VOB, named CRegMain for storing Configuration Items.

We follow the Wylie College standard product directory structure.

We expect that there will be at most 2000 project files, requiring roughly 100M of disk space.

Simon Goodman is the Configuration Manager, and is responsible for setting up the CM environments.

3. The Configuration Management Program

3.1 Configuration Identification

3.1.1 Identification Methods

See Wiley College CM Plan.

3.1.2 Project Baselines

Baselines are created at the end of each iteration, as described in the Software Development Plan.

3.2 Configuration and Change Control

3.2.1 Change Request Processing and Approval

See Wiley College CM Plan.

The Configuration Control Manager and Project Manager roles of assigning work and reviewing/approving changes are performed by the lead of each team (see the organization chart in the Software Development Plan), who may delegate this responsibility as he/she deems appropriate.

3.2.2 Change Control Board (CCB)

There is no CCB, per Wiley College CM Plan.

3.3 Configuration Status Accounting

3.3.1 Project Media Storage and Release Process

See Wiley College CM Plan.

3.3.2 Reports and Audits

See Wylie College Measurement Plan.

4. Milestones

See the C-Reg Software Development Plan.

5. Training and Resources

All team members are fully trained.

6. Subcontractor and Vendor Software Control

Example: Small Project Development Case - Introduction


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	A Development Case describes how the process is applied for a specific project or organization. It includes details such as: - which optional activities and artifacts will be used, and which will be dropped, - the relative timing of activities for each phase, - which tools will be used, and - the level of formality to be applied.

This is an example Development Case geared to projects with the following characteristics:

small project (less than 10 people, less than a year in duration)
products deployed either at a customer site or deployed via the web (RUP artifacts and activities related to shrink-wrapped packaged products are not included)
the software development environment (tools, computing infrastructure, test environment, configuration management environment, and so on) is already set up, or described separately
low management complexity (one development team, one customer, and one product)
a relatively informal process is acceptable.

This Development Case is, however, only an example. It can be tailored for use by projects with other characteristics, such as fewer tools, differing levels of formality, and so on.

Note that it follows a simplified version of the standard Development Case template.

Small Project Development Case : Artifacts

Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts

This section of the development case lists the artifacts that are part of the process, along with guidance on the tools used to create them, comments (which may include tailoring), and whether or not the artifact is a formal deliverable. Formal deliverables are provided to the customer and must be approved by the customer. Other artifacts are project-internal. Topics (on this page) - Requirements - [Analysis & Design](#Analysis & Design) - Implementation - Testing - Deployment - [Configuration & Change Management](#Configuration & Change Management) - [Project Management](#Project Management) - Environment

Requirements

Workflow

For details on the workflow, see the Requirements Overview.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Vision	Rational RequisitePro, Microsoft® Word®		Yes
Stakeholder Requests	Rational ClearQuest	Stakeholder requests are logged and managed as Rational ClearQuest Change Requests.	No
Use-Case Model (Actors, Use Cases)	Rational Rose, Rational RequisitePro	Important actors and use cases identified and flows of events will be outlined for only the most critical use cases. Descriptions will be captured as Word documents.	No (however the Use-Case Survey report is deliverable)
Glossary	Rational RequisitePro		Yes
Supplementary Specifications		Captured as part of the Vision document.	Yes
User Interface Prototype			No

Reports

The following reports are generated from the Use-Case Model.


Report	Tools Used	Formal Deliverable?
Use-Case Survey	Rational Soda	Yes

Analysis & Design

Workflow

For details on the workflow, see the Analysis & Design Overview.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Architectural Proof of Concept, Prototypes		Project risks will be addressed as early as possible using executable architectural prototypes.	No
Design Model (and all constituent artifacts)	Rational Rose	The Design Model is expected to evolve over a series of brainstorming sessions. No separate Analysis Model is created. The Design Model will only be maintained as long as the developers find it useful.	No
Data Model	Rational Rose		No
Software Architecture Document	Rational Soda, Microsoft Word	A description of the architecture will be captured that briefly describes the architecturally significant use cases (use-case view), identification of key mechanisms and design elements (logical view), plus definition of the process view and the deployment view.	Yes

Implementation

Workflow

For details see the Implementation Overview. This project is small enough that no separate subsystem integration is performed (elements are directly integrated into the overall system). High level integration planning is described in the project schedule. Detailed integration planning is done informally and as-needed.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Implementation Model (and all constituent artifacts, including Implementation Elements and Builds)	<development tools - compiler, debugger, and so on> Rational Rose, Rational Test Manager, Rational Test Factory, Rational Robot, Rational PurifyPlus .	Rational Rose will be used to generate the initial code. Unit Tests will be scripted using Rational Robot and organized into suites using Rational Test Manager. Scripts generated by Rational Test Factory will supplement hand-generated tests. Rational PurifyPlus will be used to help determine if component testing is adequate.	Yes

Test

Workflow

For details on the process, see the Test Overview.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Test Plan	Microsoft Word		No
Test Script, Test Data	Rational QualityArchitect, Rational Test Factory, Rational Robot, Rational PurifyPlus,<database tool used by the application>	User Interface (UI) component test scripts and test data are created using Rational Robot and Rational Test Factory. Non-UI components test scripts and test data are created using Rational QualityArchitect.	No
Test Suite, Test Log	Rational Test Manager	Rational Test Manager is used to create Test Suites and execute them to produce Test Logs and reports.	No
Test Ideas List	Microsoft Word	These will primarily be harvested from previous projects.	No
Test Case	Rational Test Manager		No
Test Evaluation Summary	Microsoft Word		No
Test Environment Configuration	Microsoft Word	Documented informally.	No.

Deployment

Workflow

For details on the process, see the Deployment Overview.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Product (including Deployment Unit and Installation Artifacts)			Yes
End-User Support Material (including Release Notes)		Are built into the online help.	Yes

Configuration & Change Management

Workflow

For a general description of the process, see the Configuration & Change Management Overview.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Change Request	Rational ClearQuest		No
Project Repository, Workspace	Rational ClearCase LT		No

Project Management

Workflow

For details, see Project Management Overview.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Business Case	Microsoft Word	The business case is produced and approved by company management. It is not expected to be maintained.	No
Software Development Plan (including Risk List, and Iteration Plan)	Microsoft Word, Microsoft® Project®	The schedule and resource information will be generated as reports out of Microsoft Project.	No
Review Record	Microsoft Word	This is mandatory and deliverable only for customer reviews.	Yes
Iteration Assessment, Status Assessment	Microsoft Word, email	Status Assessment is be combined with the Iteration Assessment because the iterations are frequent (one or more each month). The Project Manager will meet with each project team member on a weekly basis to determine progress, and help identify and resolve issues. At the end of each iteration, the team will meet to discuss the project status and brainstorm improvements. The intent is to capture lessons learned. This is followed by a review with the Management Reviewer.	No

Environment

Workflow

The environment for this project is already set up. The process is assessed each iteration, and improvements are implemented accordingly.

Artifacts


Artifact	Tools Used	Comments	Formal Deliverable?
Development Case	[HTML editor]	This project Development Case was created by minor tailoring of the RUP Example Development Case For Small Projects.	No
Use-Case Modeling Guidelines	Microsoft Word	This project follows the RUP Example Use-Case Modeling Guidelines without further tailoring.	No
Programming Guidelines	Microsoft Word	The Programming Guidelines for the project already exist. They are a slightly tailored version of the example provided in RUP.	No
Design Guidelines	Microsoft Word	The Design Guidelines for the project already exist (harvested from a similar, previous project).	No
Test Guidelines	Microsoft Word	The Test Guidelines for the project already exist (harvested from a similar, previous project).	No
User Interface Guidelines	Microsoft Word	The User Interface Guidelines for the project already exist (harvested from a similar, previous project).	No

Small Project Development Case : General Tailoring


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	Topics (on this page) - Reviews - Roles

Reviews

Artifacts identified as “formal deliverable” in this development case will be reviewed and approved by the customer at the appropriate Lifecycle Milestone Reviews scheduled in the Software Development Plan.

In addition, all artifacts are to be reviewed informally by at least one other person on the project, who approves the artifact before it is considered complete for a given milestone. These may be walkthroughs or inspections - as decided by the reviewer. See Guidelines: Reviews for more information.

Any defects found during review which are not corrected prior to releasing for integration must be captured as Change Requests so that they are not forgotten.

Roles

On a small project, each person is responsible for a variety of roles. The person to role mapping will be defined in the Software Development Plan.

Small Project Development Case : Project Lifecycle


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	Click on text for more information about phases and milestones The phases and milestones of a project

From a management perspective, the software lifecycle of the Rational Unified Process (RUP) is decomposed over time into four sequential phases, each concluded by a major milestone; each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed (Activity: Lifecycle Milestone Review) to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

See Phases for a more detailed description of the RUP phases and milestones.

A sample iteration plan is provided for each iteration:

Sample Iteration Plan : Inception
Sample Iteration Plan : Elaboration
Sample Iteration Plan : Construction
Sample Iteration Plan : Transition

Classics CD.com Measurement Plan

This is an example of what a measurement plan may look like. The example is in Microsoft Word format. If your browser has a viewer for Microsoft Word installed, you can click to view the Measurement Plan in Microsoft Word format.

Example: Close Registration Use Case Specification

Course Registration System

Use-Case Specification Close Registration Use Case

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Successful Close Registration

2.2    Alternative Flows

2.2.1    No Professor for the Course Offering

2.2.2    Billing System Unavailable
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

Close Registration Use Case

- Brief Description

This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.

The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.

2. Flow of Events

The use case begins when the Registrar selects the “close registration” activity from the Main Form.

2.1 Basic Flow - Successful Close Registration

The system checks to see if a Registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. .

For each open course offering, the system checks if three students have registered and a professor has signed up to teach the course offering. If so, the system closes the course offering and sends a transaction to the billing system for each student enrolled in the course offering.

Issue: Check with Registrar Office if courses should proceed with 3 students enrolled. Should it be a larger number?

2.2 Alternative Flows

2.2.1No Professor for the Course Offering

If in the basic flow there is no professor signed up to teach the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.

2.2.2Billing System Unavailable

If the system is unable to communicate with the Billing System, the system will attempt to re-send the request after a specified period. The system will continue to attempt to re-send until the Billing System becomes available

Issues:

Need to resolve what to do if too few students registered for a course.

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions > 4.1 Login

The Registrar must be logged onto the system in order for this use case to begin.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: Close Registration Use Case Specification

Course Registration System

Use-Case Specification

Close Registration Use Case

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft	S. Gamble
13/Feb/99	Version 1.0	Minor corrections based on review	S. Gamble
15/Feb/99	Version 2.0	Modify section on use case extends. Final cleanup. Revise alternative flows. Resolve outstanding issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Successful Close Registration

2.2    [Alternate Flows](#Alternate Flows)

2.2.1    Less Than Three Students in the Course Offering

2.2.2    [Cancel Course Offering](#Cancel Course Offering)

2.2.3    No Professor for the Course Offering

2.2.4    Billing System Unavailable
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

Close Registration Use Case

- Brief Description

This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.

The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.

2. Flow of Events

The use case begins when the Registrar selects the “close registration” activity from the Main Form.

2.1 Basic Flow - Successful Close Registration

The system checks to see if a Registration is in progress. If it is, then a message is displayed to the Registrar and the use case terminates. The Close Registration processing cannot be performed if registration is in progress. .

For each open course offering, the system checks if three students have registered and a professor has signed up to teach the course offering. If so, the system closes the course offering and sends a transaction to the billing system for each student enrolled in the course offering.

2.2 Alternate Flows

2.2.1 Less Than Three Students in the Course Offering

If in the basic flow less than three students signed up for the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.

2.2.2Cancel Course Offering

The system cancels the course offering. For each student enrolled in the cancelled course offering, system will modify the student’s schedule. The first available alternate course selection will be substituted for the cancelled course offering. If no alternates are available, then no substitution will be made. Control returns to the Main flow to process the next course offering for the semester.

Once all schedules have been processed for the current semester, the system will notify all students, by mail, of any changes to their schedule (e.g., cancellation or substitution).

2.2.3No Professor for the Course Offering

If in the basic flow there is no professor signed up to teach the course offering, the system will cancel the course offering. The Cancel Course Offering sub-flow is executed at this point.

2.2.4Billing System Unavailable

If the system is unable to communicate with the Billing System, the system will attempt to re-send the request after a specified period. The system will continue to attempt to re-send until the Billing System becomes available

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Login

The Registrar must be logged onto the system in order for this use case to begin.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Glossary

Course Registration System Glossary

Version 1.0

Revision History

Date	Version	Description	Author
26/12/1998	1.0	Draft version	Bill Collings

Table of Contents

Introduction
Definitions

**Glossary

Introduction**

The glossary contains the working definitions for all classes in the Course Registration System. This glossary will be expanded throughout the life of the project.

2. Definitions

Course

A class offered by the university.

Course Offering

A specific offering for a course, including days of the week and times.

Course Catalog

Unabridged catalog of all courses offered by the university.

Grade

The grade for the student in a course.

Report Card

All the grades for all courses taken by a student in a given semester.

Roster

All the students enrolled in a particular course offering.

Transcript

The history of the grades for all courses for a particular student.

Example: Glossary

Course Registration System Glossary

Version 2.0

Revision History

Date	Version	Description	Author
26/Dec/1998	1.0	Draft version	Bill Collings
19/Feb/1999	2.0	Expand glossary. Moved some of the terms to the Wylie College glossary.	Bill Collings

**Glossary

Introduction**

The glossary contains the working definitions for terms and classes in the Course Registration System. This glossary will be expanded throughout the life of the project. Any definitions not included in this document may be included in the Rational Rose Model. Generic terms used outside this project should be captured in the organizational Glossary.

2. Definitions

Alternative course selection

A student might choose to register for one or more alternative courses, in case one or more of the primary selections are not available.

Billing System

Part of the university’s Finance System used for processing billing information.

Prerequisite

The university requires for some courses that a student has passed one or more other courses to be able to register for a particular course. These are known as pre-requisites.

Primary course selection

A student must prioritize the course selections made. System will seek to fulfill the primary selections first.

Remote Access

Any system access achieved by dialing-in remotely or connecting via the internet.

University Artifacts

General term used to collect business entities associated with the University.

Example: Integration Build Plan

Course Registration System

Integration Build Plan for the Architectural Prototype

Version 1.0

Revision History

Date	Version	Description	Author
7/March/1999	1.0	Initial Release - Prototype Build Plan	P. Johnson

Table of Contents

Introduction
Subsystems
Builds

3.1 Integration Build One

3.2 Integration Build Two

**Integration Build Plan

For the

Architectural Prototype**

Introduction
Purpose

This document describes the plan for integrating the first software components of the C-Registration system into an executable and demonstrable prototype.
Scope

The Integration Build applies to the C-Registration prototype and reflects the feature content planned for Release 1 of the C-Registration System, as defined in the E1 Iteration Plan [14]. The resulting architectural prototype will bring together the key architectural components required for Release 1.0.

This document will help form the plans for the prototype integration and will be used as input into the Test Plan [16] for the prototype.

Definitions, Acronyms and Abbreviations

See Glossary [4].

References

Applicable references are:

Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT.
Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
Course Registration System Test Plan for the Architectural Prototype, WyIT432, V1.0, 1999, Wylie College IT.
Subsystems

The elaboration phase will develop the architectural prototype to verify the feasibility and performance of the architecture for Release 1.0. This will include implementing the interfaces to the external subsystems; Finance System and Course Catalog as well as implementing the course registration subsystem.

The main processes which interface with the student and which process the student’s registration request will be implemented. Security features, such as the student Logon will be implemented. The Close Registration process will be implemented to initiate the communication with the external Finance System.

Only selected components of the identified subsystems (and processes) will be implemented in the architectural prototype. The intent is to implement the interface and communication mechanisms.

The following table illustrates the subsystems and processes to be implemented for the architectural prototype:

Subsystem	Processes	Components
Course Registration	StudentApplication CourseRegistrationProcess CourseCatalogSystemAccess FinanceSystemAccess CloseRegistrationProcess	TBD
Finance System	FinanceSystem	TBD
Course Catalog	CourseCatalog	TBD

Builds

The integration (in the iteration) is divided into a number of increments, each resulting in a build, which is integration-tested. The integration of the prototype will be organized as 2 integration builds as described in the following sections.

Build integration includes the following steps:

Assembling the specified components into the build directories,
Creating the compile and link command files,
Compiling & linking the components into executables,
Initializing the database,
Transferring the executables, data, and test drivers to the target machines, and
Running integration tests.

3.1 Integration Build One

The first integration build will enable the following basic functionality:

Login Use Case: Remote or local logon,

Register for Courses Use Case: Query course catalog database and submit course registration.

Integration Build One includes the following Subsystems and Components:

Subsystem	Components
Course Registration	x-yuu a-abc x-sam x-big y-mam
Course Catalog	cc-interface main_catalog

3.2 Integration Build Two

The second integration build will enable the following basic functionality:

Close Registration Use Case: Close the registration period and initiate billing.

Integration Build Two includes the following Subsystems and Components:

Subsystem	Components
Course Registration	x-bab x-ymm c-raa x-yuu a-abc x-sam x-big y-mam
Finance System	Main_finance DB_finance

Example: Iteration Plan

Course Registration System

Iteration Plan Preliminary Iteration (Inception)

Version 1.1

Revision History

Date	Version	Description	Author
18/Jan/1999	1.0	Initial Release	Rick Bell
22/Jan/1999	1.1	Revised the high level schedule. Adjusted the budget.	Rick Bell

Table of Contents

Objectives
Scope
References
Plan

4.1    [Iteration Activities](#Iteration Activities)

4.2    [Iteration Schedule](#Iteration Schedule)

4.3    [Iteration Deliverables](#Iteration Deliverables)
Resources

5.1    Staffing Resources

5.2    Financial Resources

5.3    Equipment & Facilities Resources
[Use Cases](#Use Cases)
[Evaluation Criteria](#Evaluation Criteria)

Iteration Plan

- Objectives

This Iteration Plan describes the detailed plans for the Preliminary Iteration of the C-Registration System Project. During this iteration, the requirements of the system will be defined and the high level plan for execution of the full project will be developed. This first iteration will conduct a thorough analysis on the business case for the system and will result in a decision on whether the project will proceed.

2. Scope

The Preliminary Iteration Plan applies to the C-Registration System project being developed by Wylie College Information Systems for Wylie College. This document will be used by the Project Manager and by the project team.

3. References

Applicable references are:

Course Registration System Vision Document, WyIT387, V1.0, Wylie College IT.
Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.
Course Registration System Inception Phase Schedule, V1.0, 1999, Wylie College IT.
Course Registration System Project Plan, WyIT418, V1.0, 1999, Wylie College IT.

4. Plan

The Preliminary Iteration will develop the product requirements and establish the business case for the C-Registration System. The major use cases will be developed as well as the high level Project Plan. At the end of this iteration, Wylie College will decide whether to fund and proceed with the project based upon the business case.

4.1 Iteration Activities

The following table illustrates the high level activities with their planned start and end dates.

Activity	Start Date	End Date
Business Modeling	Dec 1, 1998	Dec 22, 1998
Requirements Definition	Dec 1, 1998	Jan 19, 1999
Configuration Management Setup	Dec 1, 1998	Jan 14, 1999
Management	Dec 1, 1998	Jan 19, 1999

4.2 Iteration Schedule

The detailed schedule showing all tasks and the assigned responsibilities is contained in the following schedule:


	Task Name	Duration	Start	Finish	Resource Names		—	—	—	—	—		Milestones	45 days	Tue 12/1/98	Mon 2/1/99			Start	0 days	Tue 12/1/98	Tue 12/1/98			Business Case Review Milestone (end Inception Phase)	0 days	Mon 2/1/99	Mon 2/1/99															Inception Phase	45 days	Tue 12/1/98	Mon 2/1/99			Preliminary Iteration	45 days	Tue 12/1/98	Mon 2/1/99			Business Modeling	18 days	Tue 12/1/98	Thu 12/24/98			Capture a Common Vocabulary	9 days	Tue 12/1/98	Fri 12/11/98	Business-Process Analyst		Find Business Actors and Use Cases	3 days	Wed 12/9/98	Fri 12/11/98	Business-Process Analyst		Describe Business Use Cases	9 days	Tue 12/1/98	Fri 12/11/98			Describe Business Use Case ‘BUC1’	9 days	Tue 12/1/98	Fri 12/11/98	Business Designer		Describe Business Use Case ‘BUC2’	9 days	Tue 12/1/98	Fri 12/11/98	Business Designer		Structure the Business Use-Case Model	14 days	Tue 12/1/98	Fri 12/18/98	Business-Process Analyst		Review Business Use-Case Model	4 days	Mon 12/21/98	Thu 12/24/98	Business-Model Reviewer		Requirements	40 days	Tue 12/1/98	Mon 1/25/99			Develop Vision	25 days	Tue 12/1/98	Mon 1/4/99	System Analyst		Elicit Stakeholder Requests	4 days	Tue 1/5/99	Fri 1/8/99	System Analyst		Manage Dependencies	26 days	Tue 12/1/98	Tue 1/5/99	System Analyst		Capture a Common Vocabulary	10 days	Wed 12/23/98	Tue 1/5/99	System Analyst		Find Actors and Use Cases	10 days	Wed 12/23/98	Tue 1/5/99	System Analyst		Prioritize Use Cases	10 days	Tue 1/12/99	Mon 1/25/99	Architect		Define System & Constraints	1 day	Mon 1/11/99	Mon 1/11/99	System Analyst		Configuration Management	34 days	Tue 12/1/98	Fri 1/15/99			Establish CM Practices	14 days	Tue 12/1/98	Fri 12/18/98

4.3 Iteration Deliverables

The following deliverables or artifacts will be generated and reviewed during the Preliminary Iteration:

Artifact Set	Deliverable	Responsible Owner
Business Modeling Set	Glossary Business Use Case Model Supplementary Business Spec. Business Use Case Realization	Bob Collings Yee Chung Bob Collings Yee Chung
Requirements Set	Vision Document Stakeholder Requests Document Use Case Specifications Supplementary Specification Requirements Attributes Document Use Case Model (and Model Survey)	Sue Gamble Bob King Sue Gamble Sue Gamble Sue Gamble Sue Gamble
Management Set	Preliminary Iteration Plan Project Plan Project Schedule Project Risk List Measurement Plan Business Case Document Status Assessment Preliminary Iteration Assessment Configuration Management Plan	Rick Bell Rick Bell Rick Bell Rick Bell Rick Bell Rick Bell Rick Bell & Carol Ming Rick Bell & Carol Ming Simon Jones
Standards and Guidelines	Requirements Attributes Guidelines Configuration Management Environment	Simon Jones Simon Jones

5. Resources**> 5.1 Staffing Resources**

The staffing requirements for the Preliminary Iteration are:

Project Management

Project Management Rick Bell

Business Modeling Group

Business Modeling Manager Bob King

Business-Process Analysts Bill Collings, Glen Fox

Business Designer Yee Chung

Business-Model Reviewer Abu Zony

Systems Engineering

Systems Engineering Manager Carol Ming

Systems Analysts Sue Gamble, <TBD>

Architect Steve Johnson

Software Engineering

Process Engineer (CM) Simon Jones

The project organization chart and the staffing requirements for the full project will be contained within the Project Plan [5].

5.2 Financial Resources

The following table shows the budget for the Preliminary Iteration. Wylie College has secured $150,000 in funds for this first iteration.

Desribed in Previous Content

5.3 Equipment & Facilities Resources

The Inception Phase requires the following computer equipment, which has already been acquired by the Information Systems department:

4 PCs (Windows 95 , MS Office, Rational Rose, RequisitePro)

6 Monitors

1 Printer

Access to the Wylie College Server.

The Wylie College Information Systems department has sufficient office space and furniture to meet the needs of this iteration.

6. Use Cases

7. Evaluation Criteria

The primary goal of the Preliminary Iteration is to define the system to the level of detail required to make a sound business judgment on the viability of the project from a business prospective. At the completion of the iteration, a review of the Business Case will arrive at a Go / No Go decision for the project.

Each deliverable developed during the iteration will be peer reviewed and subject to approval from the team.

Course Registration System

Use Case Specification

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Login

2.2    Alternative Flow

2.2.1       Invalid Name / Password
Special Requirements
Preconditions
Postconditions
Extension Points

Login Use Case

- Brief Description

This use case describes how a user logs into the Course Registration System.

The actors starting this use case are Student, Professor, and Registrar.

2. Flow of Events

The use case begins when the actor types his/her name and password on the login form.

2.1 Basic Flow - Login

The system validates the actor’s password and logs him/her into the system.

The system displays the Main Form and the use case ends.

2.2 Alternative Flows

2.2.1Invalid Name / Password

Issue: Need to decide whether password security is necessary for this application.

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions

Preconditions will be determined during the next iteration.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Course Registration System

Use-Case Specification

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble
13/Feb/99	Version 1.0	Minor corrections based on review	S. Gamble
15/Feb/99	Version 2.0	Modify section on use case extends Final cleanup. Revise alternate flows. Resolve outstanding issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1 Basic Flow - Login

2.2 Alternative Flows
Special Requirements
Preconditions
Postconditions
Extension Points

Login Use Case

Brief Description

This use case describes how a user logs into the Course Registration System.

The actors starting this use case are Student, Professor, and Registrar.

2. Flow of Events

The use case begins when the actor types his/her name and password on the login form.

2.1 Basic Flow - Login

The system validates the actor’s password and logs him/her into the system.

The system displays the Main Form and the use case ends.

2.2 Alternative Flows

Invalid Name / Password

If in the basic flow the system cannot find the name or the password is invalid, an error message is displayed. The actor can type in a new name or password or choose to cancel the operation, at which point the use case ends.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

There are no preconditions associated with this use case.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Maintain Professor Information Use Case Specification

Course Registration System

Use-Case Specification

Maintain Professor Information Use Case

**Version: Draft

Revision History**

Date	Version	Description	Author
21/Dec/98	Draft	Draft version.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Add a Professor

2.2    Alternative Flows

2.2.1    Modify and Delete a Professor
Special Requirements
Preconditions

4.1 Log In
Postconditions
Extension Points

Maintain Professor Information Use Case

- Brief Description

This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system.

The actor of this use case is the Registrar.

2. Flow of Events

The use case begins when the Registrar selects the “maintain professor” activity from the Main Form.

2.1 Basic Flow - Add a Professor

The Registrar selects “add a professor.”

The system displays a blank professor form.

The Registrar enters the following information for the professor: name, date of birth, social security number, status, and department.

The system validates the data to insure the proper data format and searches for an existing professor with the specified name. If the data is valid the system creates a new professor and assigns a unique system-generated id number. This number is displayed, so it can be used for subsequent uses of the system.

Steps 2-4 are repeated for each professor added to the system. When the Registrar is finished adding professors to the system the use case ends.

2.2 Alternative Flows

2.2.1 Modify and Delete a Professor

TBD

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions**> 4.1 Log

In**

Before this use case begins the Registrar has logged onto the system.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: Maintain Professor Information Use Case Specification

**Course Registration System

Use-Case Specification

Maintain Professor Information Use Case

Version 2.0**

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft version.	S. Gamble
13/Feb/99	Version 1.0	Minor corrections based on review	S. Gamble
15/Feb/99	Version 2.0	Modify section on use case extends. Final cleanup. Review alternate flows. Resolve outstanding issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Add a Professor

2.2    Alternative Flows

2.2.1    Modify a Professor

2.2.2    Delete a Professor

2.2.3    Professor Already Exists

2.2.4    Professor Not Found
Special Requirements
Preconditions

4.1 Log In
Postconditions
Extension Points

Maintain Professor Information Use Case

- Brief Description

This use case allows the Registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system.

The actor of this use case is the Registrar.

2. Flow of Events

The use case begins when the Registrar selects the “maintain professor” activity from the Main Form.

2.1 Basic Flow - Add a Professor

The Registrar selects “add a professor.”

The system displays a blank professor form.

The Registrar enters the following information for the professor: name, date of birth, social security number, status, and department.

The system validates the data to insure the proper data format and searches for an existing professor with the specified name. If the data is valid the system creates a new professor and assigns a unique system-generated id number. This number is displayed, so it can be used for subsequent uses of the system.

Steps 2-4 are repeated for each professor added to the system. When the Registrar is finished adding professors to the system the use case ends.

2.2 Alternative Flows

2.2.1Modify a Professor

The Registrar selects “Modify a professor.”

The system displays a blank professor form.

The Registrar types in the professor id number he/she wishes to modify

The system retrieves the professor information and displays it on the screen

The Registrar modifies one or more of the professor information fields: name, date of birth, social security number , status, and department.

When changes are complete, the Registrar selects “save.”

The system updates the professor information.

Steps 2-7 are repeated for each professor the Registrar wants to modify. When edits are complete, the use case ends.

2.2.2Delete a Professor

The Registrar selects “Delete a Professor.”

The system displays a blank professor form.

The Registrar types in the professor id number for the professor that’s being deleted.

The system retrieves the professor and displays the professor information in the form.

The Registrar selects “delete.”

The system displays a delete verification dialog confirming the deletion.

The Registrar selects “yes.”

The professor is deleted from the system.

Steps 2-8 are repeated for each professor the Registrar wants to modify. When the Registrar is finished deleting professors from the system, the use case ends.

2.2.3Professor Already Exists

If in the “Add a Professor” sub-flow, a professor already exists with the specified name, an error message, “Professor Already Exists”, is displayed. The Registrar can either change the name, choose to create another professor with the same name, or cancel the operation at which point the use case ends.

2.2.4Professor Not Found

If in the “Modify a Professor” sub-flow or “Delete a Professor” sub-flow, a professor with the specified id number does not exist, the system displays an error message, “Professor Not Found”. Then the Registrar can type in a different id number or cancel the operation at which point the use case ends.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Log In

Before this use case begins the Registrar has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Maintain Student Information Use Case Specification

Course Registration System

Use-Case Specification

Maintain Student Information Use Case

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft version	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Add Student

2.2    Alternative Flows

2.2.1    Modify a Student

2.2.2    Delete a Student
Special Requirements
Preconditions

4.1 Log In
Postconditions
Extension Points

Maintain Student Information Use Case

- Brief Description

This use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system.

The actor for this use case is the Registrar.

2. Flow of Events

The use case begins when the Registrar selects the “maintain student” activity from the Main Form.

2.1 Basic Flow - Add Student

The Registrar selects “add student.”
The system displays a blank student form.
The Registrar enters the following information for the student: name, date of birth, social security number, status, and graduation date.
The system validates the data to insure the proper format and searches for an existing student with the specified name. If the data is valid the system creates a new student and assigns a unique system-generated id number.
Steps 2-4 are repeated for each student added to the system. When the Registrar is finished adding students to the system the use case ends.

2.2 Alternative Flows

2.2.1Modify a Student

Issue: Must ensure the flows for modifying and deleting students are similar to the flows for modifying and deleting professors.

2.2.2Delete a Student

Issue: Must ensure the flows for modifying and deleting students are similar to the flows for modifying and deleting professors.

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions

4.1 Log In

Before this use case begins the Registrar has logged onto the system.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: Maintain Student Information Use Case Specification

Course Registration System

Use-Case Specification

Maintain Student Information Use Case

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft version	S. Gamble
15/Feb/1999	Version 1.0	Minor corrections based on review.	S. Gamble
19/Feb/1999	Version 2.0	Modify section on use case extends. Final cleanup. Add alternative flows. Resolve remaining issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Add Student

2.2    Alternative Flows

2.2.1    Modify a Student

2.2.2    Delete a Student

2.2.3    Student Already Exists

2.2.4    Student Not Found
Special Requirements
Preconditions

4.1 Log In
Postconditions
[Extension Points](#Extension Points)

Maintain Student Information Use Case

- Brief Description

This use case allows the Registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system.

The actor for this use case is the Registrar.

2. Flow of Events

The use case begins when the Registrar selects the “maintain student” activity from the Main Form.

2.1 Basic Flow - Add Student

The Registrar selects “add student.”

The system displays a blank student form.

The Registrar enters the following information for the student: name, date of birth, social security number, status, and graduation date.

The system validates the data to insure the proper format and searches for an existing student with the specified name. If the data is valid the system creates a new student and assigns a unique system-generated id number.

Steps 2-4 are repeated for each student added to the system. When the Registrar is finished adding students to the system the use case ends.

2.2 Alternative Flows

2.2.1 Modify a Student

The Registrar selects “modify student.”

The system displays a blank student form.

The Registrar types in the student id number he/she wishes to modify.

The system retrieves the student information and displays it on the screen.

The Registrar modifies one or more of the student information fields: name, date of birth, social security number, student id number, status, and graduation date.

When changes are complete, the Registrar selects “save.”

The system updates the student information.

Steps 2-7 are repeated for each student the Registrar wants to modify. When edits are complete, the use case ends.

2.2.2 Delete a Student

The Registrar selects “delete student.”

The system displays a blank student form.

The Registrar types in the student id number for the student that’s being deleted.

The system retrieves the student and displays the student information in the form.

The Registrar selects “delete.”

The system displays a delete verification dialog confirming the deletion.

The Registrar selects “yes.”

The student is deleted from the system.

Steps 2-8 are repeated for each student deleted from the system. When the Registrar is finished deleting students to the system the use case ends.

2.2.3Student Already Exists

If in the “Add a Student” sub-flow the system finds an existing student with the same name an error message is displayed “Student Already Exists”. The Registrar can either change the name, create a new student with the same name, or cancel the operation at which point the use case ends.

2.2.4 Student Not Found

If in the “Modify a Student” or “Delete a Student” sub-flows the student name is not located, the system displays an error message, “Student Not Found”. The Registrar can then type in a different id number or cancel the operation at which point the use case ends.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Log In

Before this use case begins the Registrar has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Pearl Circle Online Auction

The Pearl Circle Online Auction (PCOA) is an example of a Web-based application that includes a complete set of models, including:

Use-Case Model
User-Experience Model
Analysis Model
Design Model
Implementation Model

To access this example, go to the Rational Developer NetworkSM and search on either “Pearl Circle Online Auction” or “PCOA”.

Note: To access the information, you will need to have an account and sign in. To create an account, you need your Rational product account number. See the registration page on the Rational Developer Network for more information.

Project ABC-Development Case

This is an example of what a development case may look like. There is no point in restating information already in the process. What you have to describe are the deviations from the process. You may put together a Development Case that contains a small description of the process. However, the problem with that kind of document is that they tend to grow forever, until they’re the size of the process handbook!

This example is intended to give you an idea about how a development case would look for a small project, let’s say a commercial information system.

For more information about the Development Case, its contents, and outline, see Artifact: Development Case.

Topics

Introduction
- [Revision History](#Revision History)
- Purpose
- Definitions, Acronyms and Abbreviations
- References
[Overview of the Development Case](#Overview of the Development Case)
- Lifecycle Model
- [Disciplines](#Overvew: Disciplines)
- [Discipline Configuration](#Overview: Configuration)
- [Artifact Classification](#Artifact Classification)
- [Review Procedures](#Review Procedures)
- [Sample Iteration Plans](#Sample Iteration Plans)
Disciplines
- [Business Modeling](#Business Modeling)
- Requirements
- [Analysis & Design](#Analysis & Design)
- Implementation
- Test
- Deployment
- [Configuration & Change Management](#Configuration & Change Management)
- [Project Management](#Project Management)
- Environment
Roles

Introduction

Revision History

Date	Version	Description	Author
01/01/2000	1.0	-	Tom Smith

Purpose

The purpose of the document is to describe the development process for the project ABC.

Definitions, Acronyms, and Abbreviations

Not applicable.

References

Not applicable.

Overview of the Development Case

Lifecycle Model

See the section titled “Project Plan” in the project’s Software Development Plan.

Disciplines

The development-case example presented here takes you through all nine disciplines: Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment.

Discipline Configuration

The purpose of this section is to explain how the discipline configuration works. This includes the purpose of the different tables and sections that describe each workflow in the section titled “Workflows”.

Section: “Workflows”

This section details any changes made to the structure of the workflow itself. Typical changes include the addition of activities to describe company-specific ways of working or the removal of activities from the workflow.

Section: “Artifacts”

The section describes, in a table, how the artifact will be used. Additional ‘local’ artifacts can be added to the table as needed.

Artifacts	How to use				Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans

Explanation of the table

Column Name	Purpose	Contents/Comments
Artifacts	To name of the artifact	A reference to the artifact in the Rational Unified Process (RUP) or to a local artifact definition that’s held as part of the development case.
How to use	To qualify how the artifact is used across the life cycle	For each phase, decide on: - Must haves - Should haves - Could haves - Won’t haves These are defined in the Guidelines: Classifying Artifacts.
Review Details	To define the review level and review procedures applied to the artifact.	Decide on the review level: - Formal-External - Formal-Internal - Informal - None For details, see Guidelines: Review Levels. Also add a reference to the definition and detail of the relevant review procedures. The reference could point to either the RUP or to the section titled “Review Procedure” in the development case. More specific review procedures are defined in the discipline’s “Additional Review Procedures” sub-section.
Tools used	To define the tool or tools used to produce the artifact.	References to the details of the tools used to develop and maintain the artifact.
Templates/Examples	To provide the templates to be used and examples of artifacts that use the templates.	References to templates and examples. This could refer to either the templates and examples in the RUP or local templates and examples. This column may also contain references to actual artifacts that provide additional help to project members.

Section: “Notes on Artifacts”

This section has three main purposes:

It contains a list all artifacts you Won’t use and the motives behind your decision not to use them.
It contains a reference to the project’s Configuration Management (CM) Plan, which describes the configuration management strategy used when working on these artifacts. The CM Plan allows developers to answer questions such as:
- When do I release my artifact?
- Where do I put my newly created or modified artifact?
- Where do I find existing artifacts for the project?
If the development case is an organization-level development case, this is where you add notes on what each project needs to consider when they decide what to do with the artifact. Use the predefined table below as a starting point.

Artifacts	How to Use	Reason

Section: “Reports”

This section lists the reports to be used and additional ‘local’ reports can be added to the table as needed.

Reports	How to use	Templates/Examples	Tools Used

Section: “Notes on the Reports”

This section has two main purposes. First, it lists all reports that the project has decided it Won’t use, and the motives behind its decision not to use them. Secondly, if the development case is a an organization-level use case, this is where to add notes on what each project needs to consider when they decide what to do with the report.

Section: “Additional Review Procedures”

This section captures any additional review procedures required for the artifacts used in the discipline. These supplement the general review procedures described in the “Overview” section of the Development Case.

Section: “Other Issues”

This section captures any outstanding issues with the discipline’s configuration. This section can be used as an Issues List while building the development case.

Artifact Classification

An artifact is a deliverable of the process. It is often developed within one discipline, although there are exceptions. The artifacts are organized in the discipline where it’s created. To describe how an artifact will be used, consider the following classification scheme and see Guidelines: Classifying Artifacts for details:

Must
Should
Could
Won’t

Review Procedures

The project uses the following review levels:

Formal-External
Formal-Internal
Informal
None

For details, see Guidelines: Review Levels.

Sample Iteration Plans

Inception Phase

Sample Iteration Plan: Inception Phase

Elaboration Phase

To be defined later in the project.

Construction Phase

To be defined later in the project.

Transition Phase

To be defined later in the project.

Disciplines

Business Modeling

Workflow

Follow the Domain Modeling workflow detail only. See Business Modeling: Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Business Entity	Must	Could	Could	Could	Formal-External	Rational Rose
Business Glossary	Must	Could	Could	Could	Formal-External	Rational Rose
Business Analysis Model	Must	Could	Could	Could	Formal-External	Rational Rose
Target-Organization Assessment	Must	Could	Could	Could	Formal-External	Rational Rose

Notes on the Artifacts

See the project’s Configuration Management Plan for information on how the artifacts are configuration-managed.

The project decided to only perform domain modeling, which means that the following artifacts will not be developed: Business Actor, Business Architecture Document, Business Rules, Business Use Case, Business Use-Case Model, Business Vision, Business Worker, Business System, and Supplementary Business Specification.

Reports

Reports	How to use	Templates/Examples	Tools Used
Business Entity	Could		Microsoft Word
Business Analysis Model Survey	Could		Rational SoDA Microsoft Word

Requirements

Workflow

No changes. For details see the Requirements Overview.

Artifacts

Artifacts	How to use				Review Details
Incep	Elab	Const	Trans
Actor	Must	Must	Must	Must	Informal
Glossary	Must	Must	Must	Must	Formal-External
Requirements Attributes	Must	Must	Must	Must	Formal-Internal
Requirements Management Plan	Must	Must	Must	Must	Formal- Internal
Stakeholder Requests	Must	Must	Must	Must	Formal-External
Software Requirements Specification	Must	Must	Must	Must	Formal-External
Supplementary Specification	Must	Must	Must	Must	Formal-External
Use Case	Must	Must	Must	Must	Formal-External
Use-Case Model	Must	Must	Must	Must	Formal-External
Use-Case Package	Must	Must	Must	Must	Informal
Use-Case Storyboard	Won’t	Must	Could	Could	Informal
User-Interface Prototype	Won’t	Must	Could	Could	Formal-External
Vision	Must	Must	Must	Must	Formal-External

Notes on the Artifacts

See the project’s Configuration Management Plan for information about how the artifacts are configuration-managed.

Reports

Reports	How to Use	Templates/Examples	Tools Used
Actor	Could
Use-Case	Could
Use-Case Model Survey	Could
Use-Case Storyboard	Could

Analysis & Design

Workflow

A real-time application is not being developed, therefore the Capsule Designer role and the activity Capsule Design are excluded. For details on the workflow, see the Analysis & Design Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Data Model	Won’t	Could	Could	Could	Informal	Rational Rose
Deployment Model	Could	Must	Must	Must	Formal- Internal	Rational Rose
Design Class	Could	Must	Must	Must	Informal	Rational Rose
Design Model	Could	Must	Must	Must	Formal- Internal	Rational Rose
Design Package	Could	Must	Must	Must	Formal- Internal	Rational Rose
Design Subsystem	Could	Must	Must	Must	Formal- Internal	Rational Rose
Interface	Could	Must	Must	Must	Formal- Internal	Rational Rose
Reference Architecture	Could	Must	Must	Must	Formal- Internal	Rational Rose
Software Architecture Document (SAD)	Could	Must	Must	Must	Formal- External	Rational SoDA Microsoft Word
Use-Case Realization	Could	Must	Must	Must	Informal	Rational Rose

Notes on the Artifacts

The project is not developing a real-time product, which means that the following artifacts will not developed: Capsule, Event, Protocol, and Signal.

The project decided not to keep an analysis model, which means that the following artifacts will not be developed: Analysis Class and Analysis Model.

Reports

Reports	How to Use	Tools Used
Class	Could	Rational SoDA Microsoft Word
Design-Model Survey	Could	Rational SoDA Microsoft Word
Design Package/Subsystem	Could	Rational SoDA Microsoft Word
Use-Case Realization	Could	Rational SoDA Microsoft Word

Implementation

Workflow

No changes in the workflow. For details see the Implementation Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Build	Could	Must	Must	Must	Informal	Microsoft® Visual Basic®
Implementation Element	Could	Must	Must	Must	Informal Code reviews	Microsoft Visual Basic
Implementation Model	Could	Must	Must	Must	Informal	Microsoft Visual Basic
Implementation Subsystem	Could	Must	Must	Must	Formal- Internal	Microsoft Visual Basic
Integration Build Plan	Could	Must	Must	Must	Formal- Internal	Microsoft Word

Additional Review Procedures

Informal code reviews are performed.

Test

Workflow

No formal performance test is done, otherwise the workflow is followed unchanged. For details on the process, see the Test: Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Test Plan	Could	Could	Must	Must	Informal	Microsoft Word
Test-Ideas List	Won’t	Could	Must	Must	Informal	Microsoft Word
Test Case	Won’t	Could	Must	Must	Informal	Microsoft Word
Test Data	Won’t	Could	Must	Must	Informal	Rational Rose
Workload Model	Won’t	Could	Must	Must	Informal	Rational Rose
Test Class	Won’t	Could	Must	Must	Informal	Rational Rose
Test Components	Won’t	Could	Must	Must	Informal	Microsoft Visual Basic
Test Results	Won’t	Could	Must	Must	Informal	Microsoft Word
Test Evaluation Summary	Won’t	Could	Must	Must	Informal	Microsoft Word
Test Suite	Won’t	Could	Must	Must	Informal	Rational Rose
Test Script	Won’t	Could	Must	Must	Informal	Rational TestStudio
Test Environment Configuration	Won’t	Could	Must	Must	Informal	Rational Rose
Test Automation Architecture	Won’t	Could	Must	Must	Informal	Rational Rose
Test Interface Specification	Won’t	Could	Must	Must	Informal	Rational Rose

Notes on the Artifacts

No Workload Analysis Document is developed.

Additional Review Procedures

Test cases-informally approved by the system testers.
The system testers decide if the test criteria for an iteration is fulfilled.
The customer approves the final iteration.

Deployment

Workflow

A previously existing deployment workflow was adapted to use the artifacts suggested in the RUP. An exception is the Course Material artifact, which is excluded because no formal training is produced for our product.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Bill of Materials	Won’t	Won’t	Could	Must	Formal- Internal	Microsoft Word
Deployment Plan	Won’t	Could	Must	Must	Informal	Microsoft Word
Deployment Unit	Won’t	Could	Could	Must	Informal	Microsoft Word
Support Material	Won’t	Could	Could	Must	Informal	Microsoft Word
Installation Artifacts	Won’t	Could	Could	Must	Informal	Microsoft Word
Product	Won’t	Could	Could	Must	Formal- External
Product Artwork	Won’t	Could	Could	Must	Informal	Microsoft Word
Release Notes	Won’t	Could	Could	Must	Formal- Internal	Microsoft Word

Notes on the Artifacts

No Training Materials are developed because the product does not require formal training.

Reports

Reports	How to Use	Templates/Examples	Tools Used

Configuration & Change Management

Workflow

No changes in the workflow. For details on the process, see the Configuration & Change Management: Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Change Request	Won’t	Could	Must	Must	Informal	Rational ClearQuest
Configuration Audit Findings	Won’t	Could	Must	Must	Informal	Microsoft Word
Configuration Management Plan	Won’t	Must	Must	Must	Informal	Microsoft Word
Project Repository	Won’t	Could	Must	Must	None	Rational ClearCase
Workspace	Won’t	Could	Must	Must	None	Rational ClearCase

Project Management

Workflow

No changes to the workflow. For details, see Project Management: Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Business Case	Must	Must	Could	Could	Formal- External	Microsoft® Word®
Iteration Assessment	Must	Must	Must	Must	Informal	Microsoft Word
Iteration Plan	Could	Must	Must	Must	Informal	Microsoft Word
Measurement Plan	Could	Could	Could	Could	Informal	Microsoft Word
Problem Resolution Plan	Must	Must	Must	Must	Informal	Microsoft Word
Product Acceptance Plan	Could	Must	Must	Must	Informal	Microsoft Word
Project Measurements	Could	Could	Must	Must	Informal	Microsoft Word
Quality Assurance Plan	Could	Could	Could	Could	Informal	Microsoft Word
Review Record	Must	Must	Must	Must	Informal	Microsoft Word
Risk List	Must	Must	Must	Must	Formal- Internal	Microsoft Word
Risk Management Plan	Could	Must	Must	Must	Informal	Microsoft Word
Software Development Plan (SDP)	Won’t	Could	Must	Must	Formal- Internal	Microsoft Word Microsoft Project
Status Assessment	Could	Must	Must	Must	Informal	Microsoft Word

Notes on the Artifacts

The artifact Work Order won’t be used.

Environment

Workflow

No changes in the workflow. For details on the process, see the Environment: Overview.

Artifacts

Artifacts	How to use				Review Details	Tools used
Incep	Elab	Const	Trans
Business Modeling Guidelines	Must	Could	Could	Could	Informal	Microsoft Word
Design Guidelines	Won’t	Must	Must	Must	Informal	Microsoft Word
Development Case	Must	Must	Must	Must	Informal	Microsoft® FrontPage®
Development Infrastructure	Must	Must	Must	Must	Informal	Microsoft Word
Development-Organization Assessment	Must	Won’t	Won’t	Won’t	Informal	Microsoft Word
Manual Styleguide	Won’t	Could	Must	Must	Informal	Microsoft Word
Project-Specific Templates	Must	Must	Must	Must	Informal	Microsoft Word
Programming Guidelines	Won’t	Must	Must	Must	Informal	Microsoft Word
Test Guidelines	Won’t	Must	Must	Must	Informal	Microsoft Word
Tools	Must	Must	Must	Must	Informal	Microsoft Word to document
Tool Guidelines	Won’t	Could	Must	Must	Informal	Microsoft Word
Use-Case Modeling Guidelines	Must	Must	Must	Must	Informal	Microsoft Word
User-Interface Guidelines	Won’t	Must	Must	Must	Informal	Microsoft Word

Roles

Not applicable.

Example: Register for Course Use Case Specification

Course Registration System

Use-Case Specification

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble
13/Feb/99	Version 1.0	Minor corrections based on review	S. Gamble
15/Feb/99	Version 2.0	Modify section on use case extends. Final cleanup. Review alternate flows. Resolve outstanding issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Create a Schedule

2.2    Alternative Flows

2.2.1    Modify a Schedule

2.2.2    Delete a Schedule

2.2.3    Save a Schedule

2.2.4    Add Course Offering

2.2.5    Unfulfilled Prerequisites or Course Full

2.2.6    No Schedule Found

2.2.7    Course Catalog System Unavailable

2.2.8    Course Registration Closed
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

Register for Courses Use Case

1. Brief Description

This use case allows a Student to register for course offerings in the current semester. The Student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Course Catalog System provides a list of all the course offerings for the current semester.

The main actor of this use case is the Student. The Course Catalog System is an actor within the use case.

2. Flow of Events

The use case begins when the Student selects the “maintain schedule” activity from the Main Form.

2.1 Basic Flow - Create a Schedule

The Student selects “create schedule.”
The system displays a blank schedule form.
The system retrieves a list of available course offerings from the Course Catalog System.
The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings. Once the selections are complete the Student selects “submit.”
The “Add Course Offering” sub-flow is performed at this step for each selected course offering.
The system saves the schedule.

2.2 Alternative Flows

2.2.1Modify a Schedule

The Student selects “modify schedule.”

The system retrieves and displays the Student’s current schedule (e.g., the schedule for the current semester).

The system retrieves a list of all the course offerings available for the current semester from the Course Catalog System. The system displays the list to the Student.

The Student can then modify the course selections by deleting and adding new courses. The Student selects the courses to add from the list of available courses. The Student also selects any course offerings to delete from the existing schedule. Once the edits are complete the Student selects “submit”.

The “Add Course Offering” sub-flow is performed at this step for each selected course offering.

The system saves the schedule.

2.2.2Delete a Schedule

The Student selects the “delete schedule” activity.

The system retrieves and displays the Student current schedule.

The Student selects “delete.”

The system prompts the Student to verify the deletion.

The Student verifies the deletion.

The system deletes the schedule.

2.2.3 Save a Schedule

At any point, the Student may choose to save a schedule without submitting it by selecting “save”. The current schedule is saved, but the student is not added to any of the selected course offerings. The course offerings are marked as “selected” in the schedule.

2.2.4 Add Course Offering

The system verifies that the Student has the necessary prerequisites and that the course offering is open. The system then adds the Student to the selected course offering. The course offering is marked as “enrolled in” in the schedule.

2.2.5 Unfulfilled Prerequisites or Course Full

If in the “Add Course” sub-flow the system determines that the Student has not satisfied the necessary prerequisites or that the selected course offering is full, an error message is displayed. The Student can either select a different course offering or cancel the operation, at which point the use case is restarted.

2.2.6 No Schedule Found

If in the “Modify a Schedule” or “Delete a Schedule” sub-flows the system is unable to retrieve the Student’s schedule, an error message is displayed. The Student acknowledges the error and the use case is restarted.

2.2.7 Course Catalog System Unavailable

If, the system is unable to communicate with the Course Catalog System after a specified number of tries, the system will display an error message to the Student. The Student acknowledges the error message and the use case terminates.

2.2.8 Course Registration Closed

If, when the student selects “maintain schedule”, registration for the current semester has been closed, a message is displayed to the Student and the use case terminates. Students cannot register for courses after registration for the current semester has been closed.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Login

Before this use case begins the Student has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Register for Courses Use Case Specification

Course Registration System

Use-Case Specification

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Create a Schedule

2.2    Alternative Flows

2.2.1    Modify a Schedule

2.2.2    Delete a Schedule

2.2.3    Course Catalog System Unavailable
Special Requirements
Preconditions
1. Login
Postconditions
Extension Points

Register for Courses Use Case

- Brief Description

The main actor of this use case is the Student. The Course Catalog System is an actor within the use case.

2. Flow of Events

The use case begins when the Student selects the “maintain schedule” activity from the Main Form.

2.1 Basic Flow - Create a Schedule

The Student selects “create schedule.”

The system displays a blank schedule form.

The system retrieves a list of available course offerings from the Course Catalog System.

The Student selects 4 primary course offerings and 2 alternate course offerings from the list of available offerings. Once the selections are complete the Student selects “submit.”

Courses are added for each selected course offering.

The system saves the schedule.

2.2 Alternative Flows

2.2.1Modify a Schedule

TBD.

2.2.2Delete a Schedule

TBD.

2.2.3Course Catalog System Unavailable

If, the system is unable to communicate with the Course Catalog System after a specified number of tries, the system will display an error message to the Student. The Student acknowledges the error message and the use case terminates.

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions

4.1 Login

Before this use case begins the Student has logged onto the system.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: Release Notes

Course Registration System

Release 1.0

Release Notes****Version 1.0

Revision History

Date	Version	Description	Author
30/May/1999	1.0	Initial Version - Release Notes for the C-Registration System R1.0	C. Atkins

Table of Contents

Introduction
[About This Release](#About this)
Compatible Products
Upgrading
[New Features](#New Features)
[Known Bugs and Limitations](#Known Bugs)

6.1    Rejected Password

6.2    Checking of Course Pre-requisites

6.3    Delays in Accessing Course Information

6.4    Out of State Students

6.5    Incompatibility with Internet Explorer

**Release Notes

1. Introduction**

1.1 Purpose

This document describes Release 1.0 of the C-Registration System developed for Wylie College.

The purpose of the Release Notes is to communicate new features and changes in this release of the C-Registration System. This document also describes known problems in the Release.

1.2 Scope

This document describes Release 1.0 of the C-Registration System developed for Wylie College.

1.3 References

The following additional information is available to users of the C-Registration System:

User’s Guide
Installation Guide
Guide for System Administrators
Downloading New Releases: http://www/wyliecollege/it/support

2 About This Release

Release 1.0 of the C-Registration System will enable Wylie College students to register online for their courses. Students will be able to access the course information from local college personal computers or from their home computers via Internet dialup.

This release supports online maintenance of all student and professor information. The College Registrar will be able to monitor course registrations throughout the registration period. Billing to students will be initiated automatically through an interface to the existing Finance System.

Please contact the Wylie College Support Center at 339-329-8888 or email support@wyliecollege.com if you experience any difficulties with installing the software or using the system.

To obtain your login ID please contact Support at 339-329-8888.

3. Compatible Products

The C-Registration System includes a client portion that operates on the client’s personal computer. The minimum requirements for the personal computer are:

486 Microprocessor or better
32 MB RAM
20 MB disk space
Windows 95/98/NT
Internet Browser: Netscape 4.0.4 or Internet Explorer 4.0 or better
Access to internet dialup

The C-Registration System includes a server portion that operates on the Wylie College Unix Server. It interfaces with the following systems:

Finance System (Release 2.3)
Course Catalog Database System (Release 2.6)

4. Upgrading

Instructions on installing Release 1.0 are contained in the Installation Manual and are also available on the web http://www/wyliecollege/it/support.

5. New Features

The core set of features available in Release 1.0 are:

Online registration for courses

Maintenance of all student records

Maintenance of professor information

Automatic billing of students

Professor signup for courses to teach

Input of student grades

Access to student report cards

Remote or local access through personal computers

6. Known Bugs and Limitations

This section identifies known problems with Release 1.0 and describes any work-arounds. Please contact our support department if you require further help.

6.1 Rejected Password

Passwords are case sensitive.

Solution: If the system rejects your password please enter again using upper and lower case characters.

6.2 Checking of Course Pre-requisites

The system will not correctly check that the required course pre-requisites have been taken. An error message “Course pre-requisites not satisfied” is displayed and the system prevents the student from registering for the course.

Solution: If you encounter this problem, please contact the Wylie College Registrar to assist you with registering.

6.3 Delays in Accessing Course Information

During periods of peak usage, the system response times may be affected. In particular, accessing course information from the Course Catalog could be slow.

Solution: To avoid delays please register for courses following 5:00 p.m.

6.4 Out of State Students

Address information for out of state students is not retained or displayed correctly.

Solution: The State or Province of residence can be entered in address line 4, along with the Country information.

6.5 Incompatibility with Internet Explorer

Some problems have been encountered with opening multiple frames in Internet Explorer.

Solution: Close frames not in use. If this does not remove the problem, please exit the application and restart.

Example: Risk List

Course Registration System Risk List

**Version 1.0

Revision History**

Date	Version	Description	Author
18/Jan/99	1.0	Risks identified at the beginning of the Inception Phase.	Rick Bell

Risk List

Project risk is evaluated at least once per iteration and documented in this table. The risks of the greatest magnitude are listed first in the table.

Risk Ranking/ Magnitude	Risk Description & Impact	Mitigation Strategy and/or Contingency Plan
7	R1 and R2 Releases may slip and not be available by September 1999 - the start of the Registration Period.	Monitor progress against the schedule & milestones. Update effort to complete and time to complete on a regular basis.
5	Legacy Systems face a significant Y2K risk. If the legacy Billing System and Course Registration Database System are not Y2K compliant, the malfunction of these old systems could affect the operation of the C-Reg System.	Send letter to Wylie College Head Office regarding the necessity of a Y2K Audit on existing systems.
5	Interfaces to the old legacy Billing and Course Catalog Systems may introduce performance and response time issues.	Develop early prototypes to test all external interfaces.
4	Volume of students logged on during peak hours of the registration period may significantly degrade system performance.	Early prototyping and extrapolation of response time data should be done in the Elaboration Phase.
3	Incompatibility with internet browsers and specific configurations on client machines.	Address during Elaboration Phase.
3	The 4 open positions (2 Developers and 2 Designers) will not be hired within the timeframe.	If the open positions are not filled by the start of the Design, contact local recruiters.
3	The development team is relatively inexperienced with the Rational Unified Process (RUP) and Object Oriented Techniques. This could lead to lower efficiency and poorer product quality	Schedule training sessions for OO Development and the Rational Unified Process. Establish ‘process mentors’ who can assist the team in understanding the process and the development activities. Ensure all Design and Code is inspected.
2	Wylie College will be unable to fund the development as part of its 1999 budget.	Prepare a second option for financing which splits the development (and funding) across 2 years (1999 and 2000).

Example: Risk List

**Course Registration System

Risk List**

Version 2.0

Revision History

Date	Version	Description	Author
18/Jan/99	1.0	Risks identified at the beginning of the Inception Phase.	Rick Bell
12/Feb/99	2.0	Updated risk list at beginning of Elaboration Phase. No new risks. Eliminate risk of funding problems. Downgrade criticality of other risks.	Rick Bell

Risk List

Project risk is evaluated at least once per iteration and documented in this table. The risks of the greatest magnitude are listed first in the table. (This list was last updated at the beginning of the Elaboration Phase.)

Risk Ranking/ Magnitude	Risk Description & Impact	Mitigation Strategy and/or Contingency Plan
8	Volume of students logged on during peak hours of the registration period may significantly degrade system performance.	Further develop prototype to obtain more accurate numbers.
7	R1 and R2 Releases may slip and not be available by September 1999 - the start of the Registration Period.	Monitor progress against the schedule & milestones. Update effort to complete and time to complete on a regular basis.
5	Interfaces to the old legacy Billing and Course Catalog Systems may introduce performance and response time issues.	Continue to develop prototype. Monitor this issue at weekly progress meetings.
4	One Developer position remains unfilled. If not filled by the start of the Construction Phase, the schedule could slip by up to 5 weeks.	Contact local recruiting agencies. Action: Rick Bell.
3	Strike Action of College Facility Union Workers may impact project schedule if IT services are unavailable.	Monitor.

Example: Select Courses to Teach Use Case Specification

Course Registration System

Use-Case Specification

Select Courses to Teach Use Case

**Version: Draft

Revision History**

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1 Basic Flow - Select Courses to Teach

2.2 Alternative Flows
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

Select Courses to Teach Use Case

- Brief Description

This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.

The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case.

2. Flow of Events

The use case begins when the professor selects the “select courses to teach” activity from the Main Form.

2.1 Basic Flow - Select Courses to Teach

The system retrieves and displays the list of course offerings the professor is eligible to teach for the current semester. The system also retrieves and displays the list of courses the professor has previously selected to teach.

The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester.

The system removes the professor from teaching the de-selected course offerings.

The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with each other or any offerings the professor has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the professor selects.

2.2 Alternative Flows

Issues: Add flows to deal with following conditions:

Handling of course scheduling conflicts

Registration period is ended

Professor is not eligible to teach the course.

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions

4.1 Login

Before this use case begins the Professor has logged onto the system.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: Select Courses to Teach Use Case Specification

Course Registration System

Use-Case Specification

Select Courses to Teach Use Case

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble
15/Feb/99	Version 1.0	Minor corrections based on review.	S. Gamble
19/Feb/99	Version 2.0	Modify section on use case extends. Final cleanup. Review alternate flows. Resolve outstanding issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Select Courses to Teach

2.2    Alternative Flows

2.2.1    No Courses Available

2.2.2    Schedule Conflict

2.2.3    Course Registration Closed
Special Requirements
Preconditions

4.1 Login
Postconditions
[Extension Points](#Extension Points)

**Select Courses to Teach Use Case

1. Brief Description**

This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester.

The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case.

2. Flow of Events

The use case begins when the professor selects the “select courses to teach” activity from the Main Form.

2.1 Basic Flow - Select Courses to Teach

The system retrieves and displays the list of course offerings the professor is eligible to teach for the current semester. The system also retrieves and displays the list of courses the professor has previously selected to teach.
The professor selects and/or de-selects the course offerings that he/she wishes to teach for the upcoming semester.
The system removes the professor from teaching the de-selected course offerings.
The system verifies that the selected offerings do not conflict (i.e., have the same dates and times) with each other or any offerings the professor has previously signed up to teach. If there is no conflict, the system updates the course offering information for each offering the professor selects.

2.2 Alternative Flows

2.2.1*No Courses Available

If in the basic flow the professor is not eligible to teach any courses in the upcoming semester the system will display an error message. The professor acknowledges the message and the use case ends.*

2.2.2 Schedule Conflict

*> If the systems find a schedule conflict when trying to establish the

course offerings the Professor should take, the system will display an error message indicating that a schedule conflict has occurred. The system will also indicate which are the conflicting courses. The professor can either resolve the schedule conflict (i.e., by canceling his selection to teach one of the course offerings) or cancel the operation, in which case any selections will be lost and the use case ends.* 2.2.3Course Registration Closed If, when the Professor selects “select courses to teach”, registration for the current semester has been closed, a message is displayed to the Professor and the use case terminates. Professors cannot change the course offerings they teach after registration for the current semester has been closed. If a professor change is needed after registration has been closed, it is handled outside the scope of this system.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Login

Before this use case begins the Professor has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Software Architecture Document

Course Registration System

Software Architecture Document Version 1.0

Revision History

Date	Version	Description	Author
21/March/1999	1.0	Software Architecture Document generated using Rational SoDA template and Rational Rose model.	S. Johnson

Table of Contents

Introduction

Architectural Representation

Architectural Goals and Constraints

Use-Case View

Logical View

Process View

Deployment View

Size and Performance

Quality

**Software Architecture Document

Introduction**

1.1 Purpose

1.2 Scope

This Software Architecture Document provides an architectural overview of the C-Registration System. The C-Registration System is being developed by Wylie College to support online course registration.

This Document has been generated directly from the C-Registration Analysis & Design Model implemented in Rose. The majority of the sections have been extracted from the Rose Model using SoDA and the Software Architecture Document template.

1.3 Definitions, Acronyms and Abbreviations

See the Glossary [4].

1.4 References

Applicable references are:

Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT.
Course Registration System Supplementary Specification, WyIT400, V1.0, 1999, Wylie College, IT.

2. Architectural Representation

This document presents the architecture as a series of views; use case view, logical view, process view and deployment view. There is no separate implementation view described in this document. These are views on an underlying Unified Modeling Language (UML) model developed using Rational Rose. 3. Architectural Goals and Constraints

There are some key requirements and system constraints that have a significant bearing on the architecture. They are:

The existing legacy Course Catalog System at Wylie College must be accessed to retrieve all course information for the current semester. The C-Registration System must support the data formats and DBMS of the legacy Course Catalog System [2].
The existing legacy Finance System at Wylie College must be interfaced with to support billing of students. This interface is defined in the Course Billing Interface Specification [1].
All student, professor, and Registrar functionality must be available from both local campus PCs and remote PCs with internet dial up connections.
The C-Registration System must ensure complete protection of data from unauthorized access. All remote accesses are subject to user identification and password control.
The C-Registration System will be implemented as a client-server system. The client portion resides on PCs and the server portion must operate on the Wylie College UNIX Server. [3]
All performance and loading requirements, as stipulated in the Vision Document [3] and the Supplementary Specification [15], must be taken into consideration as the architecture is being developed.

4. Use-Case View

A description of the use-case view of the software architecture. The Use Case View is important input to the selection of the set of scenarios and/or use cases that are the focus of an iteration. It describes the set of scenarios and/or use cases that represent some significant, central functionality. It also describes the set of scenarios and/or use cases that have a substantial architectural coverage (that exercise many architectural elements) or that stress or illustrate a specific, delicate point of the architecture.

The C-Registration use cases are:

Login

Register for Courses

Maintain Student Information

Maintain Professor Information

Select Courses to Teach

Submit Grades

View Report Card

Close Registration.

These use cases are initiated by the student, professor, or the registrar actors. In addition, interaction with external actors; Course Catalog and Billing System occur.

4.1 Architecturally-Significant Use Cases

Caption Below in Content

Diagram Name: Architecturally Significant Use-Cases

> 4.1.1 Close Registration

Brief Description:This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. Course offerings must have a minimum of three students in them. The billing system is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering. The main actor of this use case is the Registrar. The Billing System is an actor involved within this use case.

> 4.1.2 Login

Brief Description:This use case describes how a user logs into the Course Registration System. The actors starting this use case are Student, Professor, and Registrar.

*> 4.1.3 Maintain Professor

Information*

Brief Description:This use case allows the registrar to maintain professor information in the registration system. This includes adding, modifying, and deleting professors from the system. The actor of this use case is the Registrar.

*> 4.1.4 Select Courses to

Teach*

Brief Description:This use case allows a professor to select the course offerings (date- and time- specific courses will be given) from the course catalog for the courses that he/she is eligible for and wishes to teach in the upcoming semester. The actor starting this use case is the Professor. The Course Catalog System is an actor within the use case.

> 4.1.5 Register for Courses

Brief Description:This use case allows a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester. The Billing System is notified of all registration updates. The Course Catalog provides a list of all the course offerings for the current semester. The main actor of this use case is the student. The Course Catalog System is an actor within the use case.

> 4.1.6 View Report Card

Brief Description:This use case allows a student to view his/her report card for the previously completed semester. The student is the actor of this use case.

> 4.1.7 Submit Grades

Brief Description:This use case allows a professor to submit student grades for one or more classes completed in the previous semester. The actor in this use case is the Professor.

*> 4.1.8 Maintain Student

Information*

Brief Description:This use case allows the registrar to maintain student information in the registration system. This includes adding, modifying, and deleting students from the system. The actor for this use case is the Registrar.

5. Logical View

The logical view of the course registration system is comprised of the 3 main packages: User Interface, Business Services, and Business Objects.

The User Interface Package contains classes for each of the forms that the actors use to communicate with the System. Boundary classes exist to support login, maintaining of schedules, maintaining of professor info, selecting courses, submitting grades, maintaining student info, closing registration, and viewing report cards.

The Business Services Package contains control classes for interfacing with the finance system, controlling student registration, and managing the student evaluation.

The Business Objects Package includes entity classes for the university artifacts (i.e. course offering, schedule) and boundary classes for the interface with the Course Catalog System.

5.1 Architecture Overview - Package and Subsystem Layering

Caption Above as Header

> 5.1.1 Application

layer

This application layer has all the boundary classes that represent the application screens that the user sees. This layer depends upon the Process Objects layer; that straddles the separation of the client from mid-tier.

> 5.1.2 Business Services

layer

The Business Services process layer has all the controller classes that represent the use case managers that drive the application behavior. This layer represents the client-to-mid-tier border. The Business Services layer depends upon the Process Objects layer; that straddles the separation of the client from mid-tier.

> 5.1.3 Middleware

layer

The Middleware layer supports access to Relational DBMS and OODBMS.

> 5.1.4 Base Reuse

The Base Reuse package includes classes to support list functions and patterns.

6. Process View

A description of the process view of the architecture. Describes the tasks (processes and threads) involved in the system’s execution, their interactions and configurations. Also describes the allocation of objects and classes to tasks.

The Process Model illustrates the course registration classes organized as executable processes. Processes exist to support student registration, professor functions, registration closing, and access to the external Finance System and Course Catalog System.

6.1 Processes

Caption Below in Content

Diagram Name: Processes

> 6.1.1 CourseCatalogSystemAccess

This process manages access to the legacy Course Catalog System. It can be shared by multiple users registering for courses. This allows for a cache of recently retrieved courses and offerings to improve performance.

The separate threads within the CourseCatalog process, CourseCache and OfferingCache are used to asynchronously retrieve items from the legacy system.

Analysis Mechanisms:

Legacy Interface

Requirements Traceability:

Design Constraints: The system shall integrate with existing legacy system (course catalog database).

> 6.1.2 CourseCatalog

The unabbridged catalog of all courses and course offerings offered by the university including those from previous semesters.

This class acts as an adapter (see the Gamma pattern). It works to makes sure the CourseCatalogSystem can be accessed through the ICourseCatalog interface to the subsystem.

> 6.1.3 CourseRegistrationProcess

There is one instance of this process for each student that is currently registering for courses.

> 6.1.4 RegistrationController

This supports the use case allowing a student to register for courses in the current semester. The student can also modify or delete course selections if changes are made within the add/drop period at the beginning of the semester.

Analysis Mechanisms:

Distribution

> 6.1.5 StudentApplication

Manages the student functionality, including user interface processing and coordination with the business processes.

There is one instance of this process for each student that is currently registering for courses.

> 6.1.6 MainStudentForm

Controls the interface of the Student application. Controls the family of forms that the Student uses.

> 6.1.7 BillingSystemAccess

This process communicates with the external Finance (Billing) System to initiate student billing.

> 6.1.8 CloseRegistrationProcess

The Close Registration process is initiated at the end of the registration time period. This process communicates with the process controlling access to the Finance System.

> 6.1.9 BillingSystem

The Finance System supports the submitting of student bills for the courses registered for by the student for the current semester.

Analysis Mechanisms:

Legacy Interface

> 6.1.10 CloseRegistrationController

The Close Registration Controller controls access to the Finance System.

Analysis Mechanisms:

Distribution

6.2 Process to Design Elements

Caption Below in Content

Diagram Name: Process to Design Elements

6.2.1 CourseCache**The Course Cache thread is used to asynchronously retrieve items from the legacy Course Catalog System.

*> 6.2.2 OfferingCache

The OfferingCashe thread is used to asynchronously retrieve items from the legacy Course Catalog System.* 6.2.3 Course

A class offered by the university.

Analysis Mechanisms:

Persistency

Legacy Interface

6.2.4 CourseOffering

A specific offering for a course, including days of the week and times.

Analysis Mechanisms:

Persistency
Legacy Interface

6.3 Process Model to Design Model Dependencies

Caption Below in Content

Diagram Name: Process Model to Design Model Dependencies

6.4 Processes to the Implementation

Caption Below in Content

Diagram Name: Processes to the Implementation

> 6.4.1 Remote

* The Remote interface serves to identify all remote objects. Any object that is a remote object must directly or indirectly implement this interface. Only those methods specified in a remote interface are available remotely.

* Implementation classes can implement any number of remote interfaces and can extend other remote implementation classes.

> 6.4.2 Runnable

* The Runnable interface should be implemented by any class whose instances are intended to be executed by a thread. The class must define a method of no arguments called run.

* This interface is designed to provide a common protocol for objects that wish to execute code while they are active. For example, Runnable is implemented by class Thread.

* Being active simply means that a thread has been started and has not yet been stopped.

> 6.4.3 Thread

* A thread is a thread of execution in a program. The Java Virtual Machine allows an application to have multiple threads of execution running concurrently.

* Every thread has a priority. Threads with higher priority are executed in preference to threads with lower priority. Each thread may or may not also be marked as a daemon. When code running in some thread creates a new Thread object, the new thread has its priority initially set equal to the priority of the creating thread, and is a daemon thread if and only if the creating thread is a daemon.

7. Deployment View

A description of the deployment view of the architecture Describes the various physical nodes for the most typical platform configurations. Also describes the allocation of tasks (from the Process View) to the physical nodes.

This section is organized by physical network configuration; each such configuration is illustrated by a deployment diagram, followed by a mapping of processes to each processor.

Described by Content Above

Diagram Name: Deployment View

7.1 External Desktop PC

Students register for courses using external desktop PCs which are connected to the College Server via internet dial up.

7.2 Desktop PC

Students register for courses via local Desktop PCs that are connected directly to the College Server via LAN. These local PCs are also used by professors to select course and submit student grades. The Registrar uses these local PCs to maintain student and professor information.

7.3 Registration Server

The Registration Server is the main campus UNIX Server. All faculty and students have access to the Server through the campus LAN.

7.4 Course Catalog

The Course Catalog System is a legacy system that contains the complete course catalog. Access to it is available via the College Server and LAN.

7.5 Billing System

The Billing System (also called the Finance System) is a legacy system that generates the student bills each semester.

8. Size and Performance

The chosen software architecture supports the key sizing and timing requirements, as stipulated in the Supplementary Specification [15]:

The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.
The system shall provide access to the legacy course catalog database with no more than a 10 second latency.
The system must be able to complete 80% of all transactions within 2 minutes.
The client portion shall require less than 20 MB disk space and 32 MB RAM.

The selected architecture supports the sizing and timing requirements through the implementation of a client-server architecture. The client portion is implemented on local campus PCs or remote dial up PCs. The components have been designed to ensure that minimal disk and memory requirements are needed on the PC client portion.

9. Quality

The software architecture supports the quality requirements, as stipulated in the Supplementary Specification [15]:

The desktop user-interface shall be Windows 95/98 compliant.
The user interface of the C-Registration System shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System.
Each feature of the C-Registration System shall have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronymns.
The C-Registration System shall be available 24 hours a day, 7 days a week. There shall be no more than 4% down time.
Mean Time Between Failures shall exceed 300 hours.
Upgrades to the PC client portion of C-Registration shall be downloadable from the UNIX Server over the internet. This feature enables students to have easy access to system upgrades.

Example: Submit Grades Use Case Specification

Course Registration System

Use-Case Specification

Submit Grades Use Case

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1 Basic Flow - Submit Grades

2.2 Alternative Flows
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

Submit Grades Use Case

- Brief Description

This use case allows a Professor to submit student grades for one or more classes completed in the previous semester.

The actor in this use case is the Professor.

2. Flow of Events

The use case begins when the Professor selects the “submit grades” activity from the Main Form.

2.1 Basic Flow - Submit Grades

The system displays a list of course offerings the Professor taught in the previous semester.

The Professor selects a course offering.

The system retrieves a list of all students who were registered for the course offering. The system also retrieves the grade information for each student in the offering.

The system displays each student and any grade that was previously assigned for the offering.

For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records the student’s grade for the course offering. If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Professor may also change the grade for a student by entering a new grade.

2.2 Alternative Flows

Issue: Error conditions for this use case have not been analyzed and need to be added here.

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions

4.1 Login

Before this use case begins the Professor has logged onto the system.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: Submit Grades Use Case Specification

Course Registration System

Use-Case Specification

Submit Grades Use Case

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble
15/Feb/1999	Version 1.0	Minor corrections based on review.	S. Gamble
19/Feb/1999	Version 2.0	Modify section on use case extends. Final cleanup. Add alternate flows. Resolve outstanding issues.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - Submit Grades

2.2    Alternative Flows

2.2.1    No Courses Taught

2.2.1    Course Cancelled
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

Submit Grades Use Case

- Brief Description

This use case allows a Professor to submit student grades for one or more classes completed in the previous semester.

The actor in this use case is the Professor.

2. Flow of Events

The use case begins when the Professor selects the “submit grades” activity from the Main Form.

2.1 Basic Flow - Submit Grades

The system displays a list of course offerings the Professor taught in the previous semester.

The Professor selects a course offering.

The system retrieves a list of all students who were registered for the course offering. The system also retrieves the grade information for each student in the offering.

The system displays each student and any grade that was previously assigned for the offering.

For each student on the list, the Professor enters a grade: A, B, C, D, F, or I. The system records the student’s grade for the course offering. If the Professor wishes to skip a particular student, the grade information can be left blank and filled in at a later time. The Professor may also change the grade for a student by entering a new grade.

2.2 Alternative Flows

2.2.1No Courses Taught

If in the basic flow, the Professor did not teach any course offerings in the previous semester the system displays an error message and the use case ends.

2.2.2Course Cancelled

If too many students withdrew from the course during the add/drop period and the course was cancelled after the beginning of the semester, the system displays an error message. If the Professor chooses to cancel the operation the use case terminates, otherwise is restarted at step 2 of the basic flow.

3. Special Requirements

There are no special requirements associated with this use case.

4. Preconditions

4.1 Login

Before this use case begins the Professor has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Supplementary Specification

Course Registration System Supplementary Specification

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Initial release - draft	S. Gamble

Table of Contents

Objectives
Scope
References
Functionality

4.1 System Error Logging
Usability

5.1    Windows Compliance

5.2    Design for Ease-of-Use

5.3    Online Help
Reliability

6.1 Availability

6.2 Mean Time Between Failures
Performance

7.1    Simultaneous Users

7.2    Database Access Response Time

7.3    Transaction Response Time
Supportability

8.1 New Releases Downloadable
Design Constraints

9.1    Course Catalog Legacy System

9.2    Billing System

9.3    Platform Requirements

9.4    Internet Browsers

9.5    Java Compatibility

Supplementary Specification

- Objectives

The purpose of this document is to define requirements of the Wylie course registration (C-Registration) system. This Supplementary Specification lists the requirements that are not readily captured in the use cases of the use-case model. The Supplementary Specifications and the use-case model together capture a complete set of requirements on the system.

2. Scope

This Supplementary Specification applies to the Wylie course registration system which will be developed by the Wylie College Information Systems (IT) department. The IT department will develop this client-server system to interface with the existing course catalog database.

The C-Registration System will enable students to register for courses on-line. The C-Registration System allows professors to select their teaching courses and to maintain student grades.

3. References

Applicable references are:

Course Registration System Business Case, WyIT388, DRAFT, 1998, Wylie College IT.

Course Billing Interface Specification, WC93332, 1985, Wylie College Press.

Course Catalog Database Specification, WC93422, 1985, Wylie College Press.

Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.

Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.

Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.

Course Registration System Use Case Spec - Close Registration, WyIT403, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - Login, WyIT401, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - Register for Courses, WyIT402, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - Submit Grades, WyIT409, Draft, 1998, Wylie College IT.

Course Registration System Use Case Spec - View Report Card, WyIT410, Draft, 1998, Wylie College IT.

4. Functionality

This section lists functional requirements that are common to more than one use case.

4.1 System Error Logging

All system errors shall be logged. Fatal system errors shall result in an orderly shutdown of the system.

The system error messages shall include a text description of the error, the operating system error code (if applicable), the module detecting the error condition, a data stamp, and a time stamp. All system errors shall be retained in the Error Log Database.

5. Usability

This section lists all of those requirements that relate to, or affect, the usability of the system.

5.1 Windows Compliance

The desktop user-interface shall be Windows 95/98 compliant.

5.2 Design for Ease-of-Use

The user interface of the C-Registration System shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System.

5.3 Online Help

Each feature of the C-Registration System shall have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronymns.

6. Reliability

This section lists all reliability requirements.

6.1 Availability

The availability requirements will be defined in the next iteration.

6.2 Mean Time Between Failures

The MTBF requirements will be defined in the next iteration.

7. Performance

The performance characteristics of the system are outlined in this section.

7.1 Simultaneous Users

The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.

7.2 Database Access Response Time

The system shall provide access to the legacy course catalog database with no more than a 10 second latency.

7.3 Transaction Response Time

The system must be able to complete 80% of all transactions within 2 minutes.

8. Supportability

This section defines any requirements that will enhance the supportability or maintainability of the system being built.

8.1 New Releases Downloadable

Upgrades to the PC client portion of C-Registration shall be downloadable from the UNIX Server over the internet. This feature enables students to have easy access to system upgrades.

9. Design Constraints

This section lists any design constraints on the system being built.

9.1 Course Catalog Legacy System

The system shall integrate with existing legacy system (course catalog database) which operates on the College DEC VAX Main Frame.

9.2 Billing System

The C-Registration System shall interface with the existing Course Billing System which operates on the College DEC VAX Main Frame.

9.3 Platform Requirements

The client portion of the C-Registration System shall operate on any personal computer with a 486 processor or greater. The client portion shall require less than 20 MB disk space and 32 MB RAM.

The server portion of the C-Registration System shall operate on the Wylie College UNIX server.

9.4 Internet Browsers

The web-based interface for the C-Registration System shall run in Netscape 4.0.4 and Internet Explorer 4.0 browsers.

9.5 Java Compatibility

The web-based interface shall be compatible with the Java 1.1 VM runtime environment.

Example: Supplementary Specification

Course Registration System Supplementary Specification

Version 1.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Initial release - draft	S. Gamble
19/Feb/1999	Version 1.0	Incorporate review comments. Add remote access requirement.	S. Gamble

Table of Contents

Introduction

: 1.1 Purpose: 1.2 Scope; 1.3 References

Functionality

2.1 System Error Logging

2.2 Remote Access
Usability

3.1    Windows Compliance

3.2    Design for Ease-of-Use

3.3    Online Help
Reliability

4.1 Availability

4.2 Mean Time Between Failures
Performance

5.1    Simultaneous Users

5.2    Database Access Response Time

5.3    Transaction Response Time
Supportability

6.1 New Releases Downloadable
Design Constraints

7.1    Course Catalog Legacy System

7.2    Billing System

7.3    Platform Requirements

7.4    Internet Browsers

7.5    Java Compatibility

**Supplementary Specification

Introduction

1.1 Purpose**

1.2 Scope

The C-Registration System will enable students to register for courses on-line. The C-Registration System allows professors to select their teaching courses and to maintain student grades.

1.3 References

Applicable references are:

Course Registration System System Business Case, WyIT388, DRAFT, 1998, Wylie College IT.
Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.
Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.

2. Functionality

This section lists functional requirements that are common to more than one use case.

2.1 System Error Logging

All system errors shall be logged. Fatal system errors shall result in an orderly shutdown of the system.

The system error messages shall include a text description of the error, the operating system error code (if applicable), the module detecting the error condition, a data stamp, and a time stamp. All system errors shall be retained in the Error Log Database.

2.2 Remote Access

All functionality shall be available remotely through an internet connection. This may require applications or controllers running on the remote computers.

3. Usability

This section lists all of those requirements that relate to, or affect, the usability of the system.

3.1 Windows Compliance

The desktop user-interface shall be Windows 95/98 compliant.

3.2 Design for Ease-of-Use

The user interface of the C-Registration System shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System.

3.3 Online Help

Each feature of the C-Registration System shall have built-in online help for the user. Online Help shall include step by step instructions on using the System. Online Help shall include definitions for terms and acronyms.

4. Reliability

This section lists all reliability requirements.

4.1 Availability

The C-Registration System shall be available 24 hours a day, 7 days a week. There shall be no more than 4% down time.

4.2 Mean Time Between Failures

Mean Time Between Failures shall exceed 300 hours.

5. Performance

The performance characteristics of the system are outlined in this section.

5.1 Simultaneous Users

The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.

5.2 Database Access Response Time

The system shall provide access to the legacy course catalog database with no more than a 10 second latency.

5.3 Transaction Response Time

The system must be able to complete 80% of all transactions within 2 minutes.

6. Supportability

This section defines any requirements that will enhance the supportability or maintainability of the system being built.

6.1 New Releases Downloadable

Upgrades to the PC client portion of C-Registration shall be downloadable from the UNIX Server over the internet. This feature enables students to have easy access to system upgrades.

7. Design Constraints

This section lists any design constraints on the system being built.

7.1 Course Catalog Legacy System

The system shall integrate with existing legacy system (course catalog database) which operates on the College DEC VAX Main Frame.

7.2 Billing System

The C-Registration System shall interface with the existing Course Billing System which operates on the College DEC VAX Main Frame.

7.3 Platform Requirements

The client portion of the C-Registration System shall operate on any personal computer with a 486 processor or greater. The client portion shall require less than 20 MB disk space and 32 MB RAM.

The server portion of the C-Registration System shall operate on the Wylie College UNIX server.

7.4 Internet Browsers

The web-based interface for the C-Registration System shall run in Netscape 4.0.4 and Internet Explorer 4.0 browsers.

7.5 Java Compatibility

The web-based interface shall be compatible with the Java 1.1 VM runtime environment.

Example: Test Evaluation Report

**Course Registration System

Test Evaluation Summary

for the

Architectural Prototype**

Version 1.0

Revision History

Date	Version	Description	Author
21/March/1999	1.0	Architectural prototype test evaluation	C. Smith

Table of Contents

Introduction
Test Results Summary
Test Coverage
Code Coverage
Defect Analysis
Suggested Actions
Diagrams

**> > Test Evaluation Summary

for the

Architectural Prototype**

- Introduction

Purpose

This Test Evaluation Report describes the results of the C-Registration Architectural Prototype tests in terms of test coverage (both requirements-based and code-based coverage) and defect analysis (i.e. defect density).

Scope

This Test Evaluation Report applies to the C-Registration Architectural Prototype. The tests conducted are described in the Test Plan for the Prototype [5]. This Evaluation Report is to be used for the following:

assess the acceptability and appropriateness of the performance behavior(s) of the prototype,

assess the acceptability of the tests, and

identify improvements to increase test coverage and / or test quality.

References

Applicable references are:

Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
Course Registration System Iteration Plan, Elaboration Iteration #E1 , WyIT420, V1.0, 1999, Wylie College IT.
Course Registration System Integration Build Plan for the Architectural Prototype, WyIT430, V1.0, 1999, Wylie College IT.
Course Registration System Test Plan for the Architectural Prototype, WyIT432, V1.0, 1999, Wylie College IT.
Test Results Summary

The test cases defined in the Test Suite for the Prototype were executed following the test strategy as defined in the Test Plan [5].

Test coverage (see Section 5.0 below) in terms of covering the use cases and test requirements defined in the Test Plan [5] was complete.

Code coverage is described in Section 6.0 and was not considered as a significant measure of success for the prototype.

Analysis of the defects (as shown in Section 7.0 below) indicates that there are significant performance problems accessing the legacy Course Catalog System. The performance and loading tests that involved read or write access to the Course Catalog System are well below the established targets. The Management Team will be assigning systems engineering resources to further evaluate these test results and to determine design alternatives.

Test Coverage

The tests to be performed on the prototype are defined in Section 5.1 of the Test Plan [5] along with their completion criteria. The test coverage results are as follows:

Ratio Test Cases Performed = 40/40 = 100%

Ratio Test Cases Successful = 30/40 = 80%

The area of tests with the highest failure rate was:

Performance tests involving access to the Course Catalog System
Load tests involving access to the Course Catalog System.

Further detail on test coverage is available using Rational RequisitePro and the Prototype Test Case matrix.

Code Coverage

Rational Visual PureCoverage was used to measure code coverage of the Prototype tests.

Ratio LOC executed = 12,874 / 48,916 (about 25%)

Approximately, 25% of the code was executed during the testing. It was determined that this coverage was adequate for the prototype tests as all interfaces were thoroughly exercised. Later iterations will require a significantly higher measure for code coverage.

Defect Analysis

This section summarizes the results of defect analysis that was generated using Rational ClearQuest. Section 8 recommends actions to address the findings of the defect analysis.

Defect Density

Data on defect density has been generated using data extracted from ClearQuest reports. Section 9 of this document includes charts that illustrate:

Defects by Severity Level (critical, high, medium, low)

Defect Source (the component in which the problem or fault resides)

Defect Status (logged, assigned, fixed, tested, closed).

The Defects by Severity Level chart shows that 4 critical and 4 high priority defects were logged. Detailed analysis of the defect logs has shown that the critical and high priority defects are all associated with the performance and loading problems accessing the legacy Course Catalog System. (Note: Chart not included.)

The Defect Source Chart shows an unusually high percentage of defects reside in the System Interface components.

The Defect Status chart shows that many defects are in the logged state and not assigned yet for analysis.

Defect Trend

Defect trends (i.e. defect counts over time) was not measured for the Architectural Prototype tests.

Defect Aging

Tracking of defect age is not required for the Prototype. The current plan is to start tracking the age of open defects at the beginning of the Construction Phase. ClearQuest will be used to generate the Defect Aging Charts.

Suggested Actions

The recommended actions are as follows:

Assign additional systems engineering resources to further evaluate the performance and loading problems associated with access to the legacy Course Catalog System. Design alternatives will be reviewed by the Project Team prior to implementation of any design solutions.
Assign engineering resources to resolve outstanding open defects on the Prototype.
Delay start of next iteration pending resolution of Critical and High Defects.
Design additional tests to further test loads and access times for the Course Catalog System. Try using Rational Visual Quantify to identify and analyze the performance bottlenecks.
It is recommended that future iterations include inspections of the all design or code involving external interfaces. These inspections should reduce the number of problems found during Test.

7. Diagrams

Example: Test Plan

Course Registration System

Test Plan for the Architectural Prototype

Version 1.0

Revision History


Date	Version	Description	Author
7/March/1999	1.0	Initial Release - Prototype Test Plan	K. Stone

Table of Contents

Objectives
Requirements for Test
Test Strategy
Resources
Project Milestones
Deliverables
Project Tasks

**Test Plan

for the

Architectural Prototype**

1. Objectives

1.1 Purpose

This document describes the plan for testing the architectural prototype of the C-Registration System. This Test Plan document supports the following objectives:

Identify existing project information and the software that should be tested.
List the recommended test requirements (high level).
Recommend and describe the testing strategies to be employed.
Identify the required resources and provide an estimate of the test efforts.
List the deliverable elements of the test activities.

1.2 Scope

This Test Plan describes the integration and system tests that will be conducted on the architectural prototype following integration of the subsystems and components identified in the Integration Build Plan for the Prototype [16].

It is assumed that unit testing already provided thorough black box testing, extensive coverage of source code, and testing of all module interfaces.

The purpose of assembling the architectural prototype was to test feasibility and performance of the selected architecture. It is critical that all system and subsystem interfaces be tested as well as system performance at this early stage. Testing of system functionality and features will not be conducted on the prototype.

The interfaces between the following subsystems will be tested:

Course Registration
Finance System
Course Catalog.

The external interfaces to the following devices will be tested:

Local PCs
Remote PCs.

The most critical performance measures to test are:

Response time for remote login to the course registration system.
Response time to access the Finance System.
Response time to access the Course Catalog Subsystem.
Student response time when system loaded with 200 logged in students.
Student response time when 50 simultaneous accesses to the Course Catalog database.

1.3 References

Applicable references are:

Course Billing Interface Specification, WC93332, 1985, Wylie College Press.
Course Catalog Database Specification, WC93422, 1985, Wylie College Press.
Course Registration System Vision Document, WyIT387, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Close Registration, WyIT403, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Login, WyIT401, V2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Professor Info, WyIT407, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Register for Courses, WyIT402, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Select Courses to Teach, WyIT405, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Maintain Student Info, WyIT408, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - Submit Grades, WyIT409, Version 2.0, 1999, Wylie College IT.
Course Registration System Use Case Spec - View Report Card, WyIT410, Version 2.0, 1999, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V1.0, 1999, Wylie College IT.
Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0, 1999, Wylie College IT.
Course Registration System Software Architecture Document, WyIT431, V1.0, 1999, Wylie College IT.
Course Registration System Integration Build Plan for the Architectural Prototype, WyIT430, V1.0, 1999, Wylie College IT.
Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1999, Wylie College IT.

2. Requirements for Test

The listing below identifies those items (use cases, functional requirements, non-functional requirements) that have been identified as targets for testing. This list represents what will be tested.

(Note: Future release of this Test Plan may use Rational RequisitePro for linking directly to the requirements in the Use Case Documents and Supplementary Specification.)

2.1 Data and Database Integrity Testing

Verify access to Course Catalog Database.

Verify simultaneous record read accesses.

Verify lockout during Course Catalog updates.

Verify correct retrieval of update of database data.

2.2. Function Testing

Vision Document, Section 12.2: “The system shall interface with the existing Course Catalog Database System. C-Registration shall support the data format as defined in [2].”

Vision Document, Section 12.2: “The system shall interface with the existing Billing System and shall support the data format as defined in [1].”

Vision Document, Section 12.2: “The server component of the system shall operate on the College Campus Server and shall run under the UNIX Operating System.”

Supplementary Specification, Section 9.3: “The server component of the system shall operate on the Wylie College UNIX Server.”

Vision Document, Section 12.2: “The client component of the system shall operate on any personal computer with a 486 Microprocessor or better.”

Supplementary Specification, Section 9.3: “The client component of the system shall operate on any personal computer with a 486 Microprocessor or greater.”

Supplementary Specification, Section 9.1: “The system shall integrate with existing legacy system (course catalog database) which operates on the College DEC VAX Main Frame.”

Supplementary Specification, Section 9.2: “The system shall integrate with the existing Course Billing System which operates on the College DEC VAX Main Frame.”

2.3 Business Cycle Testing

None.

2.4 User Interface Testing

Verify ease of navigation through a sample set of screens.

Verify sample screens conform to GUI standards.

Vision Document Section 10: “The System shall be easy-to-use and shall be appropriate for the target market of computer-literate students and professors.”

Vision Document, Section 12.1: “The desktop user-interface shall be Windows 95/98 compliant.”

Supplementary Specification, Section 5.1: “The desktop user-interface shall be Windows 95/98 compliant.”

Supplementary Specification, Section 5.2: “The user interface of the C-Registration System shall be designed for ease-of-use and shall be appropriate for a computer-literate user community with no additional training on the System.”

2.5 Performance Testing

Verify response time to access external Finance system.

Verify response time to access external Course Catalog subsystem.

Verify response time for remote login.

Verify response time for remote submittal of course registration.

Vision Document, Section 12.3: “The system shall provide access to the legacy Course Catalog Database with no more than a 10 second latency.”

Supplementary Specification, Section 7.2: “The system shall provide access to the legacy Course Catalog Database with no more than a 10 second latency.”

2.6 Load Testing

Verify system response when loaded with 200 logged on students.

Verify system response when 50 simultaneous student accesses to the Course Catalog.

2.7 Stress Testing

None.

2.8 Volume Testing

None.

2.9 Security and Access Control Testing

Verify Logon from a local PC.

Verify Logon from a remote PC.

Verify Logon security through user name and password mechanisms.

2.10 Failover / Recovery Testing

None.

2.11 Configuration Testing

Vision Document, Section 12.2: “The client component of the system shall run on Windows 95, Windows 98, and Microsoft Windows NT.”

Supplementary Specification, Section 9.4: “The web-based interface for the C-Registration System shall run in Netscape 4.04 and Internet Explorer 4.0 browsers.

Supplementary Specification, Section 9.5: “The web-based interface shall be compatible with the Java 1.1 VM runtime environment.

2.12 Installation Testing

None.

3. Test Strategy

The Test Strategy presents the recommended approach to the testing of the software applications. The previous section on Test Requirements described what will be tested; this describes how it will be tested.

The main considerations for the test strategy are the techniques to be used and the criterion for knowing when the testing is completed.

In addition to the considerations provided for each test below, testing should only be executed using known, controlled databases, in secured environments.

The following test strategy is generic in nature and is meant to apply to the requirements listed in Section 4 of this document.

3.1 Testing Types

3.1.1 Data and Database Integrity Testing

The databases and the database processes should be tested as separate systems. These systems should be tested without the applications (as the interface to the data). Additional research into the DBMS needs to be performed to identify the tools / techniques that may exist to support the testing identified below.


Test Objective:	Ensure Database access methods and processes function properly and without data corruption.
Technique:	- Invoke each database access method and process, seeding each with valid and invalid data (or requests for data). - Inspect the database to ensure the data has been populated as intended, all database events occurred properly, or review the returned data to ensure that the correct data was retrieved (for the correct reasons)
Completion Criteria:	All database access methods and processes function as designed and without any data corruption.
Special Considerations:	- Testing may require a DBMS development environment or drivers to enter or modify data directly in the databases. - Processes should be invoked manually. - Small or minimally sized databases (limited number of records) should be used to increase the visibility of any non-acceptable events.

3.1.2 Function Testing

Testing of the application should focus on any target requirements that can be traced directly to use cases (or business functions), and business rules. The goals of these tests are to verify proper data acceptance, processing, and retrieval, and the appropriate implementation of the business rules. This type of testing is based upon black box techniques, that is, verifying the application (and its internal processes) by interacting with the application via the GUI and analyzing the output (results). Identified below is an outline of the testing recommended for each application:


Test Objective:	Ensure proper application navigation, data entry, processing, and retrieval.
Technique:	- Execute each use case, use case flow, or function, using valid and invalid data, to verify the following: - The expected results occur when valid data is used. - The appropriate error / warning messages are displayed when invalid data is used. - Each business rule is properly applied.
Completion Criteria:	- All planned tests have been executed. - All identified defects have been addressed.
Special Considerations:	- Access to the Wylie College UNIX Server and the existing Course Catalog System and Billing System is required to run some of the identified System Tests on the Prototype.

3.1.3 Business Cycle Testing

This section is not applicable to test of the architectural prototype.

3.1.4 User Interface Testing

User Interface testing verifies a user’s interaction with the software. The goal of UI Testing is to ensure that the User Interface provides the user with the appropriate access and navigation through the functions of the applications. In addition, UI Testing ensures that the objects within the UI function as expected and conform to corporate or industry standards.


Test Objective:	Verify the following: - Navigation through the application properly reflects business functions and requirements, including window to window, field to field, and use of access methods (tab keys, mouse movements, accelerator keys) - Window objects and characteristics, such as menus, size, position, state, and focus conform to standards.
Technique:	- Create / modify tests for each window to verify proper navigation and object states for each application window and objects.
Completion Criteria:	Each window successfully verified to remain consistent with benchmark version or within acceptable standard
Special Considerations:	- Not all properties for custom and third party objects can be accessed.

3.1.5 Performance Profiling

Performance testing measures response times, transaction rates, and other time sensitive requirements. The goal of Performance testing is to verify and validate the performance requirements have been achieved. Performance testing is usually executed several times, each using a different “background load” on the system. The initial test should be performed with a “nominal” load, similar to the normal load experienced (or anticipated) on the target system. A second performance test is run using a peak load.

Additionally, Performance tests can be used to profile and tune a system’s performance as a function of conditions such as workload or hardware configurations.

NOTE: Transactions below refer to “logical business transactions.” These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract.


Test Objective:	Validate System Response time for designated transactions or business functions under a the following two conditions: - normal anticipated volume - anticipated worse case volume
Technique:	- Use Test Scripts developed for Business Model Testing (System Testing). - Modify data files (to increase the number of transactions) or modify scripts to increase the number of iterations each transaction occurs. - Scripts should be run on one machine (best case to benchmark single user, single transaction) and be repeated with multiple clients (virtual or actual, see special considerations below).
Completion Criteria:	- Single Transaction / single user: Successful completion of the test scripts without any failures and within the expected / required time allocation (per transaction) - Multiple transactions / multiple users: Successful completion of the test scripts without any failures and within acceptable time allocation.
Special considerations:	- Comprehensive performance testing includes having a “background” load on the server. There are several methods that can be used to perform this, including: - “Drive transactions” directly to the server, usually in the form of SQL calls. - Create “virtual” user load to simulate many (usually several hundred) clients. Remote Terminal Emulation tools are used to accomplish this load. This technique can also be used to load the network with “traffic.” - Use multiple physical clients, each running test scripts to place a load on the system. - Performance testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. - The databases used for Performance testing should be either actual size, or scaled equally.

3.1.6 Load Testing

Load testing measures subjects the system-under-test to varying workloads to evaluate the system’s ability to continue to function properly under these different workloads. The goal of load testing is to determine and ensure that the system functions properly beyond the expected maximum workload. Additionally, load testing evaluates the performance characteristics (response times, transaction rates, and other time sensitive issues).

NOTE: Transactions below refer to “logical business transactions.” These transactions are defined as specific functions that an end user of the system is expected to perform using the application, such as add or modify a given contract.


Test Objective:	Verify System Response time for designated transactions or business cases under varying workload conditions.
Technique:	- Use tests developed for Business Cycle Testing. - Modify data files (to increase the number of transactions) or the tests to increase the number of times each transaction occurs.
Completion Criteria:	- Multiple transactions / multiple users: Successful completion of the tests without any failures and within acceptable time allocation.
Special Considerations:	- Load testing should be performed on a dedicated machine or at a dedicated time. This permits full control and accurate measurement. - The databases used for load testing should be either actual size, or scaled equally.

3.1.7 Stress Testing

This section is not applicable to test of the architectural prototype.

3.1.8 Volume Testing

This section is not applicable to test of the architectural prototype.

3.1.9 Security and Access Control Testing

Security and Access Control Testing focus on two key areas of security:

Application security, including access to the Data or Business Functions, and

System Security, including logging into / remote access to the system.

Application security ensures that, based upon the desired security, users are restricted to specific functions or are limited in the data that is available to them. For example, everyone may be permitted to enter data and create new accounts, but only managers can delete them. If there is security at the data level, testing ensures that user “type” one can see all customer information, including financial data, however, user two only sees the demographic data for the same client.

System security ensures that only those users granted access to the system are capable of accessing the applications and only through the appropriate gateways.


Test Objective:	Function / Data Security: Verify that user can access only those functions / data for which their user type is provided permissions. System Security: Verify that only those users with access to the system and application(s) are permitted to access them.
Technique:	- Function / Data Security: Identify and list each user type and the functions / data each type has permissions for. - Create tests for each user type and verify permission by creating transactions specific to each user type. - Modify user type and re-run tests for same users. In each case verify those additional functions / data are correctly available or denied. - System Access (see special considerations below)
Completion Criteria:	For each known user type the appropriate function / data are available and all transactions function as expected and run in prior Application Function tests
Special Considerations:	- Access to the system must be reviewed / discussed with the appropriate network or systems administrator. This testing may not be required as it maybe a function of network or systems administration.

3.1.10 Failover and Recovery Testing

This section is not applicable to test of the architectural prototype.

3.1.11 Configuration Testing

Configuration testing verifies operation of the software on different software and hardware configurations. In most production environments, the particular hardware specifications for the client workstations, network connections and database servers vary. Client workstations may have different software loaded (e.g. applications, drivers, etc.) and at any one time many different combinations may be active and using different resources.


Test Objective:	Validate and verify that the client Applications function properly on the prescribed client workstations.
Technique:	- Use Integration and System Test scripts - Open / close various PC applications, either as part of the test or prior to the start of the test. - Execute selected transactions to simulate user activities into and out of various PC applications. - Repeat the above process, minimizing the available conventional memory on the client.
Completion Criteria:	For each combination of the Prototype and PC application, transactions are successfully completed without failure.
pecial Considerations:	- What PC Applications are available, accessible on the clients? - What applications are typically used? - What data are the applications running (i.e. large spreadsheet opened in Excel, 100 page document in Word). - The entire systems, network servers, databases, etc. should also be documented as part of this test.

3.1.12 Installation Testing

This section is not applicable to test of the C-Registration architectural prototype.

3.2 Tools

The following tools will be employed for testing of the architectural prototype:


	Tool	Version
Test Management	Rational RequisitePro	TBD
Test Design	RationalRose	TBD
Defect Tracking	RationalClearQuest	TBD
Functional Testing	Rational Robot	TBD
Performance Testing	RationalVisual Quantify	TBD
Test Coverage Monitor or Profiler	RationalVisual PureCoverage	TBD
Other Test Tools	RationalPurify RationalTestFactory	TBD
Project Management	Microsoft Project MicrosoftWord MicrosoftExcel	TBD
DBMS tools	TBD	TBD

4. Resources

This section presents the recommended resources for testing the C-Registration architectural prototype, their main responsibilities, and their knowledge or skill set.

4.1 Roles

This table shows the staffing assumptions for the test of the Prototype.


Human Resources
Role	Minimum Resources Recommended (number of workers allocated full-time)	Specific Responsibilities/Comments
Test Manager	1 - Kerry Stone	Provides management oversight Responsibilities: - Provide technical direction - Acquire appropriate resources - Management reporting
Test Designer	Margaret Cox Carol Smith	Identifies, prioritizes, and implements test cases Responsibilities: - Generate test plan - Generate Test Suite - Evaluate effectiveness of test effort
System Tester	Carol Smith	Executes the tests Responsibilities: - Execute tests - Log results - Recover from errors - Document defects
Test System Administrator	Simon Jones	Ensures test environment and assets are managed and maintained. Responsibilities: - Administer test management system - Install / manage worker access to test systems
Database Administration / Database Manager	Margaret Cox	Ensures test data (database) environment and assets are managed and maintained. Responsibilities: - Administer test data (database)
Designer	Margaret Cox	Identifies and defines the operations, attributes, and associations of the test classes Responsibilities: - Identifies and defines the test class(es) - Identifies and defines the test packages
Implementer	Margaret Cox	Implements and unit tests the test classes and test packages Responsibilities: - Creates the test classes and packages implemented in the Test Suite.

4.2 System

The following table sets forth the system resources for the testing the C-Registration prototype.


System Resources
Resource	Name / Type / Serial No.
Wylie College Server	Serial No: X179773562b
Course Catalog Database	Version Id: CCDB-080885
Billing System	Version Id: BSSS-88335
Client Test PC’s
3 Remote PCs (with internet access)	Serial No: A8339223 Serial No: B9334022 Serial No: B9332544
3 Local PCs (connected via LAN)	Serial No: R3322411 (Registrar’s) Serial No: A8832234 (IT Lab) Serial No: W4592233 (IT Lab)
Test Repository
Wylie College Server	Serial No: X179773562b
Test Development PC’s - 6	Serial No: A8888222 Serial No: R3322435 Serial No: I88323423 Serial No: B0980988 Serial No: R3333223 Serial No: Y7289732

5. Project Milestones

Testing of the C-Registration Architectural Prototype incorporates test activities for each of the test efforts identified in the previous sections. Separate project milestones are identified to communicate project status and accomplishments.

Refer to the Software Development Plan [13] and the E1 Iteration Plan [14] for the overall phase or master project schedule.


Milestone Task	Effort (pd)	Start Date	End Date
Prototype Test Planning	2	March 12	March 15
Prototype Test Design	3	March 15	March 18
Prototype Test Development	4	March 19	March 23
Prototype Test Execution	3	March 24	March 26
Prototype Test Evaluation	1	March 29	March 29

6. Deliverables

The deliverables of the test activities as defined in this Test Plan are outlined in the table below.


Deliverable	Owner	Review / Distribution	Due Date
Test Plan	K. Stone	Senior Project Mgmt Team	March 15
Test Environment	S. Jones	-	March 18
Test Suite	C. Smith and M. Cox	Internal Peer Review	March 23
Test Data Sets	M. Cox	Internal Peer Review	March 23
Test Scripts	M. Cox	-	March 23
Test Stubs, Drivers	M. Cox	-	March 23
Test Defect Reports	C. Smith	Senior Project Mgmt Team	March 26
Test Results	C. Smith	-	March 26
Test Evaluation Report	C. Smith	Senior Project Mgmt Team	March 29

6.1 TestSuite

The Test Suite will define all the test cases and the test scripts which are associated with each test case.

6.2 Test Logs

It is planned to use RequisitePro to identify the test cases and to track the status of each test case. The test results will be summarized in RequisitePro as untested, passed, conditional pass, or failed. In summary, RequisitePro will be setup to support the following attributes for each test case, as defined in the Requirements Attributes Guidelines [17]:

Test status

Build Number

Tested By

Date Tested

Test Notes

It will be the responsibility of the System Tester to update the test status in RequisitePro.

Test results will be retained under Configuration Control.

6.3 Defect Reports

Rational ClearQuest will be used for logging and tracking individual defects.

7. ProjectTasks

Below are the test related tasks for testing the C-Registration Architectural Prototype:

| Create Test Evaluation Report |

Use Case Specifications - E1

This page provides links to all the Use Case Specification documents produced and baselined during the Elaboration E1 Iteration.

Close Registration
Login
Maintain Professor Information
Maintain Student Information
Register for Courses
Submit Grades
Select Courses to Teach
View Report Cards

Use Case Specifications - Inception

This page provides links to all the Use Case Specification documents produced and baselined during the Preliminary Inception Iteration.

Close Registration
Login
Maintain Professor Information
Maintain Student Information
Register for Courses
Submit Grades
Select Courses to Teach
View Report Card

Example: View Report Card Use Case Specification

Course Registration System

Use-Case Specification

View Report Card Use Case

Version: Draft

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - View Report Card

2.2    Alternative Flows

2.2.1    No Grade Information Available
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

View Report Card Use Case

- Brief Description

This use case allows a Student to view his/her report card for the previously completed semester.

The Student is the actor of this use case.

2. Flow of Events

The use case begins when the Student selects the “view report card” activity from the Main Form

2.1 Basic Flow - View Report Card

The system retrieves the grade information for each of the courses the Student completed during the previous semester.

The system prepares, formats, and displays the grade information.

When Student is finished viewing the grade information the Student selects “close.”

2.2 Alternative Flows

2.2.1No Grade Information Available

If in the basic flow the system cannot find any grade information from the previous semester for the Student, a message is displayed. Once the Student acknowledges the message the use case terminates.

Issue: Should the student be able to access grades for previous completed semesters?

3. Special Requirements

Special requirements will be determined during the next iteration.

4. Preconditions

4.1 Login

Before this use case begins the Student has logged onto the system.

5. Postconditions

Postconditions will be determined during the next iteration.

6. Extension Points

Extension points of the business use case will be identified during the Elaboration Phase.

Example: View Report Card Use Case Specification

Course Registration System

Use-Case Specification

View Report Card Use Case

Version 2.0

Revision History

Date	Version	Description	Author
21/Dec/98	Draft	Draft Version	S. Gamble
15/Feb/1999	Version 1.0	Minor corrections based on review.	S. Gamble
19/Feb/1999	Version 2.0	Modify section on use case extends. Final cleanup. Resolve outstanding issues. Add Alternate Flows.	S. Gamble

Table of Contents

Brief Description
Flow of Events

2.1    Basic Flow - View Report Card

2.2    Alternative Flows

2.2.1    No Grade Information Available
Special Requirements
Preconditions

4.1 Login
Postconditions
Extension Points

View Report Card Use Case

- Brief Description

This use case allows a Student to view his/her report card for the previously completed semester.

The Student is the actor of this use case.

2. Flow of Events

The use case begins when the Student selects the “view report card” activity from the Main Form

2.1 Basic Flow - View Report Card

The system retrieves the grade information for each of the courses the Student completed during the previous semester.

The system prepares, formats, and displays the grade information.

When Student is finished viewing the grade information the Student selects “close.”

2.2 Alternative Flows

2.2.1No Grade Information Available

If in the basic flow the system cannot find any grade information from the previous semester for the Student, a message is displayed. Once the Student acknowledges the message the use case terminates.

3. Special Requirements

There are no special requirements associated with this use case.

**4.**Preconditions

4.1 Login

Before this use case begins the Student has logged onto the system.

5. Postconditions

There are no postconditions associated with this use case.

6. Extension Points

There are no extension points associated with this use case.

Example: Wylie College Software Development Process

The Wylie College Software Development Process is a configuration of the RUP tailored for a fictional organization, Wylie College. This example is available on the developerWorks®: Rational® Web site. It includes an instantiation of this process for a specific project, the Course Registration System.

Many of the examples from the Course Registration System project are included in the Classic RUP process configuration, associated to the related artifact. To see how these examples all fit together in terms of an organizational and project-specific process, download the complete example from the RUP section of the developerWorks®: Rational® Web site.

Example: Analysis Model

In order to view this example Rose Model, you must have Rational Rose installed.

A web-viewable version of this model is available in the downloadable Wylie College example.

Example: Collegiate Sports Paging System

The example artifacts presented here are based on a fictional project to develop a system to page subscribers when specified collegiate sporting events take place.

Additional examples of artifacts may be posted in the future in the RUP section of the developerWorks®: Rational® Web site.

Information Sets

[Environment Set](#Environment Set)
[Project Management Set](#Management Set)
[Requirements Set](#Requirements Set)
[Analysis & Design Set](#Design Set)
[Implementation Set](#Implementation Set)
[Test Set](#Test Set)
[Deployment Set](#Deployment Set)

**To see examples for each phase: (**I = Inception, E = Elaboration, C = Construction, T = Transition) Click below on: Preliminary Artifact, or Baselined Artifact. For the artifact description, click below on: ,, or


I	E	C	T		Environment Set
Baselined Artifact				Artifact Description	Development Case
I	E	C	T		Project Management Set
Baselined Artifact	Baselined Artifact	Baselined Artifact		Artifact Description	Risk List
	Baselined Artifact			Artifact Description	Software Development Plan
Baselined Artifact	Baselined Artifact	Baselined Artifact	Baselined Artifact	Artifact Description	Iteration Plan
	Baselined Artifact			Artifact Description	Iteration Assessment
		Baselined Artifact		Artifact Description	Status Assessment
I	E	C	T		Requirements Set
Baselined Artifact				Artifact Description	Requirements Management Plan
Baselined Artifact				Artifact Description	Vision
Baselined Artifact					Use Case Model Survey
				Artifact Description	Use Cases
Preliminary Artifact	Baselined Artifact				- Approve Story
Preliminary Artifact	Baselined Artifact				- Edit Profile
Preliminary Artifact	Baselined Artifact				- Pay Fee with Credit Card
Preliminary Artifact	Baselined Artifact				- Print Advertiser Reports
Preliminary Artifact	Baselined Artifact				- Post Advertising Content
Preliminary Artifact	Baselined Artifact				- Provide Feedback
Preliminary Artifact	Baselined Artifact				- Read Content on Web site
Preliminary Artifact	Baselined Artifact				- Send Content
Preliminary Artifact	Baselined Artifact				- Send Page
Preliminary Artifact	Baselined Artifact				- Subscribe
Baselined Artifact	Baselined Artifact			Artifact Description	Glossary
Preliminary Artifact	Baselined Artifact			Artifact Description	Supplementary Specifications
Baselined Artifact					Creative Design Brief
Baselined Artifact					Design Comparatives
Baselined Artifact					Navigation Map
I	E	C	T		Analysis & Design Set
	Baselined Artifact			Artifact Description	Software Architecture Document
	Baselined Artifact				Rational Rose Model
					Artifact Description Analysis Model
					Artifact Description Design Model
I	E	C	T		Implementation Set
	Baselined Artifact			Artifact Description	Integration Build Plan
					Test Set
	Baselined Artifact			Artifact Description	Test Plan
	Baselined Artifact			Artifact Description	Test Evaluation Summary
I	E	C	T		Deployment Set
			Baselined Artifact	Artifact Description	Release Notes

Example: Design Model

In order to view this example Rose Model, you must have Rational Rose installed.

A web-viewable version of this model is available in the downloadable Wylie College example.

Rational Unified Process: Examples

RUP can be configured to include examples for a variety of RUP artifacts. Examples may be stand-alone, or part of a set (such as a collection for an example project).

The examples included in this RUP configuration are listed below:

Pearl Circle Online Auction
Collegiate Sports Paging System
Wylie College Software Development Process
Requirements
Architecture
Design
- CSPS Navigation Map - Inception Phase
- Analysis Model
Implementation
- CREG Integration Build Plan - Elaboration Phase
- CREG Integraton Build Plan - Construction Phase
- CSPS Integration Build Plan - Elaboration Phase
Assessment
- Test
  - CREG Test Plan - Elaboration Phase
  - CREG Test Plan - Construction Phase
  - CSPS Test Plan - Elaboration Phase
- CREG Iteration Assessment - Construction Phase
- CSPS Iteration Assessment - Elaboration Phase
- CREG Status Assessment - Construction Phase
- CSPS Status Assessment - Construction Phase
- CREG Test Evaluation Summary - Elaboration Phase
- CREG Test Evaluation Summary - Construction Phase
- CSPS Test Evaluation Summary - Elaboration Phase
Production
- CREG Release Notes - Transition Phase
- CSPS Release Notes - Transition Phase
Management

(If no examples are listed on this page, then they can be installed by using RUP Builder to load one or more Plugins that contain examples).

Course Registration System

T1 & T2 Iteration Plan

Version 1.0

Revision History

Date	Version	Description	Author
May 15/1999	1.0	Initial Plan for 2 iterations of the Transition Phase: T1 and T2.	Rick Bell

Table of Contents

1.3 Definitions, Acronyms and Abbreviations

5. Evaluation Criteria

Iteration Plan

1.Introduction

1.1Purpose

This Iteration Plan describes the detailed plans for the first two iterations of the Transition Phase.

The first iteration (T1) of the Transition Phase packages and installs the R1.0 version of the C-Registration System. This release contains all key functionality for course registration with the exception of submission and viewing of student marks.

The second iteration (T2) of the Transition Phase packages and installs the R2.0 version. This release contains all key functionality as defined in the Vision Document [1].

1.2Scope

This Iteration Plan applies to the C-Registration System project being developed by Wylie College Information Systems for Wylie College. This document will be used by the Project Manager, Deployment Manager, and by the project team.

1.3Definitions, Acronyms and Abbreviations

See the Glossary [3].

1.4References

Applicable references are:

Course Registration System Vision Document, WyIT387, V1.0, Wylie College IT.
Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V2.0, 1999, Wylie College IT.
Course Registration System Schedule for the Transition Phase, V1.0, Wylie College IT.

1.5Overview

This document provides the detailed schedule for this iteration including all milestones. It also describes the required resources (staffing, financial, and equipment), expected status of use cases, and evaluation criteria for completion of the iteration.

2.Plan

The first iteration (T1) will commence when the R1.0 software baseline is available from the development team. The software will be packaged and the distribution media created. The Transition team will create the User Manual and will install the software on the Wylie College Server and selected client PCs on campus. The Transition Team is responsible for conducting the User Acceptance Tests and obtaining signoff from the Wylie College representative.

In addition, the client software will be setup on an FTP site so that any client P.C. with a valid ID and Internet access may download the client portion to their P.C.

The transition team provides training and support to the Wylie College Registrar and administration staff following installation of the software.

The second iteration (T2) will commence when the R2.0 software baseline is available from the development team. The activities for preparing the R2.0 Release are the same as defined above for R1.0, with the exception that R2.0 must convert and import the R1.0 data.

The primary use cases that form Release 1.0 are:

Logon
Close Registration
Register for Courses
Interface to Course Catalog Database
Interface to Finance System
Maintain Student Information
Maintain Professor Information

The primary use cases that form Release 2.0 are:

Submit Student Grades
View Grades
Select Courses to Teach

Iteration Activities

The following table illustrates the high level activities for T1 and T2 iterations with their planned start and end dates.

T1 Iteration - Release 1.0

Activity	Start Date	End Date
Produce Software	May 27, 1999	June 1, 1999
Package & Distribute Release	June 2, 1999	June 7, 1999
Acceptance Test	June 10, 1999	June 11, 1999

T1 Iteration - Release 2.0

Activity	Start Date	End Date
Produce Software	June 30, 1999	July 2, 1999
Package & Distribute Release	July 5, 1999	July 8, 1999
Migrate R1.0 Data	June 30, 1999	July 20, 1999
Acceptance Test	July 13, 1999	July 14, 1999

Iteration Schedule

The detailed schedule showing all tasks and the assigned responsibilities is contained in the following Microsoft Project schedule [5]:

Task Name	Start	Finish
Milestones	Thu 5/27/99	Wed 7/14/99
Start T1 Iteration	Thu 5/27/99	Thu 5/27/99
Release R1.0 Acceptance	Fri 6/11/99	Fri 6/11/99
Start T2 Iteration	Wed 6/30/99	Wed 6/30/99
Release 2.0 Acceptance	Wed 7/14/99	Wed 7/14/99

Transition Phase	Thu 5/27/99	Tue 7/20/99
Iteration T1 - Release 1	Thu 5/27/99	Wed 6/16/99
Deployment	Thu 5/27/99	Wed 6/16/99
Produce Software	Thu 5/27/99	Tue 6/1/99
Installation scripts	Thu 5/27/99	Fri 5/28/99
User documentation	Thu 5/27/99	Tue 6/1/99
Configuration data	Thu 5/27/99	Fri 5/28/99
Package Software	Wed 6/2/99	Thu 6/3/99
Distribute Software	Fri 6/4/99	Mon 6/7/99
Install Software	Tue 6/8/99	Wed 6/9/99
Provide Help and Assistance to the Users	Thu 6/10/99	Wed 6/16/99
Acceptance Testing	Thu 6/10/99	Fri 6/11/99
Iteration T2 - Release 2	Wed 6/30/99	Tue 7/20/99
Deployment	Wed 6/30/99	Tue 7/20/99
Produce Software	Wed 6/30/99	Fri 7/2/99
Installation scripts	Wed 6/30/99	Wed 6/30/99
User documentation	Wed 6/30/99	Fri 7/2/99
Configuration data	Wed 6/30/99	Wed 6/30/99
Additional programs for migration: data conversion	Wed 6/30/99	Thu 7/1/99
Package Software	Mon 7/5/99	Tue 7/6/99
Distribute Software	Wed 7/7/99	Thu 7/8/99
Install Software	Fri 7/9/99	Mon 7/12/99
Migration	Thu 7/15/99	Tue 7/20/99
Provide Help and Assistance to the Users	Tue 7/13/99	Mon 7/19/99
Acceptance Testing	Tue 7/13/99	Wed 7/14/99

Iteration Deliverables

The following deliverables will be generated and reviewed during the T1 & T2 Iterations:

Iteration	Deliverable	Responsible Owner
T1	Installation Scripts User Manual Configuration Data Software Installation Media Release Notes User Training Materials Acceptance Test Signoff	P. Armstrong G. Mandu P. Armstrong P. Armstrong G. Mandu G. Mandu K. Stone / R. Bell
T2	Installation Scripts User Manual Configuration Data Data Migration Utility Program Software Installation Media Release Notes User Training Materials Acceptance Test Signoff	P. Armstrong G. Mandu P. Armstrong B. MacDonald P. Armstrong G. Mandu G. Mandu K. Stone / R. Bell

3.Resources

Staffing Resources

During the T1 & T2 Iterations the staffing requirements are:

Project Management

Project Management Rick Bell

Deployment Management Greg Mandu

Software Engineering

Developer Beth MacDonald

Test

Test Manager Kerry Stone

Deployment

Field Engineer Phil Armstrong

The project organization chart and the staffing requirements for the full project are contained within the Project Plan [4].

Financial Resources

The following table shows the budget for the T1 & T2 Iterations.

Described in Content Above

Equipment & Facilities Resources

The T1 & T2 Iterations require no additional equipment or facilities beyond those items already identified and obtained for the Construction Phase.

The existing Wylie College web site will be used for user support and downloading the client software.

The printing of the User Manuals will be contracted to the Wylie College Print Shop.

4.Use Cases

The T1 & T2 Iterations do not include the development of any use cases.

The primary use cases that form Release 1.0 are:

Logon
Close Registration
Register for Courses
Interface to Course Catalog Database
Interface to Finance System
Maintain Student Information
Maintain Professor Information

The primary use cases that form Release 2.0 are:

Submit Student Grades
View Grades
Select Courses to Teach

5.Evaluation Criteria

The primary goal of the T1 and T2 Iterations is to install R1.0 and R2.0 and obtain user acceptance of the software.

In addition, the following criteria must be met prior to completion of the T1 and T2 Iterations:

The R1.0 and R2.0 releases must not contain any critical or high priority defects.

R2.0 must be installed and operational 3 weeks prior to the start of student registration for the Fall Semester.

R1.0 and R2.0 must pass user acceptance and must be formally signed off by the Wylie College representative.

User training must be completed.

Web site must be established for product support.

User Manuals must be printed and available either through the IT department or the Wylie College Book Store.

The process and resources to provide ongoing user support must be established.

Iteration Plan

Task Name	Start	Finish	Resource Names
Milestones	Tue 2/2/99	Thu 3/4/99
Start Elaboration Phase	Tue 2/2/99	Tue 2/2/99
User-Interface Prototype Milestone	Wed 2/3/99	Wed 2/3/99
Architectural Prototype Milestone (end Elaboration Phase)	Thu 3/4/99	Thu 3/4/99

Elaboration Phase	Tue 2/2/99	Thu 3/4/99
Iteration E1 - Develop Architectural Prototype	Tue 2/2/99	Thu 3/4/99
Business Modeling	Wed 2/3/99	Fri 2/5/99
Find Business Workers and Entities	Wed 2/3/99	Wed 2/3/99	Business Designer
Describe Business Workers	Thu 2/4/99	Thu 2/4/99
Describe Business Worker ‘BW1’	Thu 2/4/99	Thu 2/4/99	Business Designer
Describe Business Worker ‘BW2’	Thu 2/4/99	Thu 2/4/99	Business Designer
Describe Business Entities	Thu 2/4/99	Thu 2/4/99
Describe Business Entity ‘BE1’	Thu 2/4/99	Thu 2/4/99	Business Designer
Describe Business Entity ‘BE2’	Thu 2/4/99	Thu 2/4/99	Business Designer
Review the Business Analysis Model	Fri 2/5/99	Fri 2/5/99	Business-Model Reviewer
Requirements	Wed 2/3/99	Tue 2/9/99
Manage Dependencies	Wed 2/3/99	Tue 2/9/99	System Analyst
Detail Prioritized Use Cases	Wed 2/3/99	Wed 2/3/99
Detail Use Case ‘UC1’	Wed 2/3/99	Wed 2/3/99	Use-Case Author
Detail Use Case ‘UC2’	Wed 2/3/99	Wed 2/3/99	Use-Case Author
Detail Use Case ‘UC3’	Wed 2/3/99	Wed 2/3/99	Use-Case Author
Detail Use Case ‘UC4’	Wed 2/3/99	Wed 2/3/99	Use-Case Author
Detail Use Case ‘UC5’	Wed 2/3/99	Wed 2/3/99	Use-Case Author
Structure the Use Case Model	Thu 2/4/99	Thu 2/4/99	Architect
User-Interface Modeling	Wed 2/3/99	Wed 2/3/99	User-Interface Designer
User-Interface Prototyping	Wed 2/3/99	Wed 2/3/99	User-Interface Designer
Review Requirements	Fri 2/5/99	Fri 2/5/99	Requirements Reviewer
Analysis & Design (Architecture & Major Risks)	Fri 2/5/99	Thu 2/18/99
Architectural Analysis	Fri 2/5/99	Fri 2/5/99	Architect
Prioritized Use-Case Analysis	Mon 2/8/99	Mon 2/8/99
Analyze Use-Case ‘UC1’	Mon 2/8/99	Mon 2/8/99	Designer
Analyze Use-Case ‘UC2’	Mon 2/8/99	Mon 2/8/99	Designer
Analyze Use-Case ‘UC3’	Mon 2/8/99	Mon 2/8/99	Designer
Analyze Use-Case ‘UC4’	Mon 2/8/99	Mon 2/8/99	Designer
Architectural Design	Tue 2/9/99	Tue 2/9/99
Describe Concurrency	Wed 2/10/99	Wed 2/10/99	Architect
Describe Distribution	Thu 2/11/99	Thu 2/11/99	Architect
Review the Architecture	Fri 2/12/99	Fri 2/12/99	Architecture Reviewer
Prioritized Subsystem Design	Mon 2/15/99	Mon 2/15/99
Subsystem Design - Subsystem ‘S1’	Mon 2/15/99	Mon 2/15/99	Designer
Subsystem Design - Subsystem ‘S2’	Mon 2/15/99	Mon 2/15/99	Designer
Prioritized Class Design	Mon 2/15/99	Mon 2/15/99
Class Design - Class ‘C1’	Mon 2/15/99	Mon 2/15/99	Designer
Class Design - Class ‘C2’	Mon 2/15/99	Mon 2/15/99	Designer
Class Design - Class ‘C3’	Mon 2/15/99	Mon 2/15/99	Designer
Class Design - Class ‘C4’	Mon 2/15/99	Mon 2/15/99	Designer
Prioritized Use-Case Design	Tue 2/16/99	Tue 2/16/99
Design Use-Case ‘UC1’	Tue 2/16/99	Tue 2/16/99	Designer
Design Use-Case ‘UC2’	Tue 2/16/99	Tue 2/16/99	Designer
Database Design	Wed 2/17/99	Wed 2/17/99	Database Designer
Review the Design	Thu 2/18/99	Thu 2/18/99	Design Reviewer
Implementation (Architecture & Major Risks)	Mon 2/15/99	Wed 2/24/99
Structure the Implementation Model	Mon 2/15/99	Mon 2/15/99	Architect
Plan System Integration	Fri 2/19/99	Fri 2/19/99	System Integrator
Plan Subsystem Integration	Mon 2/22/99	Mon 2/22/99	Implementer
Implement Prioritized Components	Mon 2/22/99	Mon 2/22/99
Implement Component ‘c1’	Mon 2/22/99	Mon 2/22/99	Implementer
Implement Component ‘c2’	Mon 2/22/99	Mon 2/22/99	Implementer
Implement Component ‘c3’	Mon 2/22/99	Mon 2/22/99	Implementer
Implement Component ‘c4’	Mon 2/22/99	Mon 2/22/99	Implementer
Fix Defects	Tue 2/23/99	Tue 2/23/99	Implementer
Integrate Subsystems	Tue 2/23/99	Tue 2/23/99	Implementer
Integrate System	Wed 2/24/99	Wed 2/24/99	System Integrator
Test (Architecture & Major Risks)	Mon 2/22/99	Tue 3/2/99
Plan Test (Integration & System)	Mon 2/22/99	Mon 2/22/99	Test Designer
Design Test (Integration & System)	Tue 2/23/99	Tue 2/23/99	Test Designer
Implement Test	Wed 2/24/99	Wed 2/24/99	Test Designer
Design Test Packages and Classes	Thu 2/25/99	Thu 2/25/99	Designer
Implement Test Components and Subsystems	Fri 2/26/99	Fri 2/26/99	Implementer
Execute Integration Test	Mon 3/1/99	Mon 3/1/99	Integration Tester
Execute System Test	Tue 3/2/99	Tue 3/2/99	System Tester
Execute Performance Tests	Mon 3/1/99	Mon 3/1/99	Performance Tester
Evaluate Test	Tue 3/2/99	Tue 3/2/99	Test Designer
Management	Tue 2/2/99	Thu 3/4/99
Develop Iteration Plan	Tue 2/2/99	Tue 2/2/99	Project Manager
Staff the Project	Wed 2/3/99	Wed 2/3/99	Project Manager
Revisit Risk List	Tue 2/2/99	Tue 3/2/99	Project Manager
Evaluate the Iteration	Wed 3/3/99	Wed 3/3/99	Project Manager
Update Project Plan	Thu 3/4/99	Thu 3/4/99	Project Manager

Environment	Tue 2/2/99	Thu 3/4/99
Configure Processes	Tue 2/2/99	Thu 2/11/99
Improve Processes	Fri 2/12/99	Thu 3/4/99
Select and Acquire Tools	Tue 2/2/99	Thu 3/4/99
Toolsmithing	Tue 2/2/99	Thu 3/4/99
Support the Development	Tue 2/2/99	Thu 3/4/99
Training	Mon 2/8/99	Wed 2/17/99

Collegiate Sports Paging System

Requirements Management Plan

Version 1.0

Revision History


Date	Version	Description	Author
July 2, 2000	1.0	Initial release	Context Integration

Table of Contents

1.Introduction

1.1Purpose

1.2Scope

1.3Definitions, Acronyms, and Abbreviations

1.4References

2.Requirements Management

2.1Organization, Responsibilities, and Interfaces

2.2Tools, Environment, and Infrastructure

3.The Requirements Management Program

3.1Requirements Identification

3.4Reports and Measures

3.5Requirements Change Management

3.6 Workflows and Activities

4.Milestones

5.Training and Resources

Requirements Management Plan

1. Introduction

1.1 Purpose

This document describes the guidelines used by the Collegiate Sports Paging System (CSPS) project for establishing the requirements documents, requirement types, requirements attributes, and tracability in order to manage their software project requirements. It will also serve as the configuration document for the Rational RequisitePro**â requirements management tool.

1.2 Scope

This plan pertains to all phases of the project.

1.3 Definitions, Acronyms, and Abbreviations

See Glossary

1.4 References

CSPS Software Development Plan

CSPS Development Case

CSPS Measurement Plan

CSPS Configuration Management Plan

2. Requirements Management

2.1 Organization, Responsibilities, and Interfaces

See the CSPS Software Development Plan.

2.2 Tools, Environment, and Infrastructure

Rational RequisitePro will be used to manage requirements. For other information about the infrastructure and environment, refer to the CSPS Software Development Plan.

3. The Requirements Management Program

3.1 Requirements Identification


Artifact (Document Type)	Requirement Type	Description
Vision (VIS)	Stakeholder Need (NEED)	Key stakeholder or user need
Vision (VIS)	Feature (FEAT)	Conditions or capabilities of this release of the system
Use-Case Model	Use Case (UC)	Use cases for this release, documented in Rational Rose, with details in Rational RequisitePro.
Supplementary Specification (SS)	Supplementary Requirement (SUPP)	Non-functional requirements that are not captured in the use-case model

Table 3.1?1 Requirement Artifacts and Types

3.2 Traceability

Figure -1 - Traceability diagram

Criteria for FEAT

Features will be traced to use cases.

Criteria for NEED

User needs will be traced to features(FEAT). Any needs not traced to a FEAT will not be implemented.

Criteria for UC

Use-cases will be traced to test cases.

Criteria for SUPP

Supplemental specifications will be traced to test cases.

3.3 Attributes

Attributes for FEAT

Status

Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.


Proposed	Used to describe features that are under discussion but have not yet been reviewed and accepted by the “official channel,” such as a working group consisting of representatives from the project team, product management and user or customer community.
Approved	Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel.
Incorporated	Features incorporated into the product baseline at a specific point in time.

Benefit

Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requirements by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.


Critical	Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.
Important	Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
Useful	Features that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.

Effort

Set by the development team. Because some features require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

Risk

Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects teams schedule estimate.

Stability

Set by analyst and development team based on the probability the feature will change or the team’s understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

Target Release

Records the intended product version in which the feature will first appear. This field can be used to allocate features from a Vision document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various features of the release without committing them to development. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

Assigned To

In many projects, features will be assigned to “feature teams” responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.

Reason

This text field is used to track the source of the requested feature. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

Attributes for NEED

Status

Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.


Proposed	Used to describe needs that are under discussion but have not yet been reviewed and accepted by the “official channel,” such as a working group consisting of representatives from the project team, product management and user or customer community.
Approved	Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel.
Incorporated	Needs being met by the product baseline at a specific point in time.

Effort

Set by the development team. Because some needs require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

Risk

Stability

Set by analyst and development team based on the probability the need will change or the team’s understanding of the need will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

Target Release

Records the intended product version in which the need will first be met. This field can be used to allocate features from a Vision document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various features of the release without committing them to development. Only needs whose Status is set to Incorporated and whose Target Release is defined will be met. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

Reason

This text field is used to track the source of the need. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

Attributes for UC

Status

Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.


Proposed	Used to describe use-cases that are under discussion but have not yet been reviewed and accepted by the “official channel,” such as a working group consisting of representatives from the project team, product management and user or customer community.
Approved	Use-cases that are deemed useful and feasible and have been approved for implementation by the official channel.
Incorporated	Use-cases incorporated into the product baseline at a specific point in time.

Benefit

Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking use-cases by their relative benefit to the end user opens a dialogue with customers, analysts and members of the development team. Used in managing scope and determining development priority.


Critical	Essential use-cases. Failure to implement means the system will not meet customer needs. All critical use-cases must be implemented in the release or the schedule will slip.
Important	Use-cases important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
Useful	Use-cases that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.

Effort

Set by the development team. Because some use-cases require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

Risk

Stability

Set by analyst and development team based on the probability the use-case will change or the team’s understanding of the use-case will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

Target Release

Records the intended product version in which the use-case will first appear. This field can be used to allocate use-cases from a Use Case Survey document into a particular baseline release. When combined with the status field, your team can propose, record and discuss various use-cases of the release without committing them to development. Only use-cases whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.

Assigned To

In many projects, use-cases will be assigned to teams responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.

Reason

This text field is used to track the source of the requested use-case. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification, or to a minute marker on a video of an important customer interview.

Attributes for SUPP

Status

Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.


Proposed	Used to describe supplemental specifications that are under discussion but have not yet been reviewed and accepted by the “official channel,” such as a working group consisting of representatives from the project team, product management and user or customer community.
Approved	Capabilities that are deemed useful and feasible and have been approved for implementation by the official channel.
Incorporated	Supplemental specifications incorporated into the product baseline at a specific point in time.

Benefit


Critical	Essential specification. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.
Important	Specifications important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important specification may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.
Useful	Specifications that are useful in less typical applications, will be used less frequently, or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.

Effort

Set by the development team. Because some specifications require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.

Risk

Stability

Set by analyst and development team based on the probability the specification will change or the team’s understanding of the specification will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.

Target Release

Records the intended product version in which the specified attribute or feature will first appear. This field can be used to allocate specifications into a particular baseline release. When combined with the status field, your team can propose, record and discuss various specifications of the release without committing them to development. Only specifications whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the supplemental specification document but will be scheduled for a later release.

Assigned To

In many projects, specified attributes or features will be assigned to teams responsible for further elicitation, writing the software requirements and implementation. This simple pull down list will help everyone on the project team better understand responsibilities.

3.4 Reports and Measures

See the CSPS Measurement Plan.

3.5 Requirements Change Management

See the CSPS Configuration Management Plan.

The following access groups will be set up to control access to requirements in Rational RequisitePro.

·Tool Administrator - has full access to every part of the tool. Can add and remove people, change their access rights, etc.

·Author - can create new requirements

·Project Manager - sets the status of requirements

·Tester_QA - sets the status of test case requirements.

3.6 Workflows and Activities

See the CSPS Development Case.

4. Milestones

See the CSPS Software Development Plan.

5. Training and Resources

See the CSPS Software Development Plan.

Rose Web Publisher - Introduction

Created byRose Web Publisher

These web pages have been extracted automatically from a Rational Rose model with the Web Publisher for Rational Rose. For more information or downloads for Rose please visit the Rose web site or for information on Rational Software Corporation visit the Rational’s web site. For Technical Support visit the Technical Support web site.

For ordering information contact your account representative or call one of the following numbers. You can also send e-mail to rosebud@rational.com.


To Order call: United States & Canada Other Worldwide Locations	1-800-728-1212 +1-408-863-9900

Rational Rose 2000 http://www.rational.com/rose

Small Project Development Case: Construction


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	Topics (on this page) - Gantt Chart - Task Descriptions

Gantt Chart

This illustration shows how construction phase for a small project could be organized. The lengths of the bars in the chart (indicating duration) have no absolute significance. You can navigate to the corresponding task description from each line of the chart by clicking on the task name.

Task Descriptions


Task	Description
Project Management:
Managing/Monitoring	This represents ongoing project management activities, including the following workflow details: - Manage the Iteration - Monitor and Control Project On this small project, the Project Manager is also the Test Manager, so this task also includes: - Achieve Acceptable Mission (activities: Assess and Advocate Quality, Assess and Improve Test Effort) The principal output artifacts are: - Review Records - Iteration Assessment - Status Assessment
Next Iteration Planning	This includes workflow details: - Plan for Next Iteration - Develop Software Development Plan (optional, depending on scope of change) - Define Evaluation Mission (Test Manager related activities) The principal output artifacts are: - Iteration Plan - updated based on what new functionality is to be added during the new iteration, factoring in the current level of product maturity, lessons learned from the previous iterations, and any risks that need to be mitigated in the upcoming iteration) - Software Development Plan - all subplans updated as required to reflect changes in scope and risk. The Risk List in particular must be revisited if there are significant remaining risks - Test Plan - updated to reflect the mission for the next iteration’s testing. The results of status assessments and iteration assessments should be considered in determining if any changes to process and tools are necessary.
Requirements
Manage Changing Requirements	Requirements discovery and refinement is shown as complete at this stage, the remaining effort relating entirely to the management of change. The relevant workflow detail is: Manage Changing Requirements.
Development Support
Refine the Architecture	The Software Architect has an ongoing task, which lessens as the project matures, to make any necessary changes to the software architecture. The relevant workflow detail is Refine the Architecture.
Integration and Test Support	Maintaining the build environment, selecting and running regression tests on builds, is an ongoing task. The relevant workflow details are: - Validate Build Stability - Manage Baselines and Releases
Defect Fixing	Fixing defects in previously developed code is an ongoing task. The relevant workflow details are the same as for the “Develop Components/Features” tasks.
Develop Components/Features - Component/Feature A - Component/Feature B - and so on	Many tasks are organized around a feature, use case, or scenario being implemented. Thus one task will often include the following workflow details: - Design Components (or Design the Database) - Implement Component - Integrate the System - Test and Evaluate - Improve Test Assets Other tasks may design and implement components that then support multiple features, use cases, or scenarios. Large tasks (more than a couple of weeks) may be divided into subtasks of incremental functionality. Other large tasks may be subdivided by the principal activity being performed. For example, into: - Design - may include some prototyping - Implement - includes (in this small project) all unit testing - Integrate and Test - including fixing bugs found in the new code during integration. (Bugs in existing code are covered by the Defect Fixing task).

Configuration Management tasks (workflow details: Change and Deliver Configuration Items and Manage Change Requests) are folded into the above tasks. Administrative and environment support tasks have been omitted for simplification.

Small Project Development Case: Elaboration


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	Topics (on this page) - Gantt Chart - Task Descriptions

Gantt Chart

This illustration shows how the first elaboration iteration of a small project might be planned. The lengths of the bars in the chart (indicating duration) have no absolute significance. There is also no intention to suggest the application of a uniform level of effort across the duration of the workflows. You can navigate to the corresponding task description from each line of the chart - just click on the task name.

Note that although this is a plan for a single iteration, not all Requirements and Analysis and Design work performed during this iteration is intended for Implementation and Test in this iteration. This explains why the relative effort, within an iteration, for Requirements, Analysis and Design, Implementation and Test, changes through the lifecycle. However, the Iteration Plan will dictate what requirements are explored and refined and what components are designed, even if they are intended for Implementation and Test in a later iteration.

Task Descriptions


Project Management:
Managing/Monitoring	This represents ongoing project management activities, including the following workflow details: - Manage the Iteration - Monitor and Control Project On this small project, the Project Manager is also the Test Manager, so this task also includes: - Achieve Acceptable Mission (activities: Assess and Advocate Quality, Assess and Improve Test Effort) The principal output artifacts are: - Review Records - Iteration Assessment - Status Assessment
Next Iteration Planning	This includes workflow details: - Plan for Next Iteration - Develop Software Development Plan (optional, depending on scope of change) - Define Evaluation Mission (Test Manager related activities) The principal output artifacts are: - Iteration Plan - updated based on what new functionality is to be added during the new iteration, factoring in the current level of product maturity, lessons learned from the previous iterations, and any risks that need to be mitigated in the upcoming iteration) - Software Development Plan - all subplans updated as required to reflect changes in scope and risk. The Risk List in particular must be revisited if there are significant remaining risks - Test Plan - updated to reflect the mission for the next iteration’s testing. The results of status assessments and iteration assessments should be considered in determining if any changes to process and tools are necessary.
Requirements
Prototype the User Interface	This includes the Activity: Prototype the User Interface. The main output artifact is User-Interface Prototype.
Manage Changing Requirements	Requirements discovery and refinement continues in elaboration. The relevant workflow detail is: Manage Changing Requirements.
Refine the System Definition - Requirements Set 1 - Requirements Set 2 - and so on	This includes the workflow detail Refine the System Definition (except for user-interface related activities, which are a separate task). The main output artifacts are: - a Use Case Model (with highest priority use cases detailed) - updated Vision and Supplementary Specifications. The effort to define requirements is divided into smaller tasks with shorter durations (around 1 week is typical). These are represented in the example plan as “Requirements Set 1”, “Requirements Set 2”, and so on. Tasks are typically organized around use cases or scenarios, with other tasks to detail supplemental requirements or investigate specific issues or risks.
Architectural Definition
Define a Candidate Architecture	This include the workflow detail Define a Candidate Architecture.
Structure the Implementation Model	This includes the workflow detail Structure the Implementation Model.
Refine the Architecture	This includes the workflow detail Refine the Architecture.
Development Support
Integration and Test Support	Maintaining the build environment, selecting and running regression tests on builds, is an ongoing task. The relevant workflow details are: - Validate Build Stability - Manage Baselines and Releases
Defect Fixing	Fixing defects in previously developed code is an ongoing task. The relevant workflow details are the same as for the “Develop Components/Features” tasks.
Develop Components/Features - Component/Feature 1 - Component/Feature 2 - and so on	Many tasks are organized around a feature, use case, or scenario being implemented. Thus one task will often include the following workflow details: - Design Components (or Design the Database) - Implement Component - Integrate the System - Test and Evaluate - Improve Test Assets Other tasks may design and implement components that then support multiple features, use cases, or scenarios. Large tasks (more than a couple of weeks) may be divided into subtasks of incremental functionality. Other large tasks may be subdivided by the principal activity being performed. For example, into: - Design - may include some prototyping - Implement - includes (in this small project) all unit testing - Integrate and Test - including fixing bugs found in the new code during integration. (Bugs in existing code are covered by the Defect Fixing task).

Result

Subsequent Iterations In Elaboration

Small Project Development Case: Inception


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	Topics (on this page) - Gantt Chart - Task Descriptions

Gantt Chart

This illustration shows how the first iteration of a small project might be planned. The lengths of the bars in the chart (indicating duration) have no absolute significance. There is also no intention to suggest the application of a uniform level of effort across the duration of the workflows. You can navigate to the corresponding task description from each line of the chart - just click on the task name.

Task Descriptions


Task	Description
Project Management:
Conception/Approval	This includes the workflow details: - Conceive New Project - Evaluate Project Scope and Risk - Develop Software Development Plan The main output artifacts are: - an approved Business Case, - preliminary Vision - Software Development Plan (including Risk List). A more detailed plan would include some review milestones.
Plan Remainder of Initial Iteration	This includes workflow details: - Plan for Next Iteration. The principal output artifact is: - Iteration Plan.
Managing/Monitoring	This represents ongoing project management activities, including the following workflow details: - Manage the Iteration - Monitor and Control Project The principal output artifacts are: - Review Records - Iteration Assessment - Status Assessment
Next Iteration Planning	This includes workflow details: - Plan for Next Iteration - Develop Software Development Plan (optional, depending on scope of change) - Define Evaluation Mission (Test Manager related activities) The principal output artifacts are: - Iteration Plan - updated based on what new functionality is to be added during the new iteration, factoring in the current level of product maturity, lessons learned from the previous iterations, and any risks that need to be mitigated in the upcoming iteration) - Software Development Plan - all subplans updated as required to reflect changes in scope and risk. The Risk List in particular must be revisited if there are significant remaining risks - Test Plan - updated to reflect the mission for the next iteration’s testing. The results of status assessments and iteration assessments should be considered in determining if any changes to process and tools are necessary.
Requirements
Define Initial Scope	This includes the workflow details: - Analyze Problem - Understand Stakeholder Needs - Define the System - Manage the Scope of the System - Manage Changing Requirements. The main output artifact is a complete Vision, including the most important use cases prioritized by the Software Architect. (The Vision will be further refined as more Use Cases are detailed).
Prototype the User Interface	This includes the Activity: Prototype the User Interface. The main output artifact is User-Interface Prototype.
Manage Changing Requirements	This tasks tracks effort related to managing changes to requirements described in the initial Vision (as baselined at the end of the task Define Initial Scope). The relevant workflow detail is: Manage Changing Requirements.
Refine the System Definition - Requirements Set A - Requirements Set B - and so on	This includes the workflow detail Refine the System Definition (except for user-interface related activities, which are a separate task). The main output artifacts are: - a Use Case Model (with highest priority use cases detailed) - updated Vision and Supplementary Specifications. The effort to define requirements is divided into smaller tasks with shorter durations (around 1 week is typical). These are represented in the example plan as “Requirements Set A”, “Requirements Set B”, and so on. Tasks are typically organized around use cases or scenarios, with other tasks to detail supplemental requirements or investigate specific issues or risks.
Analysis and Design
Perform Architectural Synthesis	If the risks are judged to be high, then it may be necessary to do more exploration in this initial inception phase iteration. This workflow detail is: - Perform Architectural Synthesis The main output artifact is an Architectural Proof-of-Concept.

Result

Subsequent Iterations In Inception

Small Project Development Case:Transition


Table of Contents - Introduction - General Tailoring - Project Lifecycle - Inception - Elaboration - Construction - Transition - Artifacts	Topics (on this page) - Gantt Chart - Task Descriptions

Gantt Chart

This illustration shows how an iteration in transition phase could be organized on a small project. The lengths of the bars in the chart (indicating duration) have no absolute significance. You can navigate to the corresponding task description from each line of the chart by clicking on the task name.

Task Descriptions


Task	Description
Project Management:
Managing/Monitoring	This represents ongoing project management activities, including the following workflow details: - Manage the Iteration - Monitor and Control Project On this small project, the Project Manager is also the Test Manager, so this task also includes: - Achieve Acceptable Mission (activities: Assess and Advocate Quality, Assess and Improve Test Effort) The principal output artifacts are: - Review Records - Iteration Assessment - Status Assessment
Next Iteration Planning	This includes workflow details: - Plan for Next Iteration - Develop Software Development Plan (optional, depending on scope of change) - Define Evaluation Mission (Test Manager related activities) The principal output artifacts are: - Iteration Plan - updated based on what new functionality is to be added during the new iteration, factoring in the current level of product maturity, lessons learned from the previous iterations, and any risks that need to be mitigated in the upcoming iteration) - Software Development Plan - all subplans updated as required to reflect changes in scope and risk. The Risk List in particular must be revisited if there are significant remaining risks - Test Plan - updated to reflect the mission for the next iteration’s testing. The results of status assessments and iteration assessments should be considered in determining if any changes to process and tools are necessary.
Requirements
Manage Changing Requirements	Requirements discovery and refinement is shown as complete at this stage, the remaining effort relating entirely to the management of change. The relevant workflow detail is: Manage Changing Requirements.
Development Support
Refine the Architecture	The Software Architect has an ongoing task, which lessens as the project matures, to make any necessary changes to the software architecture. The relevant workflow detail is Refine the Architecture.
Integration and Test Support	Maintaining the build environment, selecting and running regression tests on builds, is an ongoing task. The relevant workflow details are: - Validate Build Stability - Manage Baselines and Releases
Defect Fixing	Fixing defects in previously developed code is an ongoing task. The relevant workflow details are the same as for the “Develop Components/Features” tasks.
Develop Components/Features - Component/Feature A - and so on	Many tasks are organized around a feature, use case, or scenario being implemented. Thus one task will often include the following workflow details: - Design Components (or Design the Database) - Implement Component - Integrate the System - Test and Evaluate - Improve Test Assets Other tasks may design and implement components that then support multiple features, use cases, or scenarios. Large tasks (more than a couple of weeks) may be divided into subtasks of incremental functionality. Other large tasks may be subdivided by the principal activity being performed. For example, into: - Design - may include some prototyping - Implement - includes (in this small project) all unit testing - Integrate and Test - including fixing bugs found in the new code during integration. (Bugs in existing code are covered by the Defect Fixing task).
Deployment
Plan Deployment	This is the workflow detail Plan Deployment. This task may alternatively be merged into the iteration planning that occurs at the end of the previous iteration. The principal output artifact is an updated Software Development Plan (Deployment Plan section).
Develop Support Material	This is the workflow detail Develop Support Material. The principal output artifact is End-User Support Material.
Manage Acceptance Test (At Development Site)	This is the workflow detail Manage Acceptance Test (At Development Site). The principal output artifact is an installed and tested Product.
Produce Deployment Unit	This is the workflow detail Produce Deployment Unit. The principal output artifacts are: - Installation Artifacts - Release Notes - Deployment Units.
Manage Acceptance Test (At Installation Site)	This is the workflow detail Manage Acceptance Test (At Installation Site). For this sample, the software is deployed at a customer site. Other forms of deployment are discussed as part of the Discipline: Deployment. The principal output artifact is a Product installed and tested at the customer site.

Software Development Plan

Phase	Iteration	Description	Associated Milestones	Risks Addressed
Inception Phase	Preliminary Iteration	Defines business model, product requirements, Software Development Plan, and business case.	Business Case Review	Clarifies user requirements up front. Develops realistic Software Development Plans and scope. Determines feasibility of project from a business point of view.
Elaboration Phase	E1 Iteration - Develop Architectural Prototype	Completes analysis & design for all high risk requirements. Develops the architectural prototype.	Architectural Prototype	Architectural issues clarified. Technical risks mitigated. Early prototype for user review.
Construction Phase	C1 Iteration - Develop R1 Beta	Implement and test key R1 requirements to provide the R1 Beta Version. Assess if the release is ready to go for beta testing.	Initial Operational Capability (R1 Beta Code Complete)	All key features from a user and architectural perspective implemented in the Beta.
Transition Phase	T1 Iteration - Develop/Deploy R1 Release	Deploy the R1 Beta. Fix defects from Beta, and incorporate feedback from Beta. Implement and test remaining R1 requirements. Package, distribute, and install R1 Release. Remaining low-risk R2 use cases fully detailed.	R1 Beta Test Complete R1 Code Complete R1 Product Release	User feedback prior to release of R1. Product quality should be high. Defects minimized. Cost of quality reduced. Two-stage release minimizes defects. Two-stage release provides easier transition for users. R1 fully reviewed by user community.
	T2 Iteration - Develop R2 Internal 1	Design, implement, and test R2 Internal 1 requirements. Incorporate enhancements and defects from R1. Deploy the R2 Internal 1.	R2 Internal 1 Test Complete	If needed, R2 Internal 1 could be released to address R1 defects, to help address customer satisfaction.
	T3 Iteration - Develop R2 Internal 2	Design, implement, and test R2 Internal 2 requirements Incorporate enhancements and defects from R2 Internal 2. Deploy the R2 Internal 2.	R2 Internal 2 Test Complete	R2 Internal 1 informally reviewed by user community. If needed, R2 Internal 1 could be released to address R1 defects, to help address customer satisfaction.
	T4 Iteration - Develop/Deploy R2 Release	Package, distribute, and install R2 Release.	R2 Code Complete R2 Product Release	R2 Internal 2 informally reviewed by user community. Two-stage release provides easier transition for users.

Course Registration System

Status Assessment

Version 1.0

Revision History

Date	Version	Description	Author
29/March/1999	1.0	Initial Version - Status Assessment taken during R1.0.	Rick Bell

Table of Contents

1.3 Definitions, Acronyms and Abbreviations

5. Major Milestone Results

2. Resources

2.1 Personnel/Staffing

2.2 Financial Data

3. Top 10-Risks

4. Technical Progress

6. Total Project/Product Scope

7. Action Items and Follow-Through

Status Assessment

1.Introduction

1.1Purpose

1.2Scope

This status assessment reviews all aspects of the C-Registration System as of the end of the C2 Iteration.

1.3Definitions, Acronyms and Abbreviations

Refer to the Glossary [3].

1.4References

Applicable references are:

Course Registration System Vision Document, WyIT387, V1.0, Wylie College IT.
Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.
Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.
Course Registration System Master Schedule, 1999, Wylie College IT.
Course Registration System Construction Phase Schedule, V1.0, 1999, Wylie College IT.
Course Registration System Software Development Plan, WyIT418, V2.0, 1999, Wylie College IT.
Course Registration System Iteration Plan, Preliminary Iteration (Inception), WyIT414, V1.0, 1999, Wylie College IT.
Course Registration System Iteration Plan, Elaboration Iteration #E1, WyIT420, V1.0 1999, Wylie College IT.
Course Registration System C2 Iteration Plan, WyIT500, V1.0. 1999, Wylie College IT.
Course Registration System C2 Integration Build Plan, WyIT502, V1.0, 1999, Wylie College IT.
Course Registration System Test Plan for the Architectural Prototype, WyIT432, V1.0, 1999, Wylie College IT.
Course Registration System Test Plan, WyIT501, V1.0, 1999, Wylie College IT.
Course Registration System Test Evaluation Summary for the Architectural Prototype, WyIT433, V1.0, 1999, Wylie College IT.
Course Registration System C2 Test Evaluation Summary, WyIT503, V1.0, 1999, Wylie College IT.
Course Registration System C2 Iteration Assessment, WyIT504, V1.0, 1999, Wylie College IT.
Course Registration System Risk List, WyIT419, V3.0, 1999, Wylie College IT.

2.Resources

2.1Personnel/Staffing

The project is fully staffed with the exception of 1 Developer position and 1 Tester position. These positions were identified during the last iteration to help move the schedule up by several weeks. Rick Bell is currently interviewing candidates.

The systems engineers were released from the project and assigned to other projects at the start of the C2 Iteration. System performance problems have resulted in 2 of the engineers returning to the project on a part-time basis.

2.2Financial Data

The original budget of $116,600 for the C2 Iteration was overrun by $10,000 due to additional effort being deployed to address the performance issues.

With respect to the overall project budget of $638,000 (see Project Plan V2.0 [6]), an overrun of $104,000 is projected.

The table below summarizes the overall project financial status as well as the last iteration’s financial status.

BUDGET


	Budget	Actual To Date	Estimate to Complete	Estimate at Completion	Variance	Percent Variance
	B	ATC	ETC	EAC=ATC+ETC	V=B-EAC	PV=V/B

Overall Project	$638,000	$402,000	$340,000	$742,000	-$104,000	-16.3%
C2 Iteration	$116,600	$126,600	$-	$126,600	-$10,000	-8.6%

3.Top 10-Risks

The top risks and their mitigation plans are documented in the Risk List [16]. The current status and any actions assigned to mitigate the risks have been updated in Version 3 of the Risk List.

4.Technical Progress

The C2 Iteration to develop the R1.0 software baseline has just completed. All deliverables as defined in the iteration plans [7],[8],[9] have been generated and reviewed.

40 defects in the R1.0 baseline remain open. 12 of these are classified as High or Critical severity. (See the C2 Test Evaluation Report [13] for more details on the C2 defects.)

Add additional iteration, C2b, has been introduced to redesign the interface to the Course Catalog System.

Meeting the performance and loading requirements is currently the only major Design Issue outstanding.

5.Major Milestone Results

The following table summarizes the results of the major milestones

Milestone	Planned Date	Actual Date	Results
Business Case Review	19/01/1999	30/01/1999	Business Case Review was well received by Senior Management Team and Wylie College representatives. No scope changes. Release 2.0 committed to June 24th, 1999.
Architectural Prototype	02/03/1999	15/03/1999	Major performance problems discovered in accessing the Course Catalog System.
Beta Release	02/04/1999	12/04/1999	User Feedback favorable. Users requested design changes to all screens and menus.
Initial Operational Capability (Release 1.0)	10/05/1999	-	Release 1.0 System Test completed. Performance requirements accessing the Course Catalog System not met. Senior Management Team has decided to add an iteration to redesign the interface software to correct the performance problems.
Product Release 1.0	19/05/1999	-
2nd Operational Capability	24/06/1999	-
Product Release 2.0	24/06/1999	-

6.Total Project/Product Scope

The overall scope of the project as defined in the Vision Document [1] has not changed. User feedback on the Beta release resulted in a redesign of all screens and menus. This change was “in scope” and no change orders will be issued to the customer.

7.Action Items and Follow-through

The following list of open action items has been compiled from the Risk List [16], C2 Test Evaluation Report [14], and the weekly Project Meetings:

Id.	Action Item Description	Assignee	Due Date	Status
1.	Devote systems engineering resources to the response time issue involving the Course Catalog System.	Rick Bell	04/04/1999	Open.
2.	Review the master schedule to see if a fourth iteration can be added to the Construction Phase.	Senior Mgmt Team	31/03/1999	Open. Meeting scheduled.
3.	Ensure all high risk components are code inspected prior to build integration.	Rick Bell	31/03/1999	Open. Rick to discuss at weekly meeting.
4.	Plan additional design reviews for the R2.0 Release.	Rick Bell	15/04/1999	Open. To be added to C3 and C2b schedules.
5.	Fix the problems with the Load Simulator Software and re-run the associated test cases.	Kerry Stone	02/04/1999	Open Test Engineer assigned to problem.
6.	Investigate defect aging. Why are a number of defects taking more than 30 days to close?	Kerry Stone	02/04/1999	Open
7.	Monitor progress on the performance issues weekly.	Rick Bell	Ongoing	Open
8.	Hire one additional developer.	Rick Bell	15/04/1999	Open Recruiting Agencies contacted.
9.	Continue to monitor Y2K status on the legacy systems.	Rick Bell	Ongoing	Open

Test-Ideas Catalog Examples

The following Concept: Test-Ideas Catalog examples are provided:

a short catalog of test ideas for developers
a Test-Ideas Catalog: Test Ideas for Mixtures of ANDs and ORs for developers

Test-Ideas Catalog: Test Ideas for Mixtures of ANDs and ORs

This catalog applies to expressions that combine ANDs and ORs. As a reminder, here’s how to derive test requirements for homogenous expressions:

A1 && A2 && … && An:

one test idea with All Ai’s true
N cases, each of which has exactly one term false.

Example:


A && B && C
A	B	C
true	true	true
FALSE	true	true
true	FALSE	true
true	true	FALSE

A1 || A2 || … || An:

one test idea with All Ai’s false
N cases, each of which has exactly one term true.

Example:


**A		B
A	B	C
FALSE	FALSE	FALSE
FALSE	true	FALSE
true	FALSE	FALSE
FALSE	FALSE	true

Two Boolean Operators


**(A && B)		C**
A	B	C
FALSE	true	true
true	true	FALSE
FALSE	true	FALSE
true	FALSE	FALSE


**A && (B		C)**
A	B	C
true	FALSE	FALSE
true	FALSE	true
true	true	FALSE
FALSE	FALSE	true


**A		(B && C)**
A	B	C
true	true	FALSE
FALSE	true	true
FALSE	FALSE	true
FALSE	true	FALSE


**(A		B) && C**
A	B	C
FALSE	FALSE	true
FALSE	true	true
true	FALSE	true
FALSE	true	FALSE

Three Boolean Operators One And

To help find an expression, read down the columns. The ANDs drift from the left to the right as you read.


**(A && B)		C		D**
A	B	C	D		A	B	C	D
FALSE	true	true	FALSE		FALSE	FALSE	true	FALSE
true	true	FALSE	FALSE		FALSE	true	true	FALSE
FALSE	true	FALSE	FALSE		true	FALSE	true	FALSE
true	FALSE	FALSE	FALSE		FALSE	FALSE	true	true
true	FALSE	FALSE	true		FALSE	true	FALSE	FALSE


**A && (B		C		D)**
A	B	C	D		A	B	C	D
true	FALSE	FALSE	FALSE		FALSE	true	FALSE	FALSE
true	FALSE	true	FALSE		FALSE	true	FALSE	true
true	true	FALSE	FALSE		FALSE	true	true	FALSE
true	FALSE	FALSE	true		true	true	FALSE	FALSE
FALSE	FALSE	FALSE	true		FALSE	FALSE	FALSE	true


**A		(B && C)		D**
A	B	C	D		A	B	C	D
true	true	FALSE	FALSE		FALSE	true	true	FALSE
FALSE	true	true	FALSE		FALSE	FALSE	FALSE	true
FALSE	FALSE	true	FALSE		true	FALSE	true	FALSE
FALSE	true	FALSE	FALSE		FALSE	FALSE	true	true
FALSE	true	FALSE	true		FALSE	FALSE	true	FALSE


**(A		B) && (C		D)**
A	B	C	D		A	B	C	D
FALSE	FALSE	FALSE	true		FALSE	FALSE	FALSE	true
FALSE	true	FALSE	true		FALSE	true	FALSE	true
true	FALSE	true	FALSE		true	FALSE	FALSE	true
FALSE	true	FALSE	FALSE		FALSE	FALSE	true	true
					FALSE	FALSE	true	FALSE

Three Boolean Operators Two Ands

To help find an expression, read down the columns. The ORs drift from the right to the left as you read


**(A && B && C)		D**				**((A && B)
A	B	C	D	A	B	C	D
true	true	true	FALSE	FALSE	true	true	true
FALSE	true	true	FALSE	true	true	FALSE	true
true	FALSE	true	FALSE	FALSE	true	FALSE	true
true	FALSE	true	true	true	FALSE	FALSE	true
true	true	FALSE	FALSE	true	FALSE	true	FALSE


**A && B && (C		D)**				**A && (B
A	B	C	D	A	B	C	D
true	true	FALSE	true	true	true	true	FALSE
FALSE	true	FALSE	true	true	FALSE	true	true
true	FALSE	FALSE	true	true	FALSE	FALSE	true
true	true	FALSE	FALSE	true	FALSE	true	FALSE
true	true	true	FALSE	FALSE	FALSE	true	true


**A && (B		C) && D**				**(A
A	B	C	D	A	B	C	D
true	FALSE	FALSE	true	FALSE	FALSE	true	true
true	FALSE	true	true	FALSE	true	true	true
true	true	FALSE	true	true	FALSE	true	true
FALSE	FALSE	true	true	FALSE	true	FALSE	true
true	FALSE	true	FALSE	FALSE	true	true	FALSE


**(A && B)		(C && D)**				**A
A	B	C	D	A	B	C	D
FALSE	true	true	true	FALSE	true	true	true
true	true	true	FALSE	FALSE	FALSE	true	true
FALSE	true	FALSE	true	FALSE	true	FALSE	true
true	FALSE	true	FALSE	true	true	true	FALSE
				FALSE	true	true	FALSE

Untitled

Project Properties

CORBA


CreateMissingDirectories	True	Editor	BuiltIn
IncludePath		StopOnError	True
EditorType	BuiltIn, WindowsShell

Oracle8


DDLScriptFilename	DDL1.SQL	DropClause	False
PrimaryKeyColumnName	_ID	PrimaryKeyColumnType	NUMBER(5,0)
SchemaNamePrefix		SchemaNameSuffix
TableNamePrefix		TableNameSuffix
TypeNamePrefix		TypeNameSuffix
ViewNamePrefix		ViewNameSuffix
VarrayNamePrefix		VarrayNameSuffix
NestedTableNamePrefix		NestedTableNameSuffix
ObjectTableNamePrefix		ObjectTableNameSuffix

Java


CreateMissingDirectories	True	StopOnError	False
UsePrefixes	False	Editor	BuiltIn
VM	Sun	ClassPath
EditorType	BuiltIn, WindowsShell	VMType	Sun, Microsoft
InstanceVariablePrefix	m_	ClassVariablePrefix	s_
DefaultAttributeDataType	int	DefaultOperationReturnType	void
AutoSync	False	NoClassCustomDlg	False
GlobalImports		OpenBraceClassStyle	True
OpenBraceMethodStyle	True	UseTabs	False
UseSpaces	True	SpacingItems	3
RoseDefaultCommentStyle	True	AsteriskCommentStyle	False
JavaCommentStyle	False	JavadocAuthor	True
JavadocDeprecated	False	JavadocException	True
JavadocParam	True	JavadocReturn	True
JavadocSee	False	JavadocSerial	False
JavadocSerialdata	False	JavadocSerialfield	False
JavadocSince	False	JavadocVersion	False
JavadocLink	False

MSVC


Version	5.0

DDL


Directory	AUTO GENERATE	DataBase	ANSI
DataBaseSet	ANSI, Oracle, SQLServer, Sybase, Watcom	PrimaryKeyColumnName	Id
PrimaryKeyColumnType	NUMBER(5)	ViewName	V_
TableName	T_	InheritSuffix	_V
DropClause	False	BaseViews	False
DDLScriptFilename	DDL1.SQL

C++


UseMSVC	False	HeaderFileExtension	h
HeaderFileBackupExtension	h~	HeaderFileTemporaryExtension	h#
CodeFileExtension	cpp	CodeFileBackupExtension	cp~
CodeFileTemporaryExtension	cp#	CreateMissingDirectories	True
StopOnError	False	ErrorLimit	30
Directory	$ROSECPP_SOURCE	PathSeparator
FileNameFormat	128vx_b	BooleanType	int
AllowTemplates	True	AllowExplicitInstantiations	False
AllowProtectedInheritance	True	CommentWidth	60
OneByValueContainer	$targetClass	OneByReferenceContainer	$targetClass *
OptionalByValueContainer	OptionalByValue<$targetClass>	OptionalByReferenceContainer	$targetClass *
FixedByValueContainer	$targetClass[$limit]	UnorderedFixedByValueContainer	$targetClass[$limit]
FixedByReferenceContainer	$targetClass *[$limit]	UnorderedFixedByReferenceContainer	$targetClass *[$limit]
BoundedByValueContainer	BoundedListByValue<$targetClass,$limit>	UnorderedBoundedByValueContainer	BoundedSetByValue<$targetClass,$limit>
BoundedByReferenceContainer	BoundedListByReference<$targetClass,$limit>	UnorderedBoundedByReferenceContainer	BoundedSetByReference<$targetClass,$limit>
UnboundedByValueContainer	UnboundedListByValue<$targetClass>	UnorderedUnboundedByValueContainer	UnboundedSetByValue<$targetClass>
UnboundedByReferenceContainer	UnboundedListByReference<$targetClass>	UnorderedUnboundedByReferenceContainer	UnboundedSetByReference<$targetClass>
QualifiedByValueContainer	AssociationByValue<$qualtype, $qualcont>	UnorderedQualifiedByValueContainer	DictionaryByValue<$qualtype, $qualcont>
QualifiedByReferenceContainer	AssociationByReference<$qualtype, $qualcont>	UnorderedQualifiedByReferenceContainer	DictionaryByReference<$qualtype, $qualcont>
AlwaysKeepOrphanedCode	False	AllowGenerateOverNewerAnnotations	False
AllowGenerateOverNewerVersion	False

Untitled

Device Pager

Characteristics


Connected Processors	Pager Gateway

Untitled

Main: / Deployment View

Untitled

Processor CSPS Server

Characteristics


Scheduling	Preemptive


Processes	CollegiateSportsPagingServerProcess


Connected Processors	Client	Pager Gateway	Existing Web Server

Untitled

Processor Pager Gateway

Characteristics


Scheduling	Preemptive


Connected Processors	CSPS Server


Connected Devices	Pager

Untitled

Processor Existing Web Server

Characteristics


Scheduling	Preemptive


Connected Processors	CSPS Server

Untitled

Processor Client

Characteristics


Scheduling	Preemptive


Connected Processors	CSPS Server

Untitled

Process CollegiateSportsPagingServerProcess

Priority

Untitled

Association (thePay fee with credit card:Pay fee with credit card) (theSubscriber:Subscriber)


Derived	No	Link Class	–Not Defined–
Element 1	Pay fee with credit card	Element 2	Subscriber
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theRead content on website:Read content on website) (theSubscriber:Subscriber)


Derived	No	Link Class	–Not Defined–
Element 1	Read content on website	Element 2	Subscriber
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theProvide feedback:Provide feedback) (thePotential Subscriber:Potential Subscriber)


Derived	No	Link Class	–Not Defined–
Element 1	Provide feedback	Element 2	Potential Subscriber
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theSubscribe:Subscribe) (thePotential Subscriber:Potential Subscriber)


Derived	No	Link Class	–Not Defined–
Element 1	Subscribe	Element 2	Potential Subscriber
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theProvide feedback:Provide feedback) (theAdvertiser:Advertiser)


Derived	No	Link Class	–Not Defined–
Element 1	Provide feedback	Element 2	Advertiser
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePost Advertising Content:Post Advertising Content) (theAdvertiser:Advertiser)


Derived	No	Link Class	–Not Defined–
Element 1	Post Advertising Content	Element 2	Advertiser
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePrint advertiser reports:Print advertiser reports) (theAdvertiser:Advertiser)


Derived	No	Link Class	–Not Defined–
Element 1	Print advertiser reports	Element 2	Advertiser
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theCurrent WebNewsOnLine System:Current WebNewsOnLine System) (theSend content:Send content)


Derived	No	Link Class	–Not Defined–
Element 1	Current WebNewsOnLine System	Element 2	Send content
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theSend content:Send content) (theCurrent WebNewsOnLine System:Current WebNewsOnLine System)


Derived	No	Link Class	–Not Defined–
Element 1	Send content	Element 2	Current WebNewsOnLine System
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theSend page:Send page) (thePager Gateway:Pager Gateway)


Derived	No	Link Class	–Not Defined–
Element 1	Send page	Element 2	Pager Gateway
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theApprove story:Approve story) (theEditor:Editor)


Derived	No	Link Class	–Not Defined–
Element 1	Approve story	Element 2	Editor
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theEdit profile:Edit profile) (thePotential Subscriber:Potential Subscriber)


Derived	No	Link Class	–Not Defined–
Element 1	Edit profile	Element 2	Potential Subscriber
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePager Gateway:Pager Gateway) (theSend content:Send content)


Derived	No	Link Class	–Not Defined–
Element 1	Pager Gateway	Element 2	Send content
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePaging Service:Paging Service) (theSend page:Send page)


Derived	No	Link Class	–Not Defined–
Element 1	Paging Service	Element 2	Send page
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theBaseProfile:BaseProfile) (theUser Profile:User Profile)


Derived	No	Link Class	–Not Defined–
Element 1	BaseProfile	Element 2	User Profile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theSubscriberAccount:SubscriberAccount) (theSubscriberProfile:SubscriberProfile)


Derived	No	Link Class	–Not Defined–
Element 1	SubscriberAccount	Element 2	SubscriberProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePersonalInfo:PersonalInfo) (theSubscriberProfile:SubscriberProfile)


Derived	No	Link Class	–Not Defined–
Element 1	PersonalInfo	Element 2	SubscriberProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePagingPreferences:PagingPreferences) (theSubscriberProfile:SubscriberProfile)


Derived	No	Link Class	–Not Defined–
Element 1	PagingPreferences	Element 2	SubscriberProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePagerInfo:PagerInfo) (theSubscriberProfile:SubscriberProfile)


Derived	No	Link Class	–Not Defined–
Element 1	PagerInfo	Element 2	SubscriberProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (thePageMeWhenInfo:PageMeWhenInfo) (theSubscriberProfile:SubscriberProfile)


Derived	No	Link Class	–Not Defined–
Element 1	PageMeWhenInfo	Element 2	SubscriberProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theContentCatagories:ContentCatagories) (theContent:Content)


Derived	No	Link Class	–Not Defined–
Element 1	ContentCatagories	Element 2	Content
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theAdvertiserAccount:AdvertiserAccount) (theAdvertiserProfile:AdvertiserProfile)


Derived	No	Link Class	–Not Defined–
Element 1	AdvertiserAccount	Element 2	AdvertiserProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theCompanyInfo:CompanyInfo) (theAdvertiserProfile:AdvertiserProfile)


Derived	No	Link Class	–Not Defined–
Element 1	CompanyInfo	Element 2	AdvertiserProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theAdContent:AdContent) (theAdvertiserAccount:AdvertiserAccount)


Derived	No	Link Class	–Not Defined–
Element 1	AdContent	Element 2	AdvertiserAccount
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theContentCatagories:ContentCatagories) (theContent:Content)


Derived	No	Link Class	–Not Defined–
Element 1	ContentCatagories	Element 2	Content
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theContent:Content) (theContentArchive:ContentArchive)


Derived	No	Link Class	–Not Defined–
Element 1	Content	Element 2	ContentArchive
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theAdFrequencyTypes:AdFrequencyTypes) (theAdContent:AdContent)


Derived	No	Link Class	–Not Defined–
Element 1	AdFrequencyTypes	Element 2	AdContent
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theContentCatagories:ContentCatagories) (theEditorProfile:EditorProfile)


Derived	No	Link Class	–Not Defined–
Element 1	ContentCatagories	Element 2	EditorProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theContentQueue:ContentQueue) (theEditorProfile:EditorProfile)


Derived	No	Link Class	–Not Defined–
Element 1	ContentQueue	Element 2	EditorProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Association (theContentQueue:ContentQueue) (theSubscriberProfile:SubscriberProfile)


Derived	No	Link Class	–Not Defined–
Element 1	ContentQueue	Element 2	SubscriberProfile
Role 1	–Not Named–	Role 2	–Not Named–

Untitled

Message authorizeAndProcessTransaction


Operation	Not assigned	Message to self	No
Sender	–Not Named–	Receiver	–Not Named–

Untitled

Message authorizeAndProcessTransaction


Operation	Not assigned	Message to self	No
Sender	–Not Named–	Receiver	–Not Named–

Untitled

Object –Not Named–


Persistence	Transient	Multiple Instances	No

Untitled

Object –Not Named–


Persistence	Transient	Multiple Instances	No

Untitled

–Not Named–, role for Element Pay fee with credit card


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Subscriber


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Read content on website


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Subscriber


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Provide feedback


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Potential Subscriber


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Subscribe


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Potential Subscriber


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Provide feedback


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Advertiser


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Post Advertising Content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Advertiser


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Print advertiser reports


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Advertiser


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Current WebNewsOnLine System


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Send content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Send content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Current WebNewsOnLine System


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Send page


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Pager Gateway


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Approve story


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Editor


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Edit profile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Potential Subscriber


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Pager Gateway


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Send content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Paging Service


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Send page


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element BaseProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	0..1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element User Profile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element SubscriberAccount


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element SubscriberProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element PersonalInfo


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element SubscriberProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element PagingPreferences


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element SubscriberProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element PagerInfo


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element SubscriberProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element PageMeWhenInfo


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element SubscriberProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element ContentCatagories


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	0..n
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element AdvertiserAccount


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element AdvertiserProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element CompanyInfo


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element AdvertiserProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element AdContent


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	0..n
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element AdvertiserAccount


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element ContentCatagories


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element Content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element Content


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element ContentArchive


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element AdFrequencyTypes


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element AdContent


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element ContentCatagories


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element EditorProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element ContentQueue


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element EditorProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

–Not Named–, role for Element ContentQueue


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality	1
Aggregate	No	Static	No
Navigable	Yes

Untitled

–Not Named–, role for Element SubscriberProfile


Association	–Not Named–	Export Control	PublicAccess
Containment	Unspecified	Cardinality
Aggregate	No	Static	No
Navigable	No

Untitled

Module Diagram: Component View / Main

Untitled

Package Component View


Parent Package	None

Property Settings

C++


Directory	AUTO GENERATE	DirectoryIsOnSearchList	False
PrecompiledHeader

Untitled

Package Use Case View


Parent Package	None	Assigned Component Package	–Not Defined–
Global	Yes


Packages	Use-Case Model

Property Settings

C++


IsNamespace	False	Indent	2
CodeName		GenerateEmptyRegions	All
GenerateEmptyRegionSet	None, Preserved, Unpreserved, All

Untitled

Use Case Diagram: Use Case View / Main

Untitled

Package Logical View


Parent Package	None	Assigned Component Package	Component View
Global	Yes


Packages	Process View	Use Case Realizations	Design Model

Property Settings

C++


IsNamespace	False	Indent	2
CodeName		GenerateEmptyRegions	All
GenerateEmptyRegionSet	None, Preserved, Unpreserved, All

Untitled

Class Diagram: Logical View / Main

Course Registration System

Vision

Version 1.0

Revision History

Table	Version	Description	Author
1/Dec/98	Draft	Initial Draft	Sue Gamble
13/Dec/98	1.0	Minor revisions following Peer Review. Added performance requirements.	Sue Gamble

Table of Contents

1 Introduction

1.3 Definitions, Acronyms and Abbreviations

2.3 Product Position Statement

2 Positioning

2.1 Business Opportunity

2.2 Problem Statement

3 Stakeholder and User Descriptions

3.1 Market Demographics

3.2 Stakeholder Summary

3.3 User Summary

3.4 User Environment

3.5 Stakeholder Profiles

3.7 Key Stakeholder / User Needs

3.8 Alternatives and Competition

4 Product Overview

4.1 Product Perspective

4.2 Summary of Capabilities

4.3 Assumptions and Dependencies

4.4 Cost and Pricing

4.5 Licensing and Installation

5 Product Features

5.1 Logon

5.2 Register for Courses

5.3 Course Cancellations

5.4 Student Billings

5.5 Enter, Update, and View Professor Information

5.6 View Student Grades

5.7 Select Courses to Teach

5.8 Enter, Update, and View Student Information

5.9 Record Student Grades

5.10 View Course Catalog Information

5.11 View Course Schedule

5.12 Monitor for Course Full

6 Constraints

7 Quality Ranges

8 Precedence and Priority

9 Other Product Requirements

9.1 Applicable Standards

9.2 System Requirements

9.3 Performance Requirements

9.4 Environmental Requirements

10 Documentation Requirements

10.1 User Manual

10.2 On-line Help

10.3 Installation Guides, Configuration, Read Me File

10.4 Labeling and Packaging

Vision

1 Introduction

1.1 Purpose

The purpose of this document is to define the high-level requirements of the Wylie course registration (C-Registration) system in terms of the needs of the end users.

1.2 Scope

This Vision Document applies to the Wylie course registration system, which will be developed by the Wylie College Information Systems (IT) department. The IT department will develop this client-server system to interface with the existing course catalog database.

The C-Registration System will enable students to register for courses on-line. The C-Registration System allows professors to select their teaching courses and to maintain student grades.

1.3 Definitions, Acronyms and Abbreviations

See the Glossary [5].

1.4 References

Applicable references are:

Course Registration System System Business Case, WyIT388, DRAFT, 1998, Wylie College IT.

Course Billing Interface Specification, WC93332, 1985, Wylie College Press.

Course Catalog Database Specification, WC93422, 1985, Wylie College Press.

Course Registration System Stakeholder Requests Document, WyIT389, V1.0, 1998, Wylie College IT.

Course Registration System Glossary, WyIT406, V1.0, 1998, Wylie College IT.

6. Course Registration System Requirements Attributes Guidelines, WyIT404, V1.0, 1998, Wylie College IT.

2 Positioning

2.1 Business Opportunity

This project will be replacing the entire front-end of the existing course registration system with a state-of-the-art on-line system that allows student and professor access through PC clients.

The current registration system has been in use since 1985 and lacks the capacity to handle the student and course load projected for year 2000. In addition, the current system is outdated mainframe technology, which only supports access through the clerk in the Registration Office. The new system will enable all professors and students to access the system through PCs connected to the Wylie College computer network and through any personal computer connected through the Internet.

The new system will bring Wylie College to the leading edge in course registration systems thus improving the image of the College, attracting more students, and streamlining administrative functions.

2.2 Problem Statement


The problem of	The outdated and largely manual student registration process at Wylie College
affects	Students, professors, and College administration.
The impact of which is	A slow and costly process combined with dissatisfied students and professors.
A successful solution would	Improve the image of the College, attract more students, and streamline administrative registration functions.

2.3 Product Position Statement


For	Wylie College students, professors, and the course registrar
Who	Attend, teach, or administer college courses
The Course Registration System	Is a tool
That	Enables online course registration and access to course and grade information
Unlike	The existing outdated mainframe registration system
Our product	Provides up-to-date information on all courses, registrations, teachers, and grades to all users from any PC connected via the College LAN or internet.

3 Stakeholder and User Descriptions

This section describes the users of the Wylie Course Registration System. There are 3 types of users of the C-Registration System; the Course Registrar, the Students, and the Professors.

3.1 Market Demographics

The University User Community is a large sophisticated community that demands the flexibility and response time that an on-line course registration can provide.

The users are educated, computer literate, and in most cases own personal computers in their homes. The ability to register for courses via personal computers and to review their grades on-line would greatly streamline course registration.

The Course Register works out of the College Admin Headquarters building and is connected to the campus LAN. The students and professors have free access to the LAN through personal computers situated in the campus library and student lounge building.

The initial release of C-Registration will be limited to Wylie College. Marketing subsequent releases to schools, colleges, and universities is under consideration by the Wylie IT Department. As a result, Course Registration will be designed to be expandable and all user community data (i.e. College Name) will be table driven and easily modifiable upon system installation.

3.2 Stakeholder Summary

Name	Represents	Role
IT Executive	IT Department and Wylie College as whole.	Responsible for project funding approval. Monitors project progress.
Registrar	The office of the registrar, administrative and data entry personnel.	Ensures that the system will meet the needs of the registrar, who has to manage the course registration data, including professor and student databases.
Student	Students	Ensures that the system will meet the needs of students.
Professor	Professors	Represents the interests of the faculty (professors).

3.3 User Summary

Name	Description	Stakeholder
Registrar	Manages the database of professors and students, opens and closes courses to registration.	self-represented
Student	Registers for courses, queries for grades and other course information.	self-represented
Professor	Selects courses to teach. Enters student grades.	self-represented

3.4 User Environment

The University User Community is a large sophisticated community that demands the flexibility and response time that an on-line course registration can provide.

3.5 Stakeholder Profiles

3.5.1 IT Executive


Representative	John Whitewood, IT Department Head
Description	Approval Authority
Type	Understands the college’s financial status, and the long term vision of the Board Of Governors.
Responsibilities	Represents the IT Department and the Board Of Governors. Monitor’s project status, and has authority over budget approval. Ensures that the project meets short term and long term goals of the college. Plans for potential re-sale opportunities, and long term maintenance of the system.
Success Criteria	Success is completion of the project within approved budget, and a demonstrated reduction in registrar workload (and therefore reduced cost for the projected future). There must also be a general perception by the Board of Governors that the project meets user needs. The system should be easily modified for use by other colleges, for potential re-sale opportunities. The stakeholder is rewarded by receiving recognition by the Board of Governors.
Involvement	Management reviewer. Budgetary approval signatory. Involved in staff performance reviews.
Deliverables	None.
Comments / Issues	None.

3.5.2 Registrar


Representative	Karen Hansen
Description	User
Type	The Registrar is typically a college-educated professional with full computer skills. The Registrar is trained and experienced with the use of the current batch-oriented registration .
Responsibilities	The Registrar is responsible for administering course registration for each school term. This includes supervising administrative and data entry personnel.
Success Criteria	The registrar’s primary responsibility will be maintaining student and professor databases, and opening/closing courses to registration. The registrar’s office will also be required to perform data entry for students and professors without online access to the system. A successful system is one which substantially reduces the workload on administrative/data entry staff. The primary tasks performed by the registrar must be easy to learn, and quick to perform. Also, the system must have good availability, and reliability, and security. The stakeholder is rewarded by reduction in onerous data entry workload, simplification of existing tasks, and quick convenient access to required information.
Involvement	Management reviewer - especially related to functionality and useability of features required by the Registrar staff.
Deliverables	None
Comments / Issues	None.

3.5.3 Student


Representative	Jane Austen
Description	User
Type	Student Representative to the Board of Governors.
Responsibilities	Ensure that the system will be acceptable to students, both in terms of ease of use and also performance/reliability. Up to 2000 students will use the C-Registration System each school term to register for courses and to review their final grades. The students are typically educated, computer literate, and have access to the Internet. It is expected that each term 10% of the students will be registering at Wylie for the first time and will be unfamiliar with the course registration process.
Success Criteria	Success is when students using the system for the first time, under normal to heavy usage levels, report that the system is easy to use and worked well. The stakeholder is rewarded by receiving recognition by the Board of Governors for his/her involvement, and by being re-elected for another term.
Involvement	Management reviewer - especially features affecting students and usability concerns.
Deliverables	None.
Comments / Issues	None.

3.5.4 Professor


Representative	Dr. Susan Smythe
Description	User
Type	Faculty representative.
Responsibilities	Ensures that the system will be acceptable to professors, both those with and without computer access. The Professors that will use C-Registration are educated, computer literate and familiar with the Wylie registration process. It can be assumed that not all Professors have personal computers in their home and that not all Professors have Internet access.
Success Criteria	Success is when most, if not all, professors are able and willing to use the system to select courses, and enter grades, and when professors report that students are no longer calling to ask about final grades. Success is also when professors are able to query for most course registration data online. The stakeholder is rewarded by receiving peer recognition from other faculty.
Involvement	Management reviewer - especially usability of features affecting professorial functions, such as course selection and grade entry.
Deliverables	None.
Comments / Issues	None.

3.6 User Profiles

Covered under the previous section.

3.7 Key Stakeholder / User Needs

A representative sampling of students, professors, as well as the current Course Registrar completed a User Survey to determine the user problems with the existing course registration system and to solicit user input on improvements. The complete survey results are included in the Stakeholder Requests Document [4]. A summary of the survey results are listed below in order of relative importance from high to low:

Need	Priority	Concerns	Current Solution	Proposed Solutions
Student Course Registration	High	Student Course Registration is slow and inefficient.	Currently students must complete a course registration form and submit it to the Registrar. The Registrar takes up to 2 weeks to process the form and another week to send the confirmation back to the student. At this point, any schedule changes due to full courses or student preference require the entire three week process to be repeated. This provides students limited flexibility in selecting their schedule of courses.	Students would like to have online access to quickly determine course availability and assigned professors.
Early access to Student Grades	Medium	Long delay to get grades, continuous queries to professors.	The final report cards are typically mailed out to the students 8 weeks after the start of the examination period. During this time, students continually phone their professors in attempts to find out their marks sooner	Online access to individual course grades was a recommendation from most students completing the survey.
Low clerical costs	Medium	Clerical effort is time intensive and costly.	The Registrar and 2-3 temporary clerical hires take 400 - 500 hours each term to process the course registration paperwork. Much of this time is spent entering information into the main course registration database and then re-registering students into other courses to resolve schedule conflicts and course availability problems.	Student access to the course registration system would effectively reduce this effort to zero.

3.8 Alternatives and Competition

The user community was unaware of any viable alternatives or off-the-shelf solutions. The user community supported the strategy that the system should be developed internally by the College in order to reduce costs, ensure appropriate functionality, and to guarantee continued support and maintenance on the system.

4 Product Overview

This section provides a high level view of the C-Registration System capabilities, interfaces to the external Billing System and Course Catalog Data Base System, and the system configuration.

4.1 Product Perspective

The C-Registration System will replace the existing mainframe course registration system at Wylie College. The new system will interface with the existing Billing System and Course Catalog Database System as shown in the context diagram below (see Figure 6.1.1).

The C-Registration System will consist of a client component and server component as illustrated in Figure 6.1.2. The server component resides on the Wylie College UNIX Server. The server component must interface with the Billing and Course Catalog Database Systems on the College DEC VAX Main Frame. This interface is supported by an existing Open SQL Interface.

The client component resides on a personal computer. The College PCs will be setup with the client component installed. Any non-college PCs must download the client software from the UNIX Server via the Internet. Once the client component is installed on the PC, the user may access the C-Registration System from the PC through the College LAN or Internet. A valid ID number and password must be entered in order for access to be granted.

Described by Label Below

Figure 6.1.1 C-Registration System Context Diagram

Described by Label Below

Figure 6.1.2 C-Registration System Overview

4.2 Summary of Capabilities

The table in this section identifies the main capabilities of the C-Registration System in terms of benefits and features. The features are further described in section 7 of this document. Refer to the Glossary [5] for a description of terms.

Customer Benefit	Supporting Features
Up-to-date course information	The system accesses the Course Catalog Database for up-to-date information on all courses offered at Wylie College. For each course, the Students and Professors may review the course description, prerequisites, assigned teachers, class locations, and class times.
Up-to-date registration information	All course registrations are immediately logged in the Registration Database to provide up-to-date information on full or cancelled courses.
Easy and timely access to course grades	Students can view their grades in any course simply by providing their user ID and password. Students may access the registration system from any College PC or from their home PC via the internet. Professors enter all student marks directly into the Registration Database from their PCs.
Access from any College PC	Students may access the registration system from any College PC or from their home PC via the internet. Installation of the client component of the C-Registration System on a PC is an easy to follow process using the internet.
Easy and convenient access from your PC at home	Students may access the registration system from any College PC or from their home PC via the internet.
Secure and confidential	A valid user ID and password is required to gain access to the C-Registration System. Student report card information is protected from unauthorized access.
Instant feedback on full or cancelled courses	All course registrations are immediately logged in the Registration Database to provide up-to-date information on full or cancelled courses.

4.3 Assumptions and Dependencies

The following assumptions and dependencies relate to the capabilities of the C-Registration System as outlined in this Vision Document:

o The existing Billing and Course Catalog Database Systems which reside on the College DEC VAX Mainframe will continue to be supported until at least 2005.

o The external interfaces of the Billing and Course Catalog Database Systems are as defined in [2] and [3] and will not be altered.

o It is assumed that the College will continue to operate and support the existing UNIX Server and the DEC VAX Mainframe until at least 2005.

o It is assumed that additional funding will be available by 2005 to replace the legacy Billing and Course Catalog Database Systems.

o Implementation of the new registration system in time for the January 2000 school term is dependent upon funding approval by March 1st, 1999.

4.4 Cost and Pricing

Due to funding constraints, the costs for developing the system must not exceed $1,200,000.

It is anticipated that existing computers of the college will be used as the target machines and that no hardware budget is required.

4.5 Licensing and Installation

There are no licensing requirements for V1.0 of the system, as it will be available only to Wylie College.

Installation of the client component must be available via diskette, CD, or downloadable from the Internet.

Installation of the server component must provide the options for retaining the existing Registration Database (without loss of any data) or generating a new Database.

5 Product Features

This section defines and describes the features of the C-Registration System. Features are the high-level capabilities of the system that are necessary to deliver benefits to the users.

5.1 Logon

Students, professors, and the Course Registrar shall provide a valid ID and password for entry to the C-Registration System. Users are assigned their ID and a temporary password at the time they apply for admission to the College. The system shall enable a user to change their temporary password.

5.2 Register for Courses

The system shall display available courses to the student upon request. The student shall be able to query based upon course name, course code, and department. The system shall accept course registrations from students and shall validate based upon course availability, schedule conflicts, and completed pre-requisite courses. The system shall notify the student immediately if the course registration does not succeed.

The system shall allow the student to change course selections prior to the end of the registration period.

5.3 Course Cancellations

The system shall allow the Registrar to cancel courses. The Registrar typically reviews all courses at the end of the registration period and cancels courses that have no assigned Professor or which have less than 3 registered students. The Course Registrar notifies students of cancelled courses by telephone or mail.

5.4 Student Billings

The system shall send notifications to the Billing System following closure of the Registration period. These notifications shall include student name, address, course selections, and payment due.

5.5 Enter, Update, and View Professor Information

The system shall accept and update professor information, including name, address, phone, fax, and email address. Professor information shall be available to the Professors and Course Registrar for viewing.

5.6 View Student Grades

The system shall enable a student to view one course grade or their entire report card. The system shall protect the student grade information from access from any user other than the student and the Professors.

5.7 Select Courses to Teach

The system shall enable Professors to sign up for courses to teach prior to the end of the Registration period.

5.8 Enter, Update, and View Student Information

The system shall accept and update student information, including student ID, name, address, phone number, and email address. Student information shall be available to the Professors and Course Registrar for viewing. The system shall ensure that a student only has access to his or her own student information. The Registrar maintains student information.

5.9 Record Student Grades

The system shall accept, validate, and retain student grades entered by the Professor.

5.10 View Course Catalog Information

The course catalog information maintained in the Course Catalog Database shall be displayed to the user upon request. Users shall be able to query for information based upon course name, course code, professor name, and department.

5.11 View Course Schedule

The system shall display the complete course schedule for a specific student upon request by that student.

5.12 Monitor for Course Full

The system shall ensure that no course is filled beyond the limit of 10 students.

6 Constraints

In addition to the assumptions and dependencies listed in Section 6, the following constraints apply to the C-Registration System:

The system shall not require any hardware development or procurement.
The course information available is limited to the type of data supported by the existing Course Catalog Database.

7 Quality Ranges

This section defines the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics for the C-Registration System

Availability: The System shall be available 24 hours a day, 7 days a week.

Usability: The System shall be easy-to-use and shall be appropriate for the target market of computer-literate students and professors.

Usability: The System shall include online help for the user. Student and Professor users should not require the use of a hardcopy Manual to use the System.

Maintainability: The System shall be designed for ease of maintenance. All college-specific data should be table-driven and modifiable without recompilation of the System.

8 Precedence and Priority

This section provides some direction on the relative importance of the proposed system features. The features defined in this Vision Document should be included in the first 2 releases of the system. All features critical to student registration are planned for the first release.

As development progresses on this system, the feature attributes (referenced in Section 7 of this document) will be used to weight the relative importance of the features and to plan the release content. The benefit, effort, and risk attributes are used to determine priority of a feature and target release.

It is anticipated that the C-Registration System will be released for general use at Wylie College through 2-4 main releases.

Release 1 must contain as a minimum the basic functionality as listed below:

Logon
Register for Courses
Interface to Course Catalog Database
Maintain Student Information
Maintain Professor Information

Release 2 should include:

Submit Student Grades
View Grades
Select Courses to Teach

The functionality for Release 3 has not yet been determined. It is anticipated that this release will contain enhancements to the existing functionality.

Future replacement of the legacy Billing System and Course Database System is targeted for Release 4 in Year 2005.

9 Other Product Requirements

9.1 Applicable Standards

The desktop user-interface shall be Windows 95/98 compliant.

9.2 System Requirements

The system shall interface with the existing Course Catalog Database System. C-Registration shall support the data format as defined in [3].

The system shall interface with the existing Billing System and shall support the interface as defined in [2].

The server component of the system shall operate on the College Campus Server and shall run under the UNIX operating system.

The client component of the system shall operate on any personal computer with a 486 Microprocessor or better.

The client component of the system shall not require more than 32 MB RAM and 20 MB Disk Space.

The client component of the system shall run on Windows 95, Windows 98, and Microsoft Windows NT.

9.3 Performance Requirements

The system shall support up to 2000 simultaneous users against the central database at any given time, and up to 500 simultaneous users against the local servers at any one time.

The system shall provide access to the legacy Course Catalog Database with no more than a 10 second latency.

The system shall complete 80% of all transactions within 2 minutes.

9.4 Environmental Requirements

None.

10 Documentation Requirements

This section describes the documentation requirements of the C-Registration System.

10.1 User Manual

The User Manual shall describe use of the System from the students’, professors’, and Registrar’s view point. The User Manual shall include:

Minimum System Requirements
Installation of the PC client
Logging On
Logging Off
All System Features
Customer Support Information

The User Manual shall follow the format as defined in the Wylie College User Manual template.

The User Manual should range from 50 - 100 pages. The User Manual page dimensions shall be 7 by 9 inches. The User Manual shall be available as hardcopy and through the online help.

10.2 On-line Help

Online Help shall be available to the user for each system function. Each topic covered in the User Manual shall also be available through the online help.

10.3 Installation Guides, Configuration, Read Me File

The Installation Guide for the server portion shall include:

Minimum System Requirements
Installation Instructions
Configuring College-Specific Parameters
How to Initialize the C-Registration Database
How to Retain the Existing C-Registration Database
Customer Support Information
How to Order Upgrades

The Read Me File shall be available for display following installation. The Read Me File will also reside on disk and be available for viewing at any time by the user. The Read Me File shall include:

New release features

Known bugs and workarounds.

10.4 Labeling and Packaging

The Wylie College logo shall be prominent on the user documentation and splash screens.

As the initial releases are strictly for Wylie College and not the general market, product marketing literature, product packaging, and promotional materials will not be developed.

Brief Description

Actor Brief Descriptions

Preconditions

<pre-condition 1>

Basic Flow of Events

1. <basic flow steps>

2. ..

3. The use case ends.

Alternative Flows

<alternate flow 1>

Subflows

<subflow 1>

Key Scenarios

<scenario 1>

Post-conditions

<post-condition 1>

Extension Points

<extension point 1>

Special Requirements

<supplementary requirement 1>

Additional Information

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Version Description](#2. Version Description)

[2.1 Inventory of Materials](#2.1 Inventory of Materials)

[2.1.1 Handling Considerations](#2.1.1 Handling Considerations)

[2.2 Inventory of Software Contents](#2.2 Inventory of Software Contents)

[2.3 Changes](#2.3 Changes)

[2.4 Adaptation Data](#2.4 Adaptation Data)

[2.5 Installation Instructions](#2.5 Installation Instructions)

[2.6 Known Errors and Problematic Features](#2.6 Known Errors and Problematic Features)

Bill of Materials

1. Introduction

[Provide an overview of the entire document.]

1.1 Purpose

[Describe the purpose of the software to which this document applies**.**]

1.2 Scope

[Identify the recipients for the items identified in the Bill of Materials; for example, the source code is typically not released to all recipients.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Bill of Materials. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Bill of Materials. Identify each document 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.5 Overview

[This subsection describes what the rest of the Bill of Materials contains and explains how the document is organized.]

2. Version Description

2.1 Inventory of Materials

[List all the physical media, such as CDs, floppies, and so on, and associated documentation that make up the software version being released. Identify numbers, titles, abbreviations, dates, versions and release numbers as applicable.]

2.1.1 Handling Considerations

[Describe safeguards for handling the material, such as concerns for static and magnetic fields, and instructions and restrictions regarding duplication and licensing.]

2.2 Inventory of Software Contents

[List all files that make up the software version being released. Identify numbers, titles, abbreviations, dates, versions, and release numbers as applicable.]

2.3 Changes

[List all changes incorporated into the software version since the previous version. Identify, as applicable, the problem reports and Change Requests associated with each change. Describe the effect of each change on software use or operation, as applicable.]

2.4 Adaptation Data

[Identify any site-unique data contained in the software.]

2.5 Installation Instructions

[Provide or reference the following information:

instructions for installing the software

procedures for determining whether the version has been properly installed]

2.6 Known Errors and Problematic Features

[Identify any possible problems or known errors with the software at the time of release. Describe steps that can be taken to recognize, avoid, correct or handle any problematic features.]

Business Architecture Document

[7. Human Resource View](#7. Human Resource View)

[7.1 Remuneration and Incentives](#7.1 Remuneration and Incentives) [7.2 Cultural Aspects](#7.2 Cultural Aspects) [7.3 Competencies](#7.3 Competencies)

[8. Domain View](#8. Domain View)

[9. Geographic View](#9. Geographic View)

[10. Communication View](#10. Communication View)

[11. Architectural Trade-offs](#11. Architectural Trade-offs)

Business Architecture Document

1. Introduction

[The introduction of the Business Architecture Document provides an overview of the entire Business Architecture Document. It needs to include the purpose, scope, definitions, acronyms, abbreviations, references and overview of the Business Architecture Document.]

1.1 Purpose

This document provides a comprehensive architectural overview of the business, using a number of different architectural views to depict different aspects of the business. It is intended to capture and convey the significant architectural decisions which have been made on the business.

[This section defines the purpose of the Business Architecture Document, in the overall project documentation, and briefly describes the structure of the document. The specific audiences for the document should be identified, with an indication of how they are expected to use the document.]

1.2 Scope

[A brief description of what the Business Architecture Document applies to; what is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Architecture Document. This information may be provided by reference to the project’s Business Glossary. Include the operational definitions of business architecture, and application architecture and technical architecture if applicable.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Business Architecture Document. Identify each document 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.5 Overview

[This subsection describes what the rest of the Business Architecture Document contains and explains how the Business Architecture Document is organized.]

2. Architectural Representation

[This section describes what business architecture is for the current business, and how it is represented. Describe the views that will be used to represent the architecture and indicate which stakeholders each view is applicable to. Also describe what types of model elements each view contains.]

3. Architectural Drivers

[This section describes the forces within the business and its environment that shape the business architecture. These are very important for bounding architectural decisions and understanding the consequences of those decisions. Architectural drivers can be classified into architectural goals, which define a desire, and architectural constraints, which imply mandatory compliance to a particular condition.]

4. Market View

[This view defines the markets the business operates in, the current or expected trends and changes in these markets (such as growth or competition), targeted customer profiles and the products and/or services the business offers to its customers (value proposition).]

5. Business Process View

[This section lists business use cases or business scenarios from the business use-case model if they represent some significant, central capability of the final business, or if they have a large architectural coverage they exercise many architectural elements or if they stress or illustrate a specific, delicate point of the business architecture. This view is mandatory.]

5.1 Business Context

[This section shows the business in the context of its environment, including partners and suppliers. Use a business context diagram - showing the business actors and the layers in the business architecture they interact with.]

5.2 Architecturally Significant Business Use Cases

[This section shows the architecturally significant business use cases. Include a diagram showing these business use cases in relation to the business actors and provide the description and flow of events of each of the business use cases. Architecturally significant business use cases are those business use cases that provide broad functional coverage and/or exercise a critical part of the business. Core business use cases typically provide broad coverage.]

6. Organization View

[This view describes the structure of the organization and the manner in which business processes are performed. The architecturally significant parts of the organization are described. This view is mandatory.]

6.1 Organization Structure

[This section provide an overview of the high-level structure of the organization into business systems and the roles and responsibilities of and within these units.]

6.2 Business Use-Case Realizations

[This section illustrates how the organization performs the architecturally significant business use cases by showing how business systems and business workers and entities interact. These business use case realizations provide a mapping between the business use cases and the organization structure.]

6.3 General Patterns of Behavior

[This section describes general patterns of interaction within the business. These can be used to describe generic or reusable processes (or sub-processes) that are performed in many different parts of the organization or under different circumstances. These patterns can be used to show, for example, how a request for a generic resource is submitted and processed.]

7. Human Resource View

[This view describes the architecturally significant human resource aspects of the business. Remuneration and incentives, corporate culture and competencies are described. This view is optional.]

7.1 Remuneration and Incentives

[This section identifies the major remuneration bracket (salary scales) and describes the incentive mechanisms for rewarding above average performance. This aspect of the human resource view is useful for re-aligning the remuneration and incentives policy in order to stimulate organizational change.]

7.2 Cultural Aspects

[This section describes the major cultural characteristics of the organization and the mechanisms for encouraging and enforcing these cultural characteristics. For example, in an organization where teamwork and initiative are considered important aspects of the culture, an annual inter-team volleyball competition and a monthly prize for the best initiative would be mechanisms that enforce these cultural aspects.]

7.3 Competencies

[This section describes the competency profiles within the organization, in terms of skills, experience, attitude and motivation. These profiles can be used to ensure that the skills required by the organization are developed and available in the long term. Education and training mechanisms for ensuring that the required competencies are acquired by and developed within the organization can also be described. Examples include recruitment strategies and special interest groups, respectively.]

8. Domain View

[This section describes the major concepts and information structures to be found within the business and its environment. This view is mandatory. These concepts and information structures (business entities) and their relationships should be shown in class diagrams. Ensure that each business entity has a description. For example, an insurance firm may have business entities such as Customer, PolicyOwner, Beneficiary, Account, Contract, Policy, Claim and InsuredObject.]]

9. Geographic View

[This view describes the geographic distribution of the organization structure and functions. This view is optional. Provide a diagram showing the physical locations at which the business has some sort of presence. These locations can be addresses within the same city, different cities or different countries. Ships can also be counted as physical locations.]

10. Communication View

[This view provides a topological overview of communication within the business. Use class diagram to indicate communicating parties, which could be communicating business processes, organization units, business workers, business actors, physical locations (localities). Associations between these parties indicate the existence of a communication link. The properties of each link can be described. Consider the subject, medium (verbal, email, video-conferencing), frequency, effectiveness, cost, direction (unidirectional or bi-directional), value and risk (impact of being tapped/misused).]

11. Architectural Trade-offs

[This section describes the how the business architecture realizes the architectural goals and constraints described above. For each architectural driver and constraint listed above, discuss how the business architecture supports that driver or constraint. Pay special attention to conflicts, because the architecture is an optimal solution to many conflicting forces.]

Business Case

1. Introduction

[The introduction of the Business Case should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Business Case.]

2. Product Description

[To give a context to the reader, briefly describe the product that is to be developed. Include the name of the system and possibly an acronym, if one is used. Explain what problem it solves and why the development will be worth the effort. Refer to the Vision document.]

3.Business Context

[Define the business context for the product. In which domain is it going to function (for example, telecom or bank) and what market who are the users? State whether the product is being developed to fulfill a contract or if it is a commercial product. If it is a continuation of an existing project, this should also be mentioned.]

4. Product Objectives

[State the objectives for developing the product the reasons why this is worthwhile. This includes a tentative schedule, and some assessment of schedule risks. Clearly defined and expressed objectives provide good grounds for formulating milestones and managing risks; that is, keeping the project on track and ensuring its success.]

5. Financial Forecast

[An example of a possible cost-benefit analysis table is shown below.]


Financial Forecast - <n> years	Value	Totals
Benefits
[revenue enhancement]	$
[expense reduction]	$
[intangibles (good will, visibility)]	$	$

Costs
[capital]	$
[expense]	$	$

ROI (benefits/costs)		%

6. Constraints

[Express the constraints under which the project is undertaken. These constraints impact risk and cost. They could be things like external interfaces that the system must adhere to, standards, certifications or a technical approach employed for strategic reasons, such as using a certain database technology or distribution mechanisms.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Product Description](#2. Product Description)

[3. Business Context](#3. Business Context)

[4. Product Objectives](#4. Product Objectives)

[5. Financial Forecast](#5. Financial Forecast)

[6. Constraints](#6. Constraints)

Business Case

1. Introduction

1.1 Purpose

[Specify the purpose of this Business Case.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Case. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Business Case. 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.5 Overview

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

2. Product Description

3.Business Context

[Define the business context for the product. In which domain is it going to function (for example, telecom or bank) and what market-who are the users? State whether the product is being developed to fulfill a contract or if it is a commercial product. If it is a continuation of an existing project, this should also be mentioned.]

4. Product Objectives

[State the objectives for developing the product- the reasons why this is worthwhile. This includes a tentative schedule, and some assessment of schedule risks. Clearly defined and expressed objectives provide good grounds for formulating milestones and managing risks; that is, keeping the project on track and ensuring its success.]

5. Financial Forecast

[For a commercial software product, the Business Case should include a set of assumptions about the project and the order of magnitude return on investment (ROI) if those assumptions are true. For example, the ROI will be a magnitude of five if completed in one year, two if completed in two years, and a negative number after that. These assumptions are checked again at the end of the elaboration phase when the scope and plan are known with more accuracy. The return is based on the cost estimate and the potential revenue estimates.

The resource estimate encompasses the entire project, through to delivery. This estimate is updated at each phase and each iteration, and becomes more accurate as each iteration is completed.

An explanation of the basis of estimates should be included.]

6. Constraints

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

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Business Use Case Modeling Guidelines](#2. Business Use Case Modeling Guidelines)

[2.1 General Guidelines](#2.1 General Guidelines)

[2.2 How to Describe a Business Use Case](#2.2 How to Describe a Business Use Case)

[2.3](#1.3 Definitions, Acronyms and Abbreviations) [How to Describe a Business Goal](#2.3 How to Describe a Business Goal)

[3. Business Analysis Modeling Guidelines](#3. Business Analysis Modeling Guidelines)

[3.1 General Guidelines](#3.1 General Guidelines)

[3.2 How to Describe Business Systems](#3.2 How to Describe Business Systems)

[3.3](#1.3 Definitions, Acronyms and Abbreviations) [How to Describe a Business Use Case Realization](#3.3 How to Describe a Business Use Case Realization)

[3.4](#1.4 References) [How to Describe a Business Worker](#3.4 How to Describe a Business Worker)

[3.5](#1.5 Overview) [How to Describe a Business Entity](#3.5 How to Describe a Business Entity)

[3.6](#1.5 Overview) [How to Describe a Business Event](#3.6 How to Describe a Business Event)

[4. Business Rules Guidelines](#4. Business Rules Guidelines)

[5. UML Stereotypes](#5. UML Stereotypes)

Business Modeling Guidelines

1. Introduction

[The introduction of the Business Modeling Guidelines should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Business Modeling Guidelines.]

1.1 Purpose

[Specify the purpose of this Business Modeling Guidelines.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Modeling Guidelines. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Business Modeling Guidelines. 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.5 Overview

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

2. Business Use Case Modeling Guidelines

2.1 General Guidelines

[The section describes which notation to use in the business use case model. For example, you may have decided not to use extends-relationships between business use cases.]

2.2 How to Describe a Business Use Case

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business use case.]

2.3 How to Describe a Business Goal

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business goal.]

3. Business Analysis Modeling Guidelines

3.1 General Guidelines

[[This section describes which notation to use in the business analysis model. For example, you may have decided not to use generalization-relationships between classes.]

3.2 How to Describe Business Systems

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business system (if any).]

3.3 How to Describe a Business Use Case Realization

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business use case realization.]

3.4 How to Describe a Business Worker

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business worker.]

3.5 How to Describe a Business Entity

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business entity.]

3.6 How to Describe a Business Event

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe each business event.]

4. Business Rules Guidelines

[This section gives rules, recommendations, and style issues, and provides instructions on how to describe business rules, either in document form or in model form.]

5. UML Stereotypes

[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 for business, in general, or the type 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.]

Business Rules

1. Introduction

[The introduction of the Business Rules Document 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 Rules Document .]

1.1 Purpose

[Specify the purpose of this document.]

1.2 Scope

[A brief description of the scope of this Business Rules Document; 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 Rules Document . 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 Rules Document 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 <aBusinessRule>

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

2.2 <anotherBusinessRule>

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

2.3 <aGroupofBusinessRules>

[Sometimes it is useful to organize Business Rules into groups to improve readability. For example, if the problem domain contains Business Rules related to both accounting and building construction (as would be the case if we were developing a system to manage construction projects), presenting the Business Rules from the two different sub-domains might prove confusing to the reader. To solve this problem, we use groupings of Business Rules. In presenting the grouping of Business Rules, provide a short description that helps the reader understand what <aGroupOfBusinessRules> represents. When using the groups, or categories, be sure that it will be very clear which group/category a business rule belongs to. Business Rules presented within the group should be organized alphabetically for easy access.]

2.3.1 <aGroupBusinessRule>

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

2.3.2 <anotherGroupBusinessRule>

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

2.4 <aSecondGroupOfBusinessRules>

2.4.1 <yetAnotherGroupBusinessRule>

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

2.4.2 <andAnotherGroupBusinessRule>

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

Business Use-Case Realization Specification: <Business Use-Case

Name>

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Workflow Realization](#2. Workflow Realization)

[3. Derived Requirements](#3. Derived Requirements)

Business Use-Case Realization Specification: <Business Use-Case Name>

1. Introduction

[The introduction of the Business Use-Case Realization Specification should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Business Use-Case Realization Specification.]

[Note: This document template assumes that the business use-case realization is partly described within a Rational Rose model; this means that the business use case’s name and brief description is within the Rose model, and that this document should be linked as an external file to the business use case. This document should contain additional properties of the business use-case realization that are not in the Rose model.]

1.1 Purpose

[Specify the purpose of this Business Use-Case Realization Specification]

1.2 Scope

[A brief description of the scope of this Business Use-Case Realization Specification; what Use-Case model(s) it is associated with, and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Use-Case Realization Specification. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Business Use-Case Realization Specification. 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.5 Overview

[This subsection should describe what the rest of the Business Use-Case Realization Specification contains and explain how the document is organized.]

2. Workflow Realization

[A textual description of how the business use case is realized in terms of collaborating objects. Its main purpose is to summarize the diagrams connected to the business use case and to explain how they are related.]

3. Derived Requirements

[A textual description that collects all requirements, such as automation requirements, on the business use-case realization that are not considered in the business use-case model but need to be taken care of when building the system.]

Business Use-Case Specification:

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Business Use Case Name](#2. Business Use Case Name)

[2.1 Brief Description](#2.1 Brief Description)

[3. Goals](#3. Goals)

[4. Performance Goals](#4. Performance Goals)

[4.1 <name of performance goal>](#4.1 <name of performance goal>)

[5. Workflow](#5. Workflow)

[5.1 Basic Workflow](#5.1 Basic Workflow)

[5.1.1 <name of workflow step>](#5.1.1 <name of workflow step>)

[5.2 Alternative Workflows](#5.2 Alternative Workflows)

[5.2.1 <name of workflow step>](#5.2.1 <name of workflow step>)

[6. Category](#6. Category)

[7. Risk](#7. Risk)

[8. Possibilities](#8. Possibilities)

[9. Process Owner](#9. Process Owner)

[10. Preconditions](#10. Preconditions)

[10.1 <Precondition One>](#10.1 <Precondition One>)

[11. Postconditions](#11. Postconditions)

[11.1 <Postcondition One>](#11.1 <Postcondition One>)

[12. Special Requirements](#12. Special Requirements)

[12.1 <name of special requirement>](#12.1 <name of special requirement>)

[13. Extension Points](#13. Extension Points)

[13.1 <name of extension point>](#13.1 <name of extension point>)

Business Use-Case Specification: <Business Use-Case Name>

1. Introduction

[The introduction of the Business Use-Case Specification should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Business Use-Case Specification.]

[Note: If you are not using Rational Requisite Pro, then this document template should be used to capture the actual Business Use Case including the workflow, special requirements, and performance goals of the Business Use Case. This file should be linked to the corresponding business use case in the Rose model.

If you use SoDA then this document is used as input to the business use-case report that combines this content with use-case diagrams from Rose.]

1.1 Purpose

[Specify the purpose of this Business Use-Case Specification]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Use-Case Specification. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Business Use-Case Specification. 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.5 Overview

[This subsection should describe what the rest of the Business Use-Case Specification contains and explain how the document is organized.]

2. Business Use Case Name

2.1 Brief Description

[The description should briefly convey the purpose of the business use case. A single paragraph should suffice for this description.]

3. Goals

[A specification of the measurable goals or objectives of the business use case.]

4. Performance Goals

[A specification of the metrics relevant to the business use case and a definition of the goals of using those metrics.]

4.1 <name of performance goal>

[A brief description of the performance goal.]

5. Workflow

[A textual description of the workflow the business use case represents. The workflow should describe what the business does to deliver value to a business actor, not how the business solves its problems.

Only one level of workflow steps is indicated in the subsections below, but you may add more levels if necessary.]

5.1 Basic Workflow

5.1.1 <name of workflow step>

[A brief description of the workflow step.]

5.2 Alternative Workflows

5.2.1 <name of workflow step>

[A brief description of the workflow step.]

6. Category

[Whether the business use case is of the category ‘core’, ‘supporting’, or ‘management’.]

7. Risk

[A specification of the risks of executing and/or implementing the business use case.]

8. Possibilities

[A description of the estimated improvement potential of the business use case.]

9. Process Owner

[A definition of who the owner of the business process is, the person who manages the changes and plans for changes.]

10. Preconditions

[A precondition of a business use case is a condition that must be true before performing the business use case.]

10.1 <Precondition One>

11. Postconditions

[A postcondition of a business use case is a condition that will be true after performing the business use case.]

11.1 <Postcondition One>

12. Special Requirements

[The special requirements of the business use case are included here. These are requirements not covered by the workflow as it has been described in the sections above.]

12.1 <name of special requirement>

[A brief description of the special requirement.]

13. Extension Points

[Extension points of the business use case.]

13.1 <name of extension point>

[Definition of the location of the extension point in the flow of events.]

Business Vision

1. Introduction

The introduction of the Business Vision provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Business Vision.]

1.1 Purpose

[Specify the purpose of this Business Vision document**.**]

1.2 Scope

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

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Business Vision document. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Business Vision. Identify each document 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.5 Overview

[This subsection describes what the rest of the Business Vision contains and explains how the document is organized.]

2. Positioning

2.1 Business Opportunity

[Briefly describe the business opportunity being met by this project.]

2.2 Problem Statement

[Provide a statement summarizing the problem being solved by this project. The following format may be used:]


The problem of	[describe the problem]
affects	[who are the stakeholders affected by the problem?]
the impact of which is	[what is the impact of the problem?]
a successful solution would be	[list some key benefits of a successful solution]

2.3 Business Position Statement

[This section is optional. If you are implementing a new business this section may be useful to help sell the idea. Provide an overall statement summarizing, at the highest level, the unique position the business intends to fill in the marketplace. The following format may be used:]


For	[target customer]
Who	[statement of the need or opportunity]
The (business name)	is a [business category]
That	[statement of key benefit; that is, what is the compelling reason to do business with?]
Unlike	[primary competitive alternative]
This business	[statement of primary differentiation]

[A business position statement communicates the business idea to all concerned.]

3. Stakeholder and Customer Descriptions

[To effectively provide products and services that meet your stakeholders’ and users’ real needs, it is necessary to identify and involve all of the stakeholders as part of the Business Modeling process. You must also identify the customers and partners of the business and ensure that they are adequately represented by the stakeholder community. This section provides a profile of the stakeholders involved in the project and the key problems that they perceive to be addressed by the proposed solution. It does not describe their specific requests or requirements as these are captured separately. Instead it provides the background and justification for why the requirements are needed.]

3.1 Market Demographics

[Summarize the key market demographics that motivate your business decisions. Describe and position target market segments. Estimate the market’s size and growth by using the number of potential customers, or the amount of money your customers spend trying to meet needs that your products or services would fulfill. Review major industry trends and technologies. Answer these strategic questions:

What is your organization’s reputation in these markets?

What would you like it to be?

How do current products and services support your goals?]

3.2 Stakeholder Profiles

[Describe each stakeholder in the business here by filling in the following table. Remember that stakeholder types can be as divergent as customers, departments, and technical developers. A thorough profile would cover the following topics for each type of stakeholder.]

3.2.1 <Stakeholder Name>


Representative	[Who is the stakeholder representative to the project? (This is optional if documented elsewhere.) What we want here is names.]
Description	[Brief description of the stakeholder type.]
Type	[Qualify the stakeholder’s expertise and background.]
Responsibilities	[List the stakeholder’s key responsibilities with regard to the changes being made that is, their interest as a stakeholder.]
Success Criteria	[How does the stakeholder define success? How is the stakeholder rewarded?]
Involvement	[How is the stakeholder involved in the project? Relate where possible to the Rational Unified Process roles that is, Business Use Case Model Reviewer, and so on.]
Deliverables	[Are there any additional deliverables required by the stakeholder? These could be project deliverables or outputs from the system under development.]
Comments / Issues	[Problems that interfere with success and any other relevant information go here.]

3.3 Customer Profiles

[Describe each unique customer of the business here by filling in the following table for each customer type. A thorough profile covers the following topics for each type of customer:]

3.3.1 <Customer Name>


Representative	[Who is the customer representative to the project? (This is optional if documented elsewhere.) This often refers to the Stakeholder that represents the set of customers; for example, Stakeholder: John Smith.]
Description	[A brief description of the customer type.]
Type	[Qualify the customer’s expertise, background and degree of sophistication.]
Success Criteria	[How does the customer define success? How is the customer rewarded?]
Involvement	[How the customer is involved in the project? Relate where possible to the Rational Unified Process roles that is, Business Use Case Model Reviewer, and so on.]
Deliverables	[Are there any deliverables the customer produces and, if so, for whom?]
Comments / Issues	[Problems that interfere with success and any other relevant information go here. These include trends that make the customer’s job easier or more difficult.]

3.4 Customer Environment

[Detail the working environment of the target customer. Here are some suggestions:

Number of people involved in completing the task? Is this changing?
How long is a task cycle? Amount of time spent in each activity? Is this changing?
Any unique environmental constraints: mobile, outdoors, in-flight, and so on.?
Which processes are in use today? Future processes?
What other organizations does the customer do business with? Does your business need to integrate with them?

This is where extracts from the Business Model could be included to outline the task and business workers involved, and so on.]

3.5 Key Stakeholder or Customer Needs

[List the key problems with existing solutions as perceived by the stakeholder. Refer back to the Problem Statement and Business Position Statement. Clarify the following issues for each problem:

What are the reasons for this problem?

How is it solved now?

What solutions does the user want?]

[It is important to understand the relative importance the stakeholder places on solving each problem. Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like addressed.

Fill in the following table-if using Rational RequisitePro to capture the Needs, this could be an extract or report from that tool.]


Need	Priority	Concerns	Current Solution	Proposed Solutions
Broadcast messages

3.6 Alternatives and Competition

[Identify alternatives the stakeholder perceives as available. These alternatives can include doing business with competitors, finding a procedural solution or simply maintaining the status quo. List any known competitive choices that exist or may become available. Include the major strengths and weaknesses of each competitor as perceived by the stakeholder.]

4. Business Modeling Objectives

[List here the objectives of the business modeling effort. Consider the following three categories for identifying objectives:

Timeliness of operations How long does it take for the business to perform its operations?
Cost of doing business How much does it cost to provide each service?
Quality of business operations How well does the business deliver its services to customers?]

5. Precedence and Priority

[Define the priority of the different objectives.]

6. Other Requirements

[At a high-level, list applicable standards, specific infrastructure requirements, quantitative requirements, and environmental restrictions.]

6.1 Constraints

[List all constraints that the business must operate under. These can include legal, regulatory standards, quality and safety standards (ISO, FDA, DoD).]

6.2 Applicable Standards

[List all standards with which the business must comply. If the business is not allowed to operate unless it conforms to a certain standard then that should be listed as a constraint.]

6.3 Quantifiers

[Quantitative requirements specify boundaries within which the business must perform its operations, such as time, cost, quality, throughput, flexibility, supportability etc.]

6.4 Infrastructure Requirements

[Describe any infrastructure required to support the business operations.]

6.5 Environmental Requirements

[Detail any applicable environmental requirements.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Software Configuration Management](#2. Software Configuration Management)

[2.1 Organization, Responsibilities, and Interfaces](#2.1 Organization, Responsibilities and Interfaces)

[2.2 Tools, Environment, and Infrastructure](#2.2 Tools, Environment and Infrastructure)

[3. The Configuration Management Program](#3. The CM Program)

[3.1 Configuration Identification](#3.1 Configuration Identification)

[3.1.1 Identification Methods](#3.1.1 Identification Methods)

[3.1.2 Project Baselines](#3.1.2 Project Baselines)

[3.2 Configuration and Change Control](#3.2 Configuration and Change Control)

[3.2.1 Change Request Processing and Approval](#3.2.1 Change Request Processing and Approval)

[3.2.2 Change Control Board (CCB)](#3.2.2 Change Control Board (CCB))

[3.3 Configuration Status Accounting](#3.3 Configuration Status Accounting)

[3.3.1 Project Media Storage and Release Process](#3.3.1 Project Media Storage and Release Process)

[3.3.2 Reports and Audits](#3.3.2 Reports and Audits)

[4. Milestones](#4. Milestones)

[5. Training and Resources](#5. Training and Resources)

[6. Subcontractor and Vendor Software Control](#6. Subcontractor and Vendor Software Control)

Configuration Management Plan

1. Introduction

[The introduction of the Configuration Management Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Configuration Management Plan.]

1.1 Purpose

[Specify the purpose of this Configuration Management Plan.]

1.2 Scope

[A brief description of the scope of this Configuration Management Plan; what model it is associated with and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Configuration Management Plan. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Configuration Management Plan. Identify each document 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.5 Overview

[This subsection describes what the rest of the Configuration Management Plan contains and explains how the document is organized.]

2. Software Configuration Management

2.1 Organization, Responsibilities, and Interfaces

[Describe who is going to be responsible for performing the various Configuration Management (CM) activities described in the CM Process Discipline.]

2.2 Tools, Environment, and Infrastructure

[Describe the computing environment and software tools to be used in fulfilling the CM functions throughout the project or product lifecycle.

Describe the tools and procedures required used to version control configuration items generated throughout the project or product lifecycle.

Issues involved in setting up the CM environment include:

anticipated size of product data

distribution of the product team

physical location of servers and client machines]

3. The Configuration Management Program

3.1 Configuration Identification

3.1.1 Identification Methods

[Describe how project or product artifacts are to be named, marked, and numbered. The identification scheme needs to cover hardware, system software, Commercial-Off-The-Shelf (COTS) products, and all application development artifacts listed in the product directory structure; for example, plans, models, components, test software, results and data, executables, and so on.]

3.1.2 Project Baselines

[Baselines provide an official standard on which subsequent work is based and to which only authorized changes are made.

Describe at what points during the project or product lifecycle baselines are to be established. The most common baselines would be at the end of each of the Inception, Elaboration, Construction, and Transition phases. Baselines could also be generated at the end of iterations within the various phases or even more frequently.

Describe who authorizes a baseline and what goes into it.]

3.2 Configuration and Change Control

3.2.1 Change Request Processing and Approval

[Describe the process by which problems and changes are submitted, reviewed, and dispositioned.]

3.2.2 Change Control Board (CCB)

[Describe the membership and procedures for processing change requests and approvals to be followed by the CCB.]

3.3 Configuration Status Accounting

3.3.1 Project Media Storage and Release Process

[Describe retention policies, and the back-up, disaster, and recovery plans. Also describe how the media is to be retained-online, offline, media type, and format.

The release process should describe what is in the release, who it is for, and whether there are any known problems and any installation instructions.]

3.3.2 Reports and Audits

[Describe the content, format, and purpose of the requested reports and configuration audits.

Reports are used to assess the “quality of the product” at any given time of the project or product lifecycle. Reporting on defects based on change requests may provide some useful quality indicators and, thereby, alert management and developers to particularly critical areas of development. Defects are often classified by criticality (high, medium, and low) and could be reported on the following basis:

Aging (Time-based Reports): How long have defects of the various kinds been open? What is the “lag time’’ of when in the lifecycle defects are found versus when they are fixed?

Distribution (Count Based Reports): How many defects are there in the various categories by owner, priority or state of fix?

Trend (Time-related and Count-related Reports): What is the cumulative number of defects found and fixed over time? What is the rate of defect discovery and fix? What is the “quality gap” in terms of open versus closed defects? What is the average defect resolution time?]

4. Milestones

[Identify the internal and customer milestones related to the project or product CM effort. This section should include details on when the CM Plan itself is to be updated.]

5. Training and Resources

[Describe the software tools, personnel, and training required to implement the specified CM activities.]

6. Subcontractor and Vendor Software Control

[Describe how software developed outside of the project environment will be incorporated.]

Context-Free Interview Script

Context-Free Interview Script (for Stakeholder Requests)

[The Generic Interview in this template features questions designed to elicit an understanding of the stakeholder or user’s problems and environment. These questions explore the functionality, usability, reliability, performance and supportability requirements for the application. As a result of using the Generic Interview, the developer or analyst will gain knowledge of the problem being solved, as well as an understanding of the stakeholder or user’s insights on the characteristics of successful solutions.]

2. Establish Stakeholder or User Profile

[Ask questions such as the following:]

Name: Company / Industry:

Job Title:

What are your key responsibilities?

What deliverables do you produce? For whom?

How is success measured?

Which problems interfere with your success?

Which, if any, trends make your job easier or harder?

3. Assessing the Problem

For which <application type> problems do you lack good solutions?

What are they? [Tip: Keep asking “Anything else?]

Ask for each problem:

Why does this problem exist?

How do you solve it now?

How would you like to solve it?

4. Understanding the User Environment

Who are the users?

What is their educational background?

What is their computer background?

Are users experienced with this type of application?

Which platforms are in use? What are your plans for future platforms?

Which additional applications do you use that we need to interface with?

What are your expectations for usability of the product?

What are your expectations for training time?

What kinds of hard copy and on-line documentation do you need?

5. Recap for Understanding

You have told me [list stakeholder-described problems in your own words]:

Does this represent the problems you are having with your existing solution?

What, if any, other problems are you experiencing?

6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions)

[If not addressed] Which, if any, problems are associated with:

[List any needs or additional problems you think should concern the stakeholder or user]

Ask for each suggested problem:

Is this a real problem?

What are the reasons for this problem?

How do you currently solve the problem?

How would you like to solve the problem?

How would you rank solving these problems in comparison to others you’ve mentioned?

7. Assessing Your Solution (if applicable)

What if you could…[summarize the key capabilities of your proposed solution]

How would you rank the importance of these?

8. Assessing the Opportunity

Who needs this application in your organization?

How many of these types of users would use the application?

How would you value a successful solution?

9. Assessing Reliability, Performance and Support Needs

What are your expectations for reliability?

What are your expectations for performance?

Will you support the product, or will others support it?

Do you have special needs for support? What about maintenance and service access?

What are the security requirements?

What are the installation and configuration requirements?

What are the special licensing requirements?

How will the software will be distributed?

What are the labeling and packaging requirements?

Other Requirements

Which, if any regulatory or environmental requirements or standards must be supported?

Can you think of any other requirements we should know about?

10. Wrap-Up

Are there any other questions I should be asking you?

If I need to ask follow up questions, may I give you a call?

Would you be willing to participate in a requirements review?

11. Analyst’s Summary

[Summarize below the three or four highest priority problems for this user/stakeholder]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Overview)

[1.4 Overview](#1.4 Definitions, Acronyms and Abbreviations)

[2. References](#2. References)

[3. Deployment Planning](#3. Deployment Planning)

[3.1 Responsibilities](#3.1 Responsibilities)

[3.2 Schedule](#3.2 Schedule)

[4. Resources](#4. Resources)

[4.1 Facilities](#4.1 Facilities)

[4.2 Hardware](#4.2 Hardware)

[4.3 The Deployment Unit](#4.3 The Deployment Unit)

[4.3.1 Support Software](#4.3.1 Support Software)

[4.3.2 Support Documentation](#4.3.2 Support Documentation)

[4.3.3 Support Personnel](#4.3.3 Support Personnel)

[5. Training](#5. Training)

Deployment Plan

1. Introduction

[Provide an overview of the entire document.]

1.1 Purpose

[Describe the purpose of the software to which this document applies**.**]

1.2 Scope

[Identify the recipients for the items identified in the Deployment Plan.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Deployment Plan. This information may be provided by reference to the project’s Glossary.]

1.4 Overview

[Explain how this document is organized.]

2. References

[This subsection provides a complete list of all documents referenced elsewhere in the Deployment Plan. Identify each document 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.]

3. Deployment Planning

[Describe all activities performed in deploying the product to the customer. Activities include planning, beta testing, preparing items to be delivered, packaging, shipping, installation, training, and support.]

3.1 Responsibilities

[Identify the responsibilities of both the customer and the development team in preparing for deployment. Of particular relevance in this section is the description of the customer’s involvement in acceptance tests and the process for handling any discrepancies.]

3.2 Schedule

[Describe the schedule and milestones to conduct the deployment activities. Deployment milestones need to conform to the project milestones.

Take into account the following Deployment workflow details:

*- Planning the Deployment

Developing the Supporting Material

Managing the Acceptance Tests

Acceptance Testing at the Development Site

Acceptance Testing at the Deployment Site

Producing the Deployment Unit

Managing the Beta Program

Managing the Product Mass Production and Packaging

Making the Product Accessible Over the Internet]*

4. Resources

[List the resources and their sources required to carry out the planned deployment activities.]

4.1 Facilities

[As applicable, describe the facilities required to test and deploy the software. Facilities may include special buildings or rooms with raised flooring, power requirements, and special features to support privacy and security requirements.]

4.2 Hardware

[Identify the hardware required to run and support the software. Specify model, versions, and configurations. Provide information about manufacturer support and licensing.]

4.3 The Deployment Unit

[List the software and documentation provided as part of the deliverable product.]

4.3.1 Support Software

[As applicable, describe all software needed to support the deliverable product, such as tools, compilers, test tools, test data, utilities, Configuration Management tools, databases, data files, and so on.]

4.3.2 Support Documentation

[As applicable, describe the documentation required to support the delivered product, including design descriptions, test cases and procedures, user manuals, and so on.]

4.3.3 Support Personnel

[As applicable, describe the personnel, and their skill levels, required to support the deliverable product.]

5. Training

[Describe the plan and inputs for training the end users such that they can use and adapt the product as required.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. General Design and Implementation Guidelines](#2. General Design and Implementation Guidelines)

[3. Database Design Guidelines](#3. Database Design Guidelines)

[4. Architectural Design Guidelines](#4. Architectural Design Guidelines)

[5. Mechanism Guidelines](#5. Programming Guidelines)

[6. UML Stereotypes](#6. UML Stereotypes)

Design Guidelines

1. Introduction

[The introduction of the Design Guidelines provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Design Guidelines document.]

1.1 Purpose

The purpose of this document is to communicate the design standards, conventions, and idioms to be used in the design of the system.

[Enter any additional description of the objectives of the Design Guidelines.]

1.2 Scope

[A brief description of what the Design Guidelines applies to; what is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Design Guidelines. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Design Guidelines. Identify each document by title, report number if applicable, date, and publishing organization. Eventually the section may be structured in subsections: external documents versus internal documents or government documents versus non-government documents and so on. 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.5 Overview

[This subsection describes what the rest of the Design Guidelines contains and explains how the document is organized.]

2. General Design and Implementation Guidelines

[This section describes the principles and strategies to be used when designing and implementing the system. In most cases, you will need strategies for the following:

Mapping from Design to Implementation

You must specify how the design is mapped to the implementation; both at the package level and at the class level.

Specifying Interfaces on Subsystems

When you are developing the system from the top down, it is important to narrow the visible interfaces to the subsystems. This enables developers to change the parts of a subsystem that are not visible outside.

Documenting Operations

It is important that you decide on a standard way of describing operations. An operation consists of the name, the arguments, a brief description, and an implementation specification. Ask yourself the following questions when documenting operations.

- Will all (formal) arguments be documented? We suggest they need to be, although experience shows that they might be difficult to maintain because they are redundant with the code.

- Will the argument type need to be documented? Generally we suggest it should be.

Will you use any naming convention for the operations in a class? For example, in C++ you might choose to prefix private and public operations in different ways. This makes the operations easier to understand.

Documenting Messages

We suggest you do not document all actual parameters in the message. It’s redundant with the code and might prove difficult to maintain.

Detecting, Handling, and Reporting Faults

You must have a strategy for fault management. Your strategy depends to a large degree on the programming language you have chosen. Many languages feature fault-management support, such as Ada “exceptions”. The fault-management strategy you choose will influence behavior in the design objects. For example, you must decide whether to use status parameters in each operation that tell if the operation has succeeded or to let the object raise an “exception”, as in Ada.

If necessary, you can apply different fault-management strategies to different parts of a system. The important thing is that you have at least one strategy and, for all possible strategies, that it is clear when to use them.

Memory Management

Memory management means ensuring that memory is always available. This implies that you remove objects not referenced by any other object so that the memory they occupy can be used for new objects. How you solve this depends on the implementation language. In some systems it will be automatically solved, for example, by a garbage collector; but in others you must carry out the memory management yourself in the programming language. In other words, you will have to define when and how to clear any memory occupied by unreferenced objects.

Software Distribution

If you have a system that will be distributed among several physical nodes, its objects must also be distributed among the nodes. Before design starts, prepare this work by specifying general strategies for how objects need to be distributed, and how to use the present inter-process communication technology. If the target environment is unfamiliar, it might prove useful to prototype solutions.

How to Represent Reusable Components

Before starting design, you must decide which reusable components, reusable component systems, libraries or “Commercial-Off-the-Shelf” (COTS) products to use. You must also decide if, and how, these need to be modeled in design.

Designing Persistent Classes

Ideally, the database-management system you choose, whether relational or object-based, should not affect the design model very much. Persistence needs to be provided by a framework that makes persistence as transparent as possible.

Most persistence design work focuses on identifying and resolving performance problems. To make this easier, do the following:

Identify the lifecycle of each persistent object: when it will be created, read, updated, and deleted within Use-Case Realizations.

Identify transaction boundaries within Use-Case Realizations.

There is some iteration between Database Design and the design of persistent classes: depending on the database, some associations between design classes are either clumsy to support in the database, or create such a performance problem that some adaptation of the Design Model is necessary.

Transaction Management

This section discusses the strategies used to manage transactions, including how transaction management will be accomplished. Discuss the interaction of transaction management and Fault Management, including how the system recovers from transaction failures or aborted transactions.

If there are special restrictions imposed by the transaction management mechanism (such as MTS requiring “stateless” objects) that affect the architecture of the system, they need to be discussed here.

Special Use of Language Features

This section describes any restrictions or policies on the language features used. For example, you may limit the use of pointers in an embedded real-time system.

Program Structure

This section includes guidelines for code layout, comments, naming conventions, module packaging, and interface conventions.

Algorithm Guidelines

This section describes particular algorithms selected for use in the system by the software architect. The section also describes the circumstances under which use of the algorithm is appropriate. This section does not document particular applications of an algorithm in the system-that is the province of the Software Architecture Document and the Design Model-rather it is intended to guide and constrain the designer’s choice.

Hardware Interfacing

This section describes guidelines for hardware interfacing, including use of interrupts, memory, type representation, and so forth.

System Modification and Build Guidelines

This section describes guidelines for software modification, special support hardware or software needed, edit, compile, and integration guidelines, and so on. This section may also contain configuration and change control guidelines elaborated from the Configuration Management Plan.

System Diagnostic Guidelines

This section describes guidelines for system setup to diagnose problems, based on the fault detection and management strategy adopted. This section describes how any special diagnostic hardware or software that may be used, how to invoke traces and profilers, and how to collect diagnostic data.]

3. Database Design Guidelines

[This section gives rules and recommendations for the database design. The following topics need to be discussed:

Mapping from persistence classes to database structures, including how to handle potential conflicts such as many-to-many associations in the design model and inheritance.

Mapping of design class attributes to database primitive data types.

Using the Process View to describe the processes and inter-process communication used by the persistence mechanism.

Using the Deployment View to describe the physical distribution of data across nodes.

Naming conventions for database structures; for example, tables, stored, stored procedures, triggers, tablespaces, and so forth.]

4. Architectural Design Guidelines

[This section gives rules and recommendations for software architecture design. They are organized around the different architectural views: Use Case, Logical, Implementation, Process, and Deployment views. The rules mostly deal with decomposition. For example, the Implementation View guidelines specify the rules for packaging modules into subsystems, layering subsystems, and so on. See the Software Architecture Document, the section titled Analysis & Design in particular*.*]

5. Mechanism Guidelines

[For each significant mechanism put in place in the low-level layers of the system, you need to have a programmers’ guide that shows the interface of the mechanism and explains how to use it. These include a user’s guide of the timer mechanism, of the inter-process communication mechanism, of the recording mechanism, of the database-management system, and so on.]

6. UML Stereotypes

[This section contains or reference 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-stereotypes already known or discovered to be useful for constructing Design models. 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, when it is felt that their use makes models significantly easier to understand, or when it ensures that common types of entities, roles, relationships, or patterns are uniformly modeled and understood. This section may be empty if no additional stereotypes, other than those predefined by the UML and the Rational Unified Process, are considered necessary.]

Development Case

1. Introduction

This document tailors software development process for the <Project Name> project.

2. Artifacts

[Describe the artifacts that will be produced as part of the development process. The following is provided as an example:]


Artifacts Created Every Iteration	Representation/Tools Used

Iteration Assessment	Email
Iteration Plan	WikiWeb
Work Order	Rational ClearQuest


Inception Artifacts (revised/maintained in later phases/iterations as required)	Representation/Tools Used

Vision	Microsoft Word
Use Case Model	Rational XDE
Analysis Model and architectural proof-of-concept models	Whiteboard
Project Plan	WikiWeb
Supplementary Specifications	Rational RequisitePro (Cut and pasted into Vision every iteration for customer review)


Elaboration Artifacts (revised/maintained in later phases/iterations as required)	Representation/Tools Used

Design Model Implementation Model Deployment Model	RationalXDE
Implementation	<compiler, test tools, >


Construction Artifacts (revised/maintained in later phases/iterations as required)	Representation/Tools Used

- There are no artifacts unique to the construction iterations.


Transition Artifacts	Representation/Tools Used

User documentation	TBD

3. Additional Guidelines/Procedures

[Describe any additional guidelines/procedures applicable to the project. For example, is there an approval process? Are code inspections applied? Is pair programming applied in place of code reviews? Which reviews require a review record to be retained?]

Revision History


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

Table of Contents

Introduction
Purpose
Scope
Definitions, Acronyms, and Abbreviations
References
Overview
[Overview of the Development Case](#Overview of the Development Case)
Lifecycle Model
[Disciplines](#Overview: Disciplines)
[Discipline Configuration](#Overview: Configuration)
[Artifact Classification](#Artifact Classification)
[Review Procedures](#Review Procedures)
[Sample Iteration Plans](#Sample Iteration Plans)
Disciplines
[Business Modeling](#Business Modeling)
Requirements
[Analysis & Design](#Analysis & Design)
Implementation
Testing
Deployment
[Configuration & Change Management](#Configuration & Change Management)
[Project Management](#Project Management)
Environment
Roles

1. Introduction (to top)

1.1 Purpose (to top)

[A brief description of the purpose of the Development Case, for example:

“The purpose of the document is to describe the development process for the <<project name>>.”

Also give a brief description of what the Development Case applies to; what is affected or influenced by this document.]

1.2 Scope (to top)

[A brief description of the scope of this Development Case; what Projects it is associated with, and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations (to top)

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Development Case. This information may be provided by reference to the project’s Glossary.]

1.4 References (to top)

[This subsection provides a complete list of all documents referenced elsewhere in the Development Case. Identify each document 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.5 Overview (to top)

[This subsection briefly describes what the rest of the Development Case contains and explains how the document is organized.]

2. Overview of the Development Case (to top)

2.1 Lifecycle Model (to top)

[Briefly describe the lifecycle model employed by the project; containing descriptions of the milestones and their purpose. The purpose is to serve as an introduction to the rest of the development case, not to be a project plan.]

2.2 Disciplines (to top)

[Describe which disciplines the Development Case covers.]

2.3 Discipline Configuration (to top)

[Explain how the discipline configuration works. Explain the sections in the Discipline sections, using the following text as a starting point:]

The purpose of this section is to explain how the discipline configuration works. This includes an explanation of the purpose for the various tables and for each of the sections that describe the various disciplines listed in the section titled Disciplines.

2.3.1 Workflow

[This section needs to detail any changes made to the structure of the workflow itself. Typical changes include adding activities to describe company-specific ways of working, or removing activities.]

2.3.2 Artifacts

[Using a tabular format, this section describes how the artifact will be used. Additional ‘local’ artifacts can be added to the table as needed.]


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans


Explanation of the table
Column Name	Purpose	Contents and Comments
‘Artifacts’	[The name of the artifact.]	[A reference to the artifact in the RUP or to a local artifact definition held as part of the development case.]
‘How to use’	[Qualify how the artifact is used across the lifecycle.]	[Decide for each phase: - Must have - Should have - Could have - Won’t have These are defined in Guidelines: Classifying Artifacts.]
‘Review Details’	[Define the review level and review the procedures to be applied to the artifact.]	[Decide on the review level: - Formal-External - Formal-Internal - Informal - None For details, see Guidelines: Review Levels. Also add a reference to the definition and detail of the relevant review procedures. The reference could point to either the RUP or to the general Review Procedure section in the Development Case. More specific review procedures are defined under the subsection titled Additional Review Procedures.]
‘Tools used’	[Definition of the tool or tools used to produce the artifact.]	[Reference the details of the tools used to develop and maintain this artifact.]
‘Templates/Examples’	[The templates to be used and examples of artifacts using the templates.]	[Reference the templates and examples. This could be references to either the templates and examples in the RUP or to local templates and examples. This column may also contain references to actual artifacts to provide additional help to the project members.]

2.3.3 Notes on Artifacts

[This section has three main purposes:

It contains a list all artifacts that you ‘Won’t’ use and the motives behind your decision for not using them.

It contains a reference to the project’s Configuration Management Plan, which describes the configuration management strategy to be used when working on these artifacts. The CM Plan needs to allow developers to answer questions such as:

When do I release my artifact?

Where do I put my newly created or modified artifact?

Where do I find existing artifacts for the project?

If the Development Case is an organization-level development case, this is where you add notes on what each project needs to consider when they decide what to do with the artifact. Use the predefined table below as a starting point.]


Artifacts	How to Use	Reason

2.3.4 Reports

[This section lists the reports to be used. Additional ‘local’ reports can be added to the table as needed.]


Reports	How to use	Templates/Examples	Tools Used

2.3.5 Notes on the Reports

[This section has two purposes. First, it will list all reports that the project has decided it ‘Won’t’ use and the motives behind why it decided not to use them. Secondly, if the Development Case is an organization-level use case, this is where you add notes on what each project needs to consider when they decide what to do with the report.]

2.3.6 Additional Review Procedures

[This section captures any additional review procedures that are required for the artifacts used in the discipline. These supplement the general “Review Procedures” described in “Overview of the Development Case” section.]

2.3.7 Other Issues

[This section captures any outstanding issues with the discipline’s configuration and can be used as an issues list when the Development Case is being built.]

2.3.8 Configuring the Discipline

[This section is used if the development case is an organization-level development case. This section contains references to helpful information for use when configuring the discipline. This section can be removed by a project.]

2.4 Artifact Classification (to top)

[Introduce the artifacts and the classification scheme, using the following text as a starting point:]

An artifact is a deliverable of the process. It is often developed within one discipline, though there are exceptions. The artifacts are organized in the discipline where it’s created. To describe how an artifact needs to be used, use the following classification scheme (see Guidelines: Classifying Artifacts for details):

Must

Should

Could

Won’t

2.5 Review Procedures (to top)

[Introduce the review levels and any additional review procedures, using the following text as a starting point:]

This project uses the following review levels:

Formal-External
Formal-Internal
Informal
None

For details see Guidelines: Review Levels.

2.6 Sample Iteration Plans (to top)

2.6.1 Inception Phase

[List the sample iteration plans used during Inception.]

2.6.2 Elaboration Phase

[List the sample iteration plans used during Elaboration.]

2.6.3 Construction Phase

[List the sample iteration plans used during Construction.]

2.6.4 Transition Phase

[List the sample iteration plans used during Transition.]

3. Disciplines (to top)

3.1 Business Modeling (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.1.1 Workflow

3.1.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Business Analysis Model
Business Entity
Business Event
Business System
Business Use-Case Realization
Business Worker
Business Architecture Document
Business Glossary
Business Goal
Business Rule
Business Use-Case Model
Business Actor
Business Use Case
Business Vision
Supplementary Business Specification
Target-Organization Assessment

3.1.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.1.4 Reports


Reports	How to use	Templates/Examples	Tools Used
Business Actor
Business Analysis Model Survey
Business Entity
Business Rules Survey
Business Use-Case
Business Use-Case Realization
Business Use-Case Model Survey
Business Worker

3.1.5 Notes on the Reports

3.1.6 Additional Review Procedures

3.1.7 Other Issues

3.1.8 Configuring the Discipline

3.2 Requirements (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.2.1 Workflow

3.2.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Glossary
Requirements Attributes
Requirements Management Plan
Stakeholder Requests
Software Requirement
Software Requirements Specification
Storyboard
Supplementary Specifications
Use-Case Model
Actor
Use Case
Use-Case Package
Vision

3.2.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.2.4 Reports


Reports	How to Use	Templates/Examples	Tools Used
Actor
Use-Case
Use-Case Model Survey

3.2.5 Notes on the Reports

3.2.6 Additional Review Procedures

3.2.7 Other Issues

3.2.8 Configuring the Discipline

3.3 Analysis & Design (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.3.1 Workflow

3.3.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Analysis Model
Analysis Class
Architectural Proof-Of-Concept
Data Model
Deployment Model
Design Model
Capsule
Design Class
Design Package
Design Subsystem
Event
Interface
Protocol
Signal
Test Design
Testability Class
Use-Case Realization
Navigation Map
Reference Architecture
Software Architecture Document
User-Interface Prototype

3.3.3 Notes on the Artifacts


Artifact	How to Use	Reason

3.3.4 Reports


Reports	How to Use	Templates/Examples	Tools Used
Class
Design-Model Survey
Design Package/Subsystem
Use-Case Realization

3.3.5 Notes on the Reports

3.3.6 Additional Review Procedures

3.3.7 Other Issues

3.3.8 Configuring the Discipline

3.4 Implementation (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.4.1 Workflow

3.4.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Build
Implementation Model
Implementation Element
Implementation Subsystem
Testability Element
Test Stub
Integration Build Plan

3.4.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.4.4 Reports


Reports	How to Use	Templates/Examples	Tools Used

3.4.5 Notes on the Reports

3.4.6 Additional Review Procedures

3.4.7 Other Issues

3.4.8 Configuring the Discipline

3.5 Testing (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.5.1 Workflow

3.5.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Test Automation Architecture
Test Case
Test Data
Test Environment Configuration
Test Evaluation Summary
Test Ideas List
Test Interface Specification
Test Log
Test Strategy
Test Suite
Test Plan
Test Results
Test Script
Workload Analysis Model

3.5.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.5.4 Reports


Reports	How to Use	Templates/Examples	Tools Used
Test Survey

3.5.5 Notes on the Reports

3.5.6 Additional Review Procedures

3.5.7 Other Issues

3.5.8 Configuring the Discipline

3.6 Deployment (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.6.1 Workflow

3.6.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Deployment Plan
End-User Support Material
Release Notes
Training Materials
Product
Bill of Materials
Deployment Unit
Installation Artifacts
Product Artwork

3.6.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.6.4 Reports


Reports	How to Use	Templates/Examples	Tools Used

3.6.5 Notes on the Reports

3.6.6 Additional Review Procedures

3.6.7 Other Issues

3.6.8 Configuring the Discipline

3.7 Configuration & Change Management (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.7.1 Workflow

3.7.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Change Request
Configuration Audit Findings
Configuration Management Plan
Project Repository
Workspace

3.7.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.7.4 Reports


Reports	How to Use	Templates/Examples	Tools Used

3.7.5 Notes on the Reports

3.7.6 Additional Review Procedures

3.7.7 Other Issues

3.7.8 Configuring the Discipline

3.8 Project Management (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.8.1 Workflow

3.8.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Business Case
Issues List
Iteration Assessment
Iteration Plan
Project Measurements
Review Record
Risk List
Software Development Plan
Measurement Plan
Problem Resolution Plan
Product Acceptance Plan
Quality Assurance Plan
Risk Management Plan
Status Assessment
Work Order

3.8.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.8.4 Reports


Reports	How to Use	Templates/Examples	Tools Used

3.8.5 Notes on the Reports

3.8.6 Additional Review Procedures

3.8.7 Other Issues

3.8.8 Configuring the Discipline

3.9 Environment (to top)

[See the section titled [Discipline Configuration](#Overview: Configuration) that describes what each of the following sections needs to contain.]

3.9.1 Workflow

3.9.2 Artifacts


Artifacts	How to use			Review Details	Tools used	Templates/ Examples
Incep	Elab	Const	Trans
Development Infrastructure
Development-Organization Assessment
Development Process
Development Case
Project-Specific Guidelines
Business Modeling Guidelines
Design Guidelines
Programming Guidelines
Test Guidelines
Use-Case Modeling Guidelines
Project-Specific Templates
Manual Styleguide
Tools

3.9.3 Notes on the Artifacts


Artifacts	How to Use	Reason

3.9.4 Reports


Reports	How to Use	Templates/Examples	Tools Used

3.9.5 Notes on the Reports

3.9.6 Additional Review Procedures

3.9.7 Other Issues

3.9.8 Configuring the Discipline

4. Roles (to top)

[This section is used for the following purposes:

To describe any changes in the set of roles. For example, it is common that you refine the role Stakeholder into more than one role.

To map job positions in the organization to the roles in the RUP. The reason for this is that in some development organizations there are job positions defined. If these job positions are commonly used and have a wide acceptance within the organization, it may be worth doing a mapping between the roles in the RUP, and the job positions in the organization. Mapping job positions to roles can make it easier for people in the organization understand how to employ the RUP. The mapping can also help people understand that roles are not job positions, which is a common misconception.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Business Context](#2. Business Context)

[3. External Factors](#3. External Factors)

[3.1 Customers](#3.1 Customers)

[3.2 Competitors](#3.2 Competitors)

[3.3 Other Stakeholders](#3.3 Other Stakeholders)

[4. Internal Factors](#4. Internal Factors)

[4.1 Development Process](#4.1 Development Process)

[4.2 Supporting Tools](#4.2 Supporting Tools)

[4.3 Internal Organization](#4.3 Internal Organization)

[4.4 Competencies, Skills and Attitudes](#4.4 Competencies, Skills and Attitudes)

[4.5 Capacity for Change](#4.5 Capacity for Change)

[5. Product Characteristics](#5. Product Characteristics)

[5.1 Size of Software-Development Effort](#5.1 Size of Software-Development Effort)

[5.2 Degree of Novelty](#5.2 Degree of Novelty)

[5.3 Type of Application](#5.3 Type of Application)

[5.4 Technical Complexity](#5.4 Technical Complexity)

[6. Assessment Conclusion](#6. Assessment Conclusion)

Development-Organization Assessment

1. Introduction

[The introduction of the Development-Organization Assessment should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Development-Organization Assessment.]

1.1 Purpose

[Specify the purpose of this Development-Organization Assessment.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Development-Organization Assessment. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Development-Organization Assessment. 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.5 Overview

[This subsection should describe what the rest of the Development-Organization Assessment contains and explain how the document is organized.]

2. Business Context

[A brief description of the business domain in which the organization work.]

3. External Factors

3.1 Customers

[A listing of the customers and what they expect of the products.]

3.2 Competitors

[A listing of the competitors.]

3.3 Other Stakeholders

[A listing of other stakeholders, such as suppliers and partners.]

4. Internal Factors

4.1 Development Process

[A brief description of the current development process. A list of problems.]

4.2 Supporting Tools

[A brief description of today’s tool support.]

4.3 Internal Organization

[A brief description of the internal organization, what roles and teams they have today.]

4.4 Competencies, Skills and Attitudes

[An inventory of the competencies, skills and attitudes of the individuals in the organization.]

4.5 Capacity for Change

[A brief description of the “capacity for change”.]

5. Product Characteristics

5.1 Size of Software-Development Effort

[A brief description of the size of the software.]

5.2 Degree of Novelty

[A description of where product is on a scale between “green-field development” and maintenance.]

5.3 Type of Application

[A brief description of the type of application, and what that can mean for the development process.]

5.4 Technical Complexity

[A description of the technical complexity of the product.]

6.Assessment Conclusion

[List the major problem areas and opportunity areas, regardless of the categories to which they belong.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 References](#1.3 References)

[1.4 Overview](#1.4 Overview)

[2. Definitions](#2. Definitions)

[2.1 <aTerm>](#2.1 <aTerm>)

[2.2 <anotherTerm>](#2.2 <anotherTerm>)

[2.3 <aGroupOfTerms>](#2.3 <aGroupofTerms>)

[2.3.1 <aGroupTerm>](#2.3.1 <aGroupTerm>)

[2.3.2 <anotherGroupTerm>](#2.3.2 <anotherGroupTerm>)

[2.4 <aSecondGroupOfTerms>](#2.4 <aSecondGroupofTerms>)

[2.4.1 <yetAnotherGroupTerm>](#2.4.1 <yetAnotherGroupTerm>)

[2.4.2 <andAnotherGroupTerm>](#2.4.2 <andAnotherGroupTerm>)

[3. UML Stereotypes](#3. UML Stereotypes)

Glossary

1. Introduction

[The introduction of the Glossary provides 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 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 provides a complete list of all documents referenced elsewhere in the Glossary. Identify each document 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 describes what the rest of the Glossary contains and explains 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’s 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.4 <aSecondGroupofTerms>

2.4.1 <yetAnotherGroupTerm>

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

2.4.2 <andAnotherGroupTerm>

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

3. UML Stereotypes

[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 for the system 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.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Subsystems](#2. Subsystems)

[3. Builds](#3. Builds)

Integration Build Plan

1. Introduction

[The introduction of the Integration Build Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Integration Build Plan.]

1.1 Purpose

[Specify the purpose of this Integration Build Plan.]

1.2 Scope

[A brief description of the scope of this Integration Build Plan; what model(s) it is associated with and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Integration Build Plan. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Integration Build Plan. Identify each document 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.5 Overview

[This subsection describes what the rest of the Integration Build Plan contains and explains how the document is organized.]

2. Subsystems

[State which subsystems to implement in this iteration. Also state the preferred order in which the subsystems should be implemented to be ready in time for integration.]

3. Builds

[The integration, in the iteration, is divided into a number of increments, each resulting in a build, which is integration-tested. This section needs to specify which builds to create and which subsystems should be part of each build. For each build, this section needs to specify how the build is constructed, the criteria for its assessment and how it is to be tested, in particular:

Construction

Build scripts and any other instructions which describe how the build is constructed

Baseline records which define the versions of the configuration items used to construct the build

Evaluation and Test

Evaluation criteria-a description of the capabilities against which the build is to be judged. This may contain a subset of the evaluation criteria in the corresponding Iteration Plan and other build specific evaluation criteria (particularly when, for example, the build is an architecture build which does not deliver much, if any capability that is visible to the end-user.

Installation and setup instructions to execute and test the build

Test cases, test procedures, test scripts and test results

Note that in all cases, there is no requirement to replicate material in this plan-references will suffice if the material exists in other artifacts-the Artifact: Iteration Test Plan, for example.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Iteration Objectives Reached](#2. Iteration Objectives Reached)

[3. Adherence to Plan](#3. Adherence to Plan)

[4. Use Cases and Scenarios Implemented](#4. Use Cases and Scenarios Implemented)

[5. Results Relative to Evaluation Criteria](#5. Results Relative to Evaluation Criteria)

[6. Test Results](#6. Test Results)

[7. External Changes Occurred](#7. External Changes Occurred)

[8. Rework Required](#8. Rework Required)

Iteration Assessment

1. Introduction

[The introduction of the Iteration Assessment should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Iteration Assessment.]

1.1 Purpose

[Specify the purpose of this Iteration Assessment.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Iteration Assessment. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Iteration Assessment. 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.5 Overview

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

2. Iteration Objectives Reached

[Acknowledge the success you reached in the iteration.]

3. Adherence to Plan

[How did the iteration run according to plan? How well was the budget met?]

4. Use Cases and Scenarios Implemented

[List the use cases and scenarios that were implemented.]

5. Results Relative to Evaluation Criteria

[Assess the results of the iteration relative to the evaluation criteria that were established for the iteration plan: functionality, performance, capacity, and quality measures.]

6. Test Results

[Refer to the test results.]

7. External Changes Occurred

[For example, changes in requirements, new user’s need,and competitor’s plan.]

8. Rework Required

[Identify problem areas that need to be reworked in upcoming iterations.]

Iteration Plan

1. Key Milestones

[Detailed diagrams showing timelines, intermediate milestones, when testing starts, beta version, demos and so on for the iteration.]


Milestone	Date
Iteration Start


Iteration Stop

2. Iteration Objectives

[Objectives/tasks assigned as part of this iteration and assignment to persons responsible]

[Objectives may include creating or refining specific artifacts, addressing risks, or implementing specific requirements, or performing supporting tasks. Some example objectives are listed below]


Objective/Task	Assigned to
Implement Use Case: Register for Course, Basic flow, Alternatve 1, Alternate 2	Fred
Complete Vision	Jill
Detail UC3: Publish Calendar	John
Test all developed requirements	Lance
Create plan for next iteration	Jill

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Plan](#2. Plan)

[3. Resources](#3. Resources)

[4. Use Cases](#4. Use Cases)

[5. Evaluation Criteria](#5. Evaluation Criteria)

Iteration Plan

1. Introduction

[The introduction of the Iteration Plan should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Iteration Plan.]

1.1 Purpose

[Specify the purpose of this Iteration Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Iteration Plan. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Iteration Plan. 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.5 Overview

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

2. Plan

[Detailed diagrams showing timelines, intermediate milestones, when testing starts, beta version, demos etc. for the iteration.]

3. Resources

[Resources needed for the iteration- human, financial, etc.]

4. Use Cases

[List the use cases and scenarios that are being developed for this iteration.]

5. Evaluation Criteria

[Functionality, performance, capacity, quality measures, quality goals, etc.]

Revision History


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

Table of Contents

1.4 Document Terminology and Acronyms

1.3 Intended Audience

1.5 References

1.6 Document Structure

2. Evaluation Mission and Test Motivation

2.1 Evaluation Mission

2.2 Test Motivators

3. Target Test Items

4. Outline of Planned Tests

4.1 Outline of Test Inclusions

4.2 Outline of Other Candidates for Potential Inclusion

4.3 Outline of Test Exclusions

5. Test Approach

5.1 Measuring the Extent of Testing

5.2 Identifying and Justifying Tests

5.3 Conducting Tests

6. Entry and Exit Criteria

6.1 Iteration Test Plan

6.1.1 Iteration Test Plan Entry Criteria

6.1.2 Iteration Test Plan Exit Criteria

6.1.3 Suspension and Resumption Criteria

6.2 Test Cycles

6.2.1 Test Cycle Entry Criteria

6.2.2 Test Cycle Exit Criteria

6.2.3 Test Cycle Abnormal Termination

7. Deliverables

7.1 Test Evaluation Summaries

7.2 Reporting on Test Coverage

7.3 Perceived Quality Reports

7.4 Incident Logs and Change Requests

7.5 Smoke Test Suite and Supporting Test Scripts

8. Testing Workflow

9. Environmental Needs

9.1 Base System Hardware

9.2 Base Software Elements in the Test Environment

9.3 Productivity and Support Tools

9.4 Test Environment Configurations

10. Responsibilities, Staffing, and Training Needs

10.2 Staffing and Training Needs

11. Key Iteration Milestones

12. Iteration Plan Risks, Dependencies, Assumptions, and Constraints

13. Management Process and Procedures

13.1 Approval and Signoff

Iteration Test Plan

1. Introduction

1.1 Purpose

The purpose of the Iteration Test Plan for the <complete lifecycle, specific-phase> of the <Project Name> is to:

Provide a central artifact to govern the planning and control of the test effort. It defines the general approach that will be employed to test the software and to evaluate the results of that testing, and is the top-level plan that will be used by managers to govern and direct the detailed testing work.

Provide visibility to stakeholders in the testing effort that adequate consideration has been given to various aspects of governing the testing effort, and where appropriate to have those stakeholders approve the plan.

This Iteration Test Plan also supports the following specific objectives:

[Identifies the items that should be targeted by the tests.
identifies the motivation for and ideas behind the test areas to be covered.
Outlines the testing approach that will be used.
identifies the required resources and provides an estimate of the test efforts.
lists the deliverable elements of the test project.]

1.2 Scope

[Defines the types of testing-such as Functionality, Usability, Reliability, Performance, and Supportability-and if necessary the levels of testing-for example, Integration or System-that will be addressed by this Iteration Test Plan. It is also important to provide a general indication of significant elements that will be excluded from scope, especially where the intended audience might otherwise reasonably assume the inclusion of those elements.

Note: Be careful to avoid repeating detail here that you will define in sections 3, Target Test Items, and 4, Outline of Planned Tests.]

1.3 Intended Audience

[Provide a brief description of the audience for whom you are writing the Iteration Test Plan. This helps readers of your document identify whether it is a document intended for their use, and helps prevent the document from being used inappropriately.

Note: The document style and content usually alters in relation to the intended audience.

This section should only be about three to five paragraphs in length.]

1.4 Document Terminology and Acronyms

[This subsection provides the definitions of any terms, acronyms, and abbreviations required to properly interpret the Iteration Test Plan. Avoid listing items that are generally applicable to the project as a whole and that are already defined in the project’s Glossary. Include a reference to the project’s Glossary in the References section.]

1.5References

[This subsection provides a list of the documents referenced elsewhere within the Iteration Test Plan. Identify each document by title, version (or report number if applicable), date, and publishing organization or original author. Avoid listing documents that are influential but not directly referenced. Specify the sources from which the “official versions” of the references can be obtained, such as intranet UNC names or document reference codes. This information may be provided by reference to an appendix or to another document.]

1.6 Document Structure

[This subsection outlines what the rest of the Iteration Test Plan contains and gives an introduction to how the rest of the document is organized. This section may be eliminated if a Table of Contents is used.]

2. Evaluation Mission and Test Motivation

[Provide an overview of the mission and motivation for the testing that will be conducted in this iteration.]

2.1 Evaluation Mission

[Provide a brief statement that defines the mission(s) for the test and evaluation effort over the scope of the plan. The governing mission statement(s) might incorporate one or more concerns including:

find as many bugs as possible

find important problems, assess perceived quality risks

advise about perceived project risks

certify to a standard

verify a specification (requirements, design or claims)

advise about product quality, satisfy stakeholders

advise about testing

fulfill process mandates

and so forth

Each mission provides a different context to the test effort and changes the way in which testing should be approached.]

2.2 Test Motivators

[Provide an outline of the key items that will motivate the testing effort in this iteration. Testing will be motivated by many things-quality risks, technical risks, project risks, use cases, functional requirements, non-functional requirements, design elements, suspected failures or types of faults (fault models), change requests, and so forth. List the specific items from each applicable category that will motivate the testing this iteration and for which reporting will focus on.]

3. Target Test Items

The listing below identifies those test items-software, hardware, and supporting product elements-that have been identified as targets for testing. This list represents what items will be tested.

[Provide a list of the major target test items. This list should include both items produced directly by the project development team, and items that those products rely on; for example, basic processor hardware, peripheral devices, operating systems, third-party products or components, and so forth. Consider grouping the list by category and assigning relative importance to each specific test motivator.]

4. Outline of Planned Tests

[This section provides an outline of the testing that will be performed for the Iteration. This outline represents the intersection between targets and the test types or quality risks. As such, it can often we represented in a tabular or spreadsheet format.

The outline in this section represents an overview of both the tests that will be performed and those that will specifically be excluded.]

4.1 Outline of Test Inclusions

[Provide an outline of the major testing planned for the current iteration. Note what will be included in the plan and record what will explicitly not be included in the section titled Outline of Test Exclusions .]

4.2 Outline of Other Candidates for Potential Inclusion

[Separately outline test areas you suspect might be useful to investigate and evaluate, but that have not been sufficiently researched to know if they are important to pursue.]

4.3 Outline of Test Exclusions

[Provide an outline of the potential tests that might otherwise have been conducted but that have been explicitly excluded from this plan. If a type of test will not be implemented and executed, indicate this in a sentence stating the test will not be implemented or executed and stating the justification, such as:

“These tests do not help achieve the evaluation mission.”

“There are insufficient resources to conduct these tests.”

“These tests are unnecessary due to the testing conducted by xxxx.”

As a heuristic, if you think it would be reasonable for one of your audience members to expect a certain aspect of testing to be included that you will not or cannot address, you should note its exclusion: If the team agrees the exclusion is obvious, you probably don’t need to list it.]

5. Test Approach

[The Test Approach presents an overview of the recommended strategy for analyzing, designing, implementing and executing the required tests. Sections 3 , Target Test Items , and 4 , Outline of Planned Tests , identified what items will be tested and what types of tests would be performed. This section describes how the tests will be realized.

As you identify each aspect of the approach, you should update Section 10 , Responsibilities, Staffing, and Training Needs , to document the test environment configuration and other resources that will be needed to implement each aspect.

In some cases the strategy you use will be common across the life of the project. As such, it can be documented in one or more separate Test Strategy artifacts or in a Master Test Plan, and reused across multiple Iterations. Where that will be done, in this section you can simply reference which artifacts contain the strategy that will be used, either under this main section heading or under sub-headings as appropriate.]

5.1 Measuring the Extent of Testing

[Describe what strategy you will use for measuring the progress of the testing effort. When deciding on a measurement strategy, it is important to consider the following advice from Cem Kaner, 2000 “Bug count metrics reflect only a small part of the work and progress of the testing group. Many alternatives look more closely at what has to be done and what has been done. These will often be more useful and less prone to side effects than bug count metrics.”

A good measurement strategy will report on multiple dimensions. Consider the following dimensions, and select a subset that are appropriate for your project context: coverage (against the product and/ or against the plan), effort, results, obstacles, risks (in product quality and/ or testing quality), historical trend (across iterations and/ or across projects).]

5.2 Identifying and Justifying Tests

[Describe how specific tests will be identified and considered for inclusion in the scope of the test effort covered by this strategy. This is done to provide insight to the stakeholders in this plan because the plan itself doesn’t usually list all of the detailed tests: these are provided in other test artifacts.

Provide a listing of resources that will be used to stimulate/ drive the identification and selection of specific tests to be conducted, such as Initial Test-Idea Catalogs, Requirements documents, User documentation and/ or Other Reference Sources. Examples of Test-Ideas Catalogs can be found in the process components shipped with RUP.]

5.3 Conducting Tests

One of the main aspects of the test approach is an explanation of how the testing will be conducted, covering the selection of quality-risk areas or test types that will be addressed and the associated techniques that will be used. If you are maintaining a separate test strategy artifact that covers this, simply list the test types or quality-risks areas that will be addressed by the plan, and refer to the test strategy artifact for the details. If there is no separate test strategy artifact, you should provide an outline here of how testing will be conducted for each technique: how design, implementation and execution of the tests will be done, and the criterion for knowing that the technique is both useful and successful. For each technique, provide a description of the technique and define why it is an important part of the test approach by briefly outlining how it helps achieve the Evaluation Mission(s).

6. Entry and Exit Criteria

6.1 Iteration Test Plan

6.1.1 Iteration Test Plan Entry Criteria

[Specify the criteria that will be used to determine whether the execution of the Iteration Test Plan can begin.]

6.1.2 Iteration Test Plan Exit Criteria

[Specify the criteria that will be used to determine whether the execution of the Iteration Test Plan is complete or that continued execution provides no further benefit.]

6.1.3 Suspension and Resumption Criteria

[Specify the criteria that will be used to determine whether testing should be prematurely suspended or ended before the plan has been completely executed, and under what criteria testing can be resumed.]

6.2 Test Cycles

6.2.1 Test Cycle Entry Criteria

[Specify the criteria to be used to determine whether the test effort for the next Test Cycle of this Iteration Test Plan can begin.]

6.2.2 Test Cycle Exit Criteria

[Specify the criteria that will be used to determine whether the test effort for the current Test Cycle of this Iteration Test Plan is deemed sufficient.]

6.2.3 Test Cycle Abnormal Termination

[Specify the criteria that will be used to determine whether testing should be prematurely suspended or ended for the current test cycle, or whether the intended build candidate to be tested must be altered.]

7. Deliverables

[In this section, list the various artifacts that will be created by the test effort that are useful deliverables to the various stakeholders of the test effort. Don’t list all work products; only list those that give direct, tangible benefit to a stakeholder and those by which you want the success of the test effort to be measured.

Note: This section may be delegated in whole or part to the Test Strategy or Master Test Plan artifacts, in which case this section can simple note any adjustments or be deleted.]

7.1 Test Evaluation Summaries

[Provide a brief outline of both the form and content of the test evaluation summaries, and indicate how frequently they will be produced.]

7.2 Reporting on Test Coverage

[Provide a brief outline of both the form and content of the reports used to measure the extent of testing, and indicate how frequently they will be produced. Give an indication as to the method and tools used to record, measure, and report on the extent of testing.]

7.3 Perceived Quality Reports

[Provide a brief outline of both the form and content of the reports used to measure the perceived quality of the product, and indicate how frequently they will be produced. Give an indication about to the method and tools used to record, measure, and report on the perceived product quality. You might include some analysis of Incidents and Change Request over Test Coverage.]

7.4 Incident Logs and Change Requests

[Provide a brief outline of both the method and tools used to record, track, and manage test incidents, associated change requests, and their status.]

7.5 Smoke Test Suite and Supporting Test Scripts

[Provide a brief outline of the test assets that will be delivered to allow ongoing regression testing of subsequent product builds to help detect regressions in the product quality.]

8. Testing Workflow

[Provide an outline of the workflow to be followed by the Test team in the development and execution of this Iteration Test Plan.]

For Iteration Test Plans, we recommend simply using this section for exceptions, noting any deviations or changes from the workflow outlined in the master planning artifacts.

Note: Where process and detailed planning information is recorded centrally and separately from this Iteration Test Plan, you will have to manage the issues that will arise from having duplicate copies of the same information. To avoid team members referencing out-of-date information, we suggest that in this situation you place the minimum amount of process and planning information within the Iteration Test Plan to make ongoing maintenance easier and simply reference the “Master” source material.]

9. Environmental Needs

[This section presents the non-human resources required for the Iteration Test Plan.

Note: This section may be delegated in whole or part to the Test Strategy artifact, in which case this section can simple note any adjustments or be deleted.]

9.1 Base System Hardware

The following table sets forth the system resources for the test effort presented in this Iteration Test Plan.

[The specific elements of the test system may not be fully understood in early iterations, so expect this section to be completed over time. We recommend that the system simulates the production environment, scaling down the concurrent access and database size, and so forth, if and where appropriate.]

[Note: Add or delete items as appropriate.]


System Resources
Resource	Quantity	Name and Type

9.2 Base Software Elements in the Test Environment

The following base software elements are required in the test environment for this Iteration Test Plan.

[Note: Add or delete items as appropriate.]

Software Element Name	Version	Type and Other Notes

9.3 Productivity and Support Tools

The following tools will be employed to support the test process for this Iteration Test Plan.

[Note: Add or delete items as appropriate.]

Tool Category or Type	Tool Brand Name	Vendor or In-house	Version

9.4 Test Environment Configurations

The following Test Environment Configurations needs to be provided and supported for this project.

Configuration Name	Description	Implemented in Physical Configuration

10. Responsibilities, Staffing, and Training Needs

[This section presents the required resources to address the test effort outlined in the Iteration Test Plan the main responsibilities, and the knowledge or skill sets required of those resources

Note: This section may be delegated in whole or part to the Test Strategy artifact, in which case this section can simple note any adjustments or be deleted.]

10.1 People and Roles

This table shows the staffing assumptions for the test effort.


Human Resources
Role	Minimum Resources Recommended (Number of full-time roles allocated)	Specific Responsibilities or Comments
Test Manager		Provides management oversight. Responsibilities include: - planning and logistics - agree on the mission - identify motivators - acquire appropriate resources - present management reporting - advocate the interests of test - evaluate effectiveness of test effort
Test Analyst		Identifies and defines the specific tests to be conducted. Responsibilities include: - identify test ideas - define test details - determine test results - document change requests - evaluate product quality
Test Designer		Defines the technical approach to the implementation of the test effort. Responsibilities include: - define test approach - define test automation architecture - verify test techniques - define testability elements - structure test implementation
Tester		Implements and executes the tests. Responsibilities include: - implement tests and test suites - execute test suites - log results - analyze and recover from test failures - document incidents
Test System Administrator		Ensures test environment and assets are managed and maintained. Responsibilities include: - administer test management system - install and support access to, and recovery of, test environment configurations and test labs
Database Administrator, Database Manager		Ensures test data (database) environment and assets are managed and maintained. Responsibilities include: - support the administration of test data and test beds (database).
Designer		Identifies and defines the operations, attributes, and associations of the test classes. Responsibilities include: - define the test classes required to support testability requirements as defined by the test team
Implementer		Implements and unit tests the test classes and test packages. Responsibilities include: - create the test components required to support testability requirements as defined by the designer

10.2 Staffing and Training Needs

This section outlines how to approach staffing and training the test roles for the project.

[The way to approach staffing and training will vary from project to project. If this section is part of a Iteration Test Plan, you should indicate at what points in the project lifecycle different skills and numbers of staff are needed. If this is an Iteration Test Plan, you should focus mainly on where and what training might occur during the Iteration.

Give thought to your training needs, and plan to schedule this based on a Just-In-Time (JIT) approach there is often a temptation to attend training too far in advance of its usage when the test team has apparent slack. Doing this introduces the risk of the training being forgotten by the time it’s needed.

Look for opportunities to combine the purchase of productivity tools with training on those tools, and arrange with the vendor to delay delivery of the training until just before you need it. If you have enough headcount, consider having training delivered in a customized manner for you, possibly at your own site.

The test team often requires the support and skills of other team members not directly part of the test team. Make sure you arrange in your plan for appropriate availability of System Administrators, Database Administrators, and Developers who are required to enable the test effort.]

11. Key Iteration Milestones

[Identify the key schedule milestones that set the context for the Testing effort. Avoid repeating too much detail that is documented elsewhere in plans that address the entire project.]

Milestone	Planned Start Date	Actual Start Date	Planned End Date	Actual End Date
Iteration starts
Iteration Test Plan agreed
Test Approach Verified
First Build delivered to test
First Build BVT passed and accepted into test
First Build test cycle finishes
[Build Two will not be tested]
Third Build delivered to test
Third Build BVT passed and accepted into test
Third Build test cycle finishes
Fourth Build delivered to test
Fourth Build BVT passed and accepted into test
Iteration Assessment review
Iteration ends

12. Iteration Plan Risks, Dependencies, Assumptions, and Constraints

[List any risks that may affect the successful execution of thisIteration Test Plan, and identify mitigation and contingency strategies for each risk. Also indicate a relative ranking for both the likelihood of occurrence and the impact if the risk is realized.]

Risk	Mitigation Strategy	Contingency (Risk is realized)

[List any dependencies identified during the development of this Iteration Test Plan that may affect its successful execution if those dependencies are not honored. Typically these dependencies relate to activities on the critical path that are prerequisites or post-requisites to one or more preceding (or subsequent) activities You should consider responsibilities you are relying on other teams or staff members external to the test effort completing, timing and dependencies of other planned tasks, the reliance on certain work products being produced.]

Dependency between	Potential Impact of Dependency	Owners

[List any assumptions made during the development of this Iteration Test Plan that may affect its successful execution if those assumptions are proven incorrect. Assumptions might relate to work you assume other teams are doing, expectations that certain aspects of the product or environment are stable, and so forth].

Assumption to be proven	Impact of Assumption being incorrect	Owners

[List any constraints placed on the test effort that have had a negative effect on the way in which this Iteration Test Plan has been approached.]

Constraint on	Impact Constraint has on test effort	Owners

13. Management Process and Procedures

[Outline any refinements to the processes and procedures that were defined in the Master Test Plan to be used when issues arise with the test effort. If there is no Master test Plan or general development plan that covers these procedures, define what you need to here in the Iteration Test Plan.]

13.1 Approval and Signoff

[Outline the approval process and list the job titles (and names of current incumbents) that initially must approve the plan, and sign off on the plans satisfactory execution.]

Revision History


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

Table of Contents

1.Introduction

1.4 Document Terminology and Acronyms

1.3 Intended Audience

1.5 References

1.6 Document Structure

2. Governing Evaluation Mission

2.1 Project Context and Background

2.2 Evaluation Missions applicable to this Project/ Phase

2.3 Sources of Test Motivators

3. Target Test Items

4. Overview of Planned Tests

4.1 Overview of Test Inclusions

4.2 Overview of Other Candidates for Potential Inclusion

4.3 Overview of Test Exclusions

5. Test Approach

5.1 Measuring the Extent of Testing

5.2 Identifying and Justifying Tests

5.3 Conducting Tests

6. Entry and Exit Criteria

6.1 Project/ Phase Master Test Plan

6.1.1 Master Test Plan Entry Criteria

6.1.2 Master Test Plan Exit Criteria

6.1.3 Suspension and Resumption Criteria

7. Deliverables

7.1 Test Evaluation Summaries

7.2 Reporting on Test Coverage

7.3 Perceived Quality Reports

7.4 Incident Logs and Change Requests

7.5 Smoke Test Suite and Supporting Test Scripts

7.6 Additional Work Products

7.6.1 Detailed Test Results

7.6.2 Additional Automated Functional Test Scripts

7.6.3 Test Guidelines

7.6.4 Traceability Matrices

8. Testing Workflow

9. Environmental Needs

9.1 Base System Hardware

9.2 Base Software Elements in the Test Environment

9.3 Productivity and Support Tools

9.4 Test Environment Configurations

10. Responsibilities, Staffing, and Training Needs

10.1 People and Roles

10.2 Staffing and Training Needs

11. Key Project/ Phase Milestones

12. Master Plan Risks, Dependencies, Assumptions, and Constraints

13. Management Process and Procedures

13.1 Measuring and Assessing the Extent of Testing

13.2 Assessing the Deliverables of this Master Test Plan

13.3 Problem Reporting, Escalation, and Issue Resolution

13.4 Managing Test Cycles

13.5 Traceability Strategies

13.6 Approval and Signoff

Master Test Plan

1. Introduction

1.1 Purpose

The purpose of the Master Test Plan for the <complete lifecycle, specific-phase> of the is to:

This Master Test Plan also supports the following specific objectives:

[Identifies the items that should be targeted by the tests.
identifies the motivation for and ideas behind the test areas to be covered.
Outlines the testing approach that will be used.
identifies the required resources and provides an estimate of the test efforts.
lists the deliverable elements of the test project.]

1.2 Scope

[Defines the types of testing ,such as Functionality, Usability, Reliability, Performance, and Supportability,and if necessary the levels of testing,for example, Integration or System, that will be addressed by this Master Test Plan. It is also important to provide a general indication of significant elements that will be excluded from scope, especially where the intended audience might otherwise reasonably assume the inclusion of those elements.

Note: Be careful to avoid repeating detail here that you will define in sections 3 , Target Test Items , and 4 , Overview of Planned Tests .]

1.3 Intended Audience

[Provide a brief description of the audience for whom you are writing the Master Test Plan. This helps readers of your document identify whether it is a document intended for their use, and helps prevent the document from being used inappropriately.

Note: The document style and content usually alters in relation to the intended audience.

This section should only be about three to five paragraphs in length.]

1.4 Document Terminology and Acronyms

[This subsection provides the definitions of any terms, acronyms, and abbreviations required to properly interpret the Master Test Plan. Avoid listing items that are generally applicable to the project as a whole and that are already defined in the project’s Glossary. Include a reference to the project’s Glossary in the References section.]

1.5References

[This subsection provides a list of the documents referenced elsewhere within the Master Test Plan. Identify each document by title, version (or report number if applicable), date, and publishing organization or original author. Avoid listing documents that are influential but not directly referenced. Specify the sources from which the “official versions” of the references can be obtained, such as intranet UNC names or document reference codes. This information may be provided by reference to an appendix or to another document.]

1.6 Document Structure

[This subsection outlines what the rest of the Master Test Plan contains and gives an introduction to how the rest of the document is organized. This section may be eliminated if a Table of Contents is used.]

2. Governing Evaluation Mission

[Provide an overview of the mission(s) that will govern the detailed testing within the iterations.]

2.1 Project Context and Background

[Provide a brief description of the background surrounding the project with specific reference or focus on important implications for the test effort. Include information such as the key problem being solved, the major benefits of the solution, the planned architecture of the solution, and a brief history of the project. Note that where this information is defined sufficiently in other documents, you might simply include a reference to those other documents if appropriate; however, it may save readers of the test plan time and effort if a limited amount of information is duplicated here: so you should use your judgment. As a general rule, this section should only be about three to five paragraphs in length.]

2.2 Evaluation Missions applicable to this Project/ Phase

find as many bugs as possible

find important problems, assess perceived quality risks

advise about perceived project risks

certify to a standard

verify a specification (requirements, design or claims)

advise about product quality, satisfy stakeholders

advise about testing

fulfill process mandates

and so forth

Each mission provides a different context to the test effort and changes the way in which testing should be approached.]

2.3 Sources of Test Motivators

[Provide an outline of the key sources from which the testing effort in this Project/ Phase will be motivated. Testing will be motivated by many things,quality risks, technical risks, project risks, use cases, functional requirements, non-functional requirements, design elements, suspected failures or faults, change requests, and so forth.]

3. Target Test Items

The listing below identifies those test items,software, hardware, and supporting product elements ,that have been identified as targets for testing. This list represents what items will be tested.

[Provide a high level list of the major target test items. This list should include both items produced directly by the project development team, and items that those products rely on; for example, basic processor hardware, peripheral devices, operating systems, third-party products or components, and so forth. In the Master plan, this may simply be a list the categories or target areas.]

4. Overview of Planned Tests

[This section provides a high-level overview of the testing that will be performed. The outline in this section represents a high level overview of both the tests that will be performed and those that will not.]

4.1 Overview of Test Inclusions

[Provide a high-level overview of the major testing planned for project/ phase. Note what will be included in the plan and record what will explicitly not be included in the following section titled Overview of Test Exclusions .]

4.2 Overview of Other Candidates for Potential Inclusion

[Give a separate overview of areas you suspect might be useful to investigate and evaluate, but that have not been sufficiently researched to know if they are important to pursue.]

4.3 Overview of Test Exclusions

[Provide a high-level overview of the potential tests that might have been conducted but that have been explicitly excluded from this plan. If a type of test will not be implemented and executed, indicate this in a sentence stating the test will not be implemented or executed and stating the justification, such as:

“These tests do not help achieve the evaluation mission.”

“There are insufficient resources to conduct these tests.”

“These tests are unnecessary due to the testing conducted by xxxx.”

5. Test Approach

[The Test Approach presents an overview of the recommended strategy for analyzing, designing, implementing and executing the required tests. Sections 3 , Target Test Items , and 4 , Overview of Planned Tests , identified what items will be tested and what types of tests would be performed. This section describes how the tests will be realized.

5.1 Measuring the Extent of Testing

5.2 Identifying and Justifying Tests

[Describe how tests will be identified and considered for inclusion in the scope of the test effort covered by this strategy. Provide a listing of resources that will be used to stimulate/ drive the identification and selection of specific tests to be conducted, such as Initial Test-Idea Catalogs, Requirements documents, User documentation and/ or Other Reference Sources. Examples of Test-Ideas Catalogs can be found in the process components shipped with RUP.]

5.3 Conducting Tests

6. Entry and Exit Criteria

6.1 Project/ Phase Master Test Plan

6.1.1 Master Test Plan Entry Criteria

[Specify the criteria that will be used to determine whether the execution of the Master Test Plan can begin.]

6.1.2 Master Test Plan Exit Criteria

[Specify the criteria that will be used to determine whether the execution of the Master Test Plan is complete or that continued execution provides no further benefit.]

6.1.3 Suspension and Resumption Criteria

7. Deliverables

7.1 Test Evaluation Summaries

[Provide a brief outline of both the form and content of the test evaluation summaries, and indicate how frequently they will be produced.]

7.2 Reporting on Test Coverage

7.3 Perceived Quality Reports

7.4 Incident Logs and Change Requests

[Provide a brief outline of both the method and tools used to record, track, and manage test incidents, associated change requests, and their status.]

7.5 Smoke Test Suite and Supporting Test Scripts

[Provide a brief outline of the test assets that will be delivered to allow ongoing regression testing of subsequent product builds to help detect regressions in the product quality.]

7.6 Additional Work Products

[In this section, identify the work products that are optional deliverables or those that should not be used to measure or assess the successful execution of the Master Test Plan.]

7.6.1 Detailed Test Results

[This denotes either a collection of Microsoft Excel spreadsheets listing the results determined for each test case, or the repository of both test logs and determined results maintained by a specialized test product.]

7.6.2 Additional Automated Functional Test Scripts

[These will be either a collection of the source code files for automated test scripts, or the repository of both source code and compiled executables for test scripts maintained by the test automation product.]

7.6.3 Test Guidelines

[Test Guidelines cover a broad set of categories, including Test-Idea catalogs, Good Practice Guidance, Test patterns, Fault and Failure Models, Automation Design Standards, and so forth.]

7.6.4 Traceability Matrices

[Using a tool such as Rational RequisitePro or MS Excel, provide one or more matrices of traceability relationships between traced items.]

8. Testing Workflow

[Provide an outline of the workflow to be followed by the Test team in the development and execution of this Master Test Plan.]

The specific testing workflow that you will use should be documented separately in the project’s Development Case. It should explain how the project has customized the base RUP test workflow (typically on a phase-by-phase basis). In most cases, we recommend you place a reference in this section of the Master Test Plan to the relevant section of the Development Case. It might be both useful and sufficient to simply include a diagram or image depicting your test workflow.

More specific details of the individual testing tasks are defined in a number of different ways, depending on project culture; for example:

defined as a list of tasks in this section of the Master Test Plan, or in an accompanying appendix

defined in a central project schedule (often in a scheduling tool such as Microsoft Project)

documented in individual, “dynamic” to-do lists for each team member, which are usually too detailed to be placed in the Master Test Plan

documented on a centrally located whiteboard and updated dynamically

not formally documented at all

Based on your project culture, you should either list your specific testing tasks here or provide some descriptive text explaining the process your team uses to handle detailed task planning and provide a reference to where the details are stored, if appropriate.

For Master Test Plans, we recommend avoiding detailed task planning, which is often an unproductive effort if done as a front-loaded activity at the beginning of the project. A Master Test Plan might usefully describe the phases and the number of iterations, and give an indication of what types of testing are generally planned for each Phase or Iteration.

Note: Where process and detailed planning information is recorded centrally and separately from this Master Test Plan, you will have to manage the issues that will arise from having duplicate copies of the same information. To avoid team members referencing out-of-date information, we suggest that in this situation you place the minimum amount of process and planning information within the Master Test Plan to make ongoing maintenance easier and simply reference the “Master” source material.]

9. Environmental Needs

[This section presents the non-human resources required for the Master Test Plan.

Note: This section may be delegated in whole or part to the Test Strategy artifact.]

9.1 Base SystemHardware

The following table sets forth the system resources for the test effort presented in this Master Test Plan.

[Note: Add or delete items as appropriate.]


System Resources
Resource	Quantity	Name and Type

9.2 Base Software Elements in the Test Environment

The following base software elements are required in the test environment for this Master Test Plan.

[Note: Add or delete items as appropriate.]

Software Element Name	Version	Type and Other Notes

9.3 Productivity and Support Tools

The following tools will be employed to support the test process for this Master Test Plan.

[Note: Add or delete items as appropriate.]

Tool Category or Type	Tool Brand Name	Vendor or In-house	Version

9.4 Test Environment Configurations

The following Test Environment Configurations needs to be provided and supported for this project.

Configuration Name	Description	Implemented in Physical Configuration

10. Responsibilities, Staffing, and Training Needs

[This section presents the required resources to address the test effort outlined in the Master Test Plan the main responsibilities, and the knowledge or skill sets required of those resources

Note: This section may be delegated in whole or part to the Test Strategy artifact..]

10.1 People and Roles

This table shows the staffing assumptions for the test effort.

[Note: Add or delete items as appropriate.]


Human Resources
Role	Minimum Resources Recommended (Number of full-time roles allocated)	Specific Responsibilities or Comments
Test Manager		Provides management oversight. Responsibilities include: - planning and logistics - agree on the mission - identify motivators - acquire appropriate resources - present management reporting - advocate the interests of test - evaluate effectiveness of test effort
Test Analyst		Identifies and defines the specific tests to be conducted. Responsibilities include: - identify test ideas - define test details - determine test results - document change requests - evaluate product quality
Test Designer		Defines the technical approach to the implementation of the test effort. Responsibilities include: - define test approach - define test automation architecture - verify test techniques - define testability elements - structure test implementation
Tester		Implements and executes the tests. Responsibilities include: - implement tests and test suites - execute test suites - log results - analyze and recover from test failures - document incidents
Test System Administrator		Ensures test environment and assets are managed and maintained. Responsibilities include: - administer test management system - install and support access to, and recovery of, test environment configurations and test labs
Database Administrator, Database Manager		Ensures test data (database) environment and assets are managed and maintained. Responsibilities include: - support the administration of test data and test beds (database).
Designer		Identifies and defines the operations, attributes, and associations of the test classes. Responsibilities include: - define the test classes required to support testability requirements as defined by the test team
Implementer		Implements and unit tests the test classes and test packages. Responsibilities include: - create the test components required to support testability requirements as defined by the designer

10.2 Staffing and Training Needs

This section outlines how to approach staffing and training the test roles for the project.

[The way to approach staffing and training will vary from project to project. If this section is part of a Master Test Plan, you should indicate at what points in the project lifecycle different skills and numbers of staff are needed.

11. Key Project/ Phase Milestones

[Identify the key schedule milestones that set the context for the Testing effort. Avoid repeating too much detail that is documented elsewhere in plans that address the entire project.]

Milestone	Planned Start Date	Actual Start Date	Planned End Date	Actual End Date
Project/ Phase starts
Master Test Plan agreed
Testing resources requisitioned
Testing team 1st training complete
Phase 1 exit milestone
Requirements baselined
Architecture baselined
User Interface baselined
Phase 2 exit milestone
Test Process Audit Conducted
System Performance Test starts
Customer Acceptance Testing Starts
Project Status Assessment review
Project/ Phase ends

12. Master Plan Risks, Dependencies, Assumptions, and Constraints

[List any risks that may affect the successful execution of thisMaster Test Plan, and identify mitigation and contingency strategies for each risk. Also indicate a relative ranking for both the likelihood of occurrence and the impact if the risk is realized.]

Risk	Mitigation Strategy	Contingency (Risk is realized)

[List any dependencies identified during the development of this Master Test Plan that may affect its successful execution if those dependencies are not honored. Typically these dependencies relate to activities on the critical path that are prerequisites or post-requisites to one or more preceding (or subsequent) activities You should consider responsibilities you are relying on other teams or staff members external to the test effort completing, timing and dependencies of other planned tasks, the reliance on certain work products being produced.]

Dependency between	Potential Impact of Dependency	Owners

[List any assumptions made during the development of this Master Test Plan that may affect its successful execution if those assumptions are proven incorrect. Assumptions might relate to work you assume other teams are doing, expectations that certain aspects of the product or environment are stable, and so forth].

Assumption to be proven	Impact of Assumption being incorrect	Owners

[List any constraints placed on the test effort that have had a negative effect on the way in which this Master Test Plan has been approached.]

Constraint on	Impact Constraint has on test effort	Owners

13. Management Process and Procedures

[Outline what processes and procedures are to be used when issues arise with the Master Test Plan and its enactment.]

13.1 Measuring and Assessing the Extent of Testing

[Define any management and procedural aspects of the measurement and assessment strategy outlined in Section 5.1 Measuring the Extent of Testing .]

13.2 Assessing the Deliverables of this Master Test Plan

[Outline the assessment process for reviewing and accepting the deliverables of this Master Test Plan]

13.3 Problem Reporting, Escalation, and Issue Resolution

[Define how process problems will be reported and escalated, and the process to be followed to achieve resolution.]

13.4 Managing Test Cycles

[Outline the management control process for a test cycle.]

13.5 Traceability Strategies

[Consider appropriate traceability strategies for:

Coverage of Testing against Specifications enables measurement the extent of testing

Motivations for Testing enables assessment of relevance of tests to help determine whether to maintain or retire tests

Software Design Elements enables tracking of subsequent design changes that would necessitate rerunning tests or retiring them

Resulting Change Requests enables the tests that discovered the need for the change to be identified and re-run to verify the change request has been completed successfully]

13.6 Approval and Signoff

[Outline the approval process and list the job titles (and names of current incumbents) that initially must approve the plan, and sign off on the plans satisfactory execution.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Management Goals and Subgoals](#2. Management Goals and Subgoals)

[3. Metrics](#3. Metrics)

[3.1](#3.1 Template for a Metric:) [Template for a metric:](#3.1 Template for a Metric:)

[4. Primitive Metrics](#4. Primitive Metrics)

[4.1 Template for a Primitive Metric:](#4.1 Template for a Primitive Metric:)

[5. Annexes](#5. Annexes)

Measurement Plan

1. Introduction

[The introduction of the Measurement Plan should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Measurement Plan.]

1.1 Purpose

[Specify the purpose of this Measurement Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Measurement Plan. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Measurement Plan. 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.5 Overview

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

2. Management Goals and Subgoals

[State what the goals of the measurement program are relative to the project in terms of achievement, improvement, and quality.]

3. Metrics

[Enumerate the metrics that are to be synthesized at regular intervals on the project to support the goals.]

3.1 Template for a Metric:


Name	[Name of the metric and any known synonyms.]
Definition	[The attributes of the entities that are measured using this metric, how the metric is calculated, and from which primitive metrics it is calculated.]
Goals	[List of goals and questions related to this metric. Also some explanation as to why the metric is being collected.]
Analysis Procedure	[How the metric is intended to be used. Preconditions for the interpretation of the metric; for example, valid range of other metrics. Target values or trends. Models of analysis techniques and tools to be used. Implicit assumptions; for example, of the environment or models. Calibration procedures. Storage.]
Responsibilities	[Who will collect and aggregate measurement data, prepare the reports, and analyze the data.]

4. Primitive Metrics

[Enumerate the primitive metrics that are collected, automatically or manually, to compute the metrics.]

4.1 Template for a Primitive Metric:


Name	[Name of the primitive metric.]
Definition	[Unambiguous description of the metric in terms of the project’s environment.]
Collection procedure	[Description of the collection procedure. Data collection tool and form to be used. Points in the lifecycle when data are collected. Verification procedure to be used. Where will the data be stored, format, precision?]
Responsibilities	[Who is responsible for collecting and verifying the data?].

5. Annexes

[Computation methods, tables for estimates, detailed procedure, as appropriate.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Problem Resolution Tasks](#2. Problem Resolution Tasks)

[3. Organization and Responsibilities](#3. Organization and Responsibilities)

[4. Tools and Techniques](#4. Tools and Techniques)

[5. Problem Tracking](#5. Problem Tracking)

Problem Resolution Plan

1. Introduction

[The introduction of the Problem Resolution Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Problem Resolution Plan.]

1.1 Purpose

[Specify the purpose of this Problem Resolution Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Problem Resolution Plan. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Problem Resolution Plan. Identify each document 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.5 Overview

[This subsection describes what the rest of the Problem Resolution Plan contains and explains how the document is organized.]

2. Problem Resolution Tasks

[A brief description of the Problem Resolution tasks to be performed during the project. In this section you should describe the following:

the procedure the project team will follow for reporting problems
the procedure to be used for analyzing problems
the procedure to be followed to implement appropriate corrective actions

Where these procedures differ for different categories of problems (product, project, and process, see Activity: Develop Problem Resolution Plan), describe the procedure for each under a separate subsection.]

3. Organization and Responsibilities

[List the specific groups or individuals to be involved in the analysis and resolution of each category of problem and identify the tasks and responsibilities of each.]

4. Tools and Techniques

[List the tools and/or techniques that will be used to store problem information, analyze problems, and track the status of problems.]

5. Problem Tracking

[Identify problem categories and where they are stored and tracked, for example:

Product and process problems (defects) may be stored and tracked in a Change Tracking System.
Project problems (issues) may be tracked in an issues list, which is a component of the Status Assessment.
Process problems (non-conformances) may be recorded in an audit report and then tracked in a Change Tracking System (as a kind of Change Request).
Review anomalies will be recorded in the Review Record and tracked from there; if the scope of the problem requires it, a Change Request may be raised.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Responsibilities](#2. Responsibilities)

[3. Product Acceptance Tasks](#3. Product Acceptance Tasks)

[3.1 Product Acceptance Criteria](#3.1 Product Acceptance Criteria)

[3.2 Physical Configuration Audit](#3.2 Physical Configuration Audit)

[3.3 Functional Configuration Audit](#3.3 Functional Configuration Audit)

[3.4 Schedule](#3.4 Schedule)

[4. Resource Requirements](#4. Resource Requirements)

[4.1 Hardware Requirements](#4.1 Hardware Requirements)

[4.2 Software Requirements](#4.2 Software Requirements)

[4.3 Documentation Requirements](#4.3 Documentation requirements)

[4.4 Personnel Requirements](#4.4 Personnel Requirements)

[4.5 Test Data Requirements](#4.5 Test Data Requirements)

[4.6 Other Requirements](#4.6 Other Requirements)

[5. Problem Resolution and Corrective Action](#5. Problem Resolution and Corrective Action)

[6. Product Acceptance Environment](#6. Product Acceptance Environment)

[7. Identification of Required Artifact Evaluations](#7. Identification of Required Artifact Evaluations)

[8. Tools, Techniques, and Methodologies](#8. Tools, Techniques and Methodologies)

Product Acceptance Plan

1. Introduction

[The introduction of the Product Acceptance Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Product Acceptance Plan.]

1.1 Purpose

[Specify the purpose of this Product Acceptance Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Product Acceptance Plan. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Product Acceptance Plan. Identify each document 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.5 Overview

[This subsection describes what the rest of the Product Acceptance Plan contains and explains how the document is organized.]

2. Responsibilities

[Explicitly identify the responsibilities of both the customer and the development team in preparing and performing the product acceptance activities.]

3. Product Acceptance Tasks

3.1 Product Acceptance Criteria

[Identify the objective criteria for determining acceptability of the deliverable artifacts from this project. These criteria should be formally agreed by the customer and the development team.]

3.2 Physical Configuration Audit

[Identify and list here the artifacts that are to be delivered to and accepted by the customer resulting from the work on this project.]

3.3 Functional Configuration Audit

[For each artifact identified in the Physical Configuration Audit, identify the evaluation methods and the level of detail that will be used to determine if it meets the product acceptance criteria.

Methods can include software execution testing, product demonstration, documentation reviews, and so on.]

3.4 Schedule

[A schedule indicating the start and end times for each of the product acceptance tasks, including preparation and setup activities.]

4. Resource Requirements

4.1 Hardware Requirements

[For example, hardware items, interfacing equipment, firmware items.]

4.2 Software Requirements

[For example, operating systems, compilers, test drivers, test data generators.]

4.3 Documentation Requirements

[For example, test documentation, technical references.]

4.4 Personnel Requirements

[For example, development team members, customer representatives, third-party party authorities.]

4.5 Test Data Requirements

[For example, size, type, and composition of data to support acceptance tests.]

4.6 Other Requirements

[For example, special equipment.]

5. Problem Resolution and Corrective Action

[This section describes the procedures for reporting and handling problems identified during the Product Acceptance activities. Usually this is addressed by enclosing the Problem Resolution Plan artifact by reference.]

6. Product Acceptance Environment

[Describe the plans for setting up the product acceptance environment.]

7. Identification of Required Artifact Evaluations

[Based on the Functional Configuration Audit description, identify each individual artifact evaluation that will be carried out. For each one, list the type of evaluation (test, review, and so on), and its objectives.

Note: A Test Case artifact will be prepared for each test identified here.]

8. Tools, Techniques, and Methodologies

[A list of any specific tools, techniques, and methodologies that are to be used when performing the Product Acceptance activities.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Code Organization and Style](#2. Code Organization and Style)

[3. Comments](#3. Comments)

[4. Naming](#4. Naming)

[5. Declaration](#5. Declaration)

[6. Expressions and Statements](#6. Expressions and Statements)

[7. Memory Management](#7. Memory Management)

[8. Error Handling and Exception](#8. Error Handling and Exception)

[9. Portability](#9. Portability)

[10. Reuse](#10. Reuse)

[11. Compilation issues](#11. Compilation issues)

[12. Annex: Summary of Guidelines](#12. Annex: Summary of Guidelines)

Programming Guidelines

1. Introduction

[The introduction of the Programming Guidelines should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Programming Guidelines.]

1.1 Purpose

[Specify the purpose of the Programming Guidelines.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Programming Guidelines. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Programming Guidelines. 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.5 Overview

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

2. Code Organization and Style

[A description of the size of a module, layout of a module, space, nesting, legibility, and so on.]

3. Comments

[A description of the use of comments.]

4. Naming

[A description of how each kind of entity (such as types, variables, and subprograms) should be named.]

5. Declaration

[A description of how declarations should be written.]

6. Expressions and Statements

[A description of how expressions and statements should be written.]

7. Memory Management

[A description of how memory should be managed.]

8. Error Handling and Exception

[This section gives rules and guidelines on how error handling and exceptions should be handled.]

9. Portability

[This section describes special rules to ensure portability across different platforms and compilers.]

10. Reuse

[This section gives rules and guidelines to foster easier reuse.]

11. Compilation issues

[This section describes dependencies between modules, compiler directives, and so on.]

12. Annex: Summary of Guidelines

[This section summarizes all guidelines; one line for each.]

Software Development Plan

1. Introduction

2. Project Organization

2.1 Organizational Structure

2.2 External Interfaces

[Describe how the project interfaces with external groups. For each external group, identify the internal and external contact names. This should include responsibilities related to deployment and acceptance of the product.]

2.3 Roles and Responsibilities

[Identify the people or organizational units that have a role on the project, and what role(s) they play.]


Person	Rational Unified Process Role
Sally Slalom, Senior Manager	Project Manager Deployment Manager Requirements Reviewer Architecture Reviewer Configuration Manager Change Control Manager
Matt Mogul, VP Operations	Management Reviewer Requirements Reviewer
Tom Telemark, Senior Software Engineer	System Analyst Requirements Specifier User Interface Designer Software Architect Design Reviewer Test Manager Test Analyst and to a lesser extent the following roles:
Susan Snow, Software Engineer Henry Halfpipe, Junior Software Engineer TBD1, Software Engineer TBD2, Junior Software Engineer	Designer Implementer Code Reviewer Integrator Test Designer Tester Technical Writer
Patrick Powder, Administrative Assistant	Responsible for maintaining the Project web site, assisting the Project Manager role in planning/scheduling activities, and assisting the Change Control Manager role in controlling changes to artifacts. May also provide assistance to other roles as necessary.

Anyone on the project can perform the activities performed by the RUP role called “Any Role”.

3. Project Schedule

[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.] For example:


Phase	Iteration	Primary Objective (risks/use cases addressed)	Scheduled Start/Stop	Effort Estimate (person days)
Inception	I1
Elaboration	E1
Construction	C1
	C2
Transition	T1
	T2

4. Project Resourcing

[Identify the numbers and type of staff required here, including any special skills or experience, scheduled by project phase or iteration.

Describe how you will approach finding and acquiring the staff needed for the project.

List any special training project team members will require, with target dates for when this training should be completed.]

5. Budget

[Describe the size of the budget, how it is allocated, and how it will be monitored.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Quality Objectives](#2. Quality Objectives)

[3. Management](#3. Management)

[3.1 Organization](#3.1 Organization)

[3.2 Tasks and Responsibilities](#3.2 Tasks & Responsibilities)

[4. Documentation](#4. Documentation)

[5. Standards and Guidelines](#5. Standards and Guidelines)

[6. Metrics](#6. Metrics)

[7. Review and Audit Plan](#7. Review and Audit Plan)

[8. Evaluation and Test](#8. Evaluation and Test)

[9. Problem Resolution and Corrective Action](#9. Problem Resolution and Corrective Action)

[10. Tools, Techniques, and Methodologies](#10. Tools, Techniques and Methodologies)

[11. Configuration Management](#11. Configuration Management)

[12. Supplier and Subcontractor Controls](#12. Supplier and Subcontractor Controls)

[13. Quality Records](#13. Quality Records)

[14. Training](#14. Training)

[15. Risk Management](#15. Risk Managemen)

Quality Assurance Plan

1. Introduction

[The introduction of the Quality Assurance Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Quality Assurance Plan.]

1.1 Purpose

[Specify the purpose of this Quality Assurance Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Quality Assurance Plan. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Quality Assurance Plan. Identify each document 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. For the Quality Assurance Plan, this should include:

Documentation Plan

Measurement Plan

Test Plan

Software Development Plan

Problem Resolution Plan

Configuration Management Plan

Subcontractor Management Plan

Risk Management Plan]

1.5 Overview

[This subsection describes what the rest of the Quality Assurance Plan contains and explains how the document is organized.]

2. Quality Objectives

[This section needs to reference the section of the Software Requirements Specification that deals with quality requirements.]

3. Management

3.1 Organization

[Describe the structure of the organization responsible for Quality Assurance. The Rational Unified Process recommends that the Software Engineering Process Authority (SEPA) be responsible for the process component of Quality Assurance. The Rational Unified Process further recommends that the evaluation of product be done within the project (most notably by an independent test team) and by joint customer/developer review.]

3.2 Tasks and Responsibilities

[Describe the various Quality Assurance tasks that will be carried out for this project and indicate how they are synchronized with the project’s major and minor milestones. These tasks will include:

Joint Reviews

Process Audits

Process Reviews

Customer Audits

For each task, identify the team member responsible for its execution.]

4. Documentation

[Enclose the Documentation Plan artifact by reference.

Also, list the minimum documentation that must be produced during the project to ensure that the software product that is developed satisfies the requirements. The suggested minimum set is:

Software Development Plan (SDP)

Test Plan

Iteration Plans

Software Requirements Specification (SRS)

Software Architecture Document

User Documentation (for example, manuals, guides)

Configuration Management Plan

Provide pointers to the Development Case to show where in the process the adequacy of these documents is evaluated.]

5. Standards and Guidelines

[This section references any standards and guidelines that are expected to be used on the project, and addresses how compliance with these standards and guidelines is to be determined. The relevant artifacts are enclosed by reference. The suggested set for the Rational Unified Process is:

Development Case

Business Modeling Guidelines

User-Interface Guidelines

Use-Case Modeling Guidelines

Design Guidelines

Programming Guidelines

Test Guidelines

Manual Style Guide]

6. Metrics

[This section describes the product, project, and process metrics that are to be captured and monitored for the project. This is usually addressed by enclosing the Measurement Plan artifact by reference.]

7. Review and Audit Plan

[This section contains the Review and Audit Plan. The Review and Audit Plan specifies the schedule, resources, and methods and procedures to be used in conducting project reviews and audits. The plan details the various types of reviews and audits to be carried out during the project, and identifies any external agencies that are expected to approve or regulate the artifacts produced by the project.

This section should identify:

Review and Audit Tasks

Describe briefly each type of review and audit that will be carried out on the project. For each type, identify the project artifacts that will be the subject of the review or audit. These may include Joint Customer-Developer Technical and Management Reviews, Process Reviews and Audits, Customer Audits, Internal Technical and Management Reviews.

Schedule

Detail here the schedule for the reviews and audits. This should include reviews and audits scheduled at project milestones, as well as reviews that are triggered by delivery of project artifacts. This subsection may reference the project or iteration plan.

Organization and Responsibilities

List here the specific groups or individuals to be involved in each of the identified review and audit activities. Describe briefly the tasks and responsibilities of each. Also, list any external agencies that are expected to approve or regulate any product of the project.

Problem Resolution and Corrective Action

This subsection describes the procedures for reporting and handling problems identified during project reviews and audits. The Problem Resolution Plan may be referenced.

Tools, Techniques and Methodologies

Describe here any specific tools, techniques or methodologies that are to be used to carry out the review and audit activities identified in this plan. You should describe the explicit process to be followed for each type of review or audit. Your organization may have a standard Review and Audit Procedures Manual, which may be referenced. These procedure descriptions should also address the collection, storage and archiving of the project’s Review Records.

A suggested set of reviews and audits (drawn from the Rational Unified Process) to use as a basis for planning is:

Requirements Review (maps to the traditional Software Specification Review)

Architecture Review (maps to the traditional Preliminary Design Review)

Design Review (maps to the traditional Critical Design Review)

Note that the product-, technique-, criteria-, and metrics- related aspects of these reviews is addressed in the Rational Unified Process itself and instantiated in the Evaluation Plan section of the Software Development Plan. The Review and Audit Plan section of the Quality Assurance Plan will concern itself with the Joint (customer, developer) Review aspects, for example, artifacts required, responsibilities, conduct of the review meeting, pass or fail criteria.

- Functional Configuration audit (to verify all requirements in the SRS have been met)

Physical configuration audit (to verify that the software and its documentation are complete and ready for delivery)

Process audits

Process reviews

Managerial reviews (Project Approval Review, Project Planning Review, Iteration Plan Review, PRA Project Review)

Post-mortem reviews (Iteration Acceptance Review, Lifecycle Milestone Review, Project Acceptance Review).]

8. Evaluation and Test

[This section references the Software Development Plan (Evaluation Plan section) and the Test Plan.]

9. Problem Resolution and Corrective Action

[This section references the Problem Resolution Plan.]

10. Tools, Techniques, and Methodologies

[A list of any tools, techniques and methodologies that are to be used when performing Quality Assurance activities.]

11. Configuration Management

[This section references the Configuration Management Plan.]

12. Supplier and Subcontractor Controls

[This section references the Subcontractor Management Plan.]

13. Quality Records

[Descriptions of the various quality records that will be maintained during the project, including how and where each type of record will be stored and for how long.]

14. Training

[List here any training activities necessary for the project team to achieve the needs of the Quality Assurance Plan.]

15. Risk Management

[This section references the Risk Management Plan.]

Revision History


Date	Version	Description	Author
<dd/mmm/yy>	<x.x>	<short description of release>	<Author Name>

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Disclaimer of Warranty](#1.1 Disclaimer of warranty)

[1.2 Purpose](#1.2 Purpose)

[1.3 Scope](#1.3 Scope)

[1.4 Definitions, Acronyms, and Abbreviations](#1.4 Definitions, Acronyms and Abbreviations)

[1.5 References](#1.5 References)

[1.6 Overview](#1.6 Overview)

[2. About This Release](#2. About This Release)

[3. Compatible Products](#3. Compatible Products)

[4. Upgrades](#4. Upgrading)

[5. New Features](#5. New Features)

[6. Known Bugs and Limitations](#6. Known Bugs and Limitations)

[6.1 General Note](#6.1 General Note)

[6.2 <Defect or Bug>](#6.2 <Defect or Bug>)

Release Notes

1. Introduction

[The introduction of the Release Notes provides an overview of the entire document. It includes the disclaimer of warranty, purpose, scope, definitions, acronyms, abbreviations, references and overview of this Release Notes.]

1.1 Disclaimer of Warranty

<CompanyName> makes no representations or warranties, either express or implied, by or with respect to anything in this document, and shall not be liable for any implied warranties of merchantability or fitness for a particular purpose or for any indirect, special or consequential damages.

GOVERNMENT RIGHTS LEGEND: Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the applicable license agreement and as provided in DFARS 227.7202-1(a) and 227.7202-3(a) (1995), DFARS 252.227-7013(c)(1)(ii) (Oct 1988), FAR 12.212(a) (1995), FAR 52.227-19, or FAR 52.227-14, as applicable.

“” and ’s products are trademarks of . References to other companies and their products use trademarks owned by the respective companies and are for reference purpose only.

1.2 Purpose

The purpose of the Release Notes is to communicate the major new features and changes in this release of the <Project Name>. It also documents known problems and workarounds.

1.3 Scope

This document describes the <Project Name>.

1.4 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Release Notes. This information may be provided by reference to the project’s Glossary.]

1.5 References

[This subsection provides a complete list of all documents referenced elsewhere in the Release Notes. Identify each document 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.6 Overview

[This subsection describes what the rest of the Release Notes contains and explains how the document is organized.]

2. About This Release

[A description of the release is presented here, including release-defining characteristics or features. The description needs to be brief, however, and simply clarifies the release definition.]

3. Compatible Products

This product has been tested on the following platforms or with the following products:

[List products or platforms here.]

[Also list any product operating environment requirements here.]

4. Upgrades

[Describe the process for upgrading from previous product releases.]

5. New Features

The following new features appear in this release:

[List of new features.]

6. Known Bugs and Limitations

6.1 General Note

[Describe any general limitations that affect overall functionality.]

6.2 <Defect or Bug>

[Describe the defect or bug symptom and any workarounds, if they exist.]

Revision History


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

Table of Contents

1.3 Definitions, Acronyms, and Abbreviations

2. Requirements Management

1.5 Overview

2.1 Organization, Responsibilities, and Interfaces

2.2 Tools, Environment, and Infrastructure

3. The Requirements Management Program

3.1 Requirements Identification

3.4 Reports and Measures

3.5 Requirements Change Management

3.5.1 Change Request Processing and Approval

3.5.2 Change Control Board (CCB)

3.5.3 Project Baselines

3.6 Workflows and Activities

4. Milestones

5. Training and Resources

Requirements Management Plan

1. Introduction

[The introduction of the Requirements Management Plan provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Requirements Management Plan.]

1.1 Purpose

[Specify the purpose of this Requirements Management Plan.]

1.2 Scope

[A brief description of the scope of this Requirements Management Plan.]

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Requirements Management Plan. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Requirements Management Plan. Each document is 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.5 Overview

[This subsection describes what the rest of the Requirements Management Plan contains and explains how the document is organized.]

2. Requirements Management

2.1 Organization, Responsibilities, and Interfaces

[Describe who is going to be responsible for performing the various activities described in the requirements workflows.]

2.2 Tools, Environment, and Infrastructure

[Describe the computing environment and software tools to be used in fulfilling the Requirements Management functions throughout the project or product lifecycle.

Describe the tools and procedures used to version control Requirements items generated throughout the project or product lifecycle.]

3. The Requirements Management Program

3.1 Requirements Identification

[Describe traceability items, and define how they are to be named, marked, and numbered. (A traceability item is any project element that needs to be explicitly traced from another textual, or model item to keep track of the dependencies between them. With respect to Rational RequisitePro this definition can be rephrased as: any project element represented within RequisitePro by an instance of a RequisitePro requirement type.)]

[For each type of requirement document or artifact in your project, list the traceability items contained in it and briefly explain what it is used for. You may also wish to list the responsible role.]


Artifact (Document Type)	Traceability Item	Description
Stakeholder Requests (STR)	Stakeholder Request (STRQ)	Key requests, including Change Requests, from stakeholders. [If you use a Change Request Management tool, such as Rational ClearQuest, then stakeholder requests are often stored in that tool and not duplicated in the requirements management tool.]
Vision (VIS)	Stakeholder Need (NEED)	Key stakeholder or user need
Vision (VIS)	Feature (FEAT)	Conditions or capabilities of this release of the system
Use-Case Model	Use Case (UC)	Use cases for this release, documented in Rational Rose
Supplementary Specification (SS)	Supplementary Requirement (SUPP)	Non-functional requirements that are not captured in the use-case model

3.2 Traceability

[Overview of traceability; for example, a traceability graph.]

3.2.1 Criteria for <traceability item>

[For each traceability item you have identified, list any additional rules or guidelines that apply to traceability links. Describe any applicable constraints, such as “every approved feature must trace to one or more Use Cases or to one or more Supplementary Requirements”.]

3.3 Attributes

3.3.1 Attributes for <traceability item>

[For each traceability item you have identified, list what attributes you will be using and briefly explain what they mean. For example, the following attributes might be specified for a traceability item of “feature”.]

Status

[Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.]


Proposed	[Used to describe features that are under discussion but have not yet been reviewed and accepted by the “official channel,” such as a working group consisting of representatives from the project team, product management, and user or customer community.]
Approved	[Capabilities that are deemed useful and feasible, and have been approved for implementation by the official channel.]
Rejected	[Rejected by the official channel.]
Incorporated	[Features incorporated into the product baseline at a specific point in time.]

Benefit

[Set by Marketing, the product manager or the business analyst. All requirements are not created equal. Ranking requirements by their relative benefit to the end user opens a dialogue with customers, analysts, and members of the development team. Used in managing scope and determining development priority.]


Critical	[Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.]
Important	[Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.]
Useful	[Features that are useful in less typical applications or for which reasonably efficient workarounds can be achieved will be used less frequently. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.]

Effort

[Set by the development team. Because some features require more time and resources than others, estimating the number of team or person-weeks, lines of code required or function points, for example, is the best way to gauge complexity and set expectations of what can and cannot be accomplished in a given time frame. Used in managing scope and determining development priority.]

Risk

[Set by the development team and based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low to be sufficient, although finer gradations are possible. Risk can often be assessed indirectly by measuring the uncertainty (range) of the projects’ team’s estimated schedule.]

Stability

[Set by the analyst and development team, this is based on the probability that the feature will change or the team’s understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.]

Target Release

[Records the intended product version in which the feature will first appear. This field can be used to allocate features from a Vision document into a particular baseline release. When combined with the status field, your team can propose, record, and discuss various features of the release without committing them to development. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document, but will be scheduled for a later release.]

Assigned To

[In many projects, features will be assigned to “feature teams” responsible for further elicitation, writing the software requirements and implementation. This simple pull-down list will help everyone on the project team to better understand responsibilities.]

Reason

[This text field is used to track the source of the requested feature. Requirements exist for specific reasons. This field records an explanation or a reference to an explanation. For example, the reference might be to a page and line number of a product requirement specification or to a minute marker on a video of an important customer interview.]

3.4 Reports and Measures

[Describe the content, format, and purpose of the requested reports/measures.

3.5 Requirements Change Management

3.5.1 Change Request Processing and Approval

[Describe the process by which problems and changes are submitted, reviewed, and dispositioned. This should include the process for negotiating requirements changes with customers, and any contractual processes, activities, and constraints].

3.5.2 Change Control Board (CCB)

[Describe the membership and procedures for processing change requests and approvals to be followed by the CCB.]

3.5.3 Project Baselines

[Baselines provide an official standard on which subsequent work is based and to which only authorized changes are made.

Describe who authorizes a baseline and what goes into it.]

3.6 Workflows and Activities

[Describe the workflows and activities that apply to managing requirements.

Describe review activities, including review objectives, responsibilities, timing, and procedures].

4. Milestones

[Identify the internal and customer milestones related to the Requirements Management effort. This section should include details on when the Requirements Management Plan itself is to be updated.]

5. Training and Resources

[Describe the software tools, personnel, and training required to implement the specified Requirements Management activities.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Risks](#2. Risks)

[2.1 <Risk Identifier - a descriptive name or number>](#2.1 <Risk Identifier)

[2.1.1 Risk Magnitude or Ranking](#2.1.1 Risk Magnitude or Ranking)

[2.1.2 Description](#2.1.2 Description)

[2.1.3 Impacts](#2.1.3 Impacts)

[2.1.4 Indicators](#2.1.4 Indicators)

[2.1.5 Mitigation Strategy](#2.1.5 Mitigation Strategy)

[2.1.6 Contingency Plan](#2.1.6 Contingency Plan)

[2.2 <next Risk Identifier - a descriptive name or number>](#2.2 <next Risk Identifier-a descriptive name or number>)

Risk List

1. Introduction

[The introduction of the Risk List provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Risk List.]

1.1 Purpose

[Specify the purpose of this Risk List.]

1.2 Scope

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

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Risk List. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Risk List. Identify each document 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.5 Overview

[This subsection describes what the rest of the Risk List contains and explains how the document is organized.]

2. Risks

2.1 <Risk Identifier-a descriptive name or number>

2.1.1 Risk Magnitude or Ranking

[An indicator of the magnitude of the risk may be assigned to help rank the risks from the most to the least damaging to the project.]

2.1.2 Description

[A brief description of the risk.]

2.1.3 Impacts

[List the impacts on the project or product.]

2.1.4 Indicators

[Describe how to monitor and detect that the risk has occurred or is about to occur. Include such things as metrics and thresholds, test results, specific events, and so on.]

2.1.5 Mitigation Strategy

[Describe what is currently done on the project to reduce the impact of the risk.]

2.1.6 Contingency Plan

[Describe what the course of action will be if the risk does materialize: alternate solution, reduction in functionality, and so forth.]

2.2 <next Risk Identifier-a descriptive name or number>

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Risk Summary](#2. Risk Summary)

[3. Risk Management Tasks](#3. Risk Management Tasks)

[4. Organization and Responsibilities](#4. Organization and Responsibilities)

[5. Budget](#5. Budget)

[6. Tools and Techniques](#6. Tools and Techniques)

[7. Risk Items to be Managed](#7. Risk Items to be Managed)

Risk Management Plan

1. Introduction

[The introduction of the Risk Management Plan should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Risk Management Plan.]

1.1 Purpose

[Specify the purpose of this Risk Management Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Risk Management Plan. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Risk Management Plan. 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.5 Overview

[This subsection should describe what the rest of the Risk Management Plan contains and explain how the document is organized.]

2. Risk Summary

[A brief overview of the project, and summary of the overall amount of risk involved in the project.]

3. Risk Management Tasks

[A brief description of the risk management tasks to be performed during the project. In this section you should describe the following:

The approach to be used to identify risks and how the risks list will be analyzed and prioritized.

The risk management strategies that will be used, including mitigation, avoidance, and/or prevention strategies for the most significant (“top-10”) risks.

How the status of each significant risk and its mitigation activities is to be monitored.

Risk review and reporting schedules. A risk review should be part of each iteration/phase acceptance review.]

4. Organization and Responsibilities

[A list of the specific groups or individuals to be involved in the project’s risk management activities and a description of the tasks and responsibilities of each.]

5. Budget

[The budget available for managing project risks (when this information is not already included in the overall project budget).]

6. Tools and Techniques

[A list of the tools and/or techniques that will be used to store risk information, evaluate risks, track the status of risks, or generate risk management reports.]

7. Risk Items to be Managed

[A list of the risk items that have been identified. This can be a link to the Artifact: Risk List for the project.

An industry best practice is to publish and keep visible a “Top-10” list of risks that are considered significant enough for the project to spend resources on their management. You may maintain a longer list if organizational practice or the contract requires it.

Indicators that the risk is being realized, and mitigation, avoidance or preventative strategies are identified for each risk listed. Some risks will also require a description of the action that is contingent upon the risk being realized.]

Software Architecture Document

[This section defines the purpose of the Software Architecture Document, in the overall project documentation, and briefly describes the structure of the document. The specific audiences for the document should be identified, with an indication of how they are expected to use the document.]

1.2 Scope

[A brief description of what the Software Architecture Document applies to; what is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Software Architecture Document. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Software Architecture Document. 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.5 Overview

[This subsection should describe what the rest of the Software Architecture Document contains and explain how the Software Architecture Document is organized.]

2. Architectural Representation

[This section describes what software architecture is for the current system, and how it is represented. Of the Use-Case, Logical, Process, Deployment, and Implementation Views, it enumerates the views that are necessary, and for each view, explains what types of model elements it contains.]

3. Architectural Goals and Constraints

[This section describes the software requirements and objectives that have some significant impact on the architecture, for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution, and reuse. It also captures the special constraints that may apply: design and implementation strategy, development tools, team structure, schedule, legacy code, and so on.]

4. Use-Case View

[This section lists use cases or scenarios from the use-case model if they represent some significant, central functionality of the final system, or if they have a large architectural coverage - they exercise many architectural elements, or if they stress or illustrate a specific, delicate point of the architecture.]

5. Logical View

[This section describes the architecturally significant parts of the design model, such as its decomposition into subsystems and packages. And for each significant package, its decomposition into classes and class utilities. You should introduce architecturally significant classes and describe their responsibilities, as well as a few very important relationships, operations, and attributes.]

5.1 Overview

[This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers.]

5.2 Architecturally Significant Design Packages

[For each significant package, include a subsection with its name, its brief description, and a diagram with all significant classes and packages contained within the package.

For each significant class in the package, include its name, brief description, and, optionally a description of some of its major responsibilities, operations and attributes.]

5.3 Use-Case Realizations

[This section illustrates how the software actually works by giving a few selected use-case (or scenario) realizations, and explains how the various design model elements contribute to their functionality.

6. Process View

[This section describes the system’s decomposition into lightweight processes (single threads of control) and heavyweight processes (groupings of lightweight processes). Organize the section by groups of processes that communicate or interact. Describe the main modes of communication between processes, such as message passing, interrupts, and rendezvous.]

7. Deployment View

[This section describes one or more physical network (hardware) configurations on which the software is deployed and run. It is a view of the Deployment Model. At a minimum for each configuration it should indicate the physical nodes (computers, CPUs) that execute the software, and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the physical nodes.]

8. Implementation View

[This section describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model, and any architecturally significant implementation elements.]

8.1 Overview

[This subsection names and defines the various layers and their contents, the rules that govern the inclusion to a given layer, and the boundaries between layers. Include a component diagram that shows the relations between layers. ]

8.2 Layers

[For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer, and a component diagram.]

9. Data View (optional)

[A description of the persistent data storage perspective of the system. This section is optional if there is little or no persistent data, or the translation between the Design Model and the Data Model is trivial.]

10. Size and Performance

[A description of the major dimensioning characteristics of the software that impact the architecture, as well as the target performance constraints.]

11. Quality

[A description of how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics have special significance, for example safety, security or privacy implications, they should be clearly delineated.]

Software Architecture Document

1. Introduction

[The introduction of the Software Architecture Document provides an overview of the entire Software Architecture Document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Software Architecture Document.]

2. Architectural Representation

3. Architectural Goals and Constraints

[This section describes the software requirements and objectives that have some significant impact on the architecture; for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution, and reuse. It also captures the special constraints that may apply: design and implementation strategy, development tools, team structure, schedule, legacy code, and so on.]

4. Use-Case View

[This section lists use cases or scenarios from the use-case model if they represent some significant, central functionality of the final system, or if they have a large architectural coverage they exercise many architectural elements or if they stress or illustrate a specific, delicate point of the architecture.]

5. Logical View

5.1 Overview

[This subsection describes the overall decomposition of the design model in terms of its package hierarchy and layers.]

5.2 Architecturally Significant Design Packages

[For each significant package, include a subsection with its name, its brief description, and a diagram with all significant classes and packages contained within the package.

For each significant class in the package, include its name, brief description, and, optionally, a description of some of its major responsibilities, operations, and attributes.]

5.3 Use-Case Realizations

6. Process View

7. Deployment View

[This section describes one or more physical network (hardware) configurations on which the software is deployed and run. It is a view of the Deployment Model. At a minimum for each configuration it should indicate the physical nodes (computers, CPUs) that execute the software and their interconnections (bus, LAN, point-to-point, and so on.) Also include a mapping of the processes of the Process View onto the physical nodes.]

8. Implementation View

8.1 Overview

8.2 Layers

[For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer, and a component diagram.]

9. Data View (optional)

10. Size and Performance

[A description of the major dimensioning characteristics of the software that impact the architecture, as well as the target performance constraints.]

11. Quality

[A description of how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics have special significance, such as safety, security or privacy implications, they must be clearly delineated.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Project Overview](#2. Project Overview)

[2.1 Project Purpose, Scope and Objectives](#2.1 Project Purpose, Scope, and Objectives)

[2.2 Assumptions and Constraints](#2.2 Assumptions and Constraints)

[2.3 Project Deliverables](#2.3 Project Deliverables)

[2.4 Evolution of the Software Development Plan](#2.4 Evolution of the Software Development Plan)

[3. Project Organization](#3. Project Organization)

[3.1 Organizational Structure](#3.1 Organizational Structure)

[3.2 External Interfaces](#3.2 External Interfaces)

[3.3 Roles and Responsibilities](#3.3 Roles and Responsibilities)

[4. Management Process](#4. Management Process)

[4.1 Project Estimates](#4.1 Project Estimates)

[4.2 Project Plan](#4.2 Project Plan)

[4.2.1 Phase Plan](#4.2.1 Phase Plan)

[4.2.2 Iteration Objectives](#4.2.2 Iteration Objectives)

[4.2.3 Releases](#4.2.3 Releases)

[4.2.4 Project Schedule](#4.2.4 Project Schedule)

[4.2.5 Project Resourcing](#4.2.5 Project Resourcing)

[4.2.5.1 Staffing Plan](#4.2.5.1 Staffing Plan)

[4.2.5.2 Resource Acquisition Plan](#4.2.5.2 Resource Acquisition Plan)

[4.2.5.3 Training Plan](#4.2.5.3 Training Plan)

[4.2.6 Budget](#4.2.6 Budget)

[4.3 Iteration Plans](#4.3 Iteration Plans)

[4.4 Project Monitoring and Control](#4.4 Project Monitoring and control)

[4.4.1 Requirements Management Plan](#4.4.1 Requirements Management Plan)

[4.4.2 Schedule Control Plan](#4.4.2 Schedule Control Plan)

[4.4.3 Budget Control Plan](#4.4.3 Budget Control Plan)

[4.4.4 Quality Control Plan](#4.4.4 Quality Control Plan)

[4.4.5 Reporting Plan](#4.4.5 Reporting Plan)

[4.4.6 Measurement Plan](#4.4.6 Measurement Plan)

[4.5 Risk Management plan](#4.5 Risk Management plan)

[4.6 Close-out Plan](#4.6 Close-out Plan)

[5. Technical process plans](#5. Technical Process Plans)

[5.1 Development Case](#5.1 Development Case)

[5.2 Methods, Tools and Techniques](#5.2 Methods, tools and techniques)

[5.3 Infrastructure Plan](#5.3 Infrastructure Plan)

[5.4 Product Acceptance Plan](#5.4 Product Acceptance Plan)

[6. Supporting Process Plans](#6. Supporting Process Plans)

[6.1 Configuration Management Plan](#6.1 Configuration Management Plan)

[6.2 Evaluation Plan](#6.2 Evaluation Plan)

[6.3 Documentation Plan](#6.3 Documentation Plan)

[6.4 Quality Assurance Plan](#6.4 Quality Assurance Plan)

[6.5 Problem Resolution Plan](#6.5 Problem Resolution Plan)

[6.6 Subcontractor Management Plan](#6.6 Subcontractor Management Plan)

[6.7 Process Improvement Plan](#6.7 Process Improvement Plan)

[7. Additional Plans](#7. Additional plans)

[8. Annexes](#8. Annexes)

[9. Index](#9. Index)

Software Development Plan

1. Introduction

[The introduction of the Software Development Plan should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Software Development Plan.]

1.1 Purpose

[Specify the purpose of this Software Development Plan.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Software Development Plan. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Software Development Plan. 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.

For the Software Development Plan, the list of referenced artifacts should include:

Iteration Plans

Requirements Management Plan

Measurement Plan

Risk Management Plan

Development Case

Business Modeling Guidelines

User Interface Guidelines

Use-Case-Modeling Guidelines

Design Guidelines

Programming Guidelines

Test Guidelines

Manual Style Guide

Infrastructure Plan

Product Acceptance Plan

Configuration Management Plan

Evaluation Plan (only if this is a separate plan - normally this is part of the SDP at Section 6.2)

Documentation Plan

Quality Assurance Plan

Problem Resolution Plan

Subcontractor Management Plan

Process Improvement Plan]

1.5 Overview

[This subsection should describe what the rest of the Software Development Plan contains and explain how the document is organized.]

2. Project Overview

2.1 Project Purpose, Scope, and Objectives

[A brief description of the purpose and objectives of this project and a brief description of what deliverables the project is expected to deliver.]

2.2 Assumptions and Constraints

[A list of assumptions that this plan is based and any constraints, for example. budget, staff, equipment, schedule, that apply to the project.]

2.3 Project Deliverables

[A tabular list of the artifacts to be created during the project, including target delivery dates.]

2.4 Evolution of the Software Development Plan

[A table of proposed versions of the Software Development Plan, and the criteria for the unscheduled revision and reissue of this plan.]

3. Project Organization

3.1 Organizational Structure

[Describe the organizational structure of the project team, including management and other review authorities.]

3.2 External Interfaces

[Describe how the project interfaces with external groups. For each external group, identify the internal and external contact names.]

3.3 Roles and Responsibilities

[Identify the project organizational units that will be responsible for each of the disciplines, workflow details, and supporting processes.]

4. Management Process

4.1 Project Estimates

[Provide the estimated cost and schedule for the project, as well as the basis for those estimates, and the points and circumstances in the project when re-estimation will occur.]

4.2 Project Plan

4.2.1 Phase Plan

[Include the following:

Work Breakdown Structure (WBS)

a timeline or Gantt chart showing the allocation of time to the project phases or iterations

identify major milestones with their achievement criteria

Define any important release points and demos]

4.2.2 Iteration Objectives

[List the objectives to be accomplished for each of the iterations.]

4.2.3 Releases

[A brief description of each software release and whether it’s demo, beta, etc.]

4.2.4 Project Schedule

[Diagrams or tables showing target dates for completion of iterations and phases, release points, demos, and other milestones.]

4.2.5 Project Resourcing

4.2.5.1 Staffing Plan

[Identify here the numbers and type of staff required, including any special skills or experience, scheduled by project phase or iteration.]

4.2.5.2 Resource Acquisition Plan

[Describe how you will approach finding and acquiring the staff needed for the project.]

4.2.5.3 Training Plan

[List any special training project team members will require, with target dates for when this training should be completed.]

4.2.6 Budget

[Allocation of costs against the WBS and the Phase Plan.]

4.3 Iteration Plans

[Each iteration plan will be enclosed in this section by reference.]

4.4 Project Monitoring and control

4.4.1 Requirements Management Plan

[Enclosed by reference.]

4.4.2 Schedule Control Plan

[Describes the approach to be taken to monitor progress against the planned schedule and how to take corrective action when required.]

4.4.3 Budget Control Plan

[Describes the approach to be taken to monitor spending against the project budget and how to take corrective action when required.]

4.4.4 Quality Control Plan

[Describe the timing and methods to be used to control the quality of the project deliverables and how to take corrective action when required.]

4.4.5 Reporting Plan

[Describes internal and external reports to be generated, and the frequency and distribution of publication.]

4.4.6 Measurement Plan

[Enclosed by reference.]

4.5 Risk Management plan

[Enclosed by reference.]

4.6 Close-out Plan

[Describe the activities for the orderly completion of the project, including staff reassignment, archiving of project materials, post-mortem debriefings and reports etc.]

5. Technical Process Plans

5.1 Development Case

[Enclosed by reference.]

5.2 Methods, tools and techniques

[Lists the documented project technical standards, etc., by reference:

Business Modeling Guidelines

User Interface Guidelines

Use-Case-Modeling Guidelines

Design Guidelines

Programming Guidelines

Test Guidelines

Manual Style guide]

5.3 Infrastructure Plan

[Enclosed by reference]

5.4 Product Acceptance Plan

[Enclosed by reference]

6. Supporting Process Plans

6.1 Configuration Management Plan

[Enclosed by reference]

6.2 Evaluation Plan

[Part of the Software Development Plan, this describes the project’s plans for product evaluation, and covers the techniques, criteria, metrics, and procedures used for evaluation- this will include walkthroughs, inspections, and reviews. Note that this is in addition to the Test Plan which is not enclosed in the Software Development Plan.]

6.3 Documentation Plan

[Enclosed by reference.]

6.4 Quality Assurance Plan

[Enclosed by reference.]

6.5 Problem Resolution Plan

[Enclosed by reference.]

6.6 Subcontractor Management Plan

[Enclosed by reference.]

6.7 Process Improvement Plan

[Enclosed by reference]

7. Additional plans

[Additional plans if required by contract or regulations.]

8. Annexes

[Additional material of use to the reader of the SDP.]

9. Index

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Overall Description](#2. Overall Description)

[3. Specific Requirements](#3. Specific Requirements)

[3.1 Functionality](#3.1 Functionality)

[3.1.1 ](#3.1.1 <Functional Requirement One>)

[3.2 Usability](#3.2 Usability)

[3.2.1 ](#3.2.1 <Usability Requirement One>)

[3.3 Reliability](#3.3 Reliability)

[3.3.1 ](#3.3.1 <Reliability Requirement One>)

[3.4 Performance](#3.4 Performance)

[3.4.1 ](#3.4.1 <Performance Requirement One>)

[3.5 Supportability](#3.5 Supportability)

[3.5.1 ](#3.5.1 <Supportability Requirement One>)

[3.6 Design Constraints](#3.6 Design Constraints)

[3.6.1 ](#3.6.1 <Design Constraint One>)

[3.7 Online User Documentation and Help System Requirements](#3.7 On-line User Documentation and Help System Requirements)

[3.8 Purchased Components](#3.8 Purchased Components)

[3.9 Interfaces](#3.9 Interfaces)

[3.9.1 User Interfaces](#3.9.1 User Interfaces)

[3.9.2 Hardware Interfaces](#3.9.2 Hardware Interfaces)

[3.9.3 Software Interfaces](#3.9.3 Software Interfaces)

[3.9.4 Communications Interfaces](#3.9.4 Communications Interfaces)

[3.10 Licensing Requirements](#3.10 Licensing Requirements)

[3.11 Legal, Copyright and Other Notices](#3.11 Legal, Copyright, and Other Notices)

[3.12 Applicable Standards](#3.12 Applicable Standards)

[4. Supporting Information](#4. Supporting Information)

Software Requirements Specification

1. Introduction

[The introduction of the Software Requirements Specification (SRS) should provide an overview of the entire SRS. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the SRS.]

[Note: The Software Requirements Specification (SRS) captures the complete software requirements for the system, or a portion of the system. Following is a typical SRS outline for a project using only traditional natural-language style requirements - with no use-case modeling. It captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed). For a template of an SRS using use-case modeling, which consists of a package containing Use-Cases of the use-case model and applicable Supplementary Specifications and other supporting information, see rup_SRS-uc.dot.]

[Many different arrangements of an SRS are possible. Refer to [IEEE830-1998] for further elaboration of these explanations, as well as other options for SRS organization.]

1.1 Purpose

[Specify the purpose of this SRS. The SRS should fully describe the external behavior of the application or subsystem identified. It also describes nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the software.]

1.2 Scope

[A brief description of the software application that the SRS applies to; the feature or other subsystem grouping; what Use-Case model(s) it is associated with; and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the SRS. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the SRS. 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.5 Overview

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

2. Overall Description

[This section of the SRS should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include such items as:

product perspective
product functions
user characteristics
constraints
assumptions and dependencies
requirements subsets]

3. Specific Requirements

[This section of the SRS should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements, and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the Use-Cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section, as shown below.]

3.1 Functionality

[This section describes the functional requirements of the system for those requirements which are expressed in the natural language style. For many applications, this may constitute the bulk of the SRS Package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods may also be appropriate, for example, organization by user or organization by subsystem. Functional requirements may include feature sets, capabilities, and security.

Where application development tools, such as requirements tools, modeling tools, etc., are employed to capture the functionality, this section document will refer to the availability of that data, indicating the location and name of the tool that is used to capture the data.]

3.1.1 <Functional Requirement One>

[The requirement description.]

3.2 Usability

[This section should include all of those requirements that affect usability. For example,

specify the required training time for a normal users and a power user to become productive at particular operations
specify measurable task times for typical tasks or base the new system’s usability requirements on other systems that the users know and like
specify requirement to conform to common usability standards, such as IBM’s CUA standards Microsoft’s GUI standards]

3.2.1 <Usability Requirement One>

[The requirement description goes here.]

3.3 Reliability

[Requirements for reliability of the system should be specified here. Some suggestions follow:

Availability-specify the percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, etc.
Mean Time Between Failures (MTBF) - this is usually specified in hours, but it could also be specified in terms of days, months or years.
Mean Time To Repair (MTTR)-how long is the system allowed to be out of operation after it has failed?
Accuracy-specify precision (resolution) and accuracy (by some known standard) that is required in the system’s output.
Maximum Bugs or Defect Rate-usually expressed in terms of bugs per thousand of lines of code (bugs/KLOC) or bugs per function-point( bugs/function-point).
Bugs or Defect Rate-categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a “critical” bug; for example, complete loss of data or a complete inability to use certain parts of the system’s functionality.]

3.3.1 <Reliability Requirement One>

[The requirement description.]

3.4 Performance

[The system’s performance characteristics should be outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name.

response time for a transaction (average, maximum)
throughput, for example, transactions per second
capacity, for example, the number of customers or transactions the system can accommodate
degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)
resource utilization, such as memory, disk, communications, etc.

3.4.1 <Performance Requirement One>

[The requirement description goes here.]

3.5 Supportability

[This section indicates any requirements that will enhance the supportability or maintainability of the system being built, including coding standards, naming conventions, class libraries, maintenance access, maintenance utilities.]

3.5.1 <Supportability Requirement One>

[The requirement description goes here.]

3.6 Design Constraints

[This section should indicate any design constraints on the system being built. Design constraints represent design decisions that have been mandated and must be adhered to. Examples include software languages, software process requirements, prescribed use of developmental tools, architectural and design constraints, purchased components, class libraries, etc.]

3.6.1 <Design Constraint One>

[The requirement description goes here.]

3.7 On-line User Documentation and Help System Requirements

[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, etc.]

3.8 Purchased Components

[This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility and interoperability or interface standards.]

3.9 Interfaces

[This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc. so that the software can be developed and verified against the interface requirements.]

3.9.1 User Interfaces

[Describe the user interfaces that are to be implemented by the software.]

3.9.2 Hardware Interfaces

[This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc. ]

3.9.3 Software Interfaces

[This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this SRS but with which this software application must interact.]

3.9.4 Communications Interfaces

[Describe any communications interfaces to other systems or devices such as local area networks, remote serial devices, etc.]

3.10 Licensing Requirements

[Defines any licensing enforcement requirements or other usage restriction requirements that are to be exhibited by the software.]

3.11 Legal, Copyright, and Other Notices

[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark, or logo compliance issues for the software.]

3.12 Applicable Standards

[This section describes by reference any applicable standard and the specific sections of any such standards which apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, etc.]

4. Supporting Information

[The supporting information makes the SRS easier to use. It includes:

Table of contents
Index
Appendices

These may include use-case storyboards or user-interface prototypes. When appendices are included, the SRS should explicitly state whether or not the appendices are to be considered part of the requirements.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Overall Description](#2. Overall Description)

[2.1 Use-Case Model Survey](#2.1 Use-Case Model Survey)

[2.2 Assumptions and Dependencies](#2.2 Assumptions and Dependencies)

[3. Specific Requirements](#3. Specific Requirements)

[3.1 Use-Case Reports](#3.1 Use-Case Reports)

[3.2 Supplementary Requirements](#3.2 Supplementary Requirements)

[4. Supporting Information](#4. Supporting Information)

Software Requirements Specification

1. Introduction

[The introduction of the Software Requirements Specification (SRS) should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Software Requirements Specification.]

[Note: The Software Requirements Specification captures the complete software requirements for the system, or a portion of the system. Following is a typical Software Requirements Specification outline for a project using use-case modeling. This artifact consists of a package containing use cases of the use-case model and applicable Supplementary Specifications and other supporting information. For a template of an Software Requirements Specification not using use-case modeling, which captures all requirements in a single document, with applicable sections inserted from the Supplementary Specifications (which would no longer be needed), see rup_srs.dot.]

[Many different arrangements of a Software Requirements Specification are possible. Refer to [IEEE830-1998] for further elaboration of these explanations, as well as other options for a Software Requirements Specification organization.]

1.1 Purpose

[Specify the purpose of this Software Requirements Specification. The Software Requirements Specification should fully describe the external behavior of the application or subsystem identified. It also describes nonfunctional requirements, design constraints and other factors necessary to provide a complete and comprehensive description of the requirements for the software.]

1.2 Scope

[A brief description of the software application that the Software Requirements Specification applies to; the feature or other subsystem grouping; what Use-case model(s) it is associated with; and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Software Requirements Specification. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Software Requirements Specification. 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.5 Overview

[This subsection should describe what the rest of the Software Requirements Specification contains and explain how the document is organized.]

2. Overall Description

[This section of the Software Requirements Specification should describe the general factors that affect the product and its requirements. This section does not state specific requirements. Instead, it provides a background for those requirements, which are defined in detail in Section 3, and makes them easier to understand. Include such items as product perspective, product functions, user characteristics, constraints, assumptions and dependencies, and requirements subsets.]

2.1 Use-Case Model Survey

[If using use-case modeling, this section contains an overview of the use-case model or the subset of the use-case model that is applicable for this subsystem or feature. This includes a list of names and brief descriptions of all use cases and actors, along with applicable diagrams and relationships. Refer to the Use-Case-Model Survey Report, which may be used as an enclosure at this point.]

2.2 Assumptions and Dependencies

[This section describes any key technical feasibility, subsystem or component availability, or other project related assumptions on which the viability of the software described by this Software Requirements Specification may be based.]

3. Specific Requirements

[This section of the Software Requirements Specification should contain all the software requirements to a level of detail sufficient to enable designers to design a system to satisfy those requirements and testers to test that the system satisfies those requirements. When using use-case modeling, these requirements are captured in the use cases and the applicable supplementary specifications. If use-case modeling is not used, the outline for supplementary specifications may be inserted directly into this section.]

3.1 Use-Case Reports

[In use-case modeling, the use cases often define the majority of the functional requirements of the system, along with some non-functional requirements. For each use case in the above use-case model, or subset thereof, refer to, or enclose, the use-case report in this section. Make sure that each requirement is clearly labeled.]

3.2 Supplementary Requirements

[Supplementary Specifications capture requirements that are not included in the use cases. The specific requirements from the Supplementary Specifications, which are applicable to this subsystem or feature, should be included here and refined to the necessary level of detail to describe this subsystem or feature. These may be captured directly in this document or referred to as separate Supplementary Specifications, which may be used as an enclosure at this point. Make sure that each requirement is clearly labeled.]

4. Supporting Information

[The supporting information makes the Software Requirements Specification easier to use. It includes:

Table of Contents
Index
Appendices

These may include use-case storyboards or user-interface prototypes. When appendices are included, the Software Requirements Specification should explicitly state whether or not the appendices are to be considered part of the requirements.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Establish Stakeholder or User Profile](#2. Establish Stakeholder or User Profile)

[3. Assessing the Problem](#3. Assessing the Problem)

[4. Understanding the User Environment](#4. Understanding the User Environment)

[5. Recap for Understanding](#5. Recap for Understanding)

[6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions)](#6. Analysts Inputs on Stakeholder’s Problem (validate or invalidate assumptions))

[7. Assessing Your Solution (if applicable)](#7. Assessing Your Solution (if applicable))

[8. Assessing the Opportunity](#8. Assessing the Opportunity)

[9. Assessing Reliability, Performance and Support Needs](#9. Assessing Reliability, Performance and Support Needs)

[10. Wrap-Up](#10. Wrap-Up)

[11. Analyst’s Summary](#11. Analysts Summary)

Stakeholder Requests

1. Introduction

[The introduction of the Stakeholder Requests should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this collection of Stakeholder Requests.]

[Context-Free Interview Script: Great opportunities exist in our industry to improve application development efforts. Understanding stakeholder or user needs before beginning development is crucial to improving this process. Many techniques are available to elicit stakeholder or user requests. One simple and inexpensive technique that is appropriate for use in virtually every situation is the Generic Interview. The Generic Interview can help the developer or analyst understand stakeholder or user objectives and problems. Armed with this insight, developers can create applications that fit the stakeholder or user’s real needs and increase their satisfaction.]

1.1 Purpose

[Specify the purpose of this collection of Stakeholder Requests.]

[Guidelines for Use: If the Generic Interview is not suited to your needs, feel free to modify it. With a little preparation and a well-structured interview plan, any developer or analyst can interview effectively. Here are some tips:

Research the background of the stakeholder or user and the company ahead of time.

Review the questions prior to the interview.

Refer to the format during the interview to ensure the right questions are being asked.

Summarize the top two or three problems at the end of the interview. Repeat what you learned to confirm your comprehension.

Do not let the script become overly constraining. Once rapport is established, the interview often takes on a life of its own, and the stakeholder or user may talk at length about the difficulties being experienced. Do not stop the stakeholder or user. Record these responses as quickly as possible. Follow up on the information with questions. Once this exchange reaches its logical end, proceed with other questions on the list.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Stakeholder Requests. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Stakeholder Requests. 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.5 Overview

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

2. Establish Stakeholder or User Profile

[Ask questions such as the following:]

Name: Company / Industry:

Job Title:

What are your key responsibilities?

What deliverables do you produce? For whom?

How is success measured?

Which problems interfere with your success?

Which, if any, trends make your job easier or harder?

3. Assessing the Problem

For which <application type> problems do you lack good solutions?

What are they? [Tip: Keep asking “Anything else?]

Ask for each problem:

Why does this problem exist?

How do you solve it now?

How would you like to solve it?

4. Understanding the User Environment

Who are the users?

What is their educational background?

What is their computer background?

Are users experienced with this type of application?

Which platforms are in use? What are your plans for future platforms?

Which additional applications do you use that we need to interface with?

What are your expectations for usability of the product?

What are your expectations for training time?

What kinds of hard copy and on-line documentation do you need?

5. Recap for Understanding

You have told me [list stakeholder-described problems in your own words]:

Does this represent the problems you are having with your existing solution?

What, if any, other problems are you experiencing?

6. Analyst’s Inputs on Stakeholder’s Problem (validate or invalidate assumptions)

[If not addressed] Which, if any, problems are associated with:

[List any needs or additional problems you think should concern the stakeholder or user]

Ask for each suggested problem:

Is this a real problem?

What are the reasons for this problem?

How do you currently solve the problem?

How would you like to solve the problem?

How would you rank solving these problems in comparison to others you’ve mentioned?

7. Assessing Your Solution (if applicable)

What if you could…[summarize the key capabilities of your proposed solution]

How would you rank the importance of these?

8. Assessing the Opportunity

Who needs this application in your organization?

How many of these types of users would use the application?

How would you value a successful solution?

9. Assessing Reliability, Performance and Support Needs

What are your expectations for reliability?

What are your expectations for performance?

Will you support the product, or will others support it?

Do you have special needs for support? What about maintenance and service access?

What are the security requirements?

What are the installation and configuration requirements?

What are the special licensing requirements?

How will the software will be distributed?

What are the labeling and packaging requirements?

Other Requirements

Which, if any regulatory or environmental requirements or standards must be supported?

Can you think of any other requirements we should know about?

10. Wrap-Up

Are there any other questions I should be asking you?

If I need to ask follow up questions, may I give you a call?

Would you be willing to participate in a requirements review?

11. Analyst’s Summary

[Summarize below the three or four highest priority problems for this user/stakeholder]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Resources](#2. Resources)

[2.1 Personnel/Staffing](#2.1 Personnel/Staffing)

[2.2 Financial Data](#2.2 Financial Data)

[3. Top 10-Risks](#3. Top 10-Risks)

[4. Technical Progress](#4. Technical Progress)

[5. Major Milestone Results](#5. Major Milestone Results)

[6. Total Project/Product Scope](#6. Total Project/Product Scope)

[7. Action Items and Follow-Through](#7. Action Items and Follow-through)

Status Assessment

1. Introduction

[The introduction of the Status Assessment should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Status Assessment.]

1.1 Purpose

[Specify the purpose of this Status Assessment.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Status Assessment. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Status Assessment. 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.5 Overview

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

2. Resources

2.1 Personnel/Staffing

[Status of personnel. Report any issues or concerns.]

2.2 Financial Data

[Current costs and revenue compared to the plan.]

3. Top 10-Risks

[Report the status of the top 10-risks.]

4. Technical Progress

[Report technical progress using metrics snapshots, etc.]

5. Major Milestone Results

[Report the status of major milestones to date.]

6. Total Project/Product Scope

[Report status of project or product scope.]

7. Action Items and Follow-through

[A list of action items and their current status.]

Supplementary Business Specification

[2. Behavior](#2. Behavior)

[3. Usability](#3. Usability)

[4. Reliability](#4. Reliability)

[5. Performance](#5. Performance)

[6. Scaling Issues](#6. Scaling Issues)

Supplementary Business Specification

1. Introduction

[The introduction of the Supplementary Business Specification should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Supplementary Business Specification.]

1.1 Purpose

[Specify the purpose of this Supplementary Business Specification]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Supplementary Business Specification. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Supplementary Business Specification. 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.5 Overview

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

2. Behavior

[This section expresses general objectives for the behavior of the organization that are not specific to a particular business use case.]

3. Usability

[This section should include all of those requirements that affect usability from the perspective of a business actor. Examples follow]:

- Specify the required training time for a normal users and power users of the organization to become productive at particular operations.

- Specify measurable task times for typical tasks.

4. Reliability

[Requirements for reliability (from a business actor perspective) of the organization should be specified here. Suggestions are as follows]:

- Availability

specify percentage of time available ( xx.xx%), anticipated hours of use, etc.

- Accuracy

specify precision (resolution) and accuracy (by some known standard) that is required in the output.

5. Performance

[The performance characteristics should be outlined in this section. Include specific response times. Where applicable, reference related business use cases by name.]

- Response time for a transaction(average, maximum)

- Throughput (e.g., transactions per second)

- Capacity (e.g., the number of customers or transactions the business can accommodate)

- Resource utilization: number of employees, memory capacity of systems, etc.

6. Scaling Issues

[List and briefly describe any information about how you expect the organization to change size in the future, and what limitations or precautions need to be considered to meet that change.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Functionality](#2. Functionality)

[2.1 <Functional Requirement One>](#2.1 <Functional Requirement One>)

[3. Usability](#3. Usability)

[3.1 <Usability Requirement One>](#3.1 <Usability Requirement One>)

[4. Reliability](#4. Reliability)

[4.1 <Reliability Requirement One>](#4.1 <Reliability Requirement One>)

[5. Performance](#5. Performance)

[5.1 <Performance Requirement One>](#5.1 <Performance Requirement One>)

[6. Supportability](#6. Supportability)

[6.1 <Supportability Requirement One>](#6.1 <Supportability Requirement One>)

[7. Design Constraints](#7. Design Constraints)

[7.1 <Design Constraint One>](#7.1 <Design Constraint One>)

[8. Online User Documentation and Help System Requirements](#8. Online User Documentation and Help System Requirements)

[9. Purchased Components](#9. Purchased Components)

[10. Interfaces](#10. Interfaces)

[10.1 User Interfaces](#10.1 User Interfaces)

[10.2 Hardware Interfaces](#10.2 Hardware Interfaces)

[10.3 Software Interfaces](#10.3 Software Interfaces)

[10.4 Communications Interfaces](#10.4 Communications Interfaces)

[11. Licensing Requirements](#11. Licensing Requirements)

[12. Legal, Copyright and Other Notices](#12. Legal, Copyright and Other Notices)

[13. Applicable Standards](#13. Applicable Standards)

Supplementary Specification

1. Introduction

[The introduction of the Supplementary Specification should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Supplementary Specification.

The Supplementary Specification captures the system requirements that are not readily captured in the use cases of the use-case model. Such requirements include:

Legal and regulatory requirements, including application standards.

Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements.

Other requirements such as operating systems and environments, compatibility requirements, and design constraints.]

1.1 Purpose

[Specify the purpose of this Supplementary Specification.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Supplementary Specification. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Supplementary Specification. 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.5 Overview

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

2. Functionality

[This section describes the functional requirements of the system for those requirements which are expressed in the natural language style. For many applications, this may constitute the bulk of the SRS Package and thought should be given to the organization of this section. This section is typically organized by feature, but alternative organization methods, for example organization by user or organization by subsystem, may also be appropriate. Functional requirements may include feature sets, capabilities, and security.

2.1 <Functional Requirement One>

[The requirement description.]

3. Usability

[This section should include all of those requirements that affect usability. Examples follow:

specify the required training time for a normal users and power users to become productive at particular operations

specify measurable task times for typical tasks, or

specify requirements to conform to common usability standards, for example, IBM’s CUA standards or Microsoft’s GUI stamdards]

3.1 <Usability Requirement One>

The requirement description.

4. Reliability

[Requirements for reliability of the system should be specified here. Suggestions are as follows:

Availability - specify percentage of time available ( xx.xx%), hours of use, maintenance access, degraded mode operations, etc.

Mean Time Between Failures (MTBF) - this is usually specified in hours but it could also be specified in terms of days, months or years.

Mean Time To Repair (MTTR) - how long is the system allowed to be out of operation after it has failed?

Accuracy - specify precision (resolution) and accuracy (by some known standard) that is required in the systems output.

Maximum bugs or defect rate - usually expressed in terms of bugs/KLOC (thousands of lines of code), or bugs/function-point.

Bugs or defect rate - categorized in terms of minor, significant, and critical bugs: the requirement(s) must define what is meant by a “critical” bug (e.g., complete loss of data or complete inability to use certain parts of the functionality of the system).]

4.1 <Reliability Requirement One>

[The requirement description.]

5. Performance

[The performance characteristics of the system should be outlined in this section. Include specific response times. Where applicable, reference related Use Cases by name.

Response time for a transaction(average, maximum)

Throughput (e.g., transactions per second)

Capacity (e.g., the number of customers or transactions the system can accommodate)

Degradation modes (what is the acceptable mode of operation when the system has been degraded in some manner)

Resource utilization: memory, disk, communications, etc.]

5.1 <Performance Requirement One>

[The requirement description.]

6. Supportability

6.1 <Supportability Requirement One>

[The requirement description.]

7. Design Constraints

7.1 <Design Constraint One>

[The requirement description.]

8. Online User Documentation and Help System Requirements

[Describes the requirements, if any, for on-line user documentation, help systems, help about notices, etc.]

9. Purchased Components

[This section describes any purchased components to be used with the system, any applicable licensing or usage restrictions, and any associated compatibility/interoperability or interface standards.]

10. Interfaces

[This section defines the interfaces that must be supported by the application. It should contain adequate specificity, protocols, ports and logical addresses, etc., so that the software can be developed and verified against the interface requirements.]

10.1 User Interfaces

[Describe the user interfaces that are to be implemented by the software.]

10.2 Hardware Interfaces

[This section defines any hardware interfaces that are to be supported by the software, including logical structure, physical addresses, expected behavior, etc. ]

10.3 Software Interfaces

[This section describes software interfaces to other components of the software system. These may be purchased components, components reused from another application or components being developed for subsystems outside of the scope of this SRS, but with which this software application must interact.]

10.4 Communications Interfaces

[Describe any communications interfaces to other systems or devices such as local area networks, remote serial devices, etc.]

11. Licensing Requirements

[Defines any licensing enforcement requirements or other usage restriction requirements which are to be exhibited by the software.]

12. Legal, Copyright and Other Notices

[This section describes any necessary legal disclaimers, warranties, copyright notices, patent notice, wordmark, trademark or logo compliance issues for the software.]

13. Applicable Standards

[This section describes by reference any applicable standards and the specific sections of any such standards that apply to the system being described. For example, this could include legal, quality and regulatory standards, industry standards for usability, interoperability, internationalization, operating system compliance, etc.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Business Context](#2. Business Context)

[3](#3. Business Idea and Strategy in the Project Context)[. Business Ideas and Strategies in the Project Context](#3. Business Idea and Strategy in the Project Context)

[4. External Factors](#3. External Factors)

[4.1 Customers](#3.1 Customers)

[4.2 Competitors](#3.2 Competitors)

[4.3 Other Stakeholders](#3.3 Other Stakeholders)

[5. Internal Factors](#4. Internal Factors)

[5.1 Business Processes](#4.1 Business Processes)

[5.2 Supporting Tools](#4.2 Supporting Tools)

[5.3 Internal Organization](#4.3 Internal Organization)

[5.4 Competencies, Skills, and Attitudes](#4.4 Competencies, Skills and Attitudes)

[5.5 Capacity for Change](#4.5 Capacity for Change)

[6.](#6. Benchmarking Results)[Benchmarking Results](#6. Benchmarking Results)

[7.](#7. Performance of Target Organization)[Performance of Target Organization](#7. Performance of Target Organization)

[8. Assessment Conclusion](#5. Assessment Conclusion)

[8](#8.1 Problems Areas)[.1 Problems Areas](#8.1 Problems Areas)

[8](#8.2 Applicable New Technologies)[.2 Applicable New Technologies](#8.2 Applicable New Technologies)

Target-Organization Assessment

1. Introduction

[The introduction of the Target-Organization Assessment provides an overview of the entire document. It includes the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Target-Organization Assessment.]

1.1 Purpose

[Specify the purpose of this Target-Organization Assessment.]

1.2 Scope

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

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Target-Organization Assessment. This information may be provided by reference to the project’s Business Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Target-Organization Assessment. Identify each document 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.5 Overview

[This subsection describes what the rest of the Target-Organization Assessment contains and explains how the document is organized.]

2. Business Context

[A brief description of the business domain in which the organization works.]

3. Business Ideas and Strategies in the Project Context

[A description of how business ideas and business strategies are related to the problem domains.

A description of how well existing processes are in line with the vision and the strategy of the business.]

4. External Factors

4.1 Customers

[A listing of the customers and what they expect of the products. This should include a summary of investigations made to understand the customers’ demands on the business. ]

4.2 Competitors

[A listing of the competitors.]

4.3 Other Stakeholders

[A listing of other stakeholders, such as suppliers and partners.]

5. Internal Factors

5.1 Business Processes

[A brief description of the current business processes.]

5.2 Supporting Tools

[A brief description of today’s tool support.]

5.3 Internal Organization

[A brief description of the internal organization, and what roles and teams they have today.]

5.4 Competencies, Skills, and Attitudes

[An inventory of the competencies, skills, and attitudes of the individuals in the organization.]

5.5 Capacity for Change

[A brief description of the “capacity for change”.]

6. Benchmarking Results

[A summary of results arrived at in benchmarking studies.]

7. Performance of Target Organization

[A summary of measurements made on the existing business, process by process.]

8. Assessment Conclusion

[List the major problem areas and opportunity areas, regardless of the categories to which they belong.]

8.1 Problems Areas

[A summary of the analysis of the activities of the exiting business processes.]

8.2 Applicable New Technologies

[A summary of available state-of-the-art solutions applicable to the business.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Test Results Summary](#2. Test Results Summary)

[3. Requirements-based Test Coverage](#3. Requirements-based Test Coverage)

[4. Code-based Coverage](#4. Code-based Coverage)

[5. Suggested Actions](#5. Suggested Actions)

[6. Diagrams](#6. Diagrams)

Test Evaluation Summary

1. Introduction

[The introduction of the Test Evaluation Summary should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Test Evaluation Summary.]

1.1 Purpose

[Specify the purpose of this Test Evaluation Summary.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Test Evaluation Summary. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Test Evaluation Summary. 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.5 Overview

[This subsection should describe what the rest of the Test Evaluation Summary contains and explain how the document is organized.]

2. Test Results Summary

[Briefly summarize the result of the test.]

3. Requirements-based Test Coverage

[For each measure you have chosen to use, state the result. Compare with previous results and discuss trends.]

4. Code-based Coverage

[For each measure you have chosen to use, state the result. Compare with previous results and discuss trends.]

5. Suggested Actions

[State any suggested actions based upon an evaluation of the test results and key measures of test.]

6. Diagrams

[Enclose any visualization of the test results or key measures of test.]

Test Evaluation Summary

1. Test Scope

[Identify what was tested (which builds, under what environment).]

2. Test Summary

[A summary of test results, such as:

Planned Test Cases: 83

Executed Test Cases: 65

Passed Test Cases: 52

Blocked Test Cases: 13

Blocked P1 (Priority One) Test Cases: 4.

This may optionally include a list of defects logged, and a summary of requirements-based test coverage or code-based test coverage results]

3. Conclusions

[Compare with previous test results and discuss trends , particular problem areas or issues.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Goals of Testing](#2. Goals of Testing)

[3. Testing Standards](#3. Testing Standards)

[4. Key Measures](#4. Key Measures)

[5. Test Completion Criteria](#5. Test Completion Criteria)

[6. Defect Management Guidelines](#6. Defect Management Guidelines)

[7. Change Management Criteria](#7. Change Management Criteria)

Test Guidelines

1. Introduction

[The introduction of the Test Guidelines should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of the Test Guidelines.]

1.1 Purpose

[Specify the purpose of the Test Guidelines.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Test Guidelines. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Test Guidelines. 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.5 Overview

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

2. Goals of Testing

[A statement to identify why testing is performed and used by the organization.]

3. Testing Standards

[This section identifies and describes all guidelines and standards to be used in the planning, design, implementation, execution, and evaluation activities including:

Test Case standards: A statement identifying the types of test cases that should be developed for testing, such as valid, invalid, boundary, etc.

Naming Convention: A description of how each kind of entity, such as test case and test procedure, should be named.

Design Guidelines: A statement identifying test procedure and script modularity goals, for reuse and maintenance.

Test Data standards: A statement of how data will be selected or created and restored to support testing.]

4. Key Measures

[A definition of what kind of measures you will use to determine the progress of test activities (what type of defect counts are going to be used, how to measure successfully executed test cases).]

5. Test Completion Criteria

[A statement identifying recommended completion and evaluation criteria.]

6. Defect Management Guidelines

[A statement identifying how defects will be managed.]

7. Change Management Criteria

[A statement identifying how test artifacts will be managed and maintained.]

Revision History


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

Table of Contents

1.4 Document Terminology and Acronyms

1.3 Intended Audience

1.5 References

1.6 Document Structure

2. Governing Evaluation Mission

2.1 Project Context and Background

2.2 Evaluation Mission

2.3 Test Motivators

3. Test Approach

3.1 Measuring the Extent of Testing

3.2 Identifying and Justifying Tests

3.3 Conducting Tests

3.3.1 Technique 1

3.3.2 Technique n+1

4. Environmental Needs

4.1 Base System Hardware

4.2 Base Software Elements in the Test Environment

4.3 Productivity and Support Tools

4.4 Test Environment Configurations

5. Responsibilities, Staffing, and Training Needs

5.1 People and Roles

5.2 Staffing and Training Needs

6. Risks, Dependencies, Assumptions, and Constraints

7. Management Process and Procedures

7.1 Problem Reporting, Escalation, and Issue Resolution

7.2 Traceability Strategies

7.3 Approval and Signoff

Test Strategy

1. Introduction

1.1 Purpose

The purpose of the Test Strategy for the <complete lifecycle, specific-phase> of the is to:

Provide a central artifact to govern the strategic approach to the test effort. It defines the general approach that will be employed to test the software and to evaluate the results of that testing, and is the artifact that planning artifacts will refer to in terms of governing the detailed testing work.

Provide visibility to stakeholders in the testing effort that adequate consideration has been given to various aspects of governing the testing effort, and where approriate to have those stakeholders approve the strategy.

This Test Strategy also supports the following specific objectives:

[Identifies the items that should be targeted by the tests.
Identifies the motivation for and ideas behind the test areas to be covered.
Outlines the testing approach that will be used.
Identifies the required resources and provides an estimate of the test efforts.
Lists the deliverable elements of the test project.]

1.2 Scope

[Defines the types of testing-such as Functionality, Usability, Reliability, Performance, and Supportability-and if necessary the levels of testing-for example, Integration or System- that will be addressed by this Test Strategy. It is also important to provide a general indication of significant elements that will be excluded from scope, especially where the intended audience might otherwise reasonably assume the inclusion of those elements.

Note: Be careful to avoid repeating detail here that you will define in sections 3, Target Test Items, and 4, Overview of Planned Tests.]

1.3 Intended Audience

[Provide a brief description of the audience for whom you are writing the Test Strategy. This helps readers of your document identify whether it is a document intended for their use, and helps prevent the document from being used inappropriately.

Note: Document style and content often alters in relation to the intended audience.

This section should only be about three to five paragraphs in length.]

1.4 Document Terminology and Acronyms

[This subsection provides the definitions of any terms, acronyms, and abbreviations required to properly interpret the Test Strategy. Avoid listing items that are generally applicable to the project as a whole and that are already defined in the project’s Glossary. Include a reference to the project’s Glossary in the References section.]

1.5References

[This subsection provides a list of the documents referenced elsewhere within the Test Strategy. Identify each document by title, version (or report number if applicable), date, and publishing organization or original author. Avoid listing documents that are influential but not directly referenced. Specify the sources from which the “official versions” of the references can be obtained, such as intranet UNC names or document reference codes. This information may be provided by reference to an appendix or to another document.]

1.6 Document Structure

[This subsection outlines what the rest of the Test Strategy contains and gives an introduction to how the rest of the document is organized. This section may be eliminated if a Table of Contents is used.]

2. Governing Evaluation Mission

[Provide an overview of the mission(s) that will govern the detailed testing within the iterations. .]

2.1 Project Context and Background

[Provide a brief description of the background surrounding the project with specific reference or focus on important implications for the test effort. Include information such as the key problem being solved, the major benefits of the solution, the planned architecture of the solution, and a brief history of the project. Note that where this information is defined sufficiently in other documents, you might simply include a reference to those other documents if appropriate; however, it may save readers of the test strategy time and effort if a limited amount of information is duplicated here: so you should use your judgement. As a general rule, this section should only be about three to five paragraphs in length.]

2.2 Evaluation Mission

find as many bugs as possible

find important problems, assess perceived quality risks

advise about perceived project risks

certify to a standard

verify a specification (requirements, design or claims)

advise about product quality, satisfy stakeholders

advise about testing

fulfill process mandates

and so forth

Each mission provides a different context to the test effort and changes the way in which testing should be approached.]

2.3 Test Motivators

[Provide an outline of the key elements that will motivate the testing effort in this iteration. Testing will be motivated by many things-quality risks, technical risks, project risks, use cases, functional requirements, non-functional requirements, design elements, suspected failures or faults, change requests, and so forth.]

3. Test Approach

[Note: It is important to remember that as a general rule an appropriate test approach is specific to the context of the individual project. As such, the elements defined in the approach will differ from project-to-project depending on the evaluation mission and otherproject-specific factors]

[The Test Approach presents the recommended strategy for analyzing, designing, implementing and executing the required tests. The specific Test Plans identify what items will be targeted for testing and what types of tests would be performed. This section of the test strategy describes how the tests will be realized.]

One of the main aspects of the test approach is the selection of techniques that will be used. This test strategy should include an outline of how each technique can be designed, implemented and executed, and the criterion for knowing that the technique is both useful and successful. For each technique, provide a description of the technique and define why it is an important part of the test approach by briefly outlining how it helps achieve the Evaluation Mission(s).

As you define each aspect of the approach, you should consider the impact it will have on resources such as staff, tools and testing hardware and note that impact accordingly.]

3.1 Measuring the Extent of Testing

3.2 Identifying and Justifying Tests

3.3 Conducting Tests

3.3.1 Technique 1

[Provide a brief one-paragraph introduction to the technique, covering the basis for or theory behind the technique and the general quality risks it addresses.]

Technique Objective:	[Explain the focus and goal of the technique in relation to the quality risks it addresses (e.g. FURPS+).]
Technique:	[Outline the high-level procedure for the technique, possibly as bulleted steps at the overview level].
Oracles:	[Outline one or more strategies that can be used with the technique to accurately observe the outcomes of the test. The oracle combines elements of both the method by which the observation can be made and the characteristics of the specific outcome that indicate probable success or failure. Ideally, oracles will be self-verifying, allowing automated tests to make an initial assessment of test pass or failure, however, you should be careful to mitigate the risks inherent in automated results determination.]
Required Tools:	- [Provide a simple list of the specific tools or a brief outline of each type of tools that the technique will require]
Success Criteria:	[Explain how the technique will be judged as successful, giving specific criteria that can and will be measured.]
Special Considerations:	- [Provide a list of any assumptions, constraints, dependencies or other considerations that will have an impact on the technique, such as tester skills or test resource requirements.]

3.3.2 Technique n+1

[Provide a brief one-paragraph introduction to the technique, covering the basis for or theory behind the technique and the general quality risks it addresses.]

Technique Objective:	[Explain the focus and goal of the technique in relation to the quality risks it addresses (e.g. FURPS+).]
Technique:	[Outline the high-level procedure for the technique, possibly as bulleted steps at the overview level].
Oracles:	[Outline one or more strategies that can be used with the technique to accurately observe the outcomes of the test. The oracle combines elements of both the method by which the observation can be made and the characteristics of the specific outcome that indicate probable success or failure. Ideally, oracles will be self-verifying, allowing automated tests to make an initial assessment of test pass or failure, however, you should be careful to mitigate the risks inherent in automated results determination.]
Required Tools:	- [Provide a simple list of the specific tools or a brief outline of each type of tools that the technique will require]
Success Criteria:	[Explain how the technique will be judged as successful, giving specific criteria that can and will be measured.]
Special Considerations:	- [Provide a list of any assumptions, constraints, dependencies or other considerations that will have an impact on the technique, such as tester skills or test resource requirements.]

4. Environmental Needs

[This section presents the non-human resources required for the Test Strategy.]

4.1 Base System Hardware

The following table sets forth the system resources for the test effort presented in this Test Strategy.

[Note: Add or delete items as appropriate.]


System Resources
Resource	Quantity	Name and Type

4.2 Base Software Elements in the Test Environment

The following base software elements are required in the test environment for this Test Strategy.

[Note: Add or delete items as appropriate.]

Software Element Name	Version	Type and Other Notes

4.3 Productivity and Support Tools

The following tools will be employed to support the test process for this Test Strategy.

[Note: Add or delete items as appropriate.]

Tool Category or Type	Tool Brand Name	Vendor or In-house	Version

4.4 Test Environment Configurations

The following Test Environment Configurations needs to be provided and supported for this project.

Configuration Name	Description	Implemented in Physical Configuration

5. Responsibilities, Staffing, and Training Needs

[This section presents the required resources to address the test effort outlined in the Test Strategy the main responsibilities, and the knowledge or skill sets required of those resources.]

5.1 People and Roles

This table shows the staffing assumptions for the test effort.

[Note: Add or delete items as appropriate.]


Human Resources
Role	Minimum Resources Recommended (number of full-time roles allocated)	Specific Responsibilities or Comments
Test Manager		Provides management oversight. Responsibilities include: - planning and logistics - agree on the mission - identify motivators - acquire appropriate resources - present management reporting - advocate the interests of test - evaluate effectiveness of test effort
Test Analyst		Identifies and defines the specific tests to be conducted. Responsibilities include: - identify test ideas - define test details - determine test results - document change requests - evaluate product quality
Test Designer		Defines the technical approach to the implementation of the test effort. Responsibilities include: - define test approach - define test automation architecture - verify test techniques - define testability elements - structure test implementation
Tester		Implements and executes the tests. Responsibilities include: - implement tests and test suites - execute test suites - log results - analyze and recover from test failures - document incidents
Test System Administrator		Ensures test environment and assets are managed and maintained. Responsibilities include: - administer test management system - install and support access to, and recovery of, test environment configurations and test labs
Database Administrator, Database Manager		Ensures test data (database) environment and assets are managed and maintained. Responsibilities include: - support the administration of test data and test beds (database).
Designer		Identifies and defines the operations, attributes, and associations of the test classes. Responsibilities include: - define the test classes required to support testability requirements as defined by the test team
Implementer		Implements and unit tests the test classes and test packages. Responsibilities include: - create the test components required to support testability requirements as defined by the designer

5.2 Staffing and Training Needs

This section outlines how to approach staffing and training the test roles for the project.

[The way to approach staffing and training will vary from project to project. If this section is part of a Test Strategy, you should indicate at what points in the project lifecycle different skills and numbers of staff are needed. In the Iteration Test Plans, you should focus mainly on where and what training might occur during the Iteration.

Give thought to your training needs, and schedule this based on a Just-In-Time (JIT) approach there is often a temptation to attend training too far in advance of its usage when the test team has apparent slack. Doing this introduces the risk of the training being forgotten by the time it’s needed.

The test team often requires the support and skills of other team members not directly part of the test team. Make sure you arrange in your strategy for appropriate availability of support staff: System Administrators, Database Administrators, and Developers who are required to enable the test effort.]

6. Risks, Dependencies, Assumptions, and Constraints

[List any risks that may affect the successful execution of thisTest Strategy, and identify mitigation and contingency strategies for each risk. Also indicate a relative ranking for both the likelihood of occurrence and the impact if the risk is realized.]

Risk	Mitigation Strategy	Contingency (Risk is realized)

[List any dependencies identified during the development of this Test Strategy that may affect its successful execution if those dependencies are not honored. Typically these dependencies relate to activities on the critical path that are prerequisites or post-requisites to one or more preceding (or subsequent) activities You should consider responsibilities you are relying on other teams or staff members external to the test effort completing, timing and dependencies of other planned tasks, the reliance on certain work products being produced.]

Dependency between	Potential Impact of Dependency	Owners

[List any assumptions made during the development of this Test Strategy that may affect its successful execution if those assumptions are proven incorrect. Assumptions might relate to work you assume other teams are doing, expectations that certain aspects of the product or environment are stable, and so forth].

Assumption to be proven	Impact of Assumption being incorrect	Owners

[List any constraints placed on the test effort that have had a negative effect on the way in which this Test Strategy has been approached.]

Constraint on	Impact Constraint has on test effort	Owners

7. Management Process and Procedures

[Outline what processes and procedures are to be used when issues arise with the Test Strategy and its enactment.]

7.1 Problem Reporting, Escalation, and Issue Resolution

[Define how process problems will be reported and escalated, and the process to be followed to achieve resolution.]

7.2 Traceability Strategies

[Consider appropriate traceability strategies for:

Coverage of Testing against Specifications enables measurement the extent of testing

Motivations for Testing enables assessment of relevance of tests to help determine whether to maintain or retire tests

Software Design Elements enables tracking of subsequent design changes that would necessitate rerunning tests or retiring them

Resulting Change Requests enables the tests that discovered the need for the change to be identified and re-run to verify the change request has been completed successfully]

7.3 Approval and Signoff

[Outline the approval process and list the job titles (and names of current incumbents) that initially must approve the strategy, and sign off on the satisfactory execution of the strategy.]

Revision History


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

Table of Contents

1. Brief Description

2. Basic Flow of Events

3. Alternative Flows

3.1 <Area of Functionality>

3.1.1 < A1 First Alternative Flow >

3.1.2 < A2 Second Alternative Flow >

3.2

3.2.1 < AN Another Alternative Flow >

4. Subflows

4.1 < S1 First Subflow>

4.2 < S2 Second Subflow>

5. Key Scenarios

6. Preconditions

[6.1 < Precondition One

](#Precondition_One)

7. Postconditions

[7.1 < Postcondition One

](#Postcondition_One)

8. Extension Points

8.1

9. Special Requirements

9.1 < First Special Requirement >

10. Additional Information

Use-Case Specification: <Use-Case Name>

[The following template is provided for a Use-Case Specification, which contains the textual properties of the use case. This document is used with a requirements management tool, such as Rational RequisitePro, for specifying and marking the requirements within the use-case properties.

The use-case diagrams can be developed in a visual modeling tool, such as Rational Rose. A use-case report, with all properties, may be generated with Rational SoDA. For more information, see the tool mentors in the Rational Unified Process.]

1 Brief Description

[The description briefly conveys the purpose of the use case. A single paragraph will suffice for this description.]

2. Basic Flow of Events

[This use case starts when the actor does something. An actor always initiates use cases. The use case describes what the actor does and what the system does in response. It is phrased in the form of a dialog between the actor and the system.

The use case describes what happens inside the system, but not how or why. If information is exchanged, be specific about what is passed back and forth. For example, it is not very illuminating to say that the actor enters customer information if it is not defined. It is better to say the actor enters the customer’s name and address. A Glossary of Terms (or a more formal Domain Model) is essential to keep the complexity of the use case manageable,you may want to define things like customer information there to keep the use case from drowning in details.

Simple alternatives may be presented within the text of the flow of events. If it only takes a few sentences to describe what happens when there is an alternative, do it directly within the flow. If the alternative flow is more complex, use a separate section to describe it. For example, an Alternative Flow subsection explains how to describe more complex alternatives.

Complex flow of events should be further structured into sub-flows. In doing this, the main goal should be improving the readability of the text. Subflows can be invoked many times from many places. Remember that the use case can perform subflows in optional sequences or in loops or even several at the same time..

A picture is sometimes worth a thousand words, though there is no substitute for clean, clear prose. If it improves clarity, feel free to paste flow charts, activity diagrams or other figures into the use case. If a flow chart is useful to present a complex decision process, by all means use it! Similarly for state-dependent behavior, a state-transition diagram often clarifies the behavior of a system better than pages upon pages of text. Use the right presentation medium for your problem, but be wary of using terminology, notations or figures that your audience may not understand. Remember that your purpose is to clarify, not obscure.]

3. Alternative Flows

[More complex alternatives are described in a separate section, referred to in the Basic Flow subsection of Flow of Events section. Think of the Alternative Flow subsections like alternative behavior, each alternative flow represents alternative behavior usually due to exceptions that occur in the main flow. They may be as long as necessary to describe the events associated with the alternative behavior.

Start each alternative flow with an initial line clearly stating where the alternative flow can occur and the conditions under which it is performed.

End each alternative flow with a line that clearly states where the events of the main flow of events are resumed. This must be explicitly stated.

Using alternative flows improves the readability of the use case. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]

3.1 <Area of Functionality>

[Often there are multiple alternative flows related to a single area of functionality (for example specialist withdrawal facilities, card handling or receipt handling for the Withdraw Cash use case of an Automated Teller Machine). It improves readability if these conceptually related sets of flows are grouped into their own clearly named sub-section. ]

3.1.1 < A1 First Alternative Flow >

[Describe the alternative flow, just like any other flow of events.]

3.1.1.1 < An Alternative Subflow >

[Alternative flows may, in turn, be divided into subsections if it improves clarity. Only place subflows here is they are only applicable to a single alternative flow.]

3.1.2 < A2 Second Alternative Flow >

[There may be, and most likely will be, a number of alternative flows in each area of functionality. Keep each alternative flow separate to improve clarity.]

3.2 <Another Area of Functionality>

[There may be, and most likely will be, a number of areas of functionality giving rise to sets of alternative flows. Keep each set of alternative flow separate to improve clarity.]

3.2.1 < AN Another Alternative Flow >

[Alternative flows may, in turn, be divided into subsections if it improves clarity.]

4. Subflows

4.1 < S1 First Subflow >

A subflow should be a segment of behavior within the use case that has a clear purpose, and is “atomic” in the sense that you do either all or none of the actions described. You may need to have several levels of sub-flows, but if you can you should avoid this as it makes the text more complex and harder to understand.

4.2 < S2 Second Subflow >

[There may be, and most likely will be, a number of subflows in a use case. Keep each sub flow separate to improve clarity. Using sub flows improves the readability of the use case, as well as preventing use cases from being decomposed into hierarchies of use cases. Keep in mind that use cases are just textual descriptions, and their main purpose is to document the behavior of a system in a clear, concise, and understandable way.]

5. Key Scenarios

[List the most important scenarios of the use case. Simply provide a short name and accompanying description to uniquely identify each key scenario. There will potentially be many scenarios possible with this use-case specification: it is important to focus on the most important or frequently discussed scenario’s that are either exemplars of this use case or are of concern or specific importance to the actor stakeholders.]

6. Preconditions

[A precondition of a use case is the state of the system that must be present prior to a use case being performed.]

6.1 < Precondition One >

7. Postconditions

[A postcondition of a use case is a list of possible states the system can be in immediately after a use case has finished.]

7.1 < Postcondition One >

8. Extension Points

[Extension points of the use case.]

8.1 <Name of Extension Point>

[Definition of the location of the extension point in the flow of events.]

9. Special Requirements

[A special requirement is typically a nonfunctional requirement that is specific to a use case, but is not easily or naturally specified in the text of the use case’s event flow. Examples of special requirements include legal and regulatory requirements, application standards, and quality attributes of the system to be built including usability, reliability, performance or supportability requirements. Additionally, other requirements-such as operating systems and environments, compatibility requirements, and design constraints-should be captured in this section.]

9.1 < First Special Requirement >

10. Additional Information

[Include, or provide references to, any additional information required to clarify the use case. This could include overview diagrams, examples or any thing else you fancy.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. General Use-Case-Modeling Guidelines](#2. General Use-Case-Modeling Guidelines)

[3. How to Describe a Use Case](#3. How to Describe a Use Case)

[4. UML Stereotypes](#4. UML Stereotypes)

Use-Case-Modeling Guidelines

1. Introduction

[The introduction of the Use-Case-Modeling Guidelines should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references and overview of this Use-Case-Modeling Guidelines.]

1.1 Purpose

[Specify the purpose of this Use-Case-Modeling Guidelines.]

1.2 Scope

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

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Use-Case-Modeling Guidelines. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Use-Case-Modeling Guidelines. 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.5 Overview

[This subsection should describe what the rest of the Use-Case-Modeling Guidelines contains and explain how the document is organized.]

2. General Use-Case-Modeling Guidelines

[The section describes which notation to use in the use-case model. For example, you may have decided not to use extends-relationships between use cases.]

3. How to Describe a Use Case

[This section gives rules, recommendations, and style issues, and how you should describe each use case.]

4. UML Stereotypes

[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-stereotypes already known or discovered to be useful for the construction of Use-Case models. 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, when it is felt that their use makes models significantly easier to understand, or when it ensures that common types of entities, roles, relationships, or patterns are uniformly modeled and understood. This section may be empty if no additional stereotypes, other than those predefined by the UML and the Rational Unified Process, are considered necessary.]

Use-Case-Realization Specification:

[2. Flow of Events](#2. Flow of Events)

[3. Derived Requirements](#3. Derived Requirements)

Use-Case-Realization Specification: <Use-Case Name>

1. Introduction

[The introduction of the Use-Case Realization Specification should provide an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Use-Case Realization Specification.]

[Note: This document template assumes that the use-case realization is partly described within a Rational Rose model; this means that the use case’s name and brief description is within the Rose model, and that this document should be linked as an external file to the use case. This document should contain additional properties of the use-case realization that are not in the Rose model.]

1.1 Purpose

[Specify the purpose of this Use-Case Realization Specification]

1.2 Scope

[A brief description of the scope of this Use-Case Realization Specification; what Use Case model(s) it is associated with, and anything else that is affected or influenced by this document.]

1.3 Definitions, Acronyms and Abbreviations

[This subsection should provide the definitions of all terms, acronyms, and abbreviations required to properly interpret the Use-Case Realization Specification. This information may be provided by reference to the project Glossary.]

1.4 References

[This subsection should provide a complete list of all documents referenced elsewhere in the Use-Case Realization Specification. 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.5 Overview

[This subsection should describe what the rest of the Use-Case Realization Specification contains and explain how the document is organized.]

2. Flow of Events

[A textual description of how the use case is realized in terms of collaborating objects. Its main purpose is to summarize the diagrams connected to the use case and to explain how they are related.]

3. Derived Requirements

[A textual description that collects all requirements, such as non-functional requirements, on the use-case realizations that are not considered in the design model, but that need to be taken care of during implementation.]

Revision History


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

Table of Contents

[1. Introduction](#1. Introduction)

[1.1 Purpose](#1.1 Purpose)

[1.2 Scope](#1.2 Scope)

[1.3 Definitions, Acronyms, and Abbreviations](#1.3 Definitions, Acronyms and Abbreviations)

[1.4 References](#1.4 References)

[1.5 Overview](#1.5 Overview)

[2. Positioning](#2. Positioning)

[2.1 Business Opportunity](#2.1 Business Opportunity)

[2.2 Problem Statement](#2.2 Problem Statement)

[2.3 Product Position Statement](#2.3 Product Position Statement)

[3. Stakeholder and User Descriptions](#3. Stakeholder and User Descriptions)

[3.1 Market Demographics](#3.1 Market Demographics)

[3.2 Stakeholder Summary](#3.2 Stakeholder Summary)

[3.3 User Summary](#3.3 User Summary)

[3.4 User environment](#3.4 User Environment)

[3.5 Stakeholder Profiles](#3.5 Stakeholder Profiles)

[3.5.1 ](#3.5.1 <Stakeholder Name>)

[3.6 User Profiles](#3.6 User Profiles)

[3.6.1 ](#3.6.1 <User Name>)

[3.7 Key Stakeholder or User Needs](#3.7 Key Stakeholder / User Needs)

[3.8 Alternatives and Competition](#3.8 Alternatives and Competition)

[3.8.1 <aCompetitor>](#3.8.1 <aCompetitor>)

[3.8.2 <anotherCompetitor>](#3.8.2 <anotherCompetitor>)

[4. Product Overview](#4. Product Overview)

[4.1 Product Perspective](#4.1 Product Perspective)

[4.2 Summary of Capabilities](#4.2 Summary of Capabilities)

[4.3 Assumptions and Dependencies](#4.3 Assumptions and Dependencies)

[4.4 Cost and Pricing](#4.4 Cost and Pricing)

[4.5 Licensing and Installation](#4.5 Licensing and Installation)

[5. Product Features](#5. Product Features)

[5.1 <aFeature>](#5.1 <aFeature>)

[5.2 <anotherFeature>](#5.2 <anotherFeature>)

[6. Constraints](#6. Constraints)

[7. Quality Ranges](#7. Quality Ranges)

[8. Precedence and Priority](#8. Precedence and Priority)

[9. Other Product Requirements](#9. Other Product Requirements)

[9.1 Applicable Standards](#9.1 Applicable Standards)

[9.2 System Requirements](#9.2 System Requirements)

[9.3 Performance Requirements](#9.3 Performance Requirements)

[9.4 Environmental Requirements](#9.4 Environmental Requirements)

[10. Documentation Requirements](#10. Documentation Requirements)

[10.1 User Manual](#10.1 User Manual)

[10.2 Online Help](#10.2 On-line Help)

[10.3 Installation Guides, Configuration, and Read Me File](#10.3 Installation Guides, Configuration, Read Me File)

[10.4 Labeling and Packaging](#10.4 Labeling and Packaging)

[A. Feature Attributes](#A. Feature Attributes)

Vision

1. Introduction

[The purpose of this document is to collect, analyze, and define high-level needs and features of the <<System Name>>. It focuses on the capabilities needed by the stakeholders, and the target users, and why these needs exist. The details of how the <<System Name>> fulfils these needs are detailed in the use-case and supplementary specifications.]

[The introduction of the Vision document provides an overview of the entire document. It should include the purpose, scope, definitions, acronyms, abbreviations, references, and overview of this Vision document.]

1.1 Purpose

[Specify the purpose of this Vision document**.**]

1.2 Scope

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

1.3 Definitions, Acronyms, and Abbreviations

[This subsection provides the definitions of all terms, acronyms, and abbreviations required to properly interpret the Vision document. This information may be provided by reference to the project’s Glossary.]

1.4 References

[This subsection provides a complete list of all documents referenced elsewhere in the Vision document. Identify each document 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.5 Overview

[This subsection describes what the rest of the Vision document contains and explains how the document is organized.]

2. Positioning

2.1 Business Opportunity

[Briefly describe the business opportunity being met by this project.]

2.2 Problem Statement

[Provide a statement summarizing the problem being solved by this project. The following format may be used:]


The problem of	[describe the problem]
affects	[the stakeholders affected by the problem]
the impact of which is	[what is the impact of the problem?]
a successful solution would be	[list some key benefits of a successful solution]

2.3 Product Position Statement

[Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. The following format may be used:]


For	[target customer]
Who	[statement of the need or opportunity]
The (product name)	is a [product category]
That	[statement of key benefit; that is, the compelling reason to buy]
Unlike	[primary competitive alternative]
Our product	[statement of primary differentiation]

[A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.]

3. Stakeholder and User Descriptions

[To effectively provide products and services that meet your stakeholders’ and users’ real needs, it is necessary to identify and involve all of the stakeholders as part of the Requirements Modeling process. You must also identify the users of the system and ensure that the stakeholder community adequately represents them. This section provides a profile of the stakeholders and users involved in the project, and the key problems that they perceive to be addressed by the proposed solution. It does not describe their specific requests or requirements as these are captured in a separate stakeholder requests artifact. Instead, it provides the background and justification for why the requirements are needed.]

3.1 Market Demographics

[Summarize the key market demographics that motivate your product decisions. Describe and position target market segments. Estimate the market’s size and growth by using the number of potential users, or the amount of money your customers spend trying to meet needs that your product or enhancement would fulfill. Review major industry trends and technologies. Answer these strategic questions:

What is your organization’s reputation in these markets?
What would you like it to be?
How does this product or service support your goals?]

3.2 Stakeholder Summary

[There are a number of stakeholders with an interest in the development and not all of them are end users. Present a summary list of these non-user stakeholders. (The users are summarized in section 3.3.)]


Name	Description	Responsibilities
[Name the stakeholder type.]	[Briefly describe the stakeholder.]	[Summarize the stakeholder’s key responsibilities with regard to the system being developed; that is, their interest as a stakeholder. For example, this stakeholder: - ensures that the system will be maintainable - ensures that there will be a market demand for the product’s features - monitors the project’s progress - approves funding - and so forth]

3.3 User Summary

[Present a summary list of all identified users.]


Name	Description	Responsibilities	Stakeholder
[Name the user type.]	[Briefly describe what they represent with respect to the system.]	[List the user’s key responsibilities with regard to the system being developed; for example: - captures details - produces reports - coordinates work - and so on]	[If the user is not directly represented, identify which stakeholder is responsible for representing the user’s interests.]

3.4 User Environment

[Detail the working environment of the target user. Here are some suggestions:

Number of people involved in completing the task? Is this changing?
How long is a task cycle? Amount of time spent in each activity? Is this changing?
Any unique environmental constraints: mobile, outdoors, in-flight, and so on.?
Which systems platforms are in use today? Future platforms?
What other applications are in use? Does your application need to integrate with them?

This is where extracts from the Business Model could be included to outline the task and business workers involved, and so on.]

3.5 Stakeholder Profiles

[Describe each stakeholder in the system here by filling in the following table for each stakeholder. Remember that stakeholder types can be as divergent as users, departments, and technical developers. A thorough profile would cover the following topics for each type of stakeholder.]

3.5.1 <Stakeholder Name>


Representative	[Who is the stakeholder representative to the project? (Optional if documented elsewhere.) What we want here is names.]
Description	[Brief description of the stakeholder type.]
Type	[Qualify the stakeholder’s expertise, technical background, and degree of sophistication-that is, guru, business, expert, casual user, and so on.]
Responsibilities	[List the stakeholder’s key responsibilities with regards to the system being developed-that is, their interest as a stakeholder.]
Success Criteria	[How does the stakeholder define success? How is the stakeholder rewarded?]
Involvement	[How is the stakeholder involved in the project? Relate where possible to Rational Unified Process roles-that is, Requirements Reviewer, and so on.]
Deliverables	[Are there any additional deliverables required by the stakeholder? These could be project deliverables or outputs from the system under development.]
Comments / Issues	[Problems that interfere with success and any other relevant information go here.]

3.6 User Profiles

[Describe each unique user of the system here by filling in the following table for each user type. Remember user types can be as divergent as gurus and novices. For example, a guru might need a sophisticated, flexible tool with cross-platform support, while a novice might need a tool that is easy to use and user-friendly. A thorough profile covers the following topics for each type of user.]

3.6.1 <User Name>


Representative	[Who is the user representative to the project? (Optional if documented elsewhere.) This often refers to the Stakeholder that represents the set of users, for example, Stakeholder: Stakeholder1.]
Description	[A brief description of the user type.]
Type	[Qualify the user’s expertise, technical background, and degree of sophistication-that is, guru, casual user, and so on.]
Responsibilities	[List the user’s key responsibilities with regard to the system being developed- that is, captures details, produces reports, coordinates work, and so on.]
Success Criteria	[How does the user define success? How is the user rewarded?]
Involvement	[How the user is involved in the project? Relate where possible to Rational Unified Process roles-that is, Requirements Reviewer, and the like.]
Deliverables	[Are there any deliverables the user produces and, if so, for whom?]
Comments / Issues	[Problems that interfere with success and any other relevant information go here. These would include trends that make the user’s job easier or harder.]

3.7 Key Stakeholder or User Needs

[List the key problems with existing solutions as perceived by the stakeholder. Clarify the following issues for each problem:

What are the reasons for this problem?
How is it solved now?
What solutions does the stakeholder or user want?]

[It is important to understand the relative importance the stakeholder or user places on solving each problem. Ranking and cumulative voting techniques indicate problems that must be solved versus issues they would like addressed.

Fill in the following table-if using Rational RequisitePro to capture the Needs, this could be an extract or report from that tool.]


Need	Priority	Concerns	Current Solution	Proposed Solutions
Broadcast messages

3.8 Alternatives and Competition

[Identify alternatives the stakeholder perceives as available. These can include buying a competitor’s product, building a homegrown solution or simply maintaining the status quo. List any known competitive choices that exist or may become available. Include the major strengths and weaknesses of each competitor as perceived by the stakeholder or end user.]

3.8.1 <aCompetitor>

3.8.2 <anotherCompetitor>

4. Product Overview

[This section provides a high level view of the product capabilities, interfaces to other applications, and systems configurations. This section usually consists of three subsections, as follows:

Product perspective
Product functions

- Assumptions and dependencies]

4.1 Product Perspective

[This subsection of the Vision document puts the product in perspective to other related products and the user’s environment. If the product is independent and totally self-contained, state it here. If the product is a component of a larger system, then this subsection relates how these systems interact and identifies the relevant interfaces between the systems. One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram.]

4.2 Summary of Capabilities

[Summarize the major benefits and features the product will provide. For example, a Vision document for a customer support system may use this part to address problem documentation, routing, and status reporting without mentioning the amount of detail each of these functions requires.

Organize the functions so the list is understandable to the customer or to anyone else reading the document for the first time. A simple table listing the key benefits and their supporting features might suffice. For example:]

Table 4-1 Customer Support System


Customer Benefit	Supporting Features
New support staff can quickly get up to speed.	Knowledge base assists support personnel in quickly identifying known fixes and workarounds.
Customer satisfaction is improved because nothing falls through the cracks.	Problems are uniquely itemized, classified and tracked throughout the resolution process. Automatic notification occurs for any aging issues.
Management can identify problem areas and gauge staff workload.	Trend and distribution reports allow high level review of problem status.
Distributed support teams can work together to solve problems.	Replication server allows current database information to be shared across the enterprise.
Customers can help themselves, lowering support costs and improving response time.	Knowledge base can be made available over the Internet. Includes hypertext search capabilities and graphical query engine.

4.3 Assumptions and Dependencies

[List each of the factors that affects the features stated in the Vision document. List assumptions that, if changed, will alter the Visiondocument. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the Vision document will need to change.]

4.4 Cost and Pricing

[For products sold to external customers and for many in- house applications, cost and pricing issues can directly impact the application’s definition and implementation. In this section, record any cost and pricing constraints that are relevant. For example, distribution costs (# of diskettes, # of CD-ROMs, CD mastering) or other cost of goods sold constraints (manuals, packaging) may be material to the projects success, or irrelevant, depending on the nature of the application.]

4.5 Licensing and Installation

[Licensing and installation issues can also directly impact the development effort. For example, the need to support serializing, password security or network licensing will create additional requirements of the system that must be considered in the development effort.

Installation requirements may also affect coding or create the need for separate installation software.]

5. Product Features

[List and briefly describe the product features. Features are the high-level capabilities of the system that are necessary to deliver benefits to the users. Each feature is an externally desired service that typically requires a series of inputs to achieve the desired result. For example, a feature of a problem tracking system might be the ability to provide trending reports. As the use-case model takes shape, update the description to refer to the use cases.

Because the Vision document is reviewed by a wide variety of involved personnel, the level of detail needs to be general enough for everyone to understand. However, enough detail must be available to provide the team with the information they need to create a use-case model.

To effectively manage application complexity, we recommend for any new system, or an increment to an existing system, capabilities are abstracted to a high enough level so 25-99 features result. These features provide the fundamental basis for product definition, scope management, and project management. Each feature will be expanded in greater detail in the use-case model.

Throughout this section, each feature will be externally perceivable by users, operators or other external systems. These features should include a description of functionality and any relevant usability issues that must be addressed. The following guidelines apply:

Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented.
If you are using the Rational RequisitePro toolkit, all need to be selected as requirements of type for easy reference and tracking.]

5.1 <aFeature>

5.2 <anotherFeature>

6. Constraints

[Note any design constraints, external constraints or other dependencies.]

7. Quality Ranges

[Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the Feature Set.]

8. Precedence and Priority

[Define the priority of the different system features.]

9. Other Product Requirements

[At a high-level, list applicable standards, hardware or platform requirements, performance requirements, and environmental requirements.]

9.1 Applicable Standards

[List all standards with which the product must comply. These can include legal and regulatory (FDA, UCC) communications standards (TCP/IP, ISDN), platform compliance standards (Windows, UNIX, and so on), and quality and safety standards (UL, ISO, CMM).]

9.2 System Requirements

[Define any system requirements necessary to support the application. These can include the supported host operating systems and network platforms, configurations, memory, peripherals, and companion software.]

9.3 Performance Requirements

[Use this section to detail performance requirements. Performance issues can include such items as user load factors, bandwidth or communication capacity, throughput, accuracy, and reliability or response times under a variety of loading conditions.]

9.4 Environmental Requirements

[Detail environmental requirements as needed. For hardware- based systems, environmental issues can include temperature, shock, humidity, radiation, and so forth. For software applications, environmental factors can include usage conditions, user environment, resource availability, maintenance issues, and error handling and recovery.]

10. Documentation Requirements

[This section describes the documentation that must be developed to support successful application deployment.]

10.1 User Manual

[Describe the purpose and contents of the User Manual. Discuss desired length, level of detail, need for index, glossary of terms, tutorial versus reference manual strategy, and so on. Formatting and printing constraints must be identified also.]

10.2 Online Help

[Many applications provide an online help system to assist the user. The nature of these systems is unique to application development as they combine aspects of programming (hyperlinks, and so on) with aspects of technical writing such as organization and presentation. Many have found the development of online help system is a project within a project that benefits from up-front scope management and planning activity.]

10.3 Installation Guides, Configuration, and Read Me File

[A document that includes installation instructions and configuration guidelines is important to a full solution offering. Also, a Read Me file is typically included as a standard component. The Read Me file can include a “What’s New With This Release” section, and a discussion of compatibility issues with earlier releases. Most users also appreciate documentation defining any known bugs and workarounds in the Read Me file.]

10.4 Labeling and Packaging

[Today’s state-of-the-art applications provide a consistent look and feel that begins with product packaging and manifests through installation menus, splash screens, help systems, GUI dialogs, and so on. This section defines the needs and types of labeling to be incorporated into the code. Examples include copyright and patent notices, corporate logos, standardized icons and other graphic elements, and so forth.]

A. Feature Attributes

[Features are given attributes that can be used to evaluate, track, prioritize, and manage the product items proposed for implementation. All requirement types and attributes are outlined in the Requirements Management Plan, however you may wish to list and briefly describe the attributes for features that have been chosen. The following subsections represent a set of suggested feature attributes.]

A.1 Status

[Set after negotiation and review by the project management team. Tracks progress during definition of the project baseline.]


Proposed	[Used to describe features that are under discussion but have not yet been reviewed and accepted by the “official channel,” such as a working group consisting of representatives from the project team, product management, and user or customer community.]
Approved	[Capabilities that are deemed useful and feasible, and have been approved for implementation by the official channel. ]
Incorporated	[Features incorporated into the product baseline at a specific point in time.]

A.2 Benefit


Critical	[Essential features. Failure to implement means the system will not meet customer needs. All critical features must be implemented in the release or the schedule will slip.]
Important	[Features important to the effectiveness and efficiency of the system for most applications. The functionality cannot be easily provided in some other way. Lack of inclusion of an important feature may affect customer or user satisfaction, or even revenue, but release will not be delayed due to lack of any important feature.]
Useful	[Features that are useful in less typical applications will be used less frequently or for which reasonably efficient workarounds can be achieved. No significant revenue or customer satisfaction impact can be expected if such an item is not included in a release.]

A.3 Effort

A.4 Risk

[Set by development team based on the probability the project will experience undesirable events, such as cost overruns, schedule delays or even cancellation. Most project managers find categorizing risks as high, medium, and low is sufficient, although finer gradations are possible. Risk can often be indirectly assessed by measuring the uncertainty (range) of the projects team’s schedule estimate.]

A.5 Stability

[Set by analyst and development team based on the probability the feature will change or the team’s understanding of the feature will change. Used to help establish development priorities and determine those items for which additional elicitation is the appropriate next action.]

A.6 Target Release

[Records the intended product version in which the feature will first appear. This field can be used to allocate features from a Visiondocument into a particular baseline release. When combined with the status field, your team can propose, record, and discuss various features of the release without committing them to development. Only features whose Status is set to Incorporated and whose Target Release is defined will be implemented. When scope management occurs, the Target Release Version Number can be increased so the item will remain in the Vision document but will be scheduled for a later release.]

A.7 Assigned To

[In many projects, features will be assigned to “feature teams” responsible for further elicitation, writing the software requirements, and implementation. This simple pull-down list will help everyone on the project team to understand responsibilities better.]

A.8 Reason

Vision

1. Introduction

2. Positioning

2.1 Problem Statement

[Provide a statement summarizing the problem being solved by this project. The following format may be used:]


The problem of	[describe the problem]
affects	[the stakeholders affected by the problem]
the impact of which is	[what is the impact of the problem?]
a successful solution would be	[list some key benefits of a successful solution]

2.2 Product Position Statement

[Provide an overall statement summarizing, at the highest level, the unique position the product intends to fill in the marketplace. The following format may be used:]


For	[target customer]
Who	[statement of the need or opportunity]
The (product name)	is a [product category]
That	[statement of key benefit; that is, the compelling reason to buy]
Unlike	[primary competitive alternative]
Our product	[statement of primary differentiation]

[A product position statement communicates the intent of the application and the importance of the project to all concerned personnel.]

3. Stakeholder Descriptions

3.1 Stakeholder Summary

Name	Description	Responsibilities
[Name the stakeholder type.]	[Briefly describe the stakeholder.]	[Summarize the stakeholder’s key responsibilities with regard to the system being developed; that is, their interest as a stakeholder. For example, this stakeholder: ensures that the system will be maintainable ensures that there will be a market demand for the product’s features monitors the project’s progress approves funding and so forth]

3.2 User Environment

[Detail the working environment of the target user. Here are some suggestions:

Number of people involved in completing the task? Is this changing?

How long is a task cycle? Amount of time spent in each activity? Is this changing?

Any unique environmental constraints: mobile, outdoors, in-flight, and so on?

Which system platforms are in use today? Future platforms?

What other applications are in use? Does your application need to integrate with them?

This is where extracts from the Business Model could be included to outline the task and roles involved, and so on.]

4. Product Overview

4.1 Product Perspective

[This subsection of the Vision document puts the product in perspective to other related products and the user’s environment. If the product is independent and totally self-contained, state it here. If the product is a component of a larger system, then this subsection needs to relate how these systems interact and needs to identify the relevant interfaces between the systems. One easy way to display the major components of the larger system, interconnections, and external interfaces is with a block diagram.]

4.2 Assumptions and Dependencies

[List each factor that affects the features stated in the Vision document. List assumptions that, if changed, will alter the Vision document. For example, an assumption may state that a specific operating system will be available for the hardware designated for the software product. If the operating system is not available, the Vision document will need to change.]

4.3 Needs and Features

[Avoid design. Keep feature descriptions at a general level. Focus on capabilities needed and why (not how) they should be implemented.]


Need	Priority	Features	Planned Release

4.4 Alternatives and Competition

[Identify alternatives the stakeholder perceives as available. These can include buying a competitor’s product, building a homegrown solution, or simply maintaining the status quo. List any known competitive choices that exist or may become available. Include the major strengths and weaknesses of each competitor as perceived by the stakeholder or end user.]

5. Other Product Requirements

[At a high level, list applicable standards, hardware, or platform requirements; performance requirements; and environmental requirements.

Define the quality ranges for performance, robustness, fault tolerance, usability, and similar characteristics that are not captured in the Feature Set.

Note any design constraints, external constraints, or other dependencies.

Define any specific documentation requirements, including user manuals, online help, installation, labeling, and packaging requirements.

Define the priority of these other product requirements. Include, if useful, attributes such as stability, benefit, effort, and risk.]

Adobe® FrameMaker® Templates

Adobe FrameMaker 6.0 templates are available for most artifacts from the various RUP disciplines. These can be downloaded from the RUP section of developerWorks®: Rational® Web site.. You can preview the list of FrameMaker templates by looking at the listing of Microsoft® Word® templates.

Guidelines: Installing and Customizing Microsoft Word Templates

Templates for use with the Rational Unified Process (RUP) are provided for Microsoft® Word® 97 and 2000.

This page addresses:

[how to install Microsoft Word document templates for your project](#To install document templates for your project)
[how to customize individual documents for your project](#To customize individual documents for your project)

Please refer to the Microsoft Word documentation for additional instructions on how to add customized templates to your Word environment and work with document fields.

To install document templates for your project

If you already have a folder for your RUP templates, remember its location in the file system and go to step 4.
Locate your Word ‘User Templates’ directory by starting Word and selecting Tools > Options > File Locations. If no folder is specified, double-click on the User Templates entry to display the Modify Location dialog. Create a folder where you want your user templates to reside, and click OK to make this folder your User Templates home.
From the Windows File Explorer, create a new folder (for example ‘RUP Templates’) within the User Templates folder created or identified in step 2.
Open the zip file containing the Rational Unified Process Word templates (click here and select Open this file…).
Extract the contents of the zip file into the RUP Templates folder you identified in step 1 or created in step 3. Hint: Check the Use Folder Names option to avoid having all the template files extracted into the same file system folder.
When you start Microsoft Word the next time, the New dialog box in the File menu will include a tab called RUP Templates.
To create a new file from a template, select the RUP Templates tab, and select the desired template file.

To customize individual documents for your project

Open Microsoft Word and select File>New, RUP Templates tab, and the template of your choice.
At the lower right side of the New dialog box, you’ll see the Create New option buttons. If you’re creating a new document using the selected template, click Document. If you’re creating a new template using the selected template, click Template. Select the desired Rational Unified Process template and click OK.
Under the Summary tab, Replace Project Name, Company Name, and customize the document title in the displayed fields, as appropriate.
Select OK to close the Properties dialog box.
From the Word menu bar, select View>Header and Footer.
Scroll through the headers and footers, changing the document version number and dates in the headers and footers, as appropriate
Select Close to close the Header and Footer dialog box.
From the Word menu bar, select File>Save As… to select the appropriate folder location and name for the new Word file.
Exit from Word and re-open the saved document to view the updated fields.
If any field is not updated in the displayed document, right-click on the displayed field name and select Update Field.
See Microsoft Word Help for more information on working with fields.

Guidelines: Installing and Customizing Microsoft Word Templates (Informal Set)

Templates for use with the Rational Unified Process (RUP) are provided for Microsoft® Word® 97 and 2000.

This page addresses:

[how to install Microsoft Word document templates for your project](#To install document templates for your project)
[how to customize individual documents for your project](#To customize individual documents for your project)

Please refer to the Microsoft Word documentation for additional instructions on how to add customized templates to your Word environment and work with document fields.

To install document templates for your project

If you already have a folder for your RUP templates, remember its location in the file system and go to step 4.
Locate your Word ‘User Templates’ directory by starting Word and selecting Tools > Options > File Locations. If no folder is specified, double-click on the User Templates entry to display the Modify Location dialog. Create a folder where you want your user templates to reside, and click OK to make this folder your User Templates home.
From the Windows File Explorer, create a new folder (for example ‘RUP Templates’) within the User Templates folder created or identified in step 2.
Open the zip file containing the Rational Unified Process Word templates (click here and select Open this file…).
Extract the contents of the zip file into the RUP Templates folder you identified in step 1 or created in step 3. Hint: Check the Use Folder Names option to avoid having all the template files extracted into the same file system folder.
When you start Microsoft Word the next time, the New dialog box in the File menu will include a tab called RUP Templates.
To create a new file from a template, select the RUP Templates tab, and select the desired template file.

To customize individual documents for your project

Open Microsoft Word and select File>New, RUP Templates tab, and the template of your choice.
At the lower right side of the New dialog box, you’ll see the Create New option buttons. If you’re creating a new document using the selected template, click Document. If you’re creating a new template using the selected template, click Template. Select the desired Rational Unified Process template and click OK.
Under the Summary tab, Replace Project Name, Company Name, and customize the document title in the displayed fields, as appropriate.
Select OK to close the Properties dialog box.
From the Word menu bar, select View>Header and Footer.
Scroll through the headers and footers, changing the document version number and dates in the headers and footers, as appropriate
Select Close to close the Header and Footer dialog box.
From the Word menu bar, select File>Save As… to select the appropriate folder location and name for the new Word file.
Exit from Word and re-open the saved document to view the updated fields.
If any field is not updated in the displayed document, right-click on the displayed field name and select Update Field.
See Microsoft Word Help for more information on working with fields.

Microsoft® Word® Templates - Informal

These templates are suited to smaller or more informal projects. The following instructions describe how to use these templates directly with Word.

To install and customize Word templates…

For viewable HTML versions of these document templates, link from the related artifact’s main description page.

Microsoft® Word® Templates for Classic RUP

The following Rational Unified Process (RUP) specific document templates are provided for use with Microsoft Word 97 or 2000. Refer to the following instructions for using these directly with Word.

To install and customize Word templates…

For viewable HTML versions of these document templates, link from the related artifact’s main description page.

Business Modeling


Artifacts	Word Template File Name
Target-Organization Assessment	rup_tarorgass.dot
Business Architecture Document	rup_barchdoc.dot
Business Glossary	rup_bgloss.dot
Business Rules	rup_brul.dot
Business Vision	rup_bvis.dot
Business Use Case	rup_bucs.dot
Business Use Case Realization	rup_bucr.dot
Supplementary Business Specification	rup_sbs.dot

Requirements


Artifacts	Word Template File Name
Glossary	rup_gloss.dot
Requirements Management Plan	rup_rmpln.dot
Vision	rup_vision.dot
Supplementary Specification	rup_sspec.dot
Stakeholder Requests	rup_stkreq.dot
Use-Case	rup_ucspec.dot
Software Requirements Specification	rup_srsuc.dot (with use cases) rup_srs.dot (without use cases)

Analysis & Design


Artifacts	Word Template File Name
Software Architecture Document	rup_sad.dot
Use-Case Realization	rup_ucrs.dot

Test


Document Title	Word Template File Name
Master Test Plan	rup_tstpln_mstr.dot
Itertaion Test Plan	rup_tstpln_itn.dot
Test Strategy	rup_tststr.dot
Test Evaluation Summary	rup_tsteval.dot

Management


Artifacts	Word Template File Name
Business Case	rup_buscs.dot
Iteration Plan	rup_itpln.dot
Iteration Assessment	rup_itass.dot
Measurement Plan	rup_mspln.dot
Product Acceptance Plan	rup_pacpln.dot
Problem Resolution Plan	rup_prspln.dot
Quality Assurance Plan	rup_qapln.dot
Risk List	rup_rsklst.dot
Risk Management Plan	rup_rskpln.dot
Software Development Plan	rup_sdpln.dot
Status Assessment	rup_stass.dot

Configuration & Change Management


Artifacts	Word Template File Name
Configuration Management Plan	rup_cmpln.dot

Deployment


Artifacts	Word Template File Name
Bill of Materials	rup_blomtl.dot
Deployment Plan	rup_dplpln.dot
Release Notes	rup_relnt.dot

Implementation


Artifacts	Word Template File Name
Integration Build Plan	rup_ibpln.dot

Environment


Artifacts	Word Template File Name
Business Modeling Guidelines	rup_bmgd.dot
Design Guidelines	rup_desgd.dot
Development Case	rup_devcs.dot
Development-Organization Assessment	rup_dorgass.dot
Programming Guidelines	rup_prggd.dot
Test Guidelines	rup_tstgd.dot
Use-Case Modeling Guidelines	rup_ucmgd.dot

Concept: Developing Component Solutions

Topics


Activities across the lifecycle: 1. Introduction 2. [Inception Phase Activities](#Inception Phase Activities) 3. [Elaboration Phase Activities](#Elaboration Phase Activities) 4. [Construction Phase Activities](#Construction Phase Activities) 5. [Transition Phase Activities](#Transition Phase Activities)	Additional topics: - Concepts - distribution patterns - Guidelines - concurrency - data modeling - functionality partitioning using analysis classes - interfaces - layering - software architecture - unit testing components - using design subsystems to represent components - White Papers - developing large-scale component-based systems

Introduction

Component-based development is a variation on general application development in which:

The application is assembled from discrete executable components which are developed and deployed relatively independently of one another, potentially by different teams.

The application may be upgraded in smaller increments by upgrading only some of the components that comprise the application.

Components may be shared between applications, creating opportunities for reuse, but also creating inter-project dependencies.

Though not strictly related to being component-based, component-based applications tend to be distributed.

Throughout this page, “component” is used to refer to these independently developed and deployable components. Elsewhere in RUP, however, we will use the term “component” in the more general sense described in Concepts: Component , and qualify as necessary.

The adaptation of the Rational Unified Process (RUP) to dealing with component-based development challenges is discussed below.

Inception Phase Activities

The basic workflow for the Inception Phase applies, with the following extensions or variations:

Project Management

Workflow Detail: Conceive New Project

The focus of the Activity: Develop Business Case is adjusted to take into account that using components change the cost structure of development. In specific, the cost of developing components decreases, but more effort is spent on identifying components and validating that selected components meet their requirements.

Workflow Detail: Evaluate Project Scope and Risk

Taking a component approach changes the nature of certain risks and introduces new risks. Specifically:

externally-sourced components increase risk because they introduce critical elements not under the direct control of the project team
externally-sourced components can reduce development time, reducing resource risk
externally-sourced components can distort the architecture of the system if they impose architectural restrictions of their own
Workflow Detail: Plan the Project

In the Activity: Plan Phases and Iterations, the plan for the Construction phase may potentially show the project splitting into two different but parallel tracks: one which develops the application-specific and domain-specific components (organized in the upper layers of the architecture - see Concepts: Layering), and the non-application and non-domain-specific components organized in lower layers. In some cases, reusable components will be developed by independently managed development teams. The decision to introduce parallel tracks is largely a staffing and resource issue introduced by a desire to manage reusable components as assets independent of the applications in which they are deployed.

Requirements

Workflow Detail: Refine the System Definition

When refining the requirements of the system, the constraints imposed by the selected component framework need to be captured. Component frameworks improve development productivity in part by restricting the degrees of freedom offered to the software architect and designer. The Activity: Detail the Software Requirements must focus on documenting these constraints.

Test

Workflow Detail: Define Evaluation Mission

A test plan identifying the overall intended testing for the project should be created, called the “Master Test Plan”.

Environment

Workflow Detail: Prepare Environment for Project

When collecting and preparing guidelines for the project, see Activity: Prepare Guidelines for the Project for details, take into account the specific component framework and the constraints imposed by it. Guidelines should include how to design and code using the framework. They should also provide testing guidance on how to verify conformance with both the component framework itself and with the interfaces defined between components.

Elaboration Phase Activities

The basic workflow for the Elaboration Phase applies, with the following extensions or variations:

Requirements

Workflow Detail: Refine the System Definition

The Activity: Detail the Software Requirements additionally focuses on the technical and non-functional requirements and constraints imposed on the components that are either built or purchased. Specific non-functional requirements to consider are size, performance, memory or disk footprint, run-time licensing issues, and similar constraints that will influence component selection or construction.

Analysis & Design

Workflow Detail: Define a Candidate Architecture

The Activity: Architectural Analysis uses the component framework and the technical and non-functional requirements to define an initial architecture, including an initial layering scheme and a default set of components and services (represented as analysis and design mechanisms). The Activity: Use-Case Analysis focuses on identifying architecturally significant components from architecturally significant use cases.

Workflow Detail: Refine the Architecture

The Activity: Structure the Implementation Model establishes an implementation model compatible with the component framework structure and the structure and responsibilities of the development team(s).

The Activity: Identify Design Mechanisms will refine the initial design mechanisms to take into account specific framework services and components.

The Activity: Identify Design Elements will identify the major, architecturally significant components of the system. Potentially reusable responsibilities should be grouped together to improve reusability; application-specific functionality should be separated from domain-specific and application-and-domain-independent functionality. For purposes of design, components can be represented as Artifact: Design Subsystems. Artifact: Interfaces should be identified for these components/subsystems.

The Activity: Incorporate Existing Design Elements will ensure that identified components are consistent and compatible with existing components identified in prior iterations, in the framework itself, or from outside sources.

The Activity: Describe the Run-time Architecture describes the basic process and thread architecture of the component framework, while the Activity: Describe Distribution describes the distributed computing environment in which the component application will execute.

Workflow Detail: Design Components

The Activity: Subsystem Design further refines the design of the components, identifying classes within the component which provide the real behavior of the component. In the early stages of the Elaboration phase, there is likely to be a single class, a kind of ‘subsystem/component proxy’ which acts as a stub to simulate the behavior of the component for architectural prototyping purposes. Later the behavior of this class is distributed to a collaboration of classes contained within the subsystem. These contained classes are refined in the Activity: Class Design.

Workflow Detail: Design the Database

The focus in elaboration is on ensuring that the persistence strategy is scalable and that the database design and persistence mechanism will support the throughput requirements of the system. Persistent classes are identified and mapped to the persistence mechanism. Data-intensive use cases are analyzed to ensure the mechanisms will be scalable. In conjunction with the Testing Workflow Details, the persistence mechanism and database design is assessed and validated.

Implementation

Workflow Detail: Implement Components

The Activity: Implement Design Elements must conform to the constraints imposed by the component framework, as described in the Programming Guidelines, provided as part of Artifact: Project-Specific Guidelines. In the Elaboration phase, most of the components will contain a great deal of ‘stub’ code, as the implementation here focuses on validating the architecture, not producing production-quality code.

Test

Workflow Details: Define Evaluation Mission, Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets

The testing activities in Elaboration focus on validating the architecture. For a component-based system, this focus translates to:
- exercising the interfaces between components, to ensure that component boundaries are appropriate, and
- a greater focus on performance testing, especially performance scaling tests, to ensure that anticipated transaction volumes can be sustained
Any inherent assumptions in the component framework need to be assessed as well. These commonly include the scalability and throughput of the persistence and transaction management mechanisms, in which hidden assumptions made by the mechanism designer often effectively undermine the application architecture if it does not understand the assumption.

Project Management

Workflow Detail: Plan for Next Iteration

Using the implementation subsystems as ‘logical units of responsibility’, the construction work can be partitioned into to or more parallel “tracks”: one which focuses on application-specific functionality, and one or more which focus on generic, reusable components. This, of course, depends on having sufficient resources to staff parallel development efforts. The ability to divide the development teams and work in parallel depends wholly on the stability of the architecture, and more specifically on the quality and stability of the interfaces between components. Strong effort in the Elaboration phase will enable this division.

Construction Phase Activities

The basic workflow for the Construction Phase applies, with the following extensions or variations:

Project Management

Workflow Detail: Plan for Next Iteration

Planning for the first construction iteration was described previously, as it occurs towards the end of elaboration. Follow-on iteration planning, and the ability to divide the development teams and work in parallel, continues to be dependent on the stability of the architecture, and the quality and stability of the interfaces between components.

Analysis & Design

Workflow Detail: Refine the Architecture and Workflow Detail: Design Components

The focus in construction is on analyzing the remainder of the use cases and identifying appropriate components and component collaborations that realize the use cases. The existing architecture is expanded and completed, and the ‘internal behaviors’ of the component are completely designed and implemented.
Workflow Detail: Design the Database

The focus in construction is on completing the database design, ensuring that all persistent classes are supported by both the database and the persistence mechanism. This work is performed in parallel and iteratively with the work done in Workflow Detail: Refine the Architecture and Workflow Detail: Design Components. The ideal organization is to have integrated component teams, with cross-team coordination on persistence issues to ensure a good database design.

Implementation

Workflow Detail: Implement Design Elements

The work here is similar to that in Elaboration, but the remaining details are increasingly complete as the phase progresses.

Workflow Detail: Integrate Each Subsystem and Workflow Detail: Integrate the System

The system is progressively built as the phase continues.

Test

Workflow Details: Define Evaluation Mission, Verify Test Approach , Validate Build Stability, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets

Performance testing remains important, but there is an increasing focus on functional testing. Completeness of functionality, regression testing of existing functionality, as well as conformance with performance expectations need to be addressed.

Transition Phase Activities

Product release in the web environment tends to be incremental and continuous, and less focused on traditional distribution of media. Release planning must be adjusted accordingly.
Production support is increasingly the focus of the phase.
Data conversion activities are performed.

Concept: Developing e-business Solutions

Topics


Activities across the lifecycle: - Introduction - [Inception Phase](#Inception Phase Activities) - [Elaboration Phase](#Elaboration Phase Activities) - [Construction Phase](#Construction Phase Activities) - [Transition Phase](#Transition Phase Activities)	Concepts: - Distribution Patterns - e-business Development - Performance Testing - User-Centered Design - Usability Testing - Structure Testing. - Web Architecture Patterns White papers: - Modeling Web Application Architectures with UML

Introduction

To build e-business applications means building Internet solutions to implement business processes. This includes e-commerce, but extends to all business processes throughout an organization. The basic concepts and technologies used in an e-business solution are described in Concepts: e-business Development.

E-business systems can be divided into:

first generation systems that simply use the web to publish information
second generation systems that implement e-commerce and simple transactional models
third generation systems that completely re-engineer a process to provide highly personalized (business-to-consumer or business-to-business) solutions that are adaptive and automate the complete business process, often integrating with legacy systems and internet devices

The further along the systems are in the generations, the more complex their development.

Inception Phase Activities

The basic workflow for the Inception Phase applies, with the following extensions or variations.

Business Modeling

In general, there is a much higher focus on business modeling compared to other types of development efforts. To develop an e-business application generally means to develop a new way of doing business; it’s an integral part of the way you run your business.

Workflow Detail: Assess Business Status

The focus here is to understand the problems the new business should solve, and also the effects of not developing the new business.

Building e-business solutions involves a greater variety of stakeholders than other software application development projects. These stakeholders will usually include business executives, marketing, creative design, customer support, and the technology development team, among others.

The Activity: Set and Adjust Goals focuses on ensuring that the new business will meet the needs of this varied group of stakeholders. The primary artifact where these needs are expressed is the Business Vision. Given the diverse backgrounds of the stakeholders, a facilitated workshop, like the one described in Work Guidelines: Requirements Workshop, is often needed to bring the group together. Extensive use of storyboards to describe the desired customer experience tend to be useful in eliciting feedback (see Work Guidelines: Storyboarding).

Sometimes the stakeholders are not available because they are only on the Internet. In these cases an important role of the Business Vision document is to describe how the stakeholders or customers should find the Web site and how user feedback is going to be collected. As well, in these cases you can develop prototypes to learn how customers find the Web site and how they are using it. The need to obtain this kind of feedback may affect the length of the iterations and the product lifecycle.

Workflow Detail: Describe Current Business

Describe in detail enough about the current business in order to determine where any issues are and where you have the best potential for improvement.

Workflow Detail: Identify Business Processes

Focus on understanding the scope-limit the organization to be modeled to your area of influence. Within in those boundaries, prioritize only the business use cases that will be automated.

Workflow Detail: Refine Business Process Definitions

Detail prioritized business use cases.

Workflow Detail: Refine Roles And Responsibilities

Even though you may be aiming at completely automating your business processes, a business worker concept is useful. In the final business analysis model, you will have two types of business workers-automated and non-automated. Business workers’ responsibilities are described to a level of detail necessary to make decisions on what to automate.

Workflow Detail: Explore Process Automation

Focus on understanding what level of automation is realistic to achieve, and what limitations any legacy systems have on what can be done.

Workflow Detail: Develop a Domain Model

This is not performed separately. The information normally captured in a domain model is already part of the business analysis model.

Environment

Workflow Detail: Prepare Environment for an Iteration

The importance of the Activity: Prepare Guidelines for the Project is amplified and focuses on what Web developers call the ‘Creative Design Brief’, which is a set of guidelines that describe (at a high level)

The mood of the site; for example, does the site convey authority, playfulness, or service? Is it conservative or provocative?

How users will be accessing the site; for example, what’s their connection speed? Is there a minimum speed specified or assumed in the design?

The degree of user-interaction; for example, should we only inform the user or should we try to communicate with the actor (two-way communication)? Should the design of the application be different depending on which user is accessing the application?

The browsers that users will be using, including differences across operating systems

Whether the site will use frames

Any color limitations the site will have

If applicable, a graphics standards guide (including standards on logos and all corporate colors)

The usage of specific web techniques; for example, mouse-overs, animation, news feeds, multimedia, and so forth

The ‘Creative Design Brief’ evolves into the user interface guidelines documented in the Artifact: Project-Specific Guidelines; it is essentially an early version of the user-interface guidelines.

Requirements

Workflow Detail: Analyze Problem

This has less emphasis. Most of the problems should already have been found in Workflow Detail: Assess Business Status and Workflow Detail: Describe Current Business from the business modeling discipline.

Workflow Detail: Understand Stakeholder Needs

This requires less emphasis. Most of the stakeholder needs should have been found during business modeling. You will, however, need to do some exercises that focus on finding non-functional requirements on the system.

Workflow Detail: Define the System

This requires less emphasis. The system boundary is defined by the boundary of the business, since the system more closely mirrors the business than in traditional applications (in some respects, the system is the business).

Analysis and Design

Workflow Detail: Analyze Behavior

The Activity: Design the User Interface produces a Navigation Map. A Navigation Map is a view of the Web solution that shows how users of the site will navigate it, possibly represented in a hierarchical “tree” diagram. Each level of the diagram shows the number of clicks it takes to get to that screen or page. Generally, you want to have the most important areas of the Web site only one click away from the first page (commonly known as the “home page”). The Navigation Map is effectively a summary of the Storyboards, which starts by identifying the major windows or Web pages for each of the Use Cases and considers how the user navigates between these elements.

Elaboration Phase Activities

The basic workflow for the Elaboration Phase applies, with the following extensions or variations.

Workflow Detail: Define a Candidate Architecture

The Activity: Architectural Analysis takes advantage of the knowledge that a Web application has a relatively well-defined architecture, including a set of well-defined mechanisms (Web browsers, Java applets and servlets, ASPs and JSPs, and the like). Usually a simple layering structure as described in Concepts: Layering is sufficient unless the Web application development framework is more specific. In many cases, there may be predefined, off-the-shelf architectures that can be purchased or re-used from prior Web development projects. Web application frameworks, such as IBM’s WebSphere or Microsoft’s Windows DNA, provide just this sort of architectural template.

Web applications typically do not have scheduled downtime. The architecture may (and typically does) need to provide for upgrading the system while it’s running, and switching to standby servers during primary server failure or when maintenance or server upgrades occur. Some Web application frameworks provide tools for production support. Regardless, if your application has high-availability requirements, you will need to plan to buy or build the infrastructure necessary to support this requirement, and to integrate the support for this capability into the architecture.
Workflow Detail: Analyze Behavior

The Activity: Design the User Interface is performed iteratively within the Elaboration iterations. The early executions of this activity focus on producing ‘creative design comps’, which are mocked-up representations of the design of key Web pages in the site. These ‘comps’ are typically “flat” pictures framed with browser window graphics to give a look of a browser window. The main benefit of ‘comps’ is to postpone the investment of more elaborate and costly HTML prototypes until there is consensus on the specific graphical direction for the site.

‘Creative Design Comps’ are created by looking at the interface requirements of the most important Use Cases and developing many alternative designs (perhaps 10 or more) for its look and feel. From this set, the three most promising options are chosen to present to the stakeholders. This is done iteratively until there is agreement on the final Web design, resulting in a set of Storyboards and a Navigational Map.

Once there is agreement and sign-off, the creative design comps evolve into a functional User-Interface Prototype through repetition of the Activity: Prototype the User Interface. The Initial Web UI Prototype typically supports only portions of the system-the most important and architecturally significant use cases. It’s important to have a good structure in the Use Case flow-of-events before developing prototypes to ensure that functionality drives the layout of the user interface and not the reverse.

In subsequent iterations, the Web prototype is expanded, gradually adding broader coverage of the use cases and deeper exercise of the architecture.

The Activity: Use-Case Analysis is relatively unchanged, except that it’s important to focus on not only the behavior of the GUI, but also the underlying business logic
- the part that will typically run on either the Web server or the application server. If this is forgotten, the most significant portion of the system behavior will be overlooked. Web pages themselves are represented as ‘boundary’ classes, data elements are represented as ‘entity’ classes, and server-side behavior (for example, active server pages, servlets, and such) is represented through ‘control’ objects.
Immediately following use-case analysis, the Activity: Identify Design Elements refines the Artifact: Analysis Classes, mapping them onto existing mechanisms in the web development framework, reusing existing design elements from prior projects or iteration where possible. This often requires readjusting the scope and definition of the identified analysis classes to achieve the desired degree of reuse.

A more detailed description of the use of UML to describe Web applications is described in Modeling Web Application Architectures with UML.
Workflow Detail: Prepare Environment for an Iteration

In addition to developing user interface guidelines, Web design elements-the discrete graphical images that are assembled to build the Web pages for a site-are created. Consistency of the user interface across a Web site is essential to usability; the Web site should provide a consistent user experience. To ensure this, the project must consistently use a set of standard graphical elements across the whole site.

The development of these elements is an extension of the Activity: Prepare Guidelines for the Project and includes the creation of guidelines for their use. Ensure that all team members understand when and how to use these elements. Examples of Web design elements include graphical elements such as navigational devices and page backgrounds. Reusing high quality, standard, graphical elements across the entire site ensures consistency, reduces time to market, and reduces development cost as well as increases quality by deploying a smaller set of higher quality elements.

The preparation of guidelines is done in conjunction with the development of the initial Web User-Interface Prototype to produce the style guide for the site. This style guide will, among other things, specify how and when Web design elements should be used, color schemes, fonts, cascading style sheets, and details on how navigational elements should function and be positioned.
Workflow Detail: Refine the Architecture

The Activity: Identify Design Mechanisms becomes more focused on mapping the non-functional requirements of the system onto the mechanisms provided by the Web development framework; mechanisms not provided by the framework (if it exists) will need to be identified and alternative solutions found.

The Activity: Describe the Run-time Architecture becomes focused mostly on the Web server and application server tiers (see Concepts: Distribution Patterns), and the processes and threads used there to manage concurrency in the application. Typically there is little or no control over processing on the client-side machines.

The Activity: Describe Distribution changes focus from one of deciding ‘what kinds of server nodes to have’ to ‘how many of each kind of server node to have’. Typically, the Web development framework will provide a fixed number of server types (for example, web servers, application servers, mail servers, communication gateway servers) with relatively well-defined functional boundaries. The software architect’s skill, as a result, becomes focused on determining how to deal with scalability and fault tolerance requirements using the available server types, usually by determining how many of each kind of server are needed. In addition, measurement plans need to be made to determine how to know when additional servers are needed.
Workflow Detail: Define Evaluation Mission

Planning focuses, to a great degree, on performance testing to ensure that the Web application can support significant increases in the number of concurrent users. As a result, the Test Workflow Details Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission, Improve Test Assets will also focus more on performance testing to ensure that the architecture is scalable.

Other important types of test are usability testing and structure testing. It’s necessary to test user-interaction to verify that the structure of the Web application is appropriate to its users. In some cases, you are forced to have the application on the Internet so that you can monitor how the users are using the application.

Another type of test that consumes a lot of time are browser tests, since compatibility between browsers and browser versions often limits the design options in the user interface.
Workflow Details: Implement Components, Integrate Each Subsystem, and Integrate the System

In order to validate the architectural decisions made so far on the project, one or more architectural prototypes are developed and tested, involving successive execution of Workflow Detail: Implement Components, Workflow Detail: Integrate Each Subsystem, and Workflow Detail: Integrate the System. Testing, as mentioned above, should especially focus on the scalability of the application to unpredictable increases in system load.

Construction Phase Activities

The basic workflow for the Construction Phase applies, with the following extensions or variations.

Workflow Detail: Plan the Integration

Activity: Plan Subsystem Integration and Activity: Plan System Integration need to address the different kinds of implementation elements created in the construction phase.
Workflow Detail: Implement Components

The Activity: Implement Design Elements focuses on several different kinds of elements:
- Web pages, applets, scripts, graphics, and other elements that “execute” in the browser environment
- Server-side pages, scripts, servlets, and other elements which “execute” in the Web server environment
- Executable code enhancements to legacy applications
- Database tables, triggers, stored procedures, and other elements that execute in the database management system
The differences in the tools, and the deployment technologies between these different kinds of elements, means there will be a number of similar variations on the Activity: Implement Design Elements. There will be similar adaptations in the Workflow Detail: Integrate Each Subsystem and Workflow Detail: Integrate the System.
Workflow Detail: Define Evaluation Mission

Test planning continues to focus on performance testing, but increasingly focuses on functional testing. A slightly different testing approach is required for each of the different kinds of elements that comprise a web application. There will be similar adaptations in the Test Workflow Details Verify Test Approach, Test and Evaluate, Achieve Acceptable Mission , Improve Test Assets, in which the focus increasingly shifts from architectural performance-focused testing to functional testing, ensuring the details of the system behavior are correct.

Transition Phase Activities

Product release in the Web environment tends to be incremental and continuous, and less focused on the traditional distribution of media. Release planning must be adjusted accordingly.
User education in the Web environment tends to be integrated into the design of the Web site itself, so that the use of the site is intuitive. Creation of traditional education and user manuals or documentation is reduced, with increased emphasis on graphic and content design at the front-end of the process.
Production application support in the Web environment must focus on maintaining high availability under unpredictable load. It may also need to be able to provide the ability to continue running when primary servers fail, and to allow for server upgrades while the system is running.
Knowledge transfer from the development team to the production support team must occur, so that the production support staff is capable of running the system and performing routine maintenance.
Follow up how the users are using the application. This information is valuable for learning who is using the application and how it’s being used. These observations can assist in developing further releases to improve user interaction.


Portions of this page are developed in cooperation with Context Integration.	http://www.context.com – This hyperlink in not present in this generated websiteContext Logo Link

Concept: Tailoring a Process for a Small Project

Topics

Introduction
Definition of “Small Project”
Characteristics of a Small Project Process
How to Get Started
Additional Process Tailoring

Introduction

Definition of “Small Project”

Small can refer to the number of people on the project, the length of the project, or the amount of software being developed. For the purposes of this roadmap, a “Small Project” is defined as a project with:

3 to10 people
project duration less than one year.

Characteristics of a Small Project Process

A key characteristic of most small projects is a lower level of formality. Although there are exceptions, the larger the number of people on the project and the larger and more complex the product, the greater the need for formal process. For example, if your project has a geographically distributed team of 100 people, or is working simultaneously on multiple related products with multiple customers and subcontractors, you require much more formal process than a typical five-person team. Similarly, a missile guidance system requires more formal artifacts than an inventory system upgrade.

So why have a process at all? A process enables successful practices to be repeated, and unsuccessful practices to be dropped or improved. RUP in particular provides:

guidance on best practices
a set of activities, roles, and artifacts your process may need to consider
- with guidance on when these are needed
lots of good detailed information that help you effectively apply the techniques that you decide are appropriate for your project. For example, if you are doing a UML design model, you find out what diagrams are appropriate and how to structure the model. Further, if you use Rational tools, there’s additional guidance on how to use them effectively as part of the overall process.
guidance on how to tailor the process to address specific process-related problems. For example, if your project has a lot of changing requirements, you may benefit from the guidance on how to effectively manage requirements.

Many of the same RUP activities and artifacts are needed on both small and large projects - the differences are more in terms of artifact formats and the level of formality, detail, and effort applied to each activity. For the purposes of this roadmap, a “small project process” will focus on projects which require little formality. Some characteristics of this small project process are as follows.

The number of documents tends to be smaller, and less detailed. Instead of detailed Risk Management Plans and Product Acceptance Plans, small projects may devote a couple of paragraphs to these topics as part of the overall Software Development Plan. The Test Plan for each iteration may be a few paragraphs in the Iteration Plan.
Small projects often start off with a minimum of software development tools. As a project grows and succeeds (which is the objective of all successful small projects!), it will be important to include effective tools to help automate your team’s implementation of the best practices.
Formal reviews may be replaced with informal meetings and discussions.
Many of the artifacts may be captured informally. A risk list may be created on a whiteboard, and status assessments may be a few paragraphs in an email.

How to Get Started

To define a process for your small project, you should first review the following RUP basics:

Process Essentials
Tailoring the Process
Best Practices for Developing Software.

Then evaluate any existing process you may be following against these essentials, and focus revisions on any weak areas. Many projects choose to incrementally adopt new tools and process, and initially use only small parts of RUP.

The Scenario: A Small Project Adopts RUP, gives an example for how a small project might approach defining a process. Detailed guidance for defining and documenting a software development process for a project is provided by Activity: Tailor the Process for the Project, including tool mentors that describe how to create a tailored process using RUP Builder.

These tool mentors describe how you can select and deselect RUP process components to perform a coarse tailoring of the process, and do finer tuning with process views, including adding your own project-specific guidelines. Note that RUP Builder includes a Small Project process template configuration. This is a smaller configuration of the RUP that includes “informal” templates and excludes guidance applicable to larger or more formal projects. Small projects should start with this template and apply their own project-specific tailoring.

Additional Process Tailoring

Smaller projects in particular may wish to adopt practices and techniques associated with “Agile Processes”. This is discussed in Concepts: Agile Practices in RUP and in White Paper: Using the RUP for Small Projects: Expanding upon eXtreme Programming.

Concept: Usability Engineering

Topics


- Introduction - Roles - Disciplines - Business Modeling - Requirements - Analysis and Design - Implementation - Test - Deployment - Iterative Development and Phases - Inception Phase - Elaboration Phase - Construction Phase - Transition Phase	Concepts: - User-Centered Design - Usability Testing

Introduction

Usability Engineering (also called User-Centered Design) is all about building better systems by getting a better understanding of the end-users, and involving users in requirements, user interface design, and testing efforts. Basic concepts are described in Concepts: User-Centered Design, and should be read prior to this concept. This concept page explains how the Rational Unified Process (RUP) currently addresses usability engineering techniques.

Roles

The RUP has a number of roles responsible for usability concerns. The Business-Process Analyst, System Analyst and Requirements Specifier must be skilled in gathering and analyzing information about users, their tasks, and their environment, and capturing these in the requirements and business modeling artifacts. This material is reviewed by the Requirements Reviewer and Business Model Reviewer respectively. The Tester and Test Analyst roles are primarily responsible for usability testing. The User-Interface Designer is responsible for the design and the “visual shaping” of the user interface. The Implementer selects and/or develops user interface components to construct the functioning user interface.

The Project Manager also has a key role. He/she enables users to be involved in the development process, and ensures that the development organization is staffed with the skills required to build usable systems. Other roles, such as Deployment Manager, Course Developer, and Technical Writer also have responsibilities for ensuring that the deployed system is usable.

Disciplines

The following sections describe RUP disciplines in terms of the activities and artifacts which are most important to usability.

Requirements

From a usability perspective, the Requirements discipline focuses on:

establishing an understanding of the users and their needs
identifying the use cases of greatest benefit to the users.

The specific activities and artifacts are as follows.

Activity	Artifact	Usability Related Content
Elicit Stakeholder Requests	Stakeholder Requests	This activity involves interviewing users, questionnaires, and holding workshops to better understand the user and the user environment. This includes the following: - Assessment Workshop - Requirements Workshop - Interviews - Brainstorming and Idea Reduction - Storyboarding - Role Playing - Reviewing Existing Requirements The template for Artifact: Stakeholder Requests captures a detailed user profile, including educational background, computer background, experience, existing environment, expectations, goals, etc. It also captures a description of problems and priorities from the user’s perspective. Stakeholder Requests are the raw material from which the Vision is compiled.
Develop Vision	Vision	The User Environment section of the Vision template describes the working environment of the end users, or what ISO refers to as the Environment Context [ISO 13407]. The User Profile section of the Vision template describes the user’s expertise, technical background, responsibilities, success criteria, deliverables etc. This is what ISO refers to as the User Context [ISO 13407].
Find Actors and Use Cases, Structure the Use Case Model, Detail a Use Case	Use-Case Model	The Use Case Model describes the tasks (use cases) that users (human Actors) perform. It capture similarities and relationships between Actors, using generalization relationships. Actors are related to use cases through This is similar to Constantine’s “Role Model” [CON99]. The use cases are structured and related to one another and to actors through communicate-association, include, generalization, and extension relationships. Workshops are an excellent way to involve the user. See: Use-Case Workshop
	Actors	The characteristics of human actors are captured as attributes of Actors. These include: - The actor’s scope of responsibility. - The physical environment in which the actor will be using the system. - The number of users represented by this actor. - The frequency with which the actor will use the system. - The actor’s level of domain knowledge. - The actor’s level of general computer experience. - General characteristics of the actors, such as level of expertise (education), social implications (language), and age.
	Use Cases	These can include essential use cases as described by Constantine [CON99] (see Concepts: User-Centered Design for a discussion of essential use cases). Specific usability requirements for a given use case may be captured as “Special Requirements” in the use case specification.
Detail the Software Requirements	Supplementary Specifications	The Supplementary Specifications capture requirements not specified in the use cases. This includes availability and performance requirements which may be closely tied to usability. General usability requirements applicable to multiple use cases are captured here, along with applicable legislation and usability standards (see Concepts: User-Centered Design for details on usability legislation and standards).
Manage Dependencies	Requirements Attributes	As use cases and usability requirements are “discovered”, their importance or benefit should be noted. This requires consultation with users and other stakeholders. Other attributes, such as the frequency a use case is executed, may also be captured in this artifact.
Review Requirements	Change Request	A user-centered development effort involves users as much as possible in all requirements reviews.
Capture a Common Vocabulary	Glossary	Captures common vocabulary terms specific to the users’ domain to facilitate communication and understanding between users and the rest of the development team.

There are some other techniques which may be useful additions to the above Requirements activities.

Affinity Diagramming [HOL96, BEY98] is a technique which each piece of information gathered about the users and their tasks is placed on a sticky note. The users and analysts collaborate to cluster related notes into conceptual groups or “affinities”. This activity helps promote a common understanding of the issues, their relative importance, and their relationships.
Card Sorting [CON99] is a similar activity where information on index cards is organized into groups. Cards can also be sorted by importance, frequency, and so on.
Hierarchical Task Modeling [MAY99, CON99] analyzes the tasks currently performed by users and organizes them into a hierarchy. The hierarchy should reflect how users currently understand the organization of their tasks.

Business Modeling

The Business Modeling Discipline involves understanding the business environment in which the users operate.

Activity	Business Modeling Artifacts	Usability Related Content
Set and Adjust Goals	Business Vision	Part of creating the Business Vision is identifying stakeholders. This includes the people that interact with the business (customers and vendors), as well as those who work in the business - many of which are or become users of automated systems. Similar to the Vision document in Requirements, the Business Vision Template captures a description of the business’s working environment and stakeholder characteristics, including their expertise, technical background, responsibilities, success criteria, deliverables etc.
Find Business Actors and Use Cases, Structure the Business Use-Case Model	Business Use Case Model	The Business Use Case model describes the tasks (business use cases) that human Business Actors perform. It capture similarities and relationships between Business Actors, using generalization relationships. The business use cases are structured and related to one another through generalization, extension, and association relationships.
	Business Actor	Human Business Actors are customers and/or vendors which interact with the business. These often are, or become, users of automated systems, and even when they do not correspond to users, an understanding of their characteristics provides a better understanding of the user environment. The Business Actor artifact includes the following attributes: - The actor’s scope of responsibility. - The physical environment in which the actor will be using the system. - The number of users represented by this actor. - The frequency with which the actor will use the system. - The actor’s level of domain knowledge. - The actor’s level of general computer experience. - General characteristics of the actors, such as level of expertise (education), social implications (language), and age See Guidelines: Business Actor.
	Business Use Case	The tasks performed by Business Actors are described by the Business Use Cases. These are typically free of technology assumptions and are goal-focused - thus they qualify as “essential” (see Concepts: User-Centered Design).
Find Business Workers and Entities	Business Analysis Model (Domain Model)	Business modeling is often used in a limited scope, referred to as Domain Modeling. A domain model captures the objects which are important in the domain, and therefore of interest and importance to users. See Business Analysis Modeling Workshop, Concepts: Scope of Business Modeling, and Workflow Detail: Develop a Domain Model.
Find Business Workers and Entities, Detail a Business Worker	Business Analysis Model (Business Worker)	The roles filled by people in the business are described by Business Workers. Attributes similar to those described above for Business Actor are captured. Since Business Workers are modeled as UML classes, generalization and association can be used to describe relationships between Business Workers. See Guidelines:Generalization in the Business Analysis Model and Guidelines: Association in the Business Analysis Model. The relationships between Actors, Business Actors and Business Workers is further discussed in Guideline: Going from Business Models to Systems.
Other	Other	Most of the other artifacts, including Business Glossary, Business Rules, and so on, contribute to an understanding of the business, and therefore the user’s environment.

Analysis and Design

A number of other activities in this discipline are focused on the shaping and design of the user-interface. These are:

Activity	Artifact	Usability Related Content
Design the User-Interface	Storyboard Navigation Map	This activity is creates what is often referred to as the Conceptual Design [FER01]. This is the initial abstraction of the user interface itself, capturing the main windows and navigation paths presented to the user. This activity focuses on use cases that drive the user interface design. Navigation Maps, see [CON99] give an overview of the navigational pathways between interaction spaces (screens, windows, and dialog boxes).
Prototype the User-Interface	User-Interface Prototype	You can make three basic kinds of prototypes: Drawings (on paper) Bitmaps (drawing tool) Executables (interactive) In most projects, you should use all three prototypes, in the order listed above. The main purpose of creating a user-interface prototype is to be able to expose and test both the functionality and the usability of the system before the real design and development starts. This way, you can ensure that you are building the right system, before you spend too much time and resources on development.

The following techniques may also be useful as part of designing the user interface:

Card Sorting [CON99], described previously, is also useful for designing the user interface. Each menu item or content item is represented by a card, and then the users organize the cards into logical groupings.

In addition to the activities described above, the following Analysis and Design activities are complementary to the designing of the user interface:

Activity	Artifact	Usability Related Content
Use-Case Analysis	Analysis Class, Use-Case Realization	Also see the following: - Guideline: Use-Case-Analysis Workshop - Concepts: Representing Graphical User-Interfaces
Class Design		This activity uses the results of the designing and prototyping of the user interface and designs the classes. Unlike the prototypes, this is not throwaway conceptual user interface work, but is intended to represent the design of the delivered system. Also see the following guidelines: Guidelines: Building Web Applications with the UML

Implementation

The implementation of the user interface follows the general Implementation Workflow. Note that implementation of the user interface is often done as part of the design activity.

Test

Usability testing, including usability-related performance testing, should be started as soon as there are mockups or executable prototypes of the user interface. Testing should include verification of usability and performance requirements captured in the Supplementary Specifications or as “Special Requirements” in the use case specification.

Deployment

Users should be heavily involved in Workflow Detail: Beta Test Product, as well as final Usability Testing during Workflow Detail: Manage Acceptance Test.

Workflow Detail: Develop Support Material includes development of training material and system support material to ensure that end users can successfully use the delivered software product.

Project Management

Project Management is the art of balancing competing objectives, managing risk, and overcoming constraints to successfully deliver a product which meets the needs of both customers (the payers of bills) and the users. From a usability engineering perspective, the most critical activity is Activity: Define Project Organization and Staffing. This activity defines the organizational structure, external interfaces, and roles and responsibilities. This includes defining the extent to which users will be involved in the development process, and determines whether the developers should be experienced with usability engineering methods.

Environment

The Environment discipline includes the definition of development process to be followed by a project or an organization. The Activity: Develop Development Case (Artifact: Development Case) defines which usability engineering techniques will be applied, and how the various RUP artifacts and activities will be tailored to incorporate these techniques.

Another important activity is Activity: Develop Project-Specific Guidelines which creates the Artifact: Project Guidelines that includes user-interface guidelines. These guidelines help ensure consistency of the user-interface, which can be a significant aid to usability. They also capture usability principles to be followed, such as guidelines for shortcuts, “undo” capabilities, recognizable exits, modeless interaction, and so on.

Iterative Development and Phases

The software lifecycle of the RUP is decomposed over time into four sequential phases, each concluded by a major milestone; each phase is essentially a span of time between two major milestones. At each phase-end an assessment is performed (Activity: Lifecycle Milestone Review) to determine whether the objectives of the phase have been met. A satisfactory assessment allows the project to move to the next phase.

Within each phase may be several iterations. An iteration is a complete development loop resulting in a release (internal or external) of an executable product, a subset of the final product under development, which grows incrementally from iteration to iteration to become the final system. Usability benefits greatly from this iterative approach. It allows users to provide early feedback on usability, and avoids heading too far down a path which simply won’t meet user needs.

The user should be involved in each iteration, to further refine requirements, to evaluate design concepts, and test/evaluate the usability of both proof-of-concept prototypes and the evolving system.

The following sections describe the usability-related phase completion criteria and the main activities for each phase.

Inception

Two key objectives of Inception Phase are:

Establishing the project’s software scope and boundary conditions, including an operational vision, acceptance criteria and what is intended to be in the product and what is not.
Discriminating the critical use cases of the system, the primary scenarios of operation that will drive the major design trade-offs.

From a usability engineering perspective, this means emphasizing Requirements and Business Modeling activities related to:

establishing an understanding of the users and their needs
identifying the use cases of greatest benefit to the users.

Inception phase is also often the time to explore some conceptual design and “proof of concept” prototyping. This is particularly true when the primary project risks are related to the user interface and usability concerns. Usability testing, including usability-related performance testing, should be started as soon as there are mockups or executable prototypes of the user interface.

Elaboration

As RUP is an iterative process, the artifacts created in Inception are revisited and reviewed with users in order to manage scope and ensure that the evolving system meets user needs.

In Elaboration, the focus is on the software architecture

including the architecture of the user interface. The conceptual user interface is defined, and the critical and/or risky elements of the user interface design are implemented. Activities related to the software architecture apply in general to the user interface - there are off-the-shelf products that must be evaluated, reuse considerations, selection of mechanisms and patterns, etc.

This phase emphasizes the user interface design activities, as well as supporting activities from the Analysis and Design discipline. Implementation and Test are also involved, since completion of Elaboration requires that a running system be constructed which can be evaluated.

Usability testing, and usability-related performance testing, should focus on any risky requirements captured in the Supplementary Specifications or as “Special Requirements” in the use case specification.

Construction

In Construction, the focus is on implementing more use cases. This involves adding to the user interface, while remaining true to the conceptual model of the user interface and user-interface guidelines captured in the Project-Specific Guidelines. Usability Testing continues to be very important as new features are added.

The selection of what functionality to place in each iteration is based on value to users.

Transition

The focus in Transition phase starts to shift towards the Deployment discipline. In a user-centered development effort, you shouldn’t wait until Transition phase to involve the user. However, the user continues to be involved, primarily to give feedback. When the user has been involved throughout the development, formal beta and acceptance testing is often significantly minimized or non-existent. Instead, detailed user feedback and approval occurs throughout the development effort.

Development of training material and system support material is finalized in Transition, but it should be started in earlier phases, if possible, in order to allow user feedback.

In Transition, there is a working system that can be used by end-users. It is a good idea to plan at least a couple of iterations during transition, so that problems with the initial release can be corrected, and so that key user feedback can be incorporated.

Scenario: A Small Project Adopts RUP

Topics

[Project Overview](#Project Overview)
General Tailoring
Roles and Lifecycle
Review

Project Overview

The following describes a scenario for a project of ABC Company, called Project X. Project X is a team consisting of a project manager, Jill, and four programmers, Angus, David, Susan, and Philip. The duration of the project is four months.

Jill is considering using the RUP as the basis for her project’s software development process. She installs the RUP, which by default installs the “Classic RUP” process configuration. She reviews the parts of Classic RUP relevant to tailoring a process for a project.

She begins by evaluating the process needs for the project, in consultation with the team. Her conclusions are as follows.

The existing process and tools for configuration management are working well, so this aspect of the process can remain unchanged.
The team has some experience with use cases and component architectures, but could use more guidance in these areas.
The project would benefit from an iterative development approach, as a means of quickly driving down key project risks.
The stakeholders have good informal working relationships with the development team, and there is no need for formal contracts or reviews. The stakeholders have ongoing visibility during development. The team is highly skilled and disciplined, and has shown in the past to produce quality products without much formal process.
Given the short time-frame of the project, only minor changes will be made to the toolset.
A separate parallel activity will be initiated to investigate tool benefits, re-use opportunities, and to further refine the process for future projects.

Jill then takes on the task of tailoring an appropriate process for the team to follow.

General Tailoring

Jill launches RUP builder and selects the the Small Project template configuration as a starting point. She selects and de-selects some components and plug-ins to perform a coarse configuration of the process. For example, she de-selects the process component “Database Design”, as the team does not intend to do any data modeling on this project.

The resulting process is reasonably close to what the project needs, but not quite. Jill refines the process further by adding project-specific pages to the process views, including:

guidelines for the tools to be used on the project
guidelines re-used from a previous similar project, including Design Guidelines and Configuration and Change Management Guidelines
guidelines for review and assessment.

She adds an “Introduction to the Process X Process” page to the Getting Started view, where she describes the basic philosophy of the configured process. For example, she states that the included templates are intended to guide content, but the format is optional. She also indicates where current versions of key project artifacts will be located.

She then saves the configuration as “ABC Project X”, and publishes it.

Roles and Lifecycle

Project X has a small team, so each person is responsible for a variety of RUP roles. Jill describes each person’s reponsibilities in the Software Development Plan. For example, on Project X, Jill is responsible for the Project Manager and Process Engineer roles.

She also describes the lifecycle of the project in the Software Development Plan, including the phases, iterations, and key milestones.

Review

Jill provides a draft of the configured RUP, Development Case, and Software Development Plan to the team and other stakeholders for review. The team begins to follow the process. Some mistakes are made, and the process is refined. In the end, the project is successful, and the team has an appropriately tuned process that can be applied on future projects.

Conceptual Road Maps

The following concepts provide a view into the Rational Unified Process (RUP), in its Classic process configuration, taken from a particular technology or stakeholder perspective. These walkthroughs of the process content are generally used as a familiarization tool.

Developing Component Solutions
Developing e-business Solutions
Usability Engineering
Tailoring a Process for a Small Project
Agile Practices and RUP

Microsoft Project Templates: Construction Iteration

The generic project plan (at the workflow detail level) used for the illustration of a Construction Iteration in the description of Phases may be found at:

Project Plan Template (Workflow Detail Level) for MicrosoftProject98.

A more detailed plan, which goes to the activity level, may be found at:

Project Plan Template (Activity Level) for MicrosoftProject98.

This template is provided by courtesy of Ensemble Systems Inc.

These plans have the tasks hyperlinked to the corresponding Rational Unified Process (RUP) activity. By default, the hyperlink base in the files assumes that the RUP will be installed at:

C:\Program Files\Rational\RationalUnifiedProcess\

If you install the RUP elsewhere, then you must change the base directory in each of the Microsoft Project files for the hyperlinks to work. Do this by opening the project file with Microsoft Project, then under File|Properties|Summary tab|Hyperlink base, enter the directory you are using for installation of the RUP.

Link to Ensemble Systems

Project Plan Template (Workflow Detail Level) for MicrosoftProject98.

Microsoft Project Templates: Elaboration Iteration

The generic project plan (at the workflow detail level) used for the illustration of an Elaboration Iteration in the description of Phases may be found at:

A more detailed plan, which goes to the activity level, may be found at:

Project Plan Template (Activity Level) for MicrosoftProject98. This template is provided by courtesy of Ensemble Systems Inc.

These plans have the tasks hyperlinked to the corresponding Rational Unified Process (RUP) activity. By default, the hyperlink base in the files assumes that the RUP will be installed at:

C:\Program Files\Rational\RationalUnifiedProcess\

Link to Ensemble Systems

Project Plan Template (Workflow Detail Level) for MicrosoftProject98.

Microsoft Project Templates: Inception Iteration

The generic project plan (at the workflow detail level) used for the illustration of an Inception Iteration in the description of Phases may be found at:

A more detailed plan, which goes to the activity level, may be found at:

Project Plan Template (Activity Level) for MicrosoftProject98. This template is provided by courtesy of Ensemble Systems Inc.

These plans have the tasks hyperlinked to the corresponding Rational Unified Process (RUP) activity. By default, the hyperlink base in the files assumes that the RUP will be installed at:

C:\Program Files\Rational\RationalUnifiedProcess\

Link to Ensemble Systems

Project Plan Template (Workflow Detail Level) for MicrosoftProject98.

Microsoft Project Templates: Transition Iteration

The generic project plan (at the workflow detail level) used for the illustration of a Transition Iteration in the description of Phases may be found at:

A more detailed plan, which goes to the activity level, may be found at:

Project Plan Template (Activity Level) for MicrosoftProject98. This template is provided by courtesy of Ensemble Systems Inc.

These plans have the tasks hyperlinked to the corresponding Rational Unified Process (RUP) activity. By default, the hyperlink base in the files assumes that the RUP will be installed at:

C:\Program Files\Rational\RationalUnifiedProcess\

Ensemble Systems Link