需求用例格式及说明.docxVIP

xx?产品需求用例 用例格式 用例编号 用例名称 创建者 最后更新 创建时间 最后更新时间 执行者 说明 前置条件 后置条件 优先级 使用频率 [流程名] 执行者行为 系统响应 [步骤?1] 基本流程 [步骤?2] [步骤?3] [步骤?4] 执行者行为 系统响应 可选流程 执行者行为 系统响应 例外因素 包含用例 特定需求 假设 问题 注释 xx?产品需求用例 用例内容说明 前置与后置条件表示用例开始和结束回发生什么。即在用例开始时系统必须处在什么 状态（前置条件）或者在用例结束时系统必须处在什么状态（后置条件）。不管紧随用例之 后是哪一个分支或选择，后置条件都必须为真。 “优先级”指该本系统对本需求任务实现的重要程度。 “使用频率”是指实际用户环境中，本任务执行的频率。预先估计的使用频度为并行 使用和性能需求提供了一个早期指示。 “基本流程”：在描述基本流程时列出执行者和系统之间相互交互或对话的顺序。当 这种对话结束时，执行者也达到了预期的目的。 “可选流程”：可选流程代表了任务的细节或用于完成任务的途径的变化部分。基本 流程可以在一些决策点上分解成可选流程。然后再重新汇成一个基本流程。 “包含用例”，许多使用实例可能共享一些公共函数。为了避免重复，你可以定义一个 独立的使用实例，这一实例包含这个公共函数，并指定其它使用实例必须包括这个公共使 用实例。 “例外因素”引起任务不能顺序完成的情况称为例外（exception），在某些时候它可 以视为可选流程。在定义使用实例时，描述例外路径是很重要的，因为它们描述了在特定 条件下用户对系统如何工作的看法。“请求一种化学制品”使用实例中的一个例外是不存在 业务上可用的化学制品。如果你没有将例外记录在文档上，那么开发者可能在设计和构造 阶段忽视这些可能性。此时，当系统遇到一个例外条件时，就会发生系统崩溃。 xx?产品需求用例 需求用例文档编写建议?--事件流程（基本流程和扩展流程） 每个用例表示用户为实现某个目标与系统的一次交互，而事件流程则是对实现该目标 的描述，事件流程包括基本流程（又称为主成功流程）和可选流程（又称为扩展流程）；对 这部分的编写应该清晰的描述不同的对象（用户、系统）完成目标的活动序列，例如，像 这种方式：球员甲将球传给球员乙，球员乙运球，球员乙将球传给球员丙。 编写一个良好的事件流程有以下准则： 准则一：使用简单语法 主语＋谓语＋宾语，例如：“系统从账户余额扣除一定数量金额”，简单的语句与用户 沟通起来对需求的理解会更准确。 准则二：明确写出“谁控制球”（比喻） 控球的执行者会做下列事情：自己运球或将球传给别人，在步骤结束时要问问“把球 给谁了”。 准则三：从系统外部的角度来编写用例 始终站在用户的角度来编写，而不是系统的角度，例如，不要出现这样的描述“系统 读取卡号和密码，并从账号余额中扣除一定的金额”，而要从系统外部的角度来编写，如： 1）用户输入?ATM?卡并输入密码 2）系统从账号余额中扣除一定的金额 准则四：描述过程向前推进 每一个步骤都要离目标更进一步，步骤不要太细，也不能太粗，一般对基本流程?3-10 步是合适的，过多则会使用例文档显得太长。 准则五：描述执行者的意图而不是动作 编写用例常见的问题就是在操作界面来描述，这应该需要避免，例如： 用例?1 xx?产品需求用例 1）?系统要求用户输入名字； 2）?用户输入名字； 3）?系统要求用户输入地址； 4）?用户输入地址； 5）?用户点击“确认” 6）?系统显示用户简介 修改后： 1）?用户输入名字和地址 2）?系统显示用户简介 虽然在操作界面进行描述能很精确的定义需求，但过多关注细节会花费大量的精力， 同时文档也会变得很长，难以维护。 准则六：包含“合理”的活动集 对场景的描述可以把每个部分作为一个单独的执行步骤，也可以以不同的方式合并其 中的几个部分，如何分隔要尽量按“是否合理”进行。一个常用的步骤模板如下： 1）?用户向系统发送请求数据 2）?系统验证请求 3）?系统更新内部状态 4）?系统显示成功处理结果 任何用例流程的描述，都可以在上述基础上进行适当的扩展完成。 准则七：“确认”而不是“检查与否” 描述中不要出现“如果”字句，例如 2）?系统检查密码是否正确 3）?如果密码正确，系统显示主页面 要修改为： 2）?系统确认密码正确 3）?系统显示主页面 对于密码错误的流程，则放到可选流程中处理 xx?产品需求用例 准则八：习惯描述“循环执行步骤?X?到?Y，直到条件满足” 例如“用户重复步骤?3－4，直到完成选购” 准则九：对于可选流程，格式如下： 如准则七的中的例子 2a：无效密码： 1）系统显示登陆失败页面 2b：用户没有响应（超时） 1）系统自动关闭该页面 参考资料： 《编写有效用例