用例(UC)文档模板
用例文档
用例编号：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用例：处理销售学号：110341228 姓名：王陈完成日期：2014-3-28用例UC1：处理销售范围：NextGen POS应用主要参与者：收银员涉众(Stakeholders and interests)及其关注点：—收银员：希望能够准确、快速地输入，而且没有支付错误，因为如果少收货款，将从其薪水中扣除。
—售货员：希望自动更新销售提成。
—顾客：希望以最小的代价完成购买活动并得到快速服务。
希望便捷、清晰地看到所输入的商品项目和价格。
希望得到购买凭证，以便退货。
—公司：希望准确地记录交易，满足客户要求。
希望确保记录了支付授权服务的支付票据。
希望有一定的容错性，即使在某些服务器构件不可用时（如远程信用卡验证），也能够完成销售。
希望能够自动、快速地更新账务和库存信息。
—经理：希望能够快速执行超控操作，并易于更正收银员的不当操作。
—政府税收代理：希望能从每笔交易中抽取税金。
可能存在多级税务代理，比如国家级、州级和县级。
—支付授权服务：希望接收到格式和协议正确的数字授权请求。
希望准确计算对商店的应付款。
前置条件：收银员必须经过确认和认证。
成功保证（或后置条件）：存储销售信息。
准确计算税金。
更新账务和库存信息。
记录提成。
生成票据。
记录支付授权的批准。
主成功场景（或基本流程）：1.顾客携带所购商品或服务到收银台通过POS机付款。
2.收银员开始一次新的销售交易。
3.收银员输入商品条码。
4.系统逐条记录出售的商品，并显示该商品的描述、价格和累计额。
价格通过一组价格规则来计算。
收银员重复3—4步，直到输入结束。
5.系统显示总额和所计算的税金。
6.收银员告知顾客总额，并请顾客付款。
7.顾客付款，系统处理支付。
8.系统记录完整的销售信息，并将销售和支付信息发送到外部的账务系统（进行账务处理和提成）和库存系统（更新库存）。
9.系统打印票据。
10.顾客携带商品和票据离开(如果有)。
扩展（或替代流程）：*a、经理在任意时刻要求进行超控操作：1. 系统进入经理授权模式。
用例描述文档模板
2. 必须要有的项目：时间＋地点＋专家＋主题
3. 邮件格式：
您好！[讲座时间]将举办[专家]主讲的[主题]讲座，
特殊需求（Special Requirement）
描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（指出所使用的操作系统、开发工具等）。
用例执行完毕后系Βιβλιοθήκη 可能处于的一组状态。涉众利益(Stakeholder)
说明涉众及涉众关心和担心的事情。如下：
1.开发人员-担心收到太多垃圾邮件
2.组织工作人员-希望操作方便，尽量减少手工劳动
用例场景 (Use-Case Scenario)
包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。
事件流 (Flow of Event)
基本流程（Base Flow）
1. 组织工作人员输入讲座信息，请求发布
2. 系统验证讲座信息充分
3. 系统保存讲座信息，生成讲座网页、讲座邮件
4. 系统发布网页到公司网站
5. 系统请求邮件列表系统发送邮件
6. 系统记录发布情况
7. 系统显示讲座消息已经发布
扩展流程（Extend Flow）
用例编号(Number)：UC_1_1用例名称(Name)：XXXXX
简要说明 (Brief Description)
简要介绍该用例的作用和目的。
执行者(Actors)
说明主要执行者和辅助执行者。
前置条件(Pre-Condition)
执行用例之前系统必须所处的状态。
后置条件(Post-Condition)
如：*1-7应在10秒之内
用例文档范例
用例文档用例编号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客户修改订单页面显示出来。
图书管理系统—用例描述
A1：读者无效
4. 管理员输入待借阅的图书条码号，检查图书有效性
A2：图书无效
5．系统登记一条新的借书信息
6．系统检查读者预定信息
A3:有预定
7．用例结束
其他事件流：
A1:读者无效
(1).系统显示读者无效的提示信息
(2).返回主事件流第3步
A2:
特殊需求：使用条码扫描仪和图书条码，预约一本书时间不超过30秒
(1). 系统显示图书无效提示信息
(2). 返回主事件流第4步
A3:有预定
(1). 系统提示预定信息，并取消预定
(2). 返回主事件流第7步
后置条件：系统成功写入一条借书信息，读者当前的借书数量加1
扩展点：
特殊需求：支持使用IC卡阅读器，输入读者证号，使用条码扫描仪和图书条码，借一本书时间不超过30秒
4.剔除新书信息
5.系统登记剔除一条旧书信息
6.用例结束
其他事件流：
A1:旧书条码无效
(1).提示新书条码无效
(2).返回主事件流第3步
后置条件：系统成功写入一条剔除旧书信息，当前的图书数量减1
特殊需求：支持使用条码扫描仪输入图书条码，剔除一本书时间不超过30秒
用例名称：统计月借阅情况
描述：馆长使用图书查询用例完成统计月借阅情况的活动
用例名称：剔除旧书
描述：图书管理员使用办理预定业务用例完成图书管理员剔除旧书活动
标识符:uc7
优先级：B(中)
角色:图书管理员
前置条件：图书馆员已成功登录系统并具有剔除旧书的权限
主事件流:
1.管理员选择“剔除旧书”选项，用例开始
2.打开剔除旧书窗体
uctext用例文档
用例文档示例（零件销售系统）执行者检索零件者：这是一个泛化角色，可以是潜在会员，也可以是会员、经理、货管员。
潜在会员：没有注册的顾客，他们的权限受到限制，只能检索零件，不能购买。
会员：已经注册的顾客经理：商店的管理人员货管员：商店专职管理货物的人员时间UC1：下小订执行者销售员前置条件销售员已经登录后置条件系统已记录小订情况，并打印出小订单涉众利益销售员――希望操作简单；希望系统能够正确记录销售员的业绩；客户――希望小订不会有其他人重复；希望房源信息真实；销售商老板――提高效率；提高签约率；保证企业形象；基本路径1. 销售员选择房源，命令系统下小订2. 系统显示下小订界面3. 销售员提交小订信息4. 系统验证小订信息合法5. 系统生成小订单号，保存小订信息和销售员，修改房源状态（？）6. 系统打印小订单7. 系统提示小订成功扩展4a. 小订信息不合法：4a1. 系统提示修改4a2. 返回35a. 系统或网络故障：5a1. 系统提示保存失败5a2. 返回35b. 该房已经被订掉：5b1. 系统提示“已被订掉”5b2. 用例结束字段列表2. 小订界面有缺省小订金额3. 小订信息＝房号＋客户姓名＋身份证号＋小订金额5. 小订信息＝3＋日期6. 小订单上应有信息＝3＋小订单号＋销售商条款声明业务规则4. 合法条件：房号、客户姓名、身份证号、小订金额都要有非功能需求设计约束2.待解决问题5. 生成小订单号规则待定UC2：会员登录执行者会员前置条件会员访问系统后置条件系统已显示该会员定制界面涉众利益会员――希望登录成功后能够出现自己的个性化信息商店――希望不会出现会员账号被冒用现象基本路径1. 会员提交用户名和密码。
2. 系统验证用户名和密码正确。
3. 系统显示带有会员信息的检索零件界面。
扩展2a. 会员提供的用户名不存在：2a1. 系统显示“用户名不存在”信息，询问会员是否注册2a2. 用例结束2b. 会员提供的密码错误：2b1. 系统显示“密码错误”信息2b2. 用例结束字段列表3. 显示会员信息为：会员姓名、账户余额、未结账订单。
产品设计体会UC(用例)写作
UC（use case，用例）是需求人员写给开发人员看的一种最基本的文档，在和其他公司合作做项目的过程中，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。
查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求，本世纪初，一些牛人们才将这种方法正式归纳为用例法。
之后在网站制作中，业界又对其发展，扩展出了“任务分解”等需求细化方法。
从一个项目的PRD开始，首先会有些总体说明，如项目概述、功能范围、用户描述、词汇表等，然后主体就是UC文档，首先需要有个总的用例图来对系统给出高级可视化的表示，说明各个UC之间的关系，UML中有相关的内容。
上个图感觉一下。
本篇简单说一下单个用例要描述哪些事情。
首先是UC概述（括号中举例说明每项内容）：用例的唯一标识（UC_ordermeal）；用例名称（点菜）；业务描述（为什么要做这个UC？小明工作一周辛苦了，周末晚上去吃一顿好的补补。
）；需求描述（这个UC要做什么？去餐馆，点一个菜，之后等烧好了吃掉）行为者（小明）；前置条件（是周末，……）；后置条件（服务员接受订单，去厨房，……）；UC主体：界面描述（小明的例子中好像没有，对于网页，我们对界面的描述经常占UC 的很大篇幅，甚至链接上demo。
当然还有一种做法是单独写界面文档，然后与UC文档互相引用）；业务规则（比如限制条件：小明不吃辣，小明口袋里只有100块）；流程描述，分主干、分支和异常三种，描述共前置条件到后置条件的过程中，系统与用户之间有何种交互步骤，这里多见的是时序图、活动图、流程图（小明自己选 or 让服务员推荐，if 服务员推荐，小明接受 or 不接受……确定点某个菜……）；其他内容，额外的一些针对项目特定的需求。
UC一般只能描述绝大部分的功能需求，无法描述诸如性能、培训需要、时间限制等非功能需求，所以再加上非功能的需求描述以及项目其他的概要信息，才构成教科书里的“需求说明书”。
用例说明模板
用例编号：UC 05.1标题：客户请求产品文档缩写标题：客户请求产品文档需求编号：14.1目的：场景叙述：客户想要获取一个选定产品的产品文档。
客户能够查看在线副本，打印副本，或者请求邮寄一个打印副本。
假设/前提条件：1.客户具有 Internet 接入。
2.客户浏览到了 Adventure Works Cycles Web 站点。
3.客户点击了Browse Product Descriptions。
4.数据库中存有产品文档，且站点运行正常。
参与者：1.客户2.充当客户的销售代表基本路线：1.用例开始于客户（用鼠标）滚动到想要的产品。
2.客户通过点击产品图形或者详细资料选择产品。
23.客户查看基本产品文档（名称、描述、图像、库存状态、价格、项编号）。
4.客户点击Need Complete Specification 了吗？5.客房查看完整的在线产品说明书（UC 05.1.3）。
6.客户点击Mail Me Full Brochure （UC 05.1.1）。
7.客户点击Submit 。
8.客户离开产品说明书页面。
9.用例结束于索取邮寄完整说明书的请求完成并保存到数据库中。
可选路线：A.情形：第1步：客户滚动到想要的产品。
a.产品不在当前的视图中。
b.客户必须呼叫销售代表订购产品。
c.销售代表完成订购。
d.继续第9步用例。
B.情形：第6步：客户点击Mail Me Full Brochure （UC 05.1.1）。
a.客户不在数据库中。
b.客户填写和保存个人资料。
c.继续第7步用例。
使用/扩展：1.使用2.扩展。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
业务描述
<商业目标，用户目的等业务内容>
需求描述
<产品需求，需要实现哪些功能点>
行为者
<该用例的Actor>
前置条件
<Pre-Conditions&g
其他说明
<任何其他的说明信息等>
界面描述
UI示意图：<页面名称>
<Demo截图1>
<截图说明1>（给出Demo文件的地址）
界面元素——表单：<表单名称>
名称
类型|长度
必填
默认值
规则
√
界面元素——列表：<列表名称>
名称
类型|长度
排序
规则
界面元素——按钮
名称
规则
界面元素——<其他>：<通用描述>
名称
<……>
规则
业务规则
序号
规则
1
（UC通用规则写在这里，流程中某步的私有规则写在流程中）
流程描述
流程1（主流程）：<流程名称>
触发事件：<触发事件>
时序图or活动图（尽量用图表达，下面的文字描述可选）
步骤
用户
系统
规则
1
2
分支流程1-1
1