Artifacts >
Project Management Artifact Set >
Business Case >
rup_buscs.htm
Artifacts >
Project Management Artifact Set >
Business Case >
rup_buscs.htm
<Project Name>
Business Case
Version <1.0>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
Revision History
|
Date |
Version |
Description |
Author |
|
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Table of Contents
1.3 Definitions, Acronyms and Abbreviations
Business Case
[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.]
[Specify the purpose of this Business Case.]
[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.]
[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.]
[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.]
[This subsection should describe what the rest of the Business Case contains and explain how the document is organized.]
[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.]
[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.]
[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.]
[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.]
[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.]