Revision History

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

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

2.3.4 Reports

[This section lists the reports to be used. Additional ‘local’ reports can be added to the table as needed.]

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

3.1.3 Notes on the Artifacts

3.1.4 Reports

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

3.2.3 Notes on the Artifacts

3.2.4 Reports

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

3.3.3 Notes on the Artifacts

3.3.4 Reports

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

3.4.3 Notes on the Artifacts

3.4.4 Reports

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

3.5.3 Notes on the Artifacts

3.5.4 Reports

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

3.6.3 Notes on the Artifacts

3.6.4 Reports

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

3.7.3 Notes on the Artifacts

3.7.4 Reports

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

3.8.3 Notes on the Artifacts

3.8.4 Reports

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

3.9.3 Notes on the Artifacts

3.9.4 Reports

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