第三章. 需求捕获

第三章. 需求捕获

N 查看原文

上一页

第一部分. ArgoUML指南

下一页

---

第三章. 需求捕获

目录

3.1. 简介

3.2. 需求捕获过程

3.2.1. 过程步骤

3.3. 需求捕获过程的产物

3.3.1. 说明文档

3.3.2. 用例图

3.3.3. 用例说明书

3.3.4. 需求补充说明书

3.4. 在ArgoUML中使用用例

3.4.1. 参与者

3.4.2. 用例

3.4.3. 联系

3.4.4. 层次化用例

3.4.5. 原型

3.4.6. 文档

3.4.7. 系统边界盒

3.5. 用例研究

3.5.1. 说明文档

3.5.2. 区分参与者和用例

3.5.3. 联系（未完成）

3.5.4. 高级图表特性（未完成）

3.5.5. 用例说明书（未完成）

3.5.6. 需求补充说明书（未完成）

3.1. 简介

需求捕获是寻找“客户”希望系统应具备的功能的过程。

这一步的关键是我们正处在问题定义阶段。在这一阶段我们必须从“客户”的角度，用“客户”的语言描述所有的东西。

在需求捕获过程中最大的错误是马上开始考虑各种可能的解决方案。解决方案的设计应该等到分析阶段（见 第四章, 分析）完成之后才开始进行。分析阶段其中的步骤之一就是利用需求阶段产生的结果并且用可能的解决方案来重新设计这些结果。

请记住我们使用的全部是不断递增的可迭代的处理过程。[译者注：即进化模型]

当我们把问题分解成更小的部分时，我们还可能再次回到需求捕获过程，每一个小问题也需要各自的需求捕获。

由于我们试图为系统定义越来越多的需求，所以我们也需要在每一次迭代时返回到需求捕获阶段。

	注
	UML标准规定用例图是在需求阶段中使用到的唯一图示。其余的图示在“过程”中使用。本章中的“过程”主要指“Rational统一过程”。[译者注：由Rantional公司制定的一套标准，被称为Rational Unified Process]

---

上一页 2.6. 案例研究

返回本部分目录 返回用户手册目录

下一页 3.2. 需求捕获过程

[译者注：本章节对应着国内软件工程中的“需求分析”，在翻译过程中对于是使用“需求捕获”还是直接使用“需求分析”考虑再三，最终决定使用前者。因为“捕获”更能体现出原文对这一过程的描述，由原文不难看出作者认为这一过程的主要目的和工作就是忠实地反映客户的需求而非分析为什么有这样的需求或这样需求的作用等，所以，使用“捕获”更为准确一些。]

---