产品设计体会（二一）——UC写作

UC（user case，用例）是需求人员写给开发人员看的一种最基本的文档，最近在和微软合作做项目，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉到在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。

查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求，本世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在网站制作中，业界又对其发展，扩展出了“任务分解”等需求细化方法。下面简单的说一下一个用例要描述哪些事情。

首先需要有个总体的用例图来对系统给出高级可视化的表示，UML中给出了几个关键点：方框代表系统边界，每个角色（小人图形）通过线条和与之交互的用例（椭圆）相连。

然后需要描述每个用例，基本元素有（括号中举例说明）：

用例的唯一标识（UC_ordermeal）；

用例名称（点菜）；

行为者（小明）；

用例的简述（小明周末晚上去A餐馆，点一个菜，之后等烧好了吃掉）；

前置条件（是周末，……）；

后置条件（服务员接受订单，去厨房，……）；

流程，分主干和分支，描述共前置条件到后置条件的过程中，系统与用户之间有何种交互步骤，这里多见的是时序图或者流程图（小明自己选 or 让服务员推荐，if 服务员推荐，小明接受 or 不接受……确定点某个菜……）；

其他内容，比如限制条件、业务规则的描述（小明不吃辣，小明口袋里只有100块）；界面描述（小明的例子中好像没有，对于网页，我们对界面的描述经常占UC的很大篇幅，甚至配上demo）；额外的一些针对项目特定的需求。

UC一般只能描述绝大部分的功能需求，无法描述诸如性能、培训需要、时间限制等非功能需求，所以把UC拼在一起，再加上非功能的需求描述以及项目其他的概要信息，才构成教科书里的“需求说明书”。