用例文档

用例编号：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的技能知识，而对于产品人员的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. 评估产品需求和优先级用例文档可以帮助产品经理评估产品需求和优先级。

用例文档示例

待解决问题
UC2：对成绩排名用例描述
参与者教师（首要）前置条件教师已经登录；成绩已经存在后置条件
系统已经保存、或打印、或显示排名结果基本路径 1. 教师提交学生范围、成绩范围、排名方式 2. 系统对成绩排名。 3. 系统显示排名结果 4. 教师可以选择以下动作：打印保存扩展点 2a. 排名时间超时： 2a1. 系统提示正在处理，询问是否继续 2a2. 教师可以选择以下动作取消继续 2a2a. 教师选择“取消”： 2a2a1. 用例结束 2a2b. 教师选择“继续”： 2a2b1. 系统继续排名 4a. ×××： 4b. ×××：补充说明 1. 学生范围。。。排名方式（升降序、） 2. 排名规则：主要科目… 3. 应显示信息为：年级、姓名… 2a. 超时时间为 2 分钟待解决问题
用例文档示例
用例文档示例（零件销售系统）
参与者
潜在会员：没有注册的顾客，他们的权限受到限制，只能检索零件，不能购买。会员：已经注册的顾客经理：商店的管理人员货管员：商店专职管理货物的人员时间
UC1：分析成绩用例描述参与者
统计人员前置条件
统计人员已经登录后置条件
系统已经显示分析结果基本路径
UC3：检索零件用例描述
参与者根据零件的类别、编号以及几何特征信息，检索出所需零件的详细信息和价格。参与者
潜在会员（首要），会员前置条件
参与者访问系统后置条件
参与者查询到所要的零件基本路径
1. 参与者提交查询条件 2. 系统按查询条件检索零件 3. 系统显示搜索到零件的编号、类别、价格 4. 参与者选中某个零件 5. 系统显示该零件的详细信息扩展点 2a. 系统没有检索到所需零件：
待解决问题

网上商城用例文档

网上商城用例文档网上商城用例文档网上商城需求分析说明书本系统主要功能是为用户在网上开店建立一个平台，二、用例文档（一）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. 精确描述用例文档应尽量准确地描述系统的功能需求和用户交互过程，避免歧义或错误信息。

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

用例文档模板

用例名：用例名：选课系统
主要参与者：教务处工作人员（管理员）主要参与者：教务处工作人员（管理员）\教师 \学生简短描述：该用例描述参与者们如何应用该选课系统。简短描述：该用例描述参与者们如何应用该选课系统参与者们如何应用该选课系统触发事件：触发事件：登录到选课系统系统的主界面。类型：类型：外部的主要输入：主要输入：描述学号或工号或用户编号登陆密码验证码学年学期来源教务处工作人员管理（员）\教师 \学生教务处工作人员管理（员）\教师 \学生教务处工作人员管理（员）\教师 \学生教务处工作人员管理（员）\教师 \学生
无
编号：编号：1
Байду номын сангаас
重要性级别：重要性级别：高
主要输出：主要输出：描述
目标:提高选课的工作效率。方便教务处对选课情况的统一管理。
若用户操作错误则进行提醒，让用户知道哪一部错误，比如学号登陆密码验证码的错误。而且登录三十分钟后再次登陆无效，再次登陆无效，需要等待一定时间此时提醒：待一定时间此时提醒：该用户已登录步骤所需信息
主要执行步骤：主要执行步骤：
以学生为例
1. 2. 3.
输入自己的学号，登陆密码，验证码并选择自己的学年学期。输入自己的学号，登陆密码，验证码并选择自己的学年学期。点击登录若登录成功则进行步骤三若不能登陆则进行步骤一进入选课系统中后进入各个具体功能区按指示操作。进入选课系统中后进入各个具体功能区按指示操作。

用例描述模板

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

员工考勤系统用例文档示例

下面是员工考勤系统的用例文档示例：
用例1：登录系统
描述：员工通过用户名和密码登录考勤系统。

功能需求：
系统验证用户名和密码的正确性。

如果登录信息正确，系统将员工导航到主页面。

如果登录信息不正确，系统显示错误消息并提示员工重新输入。

用例2：查看考勤记录
描述：员工查看自己的考勤记录。

功能需求：
员工能够选择指定的日期范围查看考勤记录。

系统显示员工在选择日期范围内的考勤记录，包括上班时间、下班时间、迟到、早退等信息。

用例3：申请请假
描述：员工申请请假，并提交给主管审批。

功能需求：
员工填写请假申请表，包括请假类型、开始日期、结束日期等信息。

系统将请假申请提交给主管进行审批。

主管能够查看请假申请列表，并批准或拒绝请假申请。

用例4：查看考勤统计报表
描述：主管或管理员查看员工的考勤统计报表。

功能需求：
主管或管理员能够选择指定的日期范围查看员工的考勤统计报表。

系统生成并显示指定日期范围内员工的考勤统计报表，包括迟到次数、早退次数、请假次数等。

用例5：生成考勤报告
描述：管理员生成考勤报告并导出。

功能需求：
管理员能够选择指定的日期范围生成考勤报告。

系统生成考勤报告，包括员工的出勤率、迟到早退情况、请假记录等。

管理员能够将考勤报告导出为PDF或其他格式。

用例文档

用例图：
版块管理
用户管理顺序图：
: 管理员
: 用户管理界面类
: 用户管理控制类 : 用户
广告管理顺序图：
: 管理员
: 广告管理界面类
: 广告管理控制类 : 广告
链接管理顺序图：
: 管理员
: 链接管理界面类
: 链接管理控制类 : 链接
登陆顺序图：
: 用户 : 登陆界面类 : 登陆控制类 : 用户信息管理顺序图:
:
用户 :
管理用户信息界面类 : 管理用户信息控制
: 用户信息
注册顺序图：
: 用户 : 注册账号界面类 :
注册账号控制类 : 账号信息版块管理顺序图：
: 版主
: 版块管理界面类
: 版块管理控制类 : 版块
帖子管理顺序图：
: 版主
: 帖子管理控制类
: 帖子管理界面类 : 帖子
发帖顺序图：
: 普通用户 : 发帖界面类 : 发帖控制类 : 帖子。

用例分析文档模板

文档名称版本<1.0 >文档属性及版本目录1 用例：<用户登录> (4)1.1用例图 (4)1.2简要说明 (4)2 事件流 (4)2.1基本流 (4)2.2备选流 (4)3 用例场景 (5)3.1成功场景 (5)3.2失败场景 (5)4 特殊需求 (5)4.1总体要求 (5)4.2用例要求 (5)5 前置条件 (5)6 后置条件 (5)7 扩展点 (5)7.1新用户注册 (5)1用例：<用户登录>1.1用例图1.2简要说明此用例主要描述XXXXXX系统的用户登录。

由于XXXXXX系统是基于用户许可授权访问的系统，在用户访问该系统时，首先要通过合法的用户身份验证，其次要控制用户对系统资源的访问权限。

根据XXXXXX系统的实际应用需求，该系统的用户分为两种类型：一种是一般用户，另一种是特殊用户。

不同类型的用户具有不同的访问权限。

2事件流用户在浏览器地址栏输入系统的URL（网址），该用例启动。

2.1基本流1．进入登录页面如果用户没有通过身份验证，则在浏览器地址栏内访问任何一个页面的URL都自动进入登录页面。

2．输入用户名和密码系统提示用户名和密码必须输入。

用户名符合数据结构要求，密码符合密码长度以及复杂度等要求。

3．选择“登录”操作系统验证用户输入数据的合法性，进而验证是不是合法的系统用户以及用户的权限（一般用户、特殊用户）。

4．进入系统主页面。

2.2备选流A1.用户和密码输入在基本流的步骤3，提示用户输入合法的用户名和密码。

A2.用户或密码错误在基本流的步骤3中，用户输入的用户名或者密码错误，提示用户重新输入。

然后继续执行基本流的步骤3。

三次输入用户名和密码无效后，该用户被锁定，用例结束。

A3.退出系统无条件关闭浏览器。

用例结束。

3用例场景3.1成功场景登录成功：基本流取消操作：备选流，退出系统。

3.2失败场景没有输入用户和密码：备选流，用户和密码输入。

输入用户或密码错误：备选流，用户或密码错误。

用例分析文档(新)

电力指标分析系统1.1. 扭亏增盈分析 (4)1.1.1用例图 (4)1.1.2 指标偏差分析 (4)1.1.3 指标完成情况分析 (5)1.1.4 历史指标分析 (6)1.1.5 调度会议信息 (7)1.1.5.1 添加扭亏增盈会议信息 (7)1.1.5.2 修改扭亏增盈会议信息 (8)1.1.5.3 删除会议信息 (9)1.1.5.4 查看会议信息 (9)1.1.5.5 查看会议详细信息 (10)2.1 系统管理 (11)用例图： (11)2.1.1 指标管理 (12)2.1.1.1 查看指标信息 (12)2.1.1.2添加指标信息 (13)2.1.1.3删除指标信息 (13)2.1.1.4修改指标信息 (14)2.1.2 部门管理 (15)2.1.2.1 查看部门信息 (15)2.1.2.2 添加部门信息 (16)2.1.2.3 删除部门信息 (16)2.1.2.4修改部门信息 (17)2.1.3 用户管理 (18)2.1.3.1 查看用户信息 (18)2.1.3.2 添加用户信息 (19)2.1.3.3 删除用户信息 (19)2.1.3.4 修改用户信息 (20)2.1.4 机构管理 (21)2.1.4.1 查看机构信息 (21)2.1.4.2 添加机构信息 (22)2.1.4.3 删除机构信息 (22)2.1.4.4 修改机构信息 (23)2.1.5 调度管理 (24)2.1.5.1 修改调度人员 (24)2.1.5.2 查看调度人员 (25)3.1 指标数据报表 (26)3.1.1用例图 (26)3.1.2 综合分析报表 (26)3.1.3 指标明细报表 (27)3.1.4 历史分析报表 (27)3.1.5 导出Excel报表文档 (28)3.1.6 打印报表 (29)4.1 数据采集 (30)4.1.1 用例图 (30)4.1.2 每月目标值采集 (30)4.1.2.1 添加每月目标值 (30)4.1.2.2 删除每月目标值 (31)4.1.3 每月完成值采集 (32)4.1.3.1 添加每月完成值 (32)4.1.3.2 删除每月完成值 (33)4.1.4 数据半自动采集 (33)4.1.5 年度值采集 (34)5.1 数据管理 (35)5.1.1 用例图 (35)5.1.2 每月目标值维护 (36)5.1.2.1 查询每月目标值 (36)5.1.2.2 修改每月目标值 (37)5.1.3 每月完成值维护 (38)5.1.3.1 查询每月完成值 (38)5.1.3.2 修改每月完成值 (39)5.1.4 年度先进值维护 (40)5.1.4.1 查询年度先进值 (40)5.1.4.2 添加年度先进值 (41)5.1.4.3 修改年度先进值 (41)5.1.5.4 删除年度先进值 (42)5.1.5 Excel模板维护 (43)5.1.6.1 查询模板 (43)5.1.6.2 添加模板 (44)5.1.6.3 修改模板 (44)5.1.6.4 删除模板 (45)5.1.6.5 导出模板 (46)5.1.6 年度值维护 (46)5.1.6.1 查看年度值信息 (46)5.1.6.2 修改年度值信息 (47)5.1.6.3 删除年度值信息 (48)系统用户1.1. 扭亏增盈分析1.1.1用例图系统用户1.1.2指标偏差分析用例名称指标偏差分析用例编号DJ_DLZBS_1_1用例审核人研发一部用例编写人唐超前置条件 1.用户成功登录系统2.用户具有指标偏差分析权限基本路径 1.系统用户选择扭亏增盈分析下的指标偏差分析。

用例文档参考模板

3b.商品标识可以是各种不同的编码方式。
7a.信用卡帐号信息可以使用读卡器或键盘输入。
7b.记录在纸面收据上的信用卡支付签名。
发生频率
可能会持续发生。
设计约束
系统中断后的自动恢复问题，怎样保存先前的交易记录？
6a.顾客想用现金付款，但随身现金不足：
1a.顾客使用替代的支付手段。
1b.顾客告诉收银员，他要取消此销售，收银员在系统上取消此销售。
7a.现金支付：
1．收银员输入收取的现金数额。
2．系统给出应找的金额，并弹出现金抽屉。
3．收银员放入收取的现金，并拿出应找的余额给顾客。
4．系统记录现金支付。
7b.信用卡支付：
1．顾客输入信用卡帐号。
2．系统向外部的信用卡授权服务系统发送支付授权请求，并请求批准此支付。
非功能需求
1、使用大型平面显示器，交易过程中的信息要能够在1米之外看清楚。
2、90%的信用卡授权机构的响应应该在30秒内收到。
3、支持多种语言显示。
4、在步骤3和步骤7中可以插入新的业务规则。
业务规则
3a.商品标识可以用条码扫描或键盘输入。
顾客：希望购买过程能够省力，并得到快速的服务，希望得到购买证明，以便退货。
公司：希望准确地记录交易，并满足顾客的要求。希望保证支付授权服务的信息被记录。希望有一定的容错性即使某些服务暂时不可用（如远程信用卡验证）也能允许收款。希望能够自动、快速的更新帐目和库存信息。
支付授权服务：希望按照正确的格式和协议收到数字授权的请求，希望准确计算给商店的应付款。
1．收银员重启系统，登录，请求恢复上次状态。
2．系统重建之前的状态。
2a.系统恢复过程中检测到异常：
1．系统向收银员指示错误，记录此错误，并进入一个清空状态。

如何编写用例文档

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

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

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

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

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

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

2.确定用例。

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

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

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

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

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

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

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

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

从我个人来看，这两者(ICONIX方法和其它方法) 是相辅相成，并无冲突。

限于篇幅直接将初步确定并整理出来的用例列出来[采用动词(短语)-名词(短语)形式]：注册用户(UC01),登陆系统(UC02),发表文章(UC03),编辑文章(UC04),删除文章(UC05),浏览评论(UC07),删除评论(UC08),浏览留言(UC09),删除留言(UC10),添加链接(UC11),编辑链接(UC12),删除链接(UC13),上传文件(UC14),删除文件(UC15),管理文件类型(UC16),编辑签名(UC17),编辑个人信息(UC18),编辑BLOG基本信息(UC19),(管理员)审核用户(UC20), 创建俱乐部[或群](UC21)等。

登录用例文档

“登录”用例文档
基本时间流
（1）用例起始于用户需要登录到该系统
（2）系统显示欢迎界面，并要求用户输入用户名和密码
（3）用户输入用户名和密码
（4）系统验证用户名和密码，允许用户登录系统（A-1）
（5）系统根据用户类型启动不同的主操作界面
备选事件流
A-1用户名错误或密码错误
（1）系统显示用户名错误或密码错误的提示信息，并进入第（2）步
（2）用户可以重新输入用户名和密码（B-1），也可以选择结束该用例
补充约束-业务规则
B-1系统允许用户重试三次登录操作，超过三次后系统自动结束，不允许用户重试补充约束-非功能需求
安全性：密码应该采用加密的方式存储，有关密码的算法待定
待解决问题
关于用户名和密码的管理和维护功能还需要进一步明确
相关图
（可画出登录过程的活动图，此处省略）。

软件测试用例文档模板(带实例)

支配形貌
数据
憧憬截止
本质截止
尝试状态（P/F）
1
采用用户称呼，按“提接”按钮.
用户名=administrators，暗号为空
隐现告诫疑息“帐号或者暗号没有克没有及为空！”
（切合）
P
2
采用用户称呼,输进过失暗号，按“提接”按钮.
用户名为administrators，暗号=123
隐现告诫疑息“帐号或者暗号没有过失！”
尝试脚段
查看维护窗体界里取安排的切合性.
预置条件
不妨登录加进到系统
特殊规程证明
（无）
参照疑息
系统提要安排证明战仔细安排证明
尝试数据
支配步调
支配形貌
数据
憧憬截止
本质截止
尝试状态（P/F）
1
…
…
…
…
…
234ຫໍສະໝຸດ 5678
9
10
11
12
尝试人员
彭贝贝、李绍霞、唐姣凤
启垦人员
杨丽娟
控造人
李虎(脚写)
功能个性
系统的初初窗体，并举止用户的合法性考证.
尝试脚段
考证是可输进合法的疑息，遏止非法登陆，以包管系统的仄安个性
预置条件
数据库中保存了一些用户疑息
特殊规程证明
（区别大小写）
参照疑息
需要证明中闭于“登录”的证明
尝试数据
用户名=administrators暗号=1001（数据库表中有相映的疑息）
支配步调
体例人
李虎、彭贝贝、唐姣凤
用例编号
Project_MA_Interface_3
体例时间
2005–2–21
相闭用例
Project_MA_Interface_1、Project_MA_Interface_2、Project_MA_Priority_1、Project_MA_DBACCESS_1