2 用例文档
一般的讲，大型系统采用UML UserCase表达客户需求。UML建模
除了UML图，还需要文档描述，文档描述建议以下格式：
前置条件：开始使用这个用例之前，必须满足的条件。非必需
主事件流：用例的正常流程。必需
其它事件流：用例的非正常流，如：错误流
后置条件：用例执行结果“必须”为真的条件，也称为“附加条件”，非必需
举例：“安全登入”就是一个用例。
Ø 前置条件：无
Ø 主事件流：用户输入正确的用户名和密码，安全登入到Web应用中。向用户返回欢迎页，包括可操作的菜单，提示登陆成功。
Ø 其它事件流1：未输入用户名或密码，显示出错信息：用户名或密码不可为空
Ø 其它事件流2：用户名和密码不匹配，显示出错信息：用户名或口令错误
Ø 后置条件：该用例不是必须为真，无
UC（user case，用例）是需求人员写给开发人员看的一种最基本的文档，最近在和微软合作做项目，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉到在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。
查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求，本世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在网站制作中，业界又对其发展，扩展出了“任务分解”等需求细化方法。下面简单的说一下一个用例要描述哪些事情。
首先需要有个总体的用例图来对系统给出高级可视化的表示，UML中给出了几个关键点：方框代表系统边界，每个角色（小人图形）通过线条和与之交互的用例（椭圆）相连。
然后需要描述每个用例，基本元素有（括号中举例说明）：
用例的唯一标识（UC_ordermeal）；
用例名称（点菜）；
行为者（小明）；
用例的简述（小明周末晚上去A餐馆，点一个菜，之后等烧好了吃掉）；
前置条件（是周末，……）；
后置条件（服务员接受订单，去厨房，……）；
流程，分主干和分支，描述共前置条件到后置条件的过程中，系统与用户之间有何种交互步骤，这里多见的是时序图或者流程图（小明自己选 or 让服务员推荐，if 服务员推荐，小明接受 or 不接受……确定点某个菜……）；
其他内容，比如限制条件、业务规则的描述（小明不吃辣，小明口袋里只有100块）；界面描述（小明的例子中好像没有，对于网页，我们对界面的描述经常占UC的很大篇幅，甚至配上demo）；额外的一些针对项目特定的需求。
UC一般只能描述绝大部分的功能需求，无法描述诸如性能、培训需要、时间限制等非功能需求，所以把UC拼在一起，再加上非功能的需求描述以及项目其他的概要信息，才构成教科书里的“需求说明书”。
做一个互联网产品设计者，编写Use Case是日常工作的一个重要内容，也是重要的技巧。
回想起来自己当年从市场部转入到产品部，编写UC也是从0开始，最初就是拿着别人写的东西，然后按照自己的思路去设计新产品。刚好今天因为工作的关系，又再跟同事说如何写好UC，顺便这里总结一下。
先发一个UC的常用模板：
————————–
用例名称
最新更新日期：
负责人：
用例描述：
用户界面设计：
用例场景：
关联ＵＣ
补充规约：
遗留问题和可能的解决方案：
————————–
作为产品设计师，开始做一个新产品设计，一开始的时候，通常是在脑子里面的一堆想法，idea或者是跟需求方讨论出来的一些业务规则等等，最终要变成可以实施的项目，需要产品设计师去梳理，规范化需求，并最终形成需求文档，UC是其中最典型的文档产出物了。
我的建议是：
- 原则上流程图，特别是业务流程图是最先开始要拿出来的，在流程图中要确保各个业务流程是完整的，而且是效率最高的。这个需要比较多时间的讨论和细化。
- 将业务流程拆分成为一些典型的用户交互模块。比如：用户管理模款、帐户管理模块等
- 将每一个模块划分成为典型的用例组合，比如：用户注册、用户信息修改等等。
所以在具体开始写UC的时候，我的建议是：
- 不要一个UC写完整了再写一个，建议是先通盘写出所有UC的名称（其实名称一定程度上已经定义好了UC的主要工作目标了，比如：用户注册、注册用户信息修改、帐户信息检索等）。等于是写文章的一个提纲，主要的章节都有了。然后再看一遍，对照自己脑子里面的业务流程，看看是否有遗漏的。
- 写完成UC的描述，我的常用格式是：通过本UC….， 比如“通过本UC，用户可以完成支付宝用户的注册。” UC 描述基本上已经明确定义了该UC的范围，大小。在往下写之前，对该UC应该完成的主要功能，以及会遇到的所有分支、输入输出应该有明确的定义。UC的撰写过程只是将上述的内容进行细化和规范化，变成其他人可以阅读使用的东西。特别提醒一点：UC是给别人看的，而不是你自己看的。
- 下面说说正式写UC正文的时候，我个人觉得特别要注意的地方：
- 主流程一定是你希望的流程，你认为用户最顺利操作你的产品的流程，那么它就是主流程。很多Pd在写UC的时候。主流程无比复杂，里面加入无数的判断，就是因为这一点上没有明确。我自己的感觉是，往往一个UC，主流程可能很短，而分支流程会比主流程多，而且复杂。
3.2 用例模版
- 3.2.1 用例名
- 3.2.2 迭代
- 3.2.3 综述
- 3.2.4 前置条件
- 3.2.5 触发器
- 3.2.6 基本事件流
- 3.2.7 备选路径
- 3.2.8 后置条件
- 3.2.9 业务规则
- 3.2.10 注释
- 3.2.11 作者与日期
-
用例名
用例名为用例提供了一个唯一标示。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。
[编辑]迭代
迭代部分通常需要告知读者用例完成的阶段。最初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。
[编辑]综述
综述 部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快的理解该用例的用途。
[编辑]前置条件
前置条件 部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。
[编辑]触发器
触发器 部分描述了启动用例的起始条件。
[编辑]基本事件流
最低限度，每一个用例都需要描述一个主场景或者典型事件流。主事件流一般是一组有编号的步骤，如：
- 1) 系统提示用户登录。
- 2) 用户输入他的名字和密码。
- 3) 系统验证用户信息。
- 4) 系统使该用户登录入系统
…其他
[编辑]备选路径
用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。
备选路径的例子:- 1) 系统识别用户机器上的cookie
- 2) 到步骤4（主路径）
异常路径的例子:
- 3) 系统不能识别用户登录信息
- 4) 到步骤1（主路径）
[编辑]后置条件
后置条件 部分总结了在场景结束后事务的状态。
[编辑]业务规则
业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。
[编辑]注释
经验告诉我们，不管采用何种模版，分析人员发现总有重要的信息不适合模版的结构。因此每一种模版通常包含了这种明显不能避免的信息的部分。
[编辑]作者与日期
这部分列出创建用例的版本和谁书写的。还需要列出开发过程中从早期阶段开始的每个用例版本的日期。作者习惯在下面列出，因为它不被认为是重要的信息；用例是共同努力的结晶，并且它们被所有人拥有。
- 需求文档有这样的一个功能：
模块：文章审批管理。
功能描述：对于企业成员发表的文章。如果该成员被设置为发表的文章需要管理员审批的。此用户发表的所有文章需要等待管理员审批后才能发表在公司网站上，如果审批不通过，管理员直接删除该文章，并通知该用户。同样的，如果某成员没有被设置为发表文章需要管理员审批，该用户发表文章直接发布在公司网站里。
项目背景：这是一个企业的网站，网站为企业的每个成员开通帐号，每个企业成员都可以发表文章到企业网站上。但需要管理员审批通过后才发布出去。 - 首先，你要分清楚里面的事件流：
事件流分为两种：
1.基本流
2.备选流通俗点来解释：
基本流：就是正常的，正确场景
备选流：一般指中断操作的针对上面的功能，我简单阐述一下
基本流：
1.一用户（企业成员）被设置，设置内容为：该用户发表文章时需要由管理员审批后，才能发表到公司网站上面。
（被设置为该项内容的用户简称为A用户）
2.A用户发表了一篇文章。
3.管理员收到A用户发表文章请求。
4.管理员审批通过A用户发表的文章。
5.A用户文章发表到网站上。备选流：
1.用户被设置，设置内容为：该用户发表文章时不需要由管理员审批后，就能发表到公司网站上面。
（被设置为该项内容的用户简称为B用户）
2.B用户发表文章。
2.管理员拒绝A用户发表文章请求。
3.管理员删除A用户文章，系统通知A用户。以上是这个需求的主要事件流
在设计用例的时候，根据每个事件流和事件流组合的期望输出，设计相应的用例。不知道按照上面的事件流来分场景，你有思路了没有？
你也可以把你们的测试用例的模版传上来
我就按照你们的模版给你做几个例子～你应该就更加明白了～
3 设计数据库
UC（user case，用例）是需求人员写给开发人员看的一种最基本的文档，最近在和微软合作做项目，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉到在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。
查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求，本世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在网站制作中，业界又对其发展，扩展出了“任务分解”等需求细化方法。下面简单的说一下一个用例要描述哪些事情。
首先需要有个总体的用例图来对系统给出高级可视化的表示，UML中给出了几个关键点：方框代表系统边界，每个角色（小人图形）通过线条和与之交互的用例（椭圆）相连。
然后需要描述每个用例，基本元素有（括号中举例说明）：
用例的唯一标识（UC_ordermeal）；
用例名称（点菜）；
行为者（小明）；
用例的简述（小明周末晚上去A餐馆，点一个菜，之后等烧好了吃掉）；
前置条件（是周末，……）；
后置条件（服务员接受订单，去厨房，……）；
流程，分主干和分支，描述共前置条件到后置条件的过程中，系统与用户之间有何种交互步骤，这里多见的是时序图或者流程图（小明自己选 or 让服务员推荐，if 服务员推荐，小明接受 or 不接受……确定点某个菜……）；
其他内容，比如限制条件、业务规则的描述（小明不吃辣，小明口袋里只有100块）；界面描述（小明的例子中好像没有，对于网页，我们对界面的描述经常占UC的很大篇幅，甚至配上demo）；额外的一些针对项目特定的需求。
UC一般只能描述绝大部分的功能需求，无法描述诸如性能、培训需要、时间限制等非功能需求，所以把UC拼在一起，再加上非功能的需求描述以及项目其他的概要信息，才构成教科书里的“需求说明书”。
做一个互联网产品设计者，编写Use Case是日常工作的一个重要内容，也是重要的技巧。
回想起来自己当年从市场部转入到产品部，编写UC也是从0开始，最初就是拿着别人写的东西，然后按照自己的思路去设计新产品。刚好今天因为工作的关系，又再跟同事说如何写好UC，顺便这里总结一下。
先发一个UC的常用模板：
————————–
用例名称
最新更新日期：
负责人：
用例描述：
用户界面设计：
用例场景：
关联ＵＣ
补充规约：
遗留问题和可能的解决方案：
————————–
作为产品设计师，开始做一个新产品设计，一开始的时候，通常是在脑子里面的一堆想法，idea或者是跟需求方讨论出来的一些业务规则等等，最终要变成可以实施的项目，需要产品设计师去梳理，规范化需求，并最终形成需求文档，UC是其中最典型的文档产出物了。
我的建议是：
- 原则上流程图，特别是业务流程图是最先开始要拿出来的，在流程图中要确保各个业务流程是完整的，而且是效率最高的。这个需要比较多时间的讨论和细化。
- 将业务流程拆分成为一些典型的用户交互模块。比如：用户管理模款、帐户管理模块等
- 将每一个模块划分成为典型的用例组合，比如：用户注册、用户信息修改等等。
所以在具体开始写UC的时候，我的建议是：
- 不要一个UC写完整了再写一个，建议是先通盘写出所有UC的名称（其实名称一定程度上已经定义好了UC的主要工作目标了，比如：用户注册、注册用户信息修改、帐户信息检索等）。等于是写文章的一个提纲，主要的章节都有了。然后再看一遍，对照自己脑子里面的业务流程，看看是否有遗漏的。
- 写完成UC的描述，我的常用格式是：通过本UC….， 比如“通过本UC，用户可以完成支付宝用户的注册。” UC 描述基本上已经明确定义了该UC的范围，大小。在往下写之前，对该UC应该完成的主要功能，以及会遇到的所有分支、输入输出应该有明确的定义。UC的撰写过程只是将上述的内容进行细化和规范化，变成其他人可以阅读使用的东西。特别提醒一点：UC是给别人看的，而不是你自己看的。
- 下面说说正式写UC正文的时候，我个人觉得特别要注意的地方：
- 主流程一定是你希望的流程，你认为用户最顺利操作你的产品的流程，那么它就是主流程。很多Pd在写UC的时候。主流程无比复杂，里面加入无数的判断，就是因为这一点上没有明确。我自己的感觉是，往往一个UC，主流程可能很短，而分支流程会比主流程多，而且复杂。
3.2 用例模版
- 3.2.1 用例名
- 3.2.2 迭代
- 3.2.3 综述
- 3.2.4 前置条件
- 3.2.5 触发器
- 3.2.6 基本事件流
- 3.2.7 备选路径
- 3.2.8 后置条件
- 3.2.9 业务规则
- 3.2.10 注释
- 3.2.11 作者与日期
-
用例名
用例名为用例提供了一个唯一标示。它要用动/宾格式书写，并且要充分，达到最终用户能够明白用例中描述的是什么。
[编辑]迭代
迭代部分通常需要告知读者用例完成的阶段。最初，为业务分析和确定范围的用例和用于软件开发的用例肯定会有许多不同。老版本的用例可能还在当前文档中，因为它们对不同的用户群可能会有价值。
[编辑]综述
综述 部分用于在主体完成之前捕获基本场景。它提供了快速的总结，避免了读者浏览全部内容，能够很快的理解该用例的用途。
[编辑]前置条件
前置条件 部分用来表达当用户开始用例时某些条件必须为真。但是它们不是启动用例的触发器。
[编辑]触发器
触发器 部分描述了启动用例的起始条件。
[编辑]基本事件流
最低限度，每一个用例都需要描述一个主场景或者典型事件流。主事件流一般是一组有编号的步骤，如：
- 1) 系统提示用户登录。
- 2) 用户输入他的名字和密码。
- 3) 系统验证用户信息。
- 4) 系统使该用户登录入系统
…其他
[编辑]备选路径
用例可能包含第二条路径，或者和主题不同的备选场景。异常或当出错时会发生什么事情也需要描述出来，这种描述可以在备选路径中或者在它本身的部分。备选路径使用基本事件流中的序号来标示在哪一点上同基本场景不同，并且如果合适它从哪一点回到基本场景中。目的是避免不必要的重复信息。
备选路径的例子:- 1) 系统识别用户机器上的cookie
- 2) 到步骤4（主路径）
异常路径的例子:
- 3) 系统不能识别用户登录信息
- 4) 到步骤1（主路径）
[编辑]后置条件
后置条件 部分总结了在场景结束后事务的状态。
[编辑]业务规则
业务规则是一些成文的或未成文的规则，对于用例来说它决定了一个组织是如何执行业务的。业务规则是一个特殊种类的假定。它可能适用于某一个用例或者整个用例，甚至整个业务。
[编辑]注释
经验告诉我们，不管采用何种模版，分析人员发现总有重要的信息不适合模版的结构。因此每一种模版通常包含了这种明显不能避免的信息的部分。
[编辑]作者与日期
这部分列出创建用例的版本和谁书写的。还需要列出开发过程中从早期阶段开始的每个用例版本的日期。作者习惯在下面列出，因为它不被认为是重要的信息；用例是共同努力的结晶，并且它们被所有人拥有。
- 需求文档有这样的一个功能：
模块：文章审批管理。
功能描述：对于企业成员发表的文章。如果该成员被设置为发表的文章需要管理员审批的。此用户发表的所有文章需要等待管理员审批后才能发表在公司网站上，如果审批不通过，管理员直接删除该文章，并通知该用户。同样的，如果某成员没有被设置为发表文章需要管理员审批，该用户发表文章直接发布在公司网站里。
项目背景：这是一个企业的网站，网站为企业的每个成员开通帐号，每个企业成员都可以发表文章到企业网站上。但需要管理员审批通过后才发布出去。 - 首先，你要分清楚里面的事件流：
事件流分为两种：
1.基本流
2.备选流通俗点来解释：
基本流：就是正常的，正确场景
备选流：一般指中断操作的针对上面的功能，我简单阐述一下
基本流：
1.一用户（企业成员）被设置，设置内容为：该用户发表文章时需要由管理员审批后，才能发表到公司网站上面。
（被设置为该项内容的用户简称为A用户）
2.A用户发表了一篇文章。
3.管理员收到A用户发表文章请求。
4.管理员审批通过A用户发表的文章。
5.A用户文章发表到网站上。备选流：
1.用户被设置，设置内容为：该用户发表文章时不需要由管理员审批后，就能发表到公司网站上面。
（被设置为该项内容的用户简称为B用户）
2.B用户发表文章。
2.管理员拒绝A用户发表文章请求。
3.管理员删除A用户文章，系统通知A用户。以上是这个需求的主要事件流
在设计用例的时候，根据每个事件流和事件流组合的期望输出，设计相应的用例。不知道按照上面的事件流来分场景，你有思路了没有？
你也可以把你们的测试用例的模版传上来
我就按照你们的模版给你做几个例子～你应该就更加明白了～
今天的文章用例前置条件该怎么写_监理招标的前置条件分享到此就结束了，感谢您的阅读。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/87236.html
