怎样做需求分析之十：分析之用例说明

《怎样做需求分析之十：分析之用例说明》由会员上传分享，免费在线阅读，更多相关内容在工程资料-天天文库。

1、怎样做需求分析之十：分析之用例说明作者:fangang发布时间:2012-04-1022:30当我们进行业务流程分析时，只空对空而不落到纸面上是不可以的。过去，在1侨向过程的时代，我们绘制DFD图、流程图，以及编写流程说明來描绘这一部分分析；而现在，在面向对彖的时代，我们则是绘制行动图、状态图，以及编写用例说明來完成这部分工作。在这部分工作中，编写用例说明应当是最主要的工作，Z后在一些关键部分辅Z以行动图、状态图。现在我们來看看用例说明应当怎样编写。用例标识用例名称创建人创建曰期版本用例类型用例描述参

2、与者触发事件前置条件亳不疑问，做用例分析首先是要绘制出用例图（IT血已经说过了）。图形的最大优势是能够形彖生动地描述我们的分析，但它授大的缺点是会遗失许多的细节信息，因此我们必须要对它进行进一步的文字描述。事件流基本流程扩展流程畀常流程后置条件假设与约束非功能需求补充规格说明书优先级前置条件业勢需求列表创建人版本描述创建日期由于不同的人对用例的理解不同，格式也不尽相同，但一些基木的元素是一样的。以上表格是我采用的用例说明格式，其中用例名称、用例描述、参与者、前置条件、事件流、后置条件是公认的、用例说明

3、的基木元素。用例标识：就是用例的编号，i般采用“项目编号■子系统编号■模块编号■序号”來编号。用例名称：没啥町说的，就是用例图屮该用例的名称。注意用例的命名规则：丿IJ例名称通常是一个动词短语或短句，而不是一个名词短语。它可以是一个动词（如：自动考核），一个动宾短语（如：捉取存款），一个被动句（如：发票填报），或者一个主谓句（如：用户提款，这个不推荐，因为主语就是参与者，显得有些多余）。用例类型：在我看来，不同类型的用例，其用例说明的格式是不一样的。以上给岀的是“业务操作”类用例的格式，它更加着重地在

4、描述业务操作的流程。而“查询报表”类用例则没有什么流程，它更加着重地在描述报表格式及显示内容（示面再给出）。还有用例类型还包括“了用例”、“扩展用例”。用例描述：对该用例的功能定义、要实现的业务需求，以及谁（参与者）应该如何使丿IJ进行描述。同时，这部分述可以整体概述实现业务需求的主要流程，以及与其它用例、其它外部系统的关系。通过用例描述，阅读者可以对该用例有一个整体的认识。参与者：用例图中该用例的参与者，通常是业务操作的触发者和施与对彖（如外部系统）。触发事件：谁干了什么，触发了这个用例。前證条件：

5、在触发该用例相关操作前必须达到的条件。事件流：这是用例说明中最重耍的部分，它详细描述了该用例对能出现的所有流程。1.基本流程：另一个名称更能表达它的意义：最佳流程（TheBestFlow）。它描述的是该用例以最住的、最正常的方式流转，没有岀现任何异常，并且最终成功完成操作的流程。基木流程在编写时，应当通过数字对流程中的每一步进行编号。2.扩展流程：或者叫“分支流程”，它描述的是基本流程在流转过程屮可能出现的所有分支。扩展流程最大的特点就是，它应当是在基本流程的某一步骤发生的分支，因此它的编号规则是“基

6、本流程号+序号”。基本流程号就是发牛分支的那一个基本流程的编号。在同一个基本流程上发生多个分支时，它们的序号从1依次开始编号。另一种情况是，某个扩展流程本身拥有多个步骤，这时应当在“基本流程号+自身序号”的基础上再添加序号，如“2.1.1”。扩展流程在描述时，应当首先描述进入这个分支的条件，即“如果XX则XX”、“当XX时XX”。3.异常流程：就是发生异常惜况时的处理流程。注意，用例说明是站在用例角度进行的说明，因此这里并不是我们通常一样的发牛程序界常的处理流程，而是用八在处理业务操作时发生的异常情况

7、,如：如果顾客不能提供身份证，贝!]••••••后迸条件：乂称为“成功保证”，就是执行基本流程获得成功以后所达到的状态(条件)。后置条件往往体现的是执行该用例的最终目的。如：完成用户档案的填写并提交。非功能需求：简称为“URPS+”，即可用性(Usability)、可靠性(Reliability).性能(Performance)＞可支持性(Supportability)以及其它(+)。这一部分的需求分析相当重要而又最容易被忽略，麻而我们再详细讨论。假设与约束：就是隐藏于业务功能中的各项规则与条件，如各

8、种逻辑条件、计算公式、环境限制等等。优先级：没啥可说的，最关键的是怎么去评定。这里我卖一个官子，在需求评审阶段，我会给人家一个比较准确而又可操作的评定方法。除此Z外，我还往往在每一个用例说明的后面与该用例相关的需求列表，便于需求跟踪。用例分析实质是需求人员的一份设计。既然是设计就可能出现偏差，最终偏离原始的需求(这种情况特别容易出现在FI后的升级维护中)。因此，将需求列表附在用例后面，便于FI后的需求评审与确认。当每次需要升级时，则添加上新的需求，或对以