3.2. 需求捕获流程

最新推荐文章于 2023-04-11 22:02:19 发布

翻译最新推荐文章于 2023-04-11 22:02:19 发布 · 3.3k 阅读

文章标签：

#活动 #文档

ArgoUML用户手册中文版专栏收录该内容

4 篇文章

订阅专栏

博客围绕自动柜员机系统（ATM）需求捕获展开。先介绍要在说明文档描述问题及解决方案特性，找出用例和参与者并展示关系，详细说明用例。还提及用例拆分、数量规则，总结需求捕获流程步骤，强调客户参与需求捕获的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

3.2. 需求捕获流程

N 查看原文

第三章. 需求捕获

3.2. 需求捕获流程

开始的时候，我们要先全面地看一下我们要解决的问题，考虑一下在任何解决方案中都应该有的关键功能。这是我们的说明文档，可能会有几页长。

例如自动柜员机系统（ATM）应该提供以下功能。
1. 客户现金的存取和帐户查询。
2. 接受银行工程师对设备的维护以及当地银行分支机构对其内部现金和存款的管理。
3. 审核所有发往银行主机的活动。

从这个角度我们分析出了系统的基本活动以及涉及这些活动的系统外部元素（人，设备）。这些活动被称为用例，外部元素被称为参与者。

参与者可能是人或者机器。从某个角度来说，应该找出在机器后边的那些人，因为只有他们会关注需求捕获。

用例应该反映系统的主要活动。例如用户使用ATM就是一个用例而用户输入个人信息代码（PIN）就不是。

有时这样做有一些困难，所以我们看到把大的用例分成较小的子用例是很有用的。比如我们可能有关于存款、取款和帐户查询的几个用例。

没有一个严格的和快速的规则。一些系统结构师喜欢用少量的彼此关联的大型用例；另一些人喜欢用大量的小型用例。对于任何一个特定的项目来说一个有用的规则是用例数不应该超过30个（如果需要更多的用例，那么就应该把项目拆开来做）。

接下来我们要在一个或多个用例图上展示用例和参与者之间的关系。对一个大型项目来说可能需要不止一个用例。通常把彼此有关系的一组用例显示在一张图上。

我们必须针对每一个用例给出一个详细的说明。这些说明包括用例的正常行为，可选行为以及前约束和后约束条件。所有这些都包含在被称为用例说明书或用例策略的文档中。

3.2.1 流程步骤
需求捕获流程的步骤可以总结如下：
1. 在说明文档中描述问题的概况，描述其解决方案应有的特性。
2. 找出用例和参与者，并在用例图中显示它们之间的关系。
3. 对用例加以详细说明，包括常态行为，可选行为，前约束和后约束条件。
4. 在需求补充说明书中描述所有非功能性的需求。
在渐进的开发过程中，我们会根据用例的重要程度来选择处理用例的顺序。早期的过程会着重于捕获重要用例的关键行为。

大部分的关于需求捕获的现代理论都认同在需求捕获过程中让客户参与是什么重要的。