<Project Name>
Requirements Management Plan
<o:p> </o:p>
Version <1.0><o:p></o:p>
<o:p> </o:p>
<o:p> </o:p>
[Note: The following template is provided for use with the Rational Unified Process. Text enclosed in square brackets and displayed in blue italics (style=InfoBlue) is included to provide guidance to the author and should be deleted before publishing the document. A paragraph entered following this style will automatically be set to normal (style=Body Text).]
[To customize automatic fields in Microsoft Word (which display a gray background when selected), select File>Properties and replace the Title, Subject and Company fields with the appropriate information for this document. After closing the dialog, automatic fields may be updated throughout the document by selecting Edit>Select All (or Ctrl-A) and pressing F9, or simply click on the field and press F9. This must be done separately for Headers and Footers. Alt-F9 will toggle between displaying the field names and the field contents. See Word help for more information on working with fields.]
Revision History
Date<o:p></o:p> |
Version<o:p></o:p> |
Description<o:p></o:p> |
Author<o:p></o:p> |
<dd/mmm/yy> |
<x.x> |
<details> |
<name> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p> |
<o:p> </o:p>
Table of Contents
<!---->1. Introduction <!---->2<!----><!----><o:p></o:p>
1.1 Purpose <!---->2<!----><!----><o:p></o:p>
1.2 Scope <!---->2<!----><!----><o:p></o:p>
1.3 Definitions, Acronyms, and Abbreviations <!---->2<!----><!----><o:p></o:p>
1.4 References <!---->2<!----><!----><o:p></o:p>
1.5 Overview <!---->2<!----><!----><o:p></o:p>
2. Requirements Management <!---->2<!----><!----><o:p></o:p>
2.1 Organization, Responsibilities, and Interfaces <!---->2<!----><!----><o:p></o:p>
2.2 Tools, Environment, and Infrastructure <!---->2<!----><!----><o:p></o:p>
3. The Requirements Management Program <!---->2<!----><!----><o:p></o:p>
3.1 Requirements Identification <!---->2<!----><!----><o:p></o:p>
3.2 Traceability <!---->2<!----><!----><o:p></o:p>
3.2.1 Criteria for <traceability item> <!---->2<!----><!----><o:p></o:p>
3.3 Attributes <!---->2<!----><!----><o:p></o:p>
3.3.1 Attributes for <traceability item> <!---->2<!----><!----><o:p></o:p>
3.4 Reports and Measures <!---->2<!----><!----><o:p></o:p>
3.5 Requirements Change Management <!---->2<!----><!----><o:p></o:p>
3.5.1 Change Request Processing and Approval <!---->2<!----><!----><o:p></o:p>
3.5.2 Change Control Board (CCB) <!---->2<!----><!----><o:p></o:p>
3.5.3 Project Baselines <!---->2<!----><!----><o:p></o:p>
3.6 Workflows and Activities <!---->2<!----><!----><o:p></o:p>
4. Milestones <!---->2<!----><!----><o:p></o:p>
5. Training and Resources <!---->2<!----><!----><o:p></o:p>
<!---->
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 provides a complete list of all documents referenced elsewhere in the Requirements 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 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 in order to keep track of the dependencies between them. With respect to Rational Requisite Pro, 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.]
<o:p> </o:p>
Artifact<o:p></o:p> (Document Type) |
Traceability Item<o:p></o:p> |
Description<o:p></o:p> |
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.]
相关推荐
银行业的应用 17<br>界面设计指导原则 19<br>论开放系统应用的互操作性 20<br>基于RUP的软件过程及应用 20<br>长春经济技术开发区的网络安全建设 25<br>基于 B/S 结构的电子政务信息系统的研究与开发 29<br>基于J2EE...
object-package.ppt<br>4e-05状态-活动-构件-配置图.ppt<br>4e-06Web建模.ppt<br>4e-07Rose开发工具.ppt<br>4e-08UML与设计模式.ppt<br>4e-09UML常见问题分析.ppt<br>4e-10面向对象实现技术.ppt<br>4e-11RUP.ppt
5.1.1 <用例名> 4 6. 逻辑视图 6 6.1 对架构重要的模型元素 6 6.1.1 <类名> 6 6.1.2 <包名> 6 6.2 架构视图 – 包和子系统分层 6 6.2.1 <类名> 7 6.2.2 <包名> 7 7. 进程视图 7 7.1 <类图名> 8 7.1.1 <进程元素名> 8...
现在RUP如日中天,需求分析是第一步,可以看作是高级系统分析员的必备知识,那么,如果用面向对象的分析技术来描述需求呢?你还在为怎么建模而烦吗?你还不知道如果开始您的系统用例分析吗?那么强烈建议您看看这本...
在RUP的"ATLAS TDAQ <sub-group> <component> Requirements"模板中,我们可以看到以下关键组成部分: 1. **文档信息**:包括文档版本(如1.0)、文档ID(ATLAS-TDAQ-2002-XXX)、日期和状态(草案或最终)。这些...
一个rup协议,能解决如下问题: <br>1. lost; never delivered <br>2. partially destroyed (data corruption) <br>3. delivered out of order <br>4. duplicated <br>参看...
### Rational Unified Process (RUP) 最佳实践 #### 什么是Rational Unified Process (RUP)? Rational Unified Process(简称RUP)是一种软件工程过程,它为软件开发团队提供了一个结构化的方法来指导整个软件开发...
后续的,总共3部分的!<br>
2. 包图是用来组织和管理系统的组件,关系包括`<<use>>`(使用)、`<<access>>`(访问)、`<<trace>>`(跟踪),不包括`<<stub>>`。 3. 类图中,继承关系通常用带空心箭头的实线表示,选项C符合描述。 4. 类图中,...
软件开发过程产生的背景 <br/>软件开发过程是什么<br/>RUP是什么 <br/>ISO9001是什么<br/>CMM是什么 <br/>UML是什么<br/>XP是什么 <br/>软件开发过程的比较<br/>测试在软件开发过程中的地位<br/>
在包图中,存在多种关系,如`<<use>>`、`<<access>>`和`<<trace>>`,但不包括`<<stub>>`(D)。`<<stub>>`通常与代理模式相关,而不是包之间的关系。 #### 3. 类图中的继承关系 类图是UML中最常用的图之一,用于描述...
RUP模板,为开发者努力此文档的目的是收集、分析和定义<<系统名>>的高层次需求和特性。它侧重于涉众和目标用户所需的功能以及这些需要存在的原因。<<系统名>>如何满足这些需要的详细情况记录在用例和补充规约中。
2. **包图中的关系**:包图中的关系有`<<use>>`(使用)、`<<access>>`(访问)和`<<trace>>`(追踪),但没有`<<stub>>`。 3. **继承关系的表示**:在类图中,继承关系通常由一个空心的三角形指向基类,表示子类...
<1>管理员类型:安装管理控制台,管理工具,网络服务,使用程序,和基本的客户端软件。 <2>运行时类型:只安装应用开发程序,网络服务,基本客户软件 <3>自定义:自己决定的组件安装。 (4) Oracle ...
每个特征通常表述为<行动><结果><对象>的形式,便于理解和实施。 在实际应用中,考虑到上手难度和理论成熟度,本文作者选择了用例分析技术作为首选实践。用例分析技术由Ivar Jacobson在1967年提出,其核心是用例...
总的来说,"RUP课件中英文版本.7z"提供了全面的RUP学习资源,无论你是初学者还是经验丰富的开发者,都能从中受益。通过系统地学习和应用RUP,你可以更好地掌握软件开发的全过程,从而提高你的专业素养和项目成功率。
**RUP(Rational Unified Process)模板详解** RUP,全称为 Rational Unified Process,是由IBM公司开发的一种软件开发过程框架,它提供了一种结构化的方法来管理软件开发生命周期中的各个阶段。RUP模板是RUP过程的...
这是以软件工程导论(第四版)张海藩为教材的上海交通大学课件,还添加了RUP\类与类图\基于用例的需求分析等.
RUP(Rational Unified Process)是一种广泛使用的软件开发过程框架,由IBM的Rational公司开发。RUP的核心概念包括了软件开发过程中多个关键元素及其相互关系。本文将深入解析RUP的一些关键概念,以帮助读者更好地...
[TF2]比赛控制允许在tf2的比赛模式中强行准备/未读或强制重命名团队用法: sm_rup / sm_unrup <red> -准备就绪/未就绪选择的团队。 sm_renameteam / sm_renameteams <red> <teamname>团队名称sm_renameteam / sm_...