用例文档

用例编号：UC-9 用例名称：添加文章描述：使用该博客系统并且要进行文章添加的用户,必须先通过用户身份确认,博客系统不支持匿名添加,方法是点击添加文章按钮，确认添加文章，系统接受请求，显示添加成功界面。

前置条件：1.用户身份已通过确认。

后置条件：1. 请求在系统中的状态是已接受2.根据这一请求的文章条目来更新文章信息主干过程：9.0添加文章1.用户浏览文章系统按照用户指令进行响应2.用户选择文章类别系统接受请求并响应3.用户点击添加文章按钮系统记录选择并显示添加文章界面4.用户添加文章系统将数据写入数据库5.用户选择文章浏览权限系统记录选择6.用户确认发布文章系统接受请求并返回相应信息分支过程：9.1如果博主不选择文章浏览权限，那么浏览权限默认为公开（发生于主干过程的第5步）9.2如果用户不确认发布文章，给出提示（发生于主干过程的第6步）异常：9.0.E.1 系统无响应（可能发生在主干过程中的任意一步）用例编号：UC-10 用例名称：上传照片描述：主要描述用户上传照片过程，方法是用户选择上传的照片后，系统满足这种请求，系统记录数据并将数据写入数据库。

前置条件：用户已登陆到博客界面。

后置条件：上传相片的请求已被保存在博客系统中。

主干过程：10.0 上传照片1.用户选择“上传图片”系统接受请求并显示上传相册界面2.用户选择要上传的相册系统搜索相册路径3.用户选择要上传的图片系统记录选择4. 用户确认上传的图片系统记录数据并将数据写入数据库分支过程：10.1如果用户不确认上传图片，给出提示（发生于主干过程的第4步）异常：10.0.E.1 系统无响应（可能发生在主干过程中的任意一步）10.0.E.2系统显示“没有搜索到相册”（第2步）系统询问用户是否打算要重新上传相册或者退出3a.用户要重新上传相册4a.系统重新开始主干过程3b.用户要求退出4b.系统结束用例用例编号：UC-11 用例名称：查看照片描述：主要描述了博友查看图片的过程，方法是用户登陆博客后，选择博友，查看博友照片前置条件：用户已登陆到博客界面。

产品需求文档的写作(五) –用例文档(UML用例图、流程图)在产品和技术领域里都有UML的技能知识，而对于产品人员的UML则更多的是指用例图，也就是我所称呼的用户流程图。

在讲PRD文档写作的第二篇文章里，我提到了用户流程图的制作，实际上用户流程图是我在产品规则的初期对用例图的一种结构化的表达方式，由于以结构化的方式描述用例太抽象，缺少逻辑性表达，并且那篇文章更偏向于功能性用户流程，还不是实际意义上的用例，因此今天我补文一篇，细讲一下UML用例图和用例文档。

用例文档是由多个用例组成的一份文档，主要用于技术开发与测试使用，他是PRD中的重要辅助文档，用于讲解某个环节的功能逻辑，例如用户注册、活动报名等等功能都是需要用例辅助说明的。

用例文档的写作时间在原型设计之后，通常和PRD文档同步撰写。

用例文档中有两个关联文件，分别是用例图和流程图。

用例图是UML的一种类图表现方式，是从用户角度描述产品功能，并指出该用户在产品各功能中的操作权限。

流程图是通过线框图形的方式描述产品功能的处理过程，主要是描述功能的执行顺序、分支和循环的逻辑。

写用户文档的常用软件是Word，其中用例图和流程图的制作软件常用的是Visio，当然也有用Axure RP软件制作的，例如下面的第三步流程图就是用Axure RP制作的。

一份完整的用例文档分别是由以下三点内容组成，其中第3点的“用例”是描述功能逻辑的部分，根据功能的多少决定有多少个用例。

用例文档的大概组成部分如下：1、修改记录：每次修改的备注记录，同PRD文档。

2、角色介绍：描述参与系统中的各个角色3、用例：同下方步骤的第4步，其中第3步中的流程图是直接插入到第4步的流程图表格项中的。

用例文档的模板格式如同以上三点内容，通过Word文档绘制表格，在表格中撰写用例描述，表格的格式和样式参考以下示例图。

1、撰写用例文档的第一步是注明使用产品的各个角色(参与者)和角色说明(角色介绍)。

如何进行用例‎建模呢，这里主要分解‎为三步：1.识别参与者(ACTOR)参与者作为同‎系统交互的所‎有事物，它可以是人也‎可以是其它系‎统或硬件等。

它不是系统的‎组成部分，是独立于系统‎而客观存在的‎。

其实在确定参‎与者时可以采‎用提问的方式‎来找出来，如谁是系统的主要用户‎？谁从系统获得‎信息等等。

而作为BLO‎G这种软件，这里为了便于‎分析，将参与者确定‎为用户(或会员和作者‎等，一但确定之后‎，下面的用例描‎述就要这样使‎用它们)，同时为了不与‎域模型中的用户和用‎户列表有任何‎模糊上的关联‎。

这里将域模型‎中的用户和用‎户列表更名为‎用户信息，用户信息列表。

而另一个AC‎T OR就是系‎统管理员了，而先前域模型‎中的系统管理‎员则相应更名‎为系统管理员信息。

2.确定用例。

确定用例时I‎C ONIX方‎法认为“首先要确定尽‎可能多的用例‎，然后不断地编‎写和改进描述‎这些用例的文本，在这一过程中‎，您将发现新的‎用例和通用情‎况”。

而确定用例的‎一个最重要的‎原则就是它必须同用户手‎册中的材料密‎切相关，每个用户和用‎户指南的各部‎分之间的关系‎必须是显而易‎见的。

从手册出发的原‎因就是要求开‎发人员“必须从用户角‎度来分析和设‎计系统”。

因为手册内容‎一般都非常庞大(相关模版在网‎上获取)，动不动就几十‎甚至几百页。

而从中归纳出‎文档所需要的‎内容必定也是‎非常繁琐的，但这一步又非‎常必要。

因为篇幅所限‎，又因为担心大‎家偏离本文的‎思想，所以这里也只‎有跳过了，大家完全可以‎在网上找到相‎关的信息来填‎充这一空白。

另外识别用例‎也可以采用提‎问方式，如每个参与者‎的任务？系统需要何种‎输入输出？等（详见“系统分析师设‎计指南之统一‎建模语言”）。

在有些书中会‎使用合并需求‎（主要是功能性‎需求，非功能性需求‎可附加到用例‎描述中）来获得用例，而进行合并操‎作的原则也就‎是生成“可见结果”的过程(这一步因为所‎做的事情过于‎繁杂，本文就不再涉略了‎)，并完成用例命‎名和绘制用例‎图。

用例文档用例编号UC001用例名称订餐参与者客户过程描述用例起始于用户想要订餐，客户点击系统提供的订餐功能键，系统显示可供选择的餐品信息，客户填写相应餐品的份数，并填好送餐地址、联系电话、送餐时间、其他要求（粗斜体字未必填内容）后，提交订单。

系统根据业务规则BR_E001Celerity营业时间规则，判断该订单是否在营业时间内，以及业务规则BR_E003 Celerity订餐时间和送餐时间间隔规则，判断该订单的送餐时间是否有效。

系统保存有效订单、废弃无效订单，并对客户进行反馈。

基本流程参与者的动作系统动作1）用例起始于用户想要订餐，客户通过UIC000客户专业功能页面，点击系统提供的订餐功能键。

2）系统通过UIC001客户订餐页面，显示可供选择的餐品信息。

3）客户通过UIC001客户订餐页面，填写相应餐品的份数，并填好送餐地址、联系电话、送餐时间、其他要求（粗斜体字未必填内容）后，提交订单。

4）系统根据业务规则BR_E001Celerity营业时间规则，判断新订单是否在营业时间内，以及业务规则BR_E003 Celerity订餐时间和送餐时间间隔规则，判断新订单的送餐时间是否有效。

5）系统保存有效订单，并通过UIC801订餐成功返回页面，对客户进行反馈。

分支流程第4步验证订单为无效状态时5）系统废弃无效订单，并通过UIC901订单无效返回页面对客户进行反馈。

6）客户可以通过UIC901订单无效返回页面选择重填或放弃。

7）系统根据用户的选择返回UIC001客户订餐页面，或UIC000客户专业功能页面。

用例编号UC004用例名称修改订单参与者客户过程描述用例起始于想要修改订单，客户点击系统提供的修改订餐功能键，系统对满足业务规则BR_C001客户订单修改规则的订单进行修改。

基本流程参与者的动作系统动作1）用例起始于想要修改订单，客户通过UIC000客户专业功能页面，点击系统提供的修改订单功能键。

2）系统将客户提交的满足业务规则BR_C001客户订单修改规则的未处理订单,通过UIC012客户修改订单页面显示出来。

产品经理用例文档一、用例文档简介用例文档是产品经理在产品开发过程中编写的重要文档之一，用于描述产品的功能需求和使用场景。

它可以帮助开发团队更好地理解产品需求，指导开发工作，并与各方沟通和协作。

用例文档通常包括用例名称、参与角色、前置条件、基本流程、异常流程和后置条件等内容。

二、编写用例文档的步骤1. 确定用例名称用例名称应准确地描述用例的功能或操作，便于阅读和理解。

例如，“用户登录”、“发布文章”等。

2. 确定参与角色参与角色是指在该用例中扮演的角色，可以是系统管理员、普通用户、游客等。

明确参与角色有助于理清用例的流程和权限。

3. 确定前置条件前置条件是指执行用例前的必要条件或假设条件。

例如，“用户已注册并登录”、“网络连接正常”等。

前置条件应具体明确，以保证用例的可执行性。

4. 描述基本流程基本流程是指用例的主要操作流程，包括用户的输入、系统的处理和输出等。

可以使用步骤、动作和期望结果等来描述基本流程。

例如，“用户输入用户名和密码，系统验证成功后跳转到首页”。

5. 描述异常流程异常流程是指当用例执行过程中出现异常或错误时的处理流程。

例如，“用户输入错误的用户名或密码，系统提示登录失败并要求重新输入”。

6. 确定后置条件后置条件是指用例执行后的状态或结果。

例如，“用户登录成功后显示用户信息”。

7. 编写用例文档在编写用例文档时，要注意语句通顺、表达清晰，使用词汇丰富，避免歧义或错误信息。

可以使用恰当的段落和标题，使文章结构清晰，易于阅读。

三、用例文档的价值和作用1. 指导开发工作用例文档可以帮助开发团队更好地理解产品需求，指导开发工作。

开发人员可以根据用例文档中描述的功能需求和使用场景进行开发和测试。

2. 与各方沟通和协作用例文档可以作为产品经理与开发团队、测试团队和其他相关人员沟通和协作的工具。

通过用例文档，各方可以更清楚地了解产品需求和使用场景，提出问题和建议，促进项目的顺利进行。

3. 评估产品需求和优先级用例文档可以帮助产品经理评估产品需求和优先级。

网上商城用例文档网上商城用例文档网上商城需求分析说明书本系统主要功能是为用户在网上开店建立一个平台，二、用例文档（一）1、用例编号： 2、用例名称：会员登录3、用例说明：登陆后会话的管理。

4、参与者：会员5、前置条件：网上商城系统正常运行 //实现该功能前要满足的条件6、后置条件：如果会员成功登陆，可以进行商品的搜索或者购买，否则只能进行搜索。

//当该功能实现后还要附加实现的功能 7、基本路径： uc_customer_login用户可以针对习惯网上购物的客户展示和销售商品，并实现安全交易。

实现的功能模块有，前台的商品展示、购物车、订单、收藏夹、缺货登记、会员信息管理等，后台实现了商品的列表和管理、会员管理、订单管理、报表管理、系统管理实现会员登录时的账号和密码验证功能以及（基本操作流程）1. 登录网上商城系统2. 输入用户名和密码3. 提交基本信息4. 系统对用户名和密码进行有效性检查5. 系统成功登陆后在系统界面显示用户名6. 7. 8、扩展点：a1、系统弹出账号错误或账号已经关闭等警告 a2、用户离开或者重新输入账号 b1、系统弹出密码错误警告 b2、重新输入密码 b3、对于多次猜测密码者进行账号锁定9、优先级：10、修改的历史记录1、用例编号：2、用例名称3、用例说明：实现新会员在线注册的功能4、参与者：普通用户a:会员账号错误 b:会员密码错误c:登录时间过长与系统无交互，提示重新登陆验uc_use_login :新会员注册搜索并购买商品系统鉴别用户时候有购买的操作能力（二）5、前置条件:系统正常运行6、后置条件：如果新会员注册成功，给指定邮箱发送确认信7、基本路径（基本流程）：1. 登陆网上商城系统 2．输入基本信息 3. 提交基本信息4. 系统对基本信息进行有效性检查 5．系统注册成功，发送确认邮件 6．通过确认邮件链接a:输入信息有误 a1:重新输入 b:基本信息填写有误9、优先级： 10、修改的历史记录。

用例文档的编写方法一、引言用例文档是软件开发过程中非常重要的一项文档，它描述了系统的功能需求和用户的交互过程。

本文将介绍用例文档的编写方法，旨在帮助开发人员更好地理解和分析系统需求。

二、用例文档的结构用例文档通常包含以下几个部分：引言、用例列表、用例描述、用例执行流程、用例扩展和用例特殊需求。

1. 引言引言部分简要介绍了系统的背景和目的，以及本文档的读者和编写目的。

在此部分中，应概述系统的主要功能和用户需求，并指明本文档所描述的用例的范围和目标。

2. 用例列表用例列表部分列出了系统中的所有用例，每个用例都有一个唯一的标识符和简短的名称。

该部分还可以包含一些关于每个用例的摘要信息，例如优先级、状态、参与者等。

3. 用例描述用例描述是用例文档的核心部分，它详细描述了每个用例的功能需求和用户交互过程。

每个用例描述应包含以下几个主要部分：前提条件、基本流程、备选流程和后置条件。

- 前提条件指明了执行该用例的前提条件，例如用户登录、系统初始化等。

- 基本流程描述了用例的主要功能和用户交互过程，通常以步骤的形式呈现。

- 备选流程描述了一些可能的异常情况或分支流程，例如用户取消操作、系统错误等。

- 后置条件指明了用例执行完成后的状态或结果，例如保存数据、显示结果等。

4. 用例执行流程用例执行流程部分通过流程图或伪代码的形式描述了每个用例的执行流程。

这有助于开发人员更好地理解和实现用例的功能需求。

5. 用例扩展用例扩展部分描述了一些可能的用例扩展场景，例如新增功能、修改功能等。

这有助于开发人员在未来的版本中对系统进行扩展和改进。

6. 用例特殊需求用例特殊需求部分描述了一些特殊需求，例如性能要求、安全要求等。

这有助于开发人员在实现过程中考虑到这些特殊需求。

三、用例文档的编写方法编写用例文档时，需要注意以下几个方面：1. 精确描述用例文档应尽量准确地描述系统的功能需求和用户交互过程，避免歧义或错误信息。

在编写过程中，可以使用恰当的词汇和语句，使描述更加清晰和准确。

用例描述模板篇一：用例描述文档模板篇二：用例描述模板实验一编写用例（以下给出用例描述模板），并画出用例图（编写时可参照下面的实例）用例描述模板是一种被广泛使用的用于发现和记录需求(特别是功能需求)的机制。

写出用例是一种最好的理解和描述需求的技巧。

注意：这个模板列出可以定义用例的典型标题，但应当强调的是，实用上更重要的是专注于写出完整的可理解的事件路径，而不是按指定的模板填写每个部分。

名称用例的名称应当用简短的动词短语表达，说明用户使用用例完成的任务。

概述或简要描述单列一节概述该用例完成什么通常是有益的。

参与者列出此用例涉及的参与者和负责发起此用例执行的主要参与者。

触发器触发器是开始此用例的事件。

触发者并不必须向该系统输入事件，例如，在预约系统示例中，“预约”用例的触发者可能是“一个潜在的客户打给餐馆(来自: 小龙文档网:用例描述模板)的一个预约电话”。

而在另一种情况下，触发者可能是此用例中第一个系统事件。

前置条件前置条件概述在用例可以开始前，什么必须为真。

通常前置条件说明在指定的一个用例运行前，另一个什么用例必须运行。

典型的前置条件可以是“用户已成功登陆”。

后置条件后置条件概述当用例完成时什么是真。

在许多情况下，这将依赖于在一个特定用例实例中发生的确切的一系列交互。

区分“最低保证”和“成功保证”可能是实用的，前者描述在所有情况下发生什么和不发生什么，后者描述如果正常的事件路径成功地完成将会发生什么。

事件路径或脚本基本的或正常的事件路径，通常应当作为不中止的交互序列出现。

对事件路径中的交互通常加以编号，以便于以后的参考。

可选和例外事件路径可选和例外事件路径可以完整地写出。

然而通常只须在基本事件路径中的分叉点简单地指明可选事件流，对行为可能改变的位置予以编号，并指明导致分叉的事件。

扩展点这一节应当列出在事件路径中可能发生扩展的位置，并给出确定扩展是否发生的条件或事件。

扩展本身应当作为单独的用例写出；否则，可以指明可选的事件路径。