架构层面的需求分析

一、业务用例的分析
不论是预测性过程还是敏捷过程，需求都是从了解业务开始的，并且在建立业务模型的
过程中发现和挖掘需求。建立业务模型首先是建立业务上下文图，也就是业务范围看成一个
黑箱，表示所有相邻系统与业务范围的数据交互关系。例如我们需要了解一个“道路除冰工
作系统”，我们可以把上下文图绘制如下。
我们知道，在任何情况下，图形都没有办法表达细节，但更容易表达关系。为了更精确
的描述外部系统与系统之间数据流动关系，需要通过表格仔细列出每一个参与者与系统之间
的数据流动，下表列出了这样的数据流清单。
道路除冰系统数据流
编号 参与者 输入数据流 输出数据流
1 气象站 气象站读数
2 气象预报服务 区域气象报告
3 热像图提供者 热像图
改变的道路
新的气象站
改变的气象站
4 道路工程部门
失效的气象站告警
卡车改变 修订的除冰调度计划
道路除冰调度计划
已处理的道路
卡车故障 修订的除冰调度计划
5 卡车车库
对没有处理的道路进行提醒
然后，我们通过研究相邻系统与业务的数据交互，发现业务事件，然后列出一个业务事件清
单，下表列出了这样的事件清单。
道路除冰系统事件清单
编号 事件名称 输入数据流 输出数据流
1 气象站传送数据 气象站读数
2 气象局预报天气 区域气象报告
3 道路工程师通知改变的道路 改变的道路
4 道路工程师安装了新的气象站 新的气象站
5 道路工程师改变了气象站 改变的气象站
6 到了测试气象站的时间 失效的气象站告警
7 卡车车库改变了卡车 卡车改变 修订的除冰调度计划
8 到了检查结冰道路的时间 道路除冰调度计划
9 卡车处理了一条道路 已处理的道路
10 卡车车库报告卡车出问题 卡车故障 修订的除冰调度计划
11 到了监控道路除冰的时间 对没有处理的道路进行提醒
针对每个业务事件，有一个预先计划的对它的响应，被称之为“业务用例”。业务用例
总是包含着一些可识别的过程，一些被存储的数据，产生一些输出，发送一些消息，或者是
这些事件的组合。也就是说业务用例是一个功能单元，这些功能是编写功能需求与非功能需
求的基础。
业务用例是方便研究的组合，可以把业务用例的工作相互隔离开来，因为它与其它业务
基本上没有联系，因此不同的分析师可以调研不同的部分，不需要彼此之间一直保持沟通。
实际上业务用例之间唯一的重合是它们之间存储的数据。
每个业务用例的相互隔离意味着可以找到一个或者多个这方面工作的专家，他们在您的
帮助下可以准确而且详尽的描述这部分工作。可以描述正常情况（计划中的状态），也可以
描述异常情况（偏离计划的状态）及其处理办法。它们可以描述组织是如何相应业务事件的。
一个业务用例的处理应该是连续的，也就是说一个业务用例被触发以后，它将处理所有的事
情，直到从逻辑上说无事可做为止（所有的功能都被执行、所有该存储的数据都已经存储、
所有的相邻系统都已经得到通知），下图就是一个处理的例子。



二、产品边界的确定
当对工作有了比较深入而且条理化的理解之后，就可以思考“产品应该是怎样的？”这
样一个问题了。遗憾的是许多项目开始的时候都有关于“产品应该是什么”的先入为主的概
念，但不理解产品将成为其工作的一部分。这里我们看看为了发现优化的产品，我们可以做
些什么？
产品分析很重要的一项任务，就是确定工作将来应该是怎样的，以及产品是怎样才能对
工作产生最大的帮助。产品是工作的一部分，工作是打算以某种程度改变的东西（通常是把
它自动化），目标是找到优化的业务用例。
思考“产品应该是怎样的？”的直接结果，是最终确定产品的边界。在与风险承担者也
进行了深入的交流以后，我们需要最终确定当前产品的边界并把它固定下来，否则产品将无
法进入真正的设计，另一方面，最后确定的边界，也是作为下一步进行产品建模的必要输入。
在确定边界的时候，我们需要进行一些创新的思考，例如：从顾客的角度，能不能使这个事
情变得更方便呢？从方便和服务的角度来说（站在顾客的角度），还有没有更好的想法呢？
从提供服务来保持顾客的忠诚度来说（站在销售公司的角度），某种想法是不更好呢？如果
是，那我们的业务会做些什么样的改变呢？继续深入的思维和研究，可能会创造出更好的产
品。


三、业务用例与产品用例
我们已经强调了理解工作，而不是理解产品的重要性。通过查看更大范围的工作，可以
对业务需求提出更多的问题并且构建出更好的产品。研究业务用例，我们主要考虑的是工作
要做哪些事情，相邻系统的期望和预期的结果。而产品用例，指的是建议的自动化产品所需
要作出的响应。
在确定产品用例的时候，也是在选择与产品交互的参与者，精良的产品用例分析可以给
后期工作带来巨大的好处，事实上引发了基于用例的开发这样一种概念。除了上面列出这一
些，还可以在很多地方享受产品用例带来的好处：
它提供了一种手段，用于发现一些相关的需求并进行分组。
可以通过产品用例来计划实现版本。
测试人员可以把产品用例作为编写测试用例的输入信息。
产品用例为构建模拟原型提供了业务上的基础。
能够更早的响应变更，因为产品用例可以追踪到业务用例，然后追踪到业务事件。
在前期分析中，主要是在抽象层面构造用例模型，关注的是产品用例之间的关系，建立
一个产品整体的图像，而不是对每个用例进行详细描述。在进入迭代过程之后，才必须对选
中的用例（或者用户描述）进行详细的分析和描述，从而进入完整的开发过程。