http://fangang.iteye.com/blog/1506403
需求捕获主要的方法: 功能角色分析、业务流程分析与业务领域分析。 之前一篇介绍了功能角色分析(用户角度从整理上分模块,分析主要功能,给哪些人用),业务流程分析(分析具体功能是如何流转,如何被使用的)
除了最终的需求规格文档,中间的产物,可能是纸上随手乱花的,乱花的专业点就叫用例说明(UML图的一种)
用例说明
- 当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。过去，在面向过程的时代，我们绘制DFD图、流程图，以及编写流程说明来描绘这一部分分析；而现在，在面向对象的时代，我们则是绘制行动图、状态图，以及编写用例说明来完成这部分工作。
- 图形的最大优势是能够形象生动地描述我们的分析，但它最大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。
- 用例标识：就是用例的编号，一般采用“项目编号-子系统编号-模块编号-序号”来编号
- 用例名称：就是用例图中该用例的名称。注意用例的命名规则：用例名称通常是一个动词短语或短句，而不是一个名词短语。
- 用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使用进行描述。
- 参与者：用例图中该用例的参与者，通常是业务操作的触发者和施与对象（如外部系统）。
- 触发事件：谁干了什么，触发了这个用例。
- 前置条件：在触发该用例相关操作前必须达到的条件。
- 后置条件：又称为“成功保证”，就是执行基本流程获得成功以后所达到的状态（条件）。后置条件往往体现的是执行该用例的最终目的。如：完成用户档案的填写并提交。
- 假设与约束：就是隐藏于业务功能中的各项规则与条件，如各种逻辑条件、计算公式、环境限制等等。
- 非功能需求：简称为“URPS+”，即可用性（Usability）、可靠性（Reliability）、性能（Performance）、可支持性（Supportability）以及其它（+）。这一部分的需求分析相当重要而又最容易被忽略，后面我们再详细讨论。
- 事件流：这是用例说明中最重要的部分，它详细描述了该用例可能出现的所有流程。
- 1.基本流程：另一个名称更能表达它的意义：最佳流程（The Best Flow）。它描述的是该用例以最佳的、最正常的方式流转，没有出现任何异常，并且最终成功完成操作的流程。基本流程在编写时，应当通过数字对流程中的每一步进行编号。
- 扩展流程：或者叫“分支流程”，它描述的是基本流程在流转过程中可能出现的所有分支。扩展流程最大的特点就是，它应当是在基本流程的某一步骤发生的分支，因此它的编号规则是“基本流程号+序号”。基本流程号就是发生分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时，它们的序号从1依次开始编号。 另一种情况是，某个扩展流程本身拥有多个步骤，这时应当在“基本流程号+自身序号”的基础上再添加序号，如“2.1.1”。 扩展流程在描述时，应当首先描述进入这个分支的条件，即“如果××则××”、“当××时××”。
- 异常流程：就是发生异常情况时的处理流程。注意，用例说明是站在用例角度进行的说明，因此这里并不是我们通常一样的发生程序异常的处理流程，而是用户在处理业务操作时发生的异常情况，如：如果顾客不能提供身份证，则••••••
- 我还往往在每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。
查询报表分析
- 那些查询、汇总与报表功能。对于这部分功能，需要我们描述的不是什么操作流程，而更重要的是那些数据项、数据来源、报表格式、数据链接，以及使用者、使用频率的说明。
- 报表作用：就是描述参与者使用这个报表做什么。如果有多个参与者，每一个都应当描述。
- 报表内容：用简短的话描述一下。
- 输出列：罗列报表的输出列，如果需要的话，还应对输出列进行说明，或描述它的数据来源。
- 使用频率：参与者使用它的频率，便于设计者考虑报表的查询效率。
- 数据链接：哪些数据项有链接，链接到什么报表，或显示什么数据。
- 最后依然是那个需求列表，便于业务需求的跟踪。
- 一个有效的报表，往往不是对数字的简单堆砌，它通过一组一组的数据，揭示的都是一些客观规律、复杂活动与发展趋势。客户方的领导，特别是那些中层和高层领导，通过对这些报表的阅读，就可以掌握他们的工作进程、加强他们的人员管理、发现他们的管理漏洞、指导他们的战略决策。总之一句话，每个报表都有他们的设计意图。
- 没有弄清楚一个报表的真实意图，就不算真正理解了这个报表的业务需求。 报表的数据项应当都是来源与系统中各项操作的结果数据。许多业务系统的操作流程都是纷繁复杂的，其中还包括各种情况。更复杂的，一些商业智能与分析决策系统，报表所需的各种数据，甚至来源与各种各样的外部系统。
- 分析一个报表的数据来源，就是在梳理各种业务流、数据流，以及各种数据间的关系。如果这方面的分析不到位，最终设计出来的报表往往是不准确的。报表的数据项应当都是来源与系统中各项操作的结果数据。许多业务系统的操作流程都是纷繁复杂的，其中还包括各种情况。更复杂的，一些商业智能与分析决策系统，报表所需的各种数据，甚至来源与各种各样的外部系统。
- 用户使用报表的频率，常常决定了报表设计的方式。如果报表中的数据总是在实时变化，并且用户总是在密切关注这些数据的变化，那么报表必须设计成实时查询的
- 一个报表的核心就是展现给客户的报表格式，以及报表与报表间的各种链接。需求人员在进行需求分析阶段，应当准确地与客户敲定这些格式，并最终在用例说明中体现出来。
- 报表作用体现的是报表对于不同用户的真实意图；输出列体现的是对各个数据项及其数据来源的说明；假设与约束罗列的是报表中各个数据项的运算公式、数据规则与约束；还有使用频率、数据链接、非功能需求，以及最后的界面原型，等等。只要我们把这些都分析到了，我们的查询报表就分析到位了。
子用例与扩展用例
- 用例模型将现实世界中连续的一个一个业务流程，按照场景划分到了一个一个的用例中。
- 同时，在用例分析中，又将那些存在于各个用例中的，相同或相近的业务操作提取出来，形成一个一个的子用例或扩展用例，又体现了面向对象设计中的复用性。
- 基本流程就是所有步骤都非常理想地正确执行，并最终完成所有操作的那个“最佳流程”。在基本流程中，可能有些步骤是多个用例都共有的，可以相互共享的流程。将这部分流程提取出来形成的就是子用例。
- 子用例应当是在逻辑上相对独立的一系统流程组成的用例。这个用例应当是抽象的，没有自己的参与者，只有在调用它的用例中，才能真正明确它的使用者。
- 扩展流和异常流中的流程如果相对独立、可以为其它流程所共享，则可以提取出来，形成一个单独的用例，叫扩展用例。
行动图和状态图
- 用例图，无疑是功能分析、角色分析，以及流程分析的利器，它将我们要开发的系统，清晰而详尽地描述出来。不利的一面集中体现在两个方面：只见树木不见森林、不生动形象。
- 行动图（Active Diagram），比较类似于我们过去绘制的流程图，是UML中描述流程与分支的视图。在行动图中，往往是从一个实心圆的起始节点开始的。最频繁使用的则是活动节点了，它表示的是业务流程中的一项活动。活动节点可以表述为一个活动短语（如下订单），可以表述为一个表达式（如len=a.length+x），还可以表述为一个消息（如send(msg)）。同时，将各个活动节点连接起来的一个个实线箭头，表明了各种活动之间的流转顺序。
- 在行动图中，分支用一个菱形来表示。一个指向菱形的箭头，表示流程进入分支，另外两个或多个从菱形伸出的箭头，则表示不同条件下的分支流。而菱形本身，则表示为一个条件判断语句。
- 分岔，表示在某个时间点上，同时开始两个业务流程，这两个业务流程是同步进行的。分岔用一个入箭头，一根横杠，与两个出箭头表示。汇合，则表示，只有在两个流程都完成的情况下，才会进入下一流程，否则只能等待。
- 最后，用一个或多个带环的实心圆，表示的是活动图的终止节点，代表了业务流程的终结。
- 使用状态图时，一个非常关键的概念就是，一定是对某个关键对象的状态变化的描述，而这些状态变化一定是在某个业务流程的大背景下进行的。