2009年1月20日 2 条评论 UC（use case，用例）是需求人员写给开发人员看的一种最基本的文档，在和其他公司合作做项目的过程中，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。
查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求，本世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在网站制作中，业界又对其发展，扩展出了“任务分解”等需求细化方法。
从一个项目的PRD开始，首先会有些总体说明，如项目概述、功能范围、用户描述、词汇表等，然后主体就是UC文档，首先需要有个总的用例图来对系统给出高级可视化的表示，说明各个UC之间的关系，UML中有相关的内容。上个图感觉一下。
本篇简单说一下单个用例要描述哪些事情。
首先是UC概述（括号中举例说明每项内容）：
用例的唯一标识（UC_ordermeal）；
用例名称（点菜）；
业务描述（为什么要做这个UC？小明工作一周辛苦了，周末晚上去吃一顿好的补补。）；
需求描述（这个UC要做什么？去餐馆，点一个菜，之后等烧好了吃掉）
行为者（小明）；
前置条件（是周末，……）；
后置条件（服务员接受订单，去厨房，……）；
UC主体：
界面描述（小明的例子中好像没有，对于网页，我们对界面的描述经常占UC的很大篇幅，甚至链接上demo。当然还有一种做法是单独写界面文档，然后与UC文档互相引用）；
业务规则（比如限制条件：小明不吃辣，小明口袋里只有100块）；
流程描述，分主干、分支和异常三种，描述共前置条件到后置条件的过程中，系统与用户之间有何种交互步骤，这里多见的是时序图、活动图、流程图（小明自己选 or 让服务员推荐，if 服务员推荐，小明接受 or 不接受……确定点某个菜……）；
其他内容，额外的一些针对项目特定的需求。
UC一般只能描述绝大部分的功能需求，无法描述诸如性能、培训需要、时间限制等非功能需求，所以再加上非功能的需求描述以及项目其他的概要信息，才构成教科书里的“需求说明书”。
该文章出自《iamsujie的产品设计》,原文链接：http://iamsujie.com/page/34/
