产品设计体会(3010)UC(用例)写作

UCuse case,用例)是需求人员写给开发人员看的一种最基本的文档,在和其他公司合作做项目的过程中,发现双方的文档规范差异很大,造成了沟通成本的提高,所以感觉在一个长期合作的团队中,文档与规范的统一真的是非常必要的(我强调的是“统一”,并没有强调要一定要用“某种格式”)。

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

从一个项目的PRD开始,首先会有些总体说明,如项目概述、功能范围、用户描述、词汇表等,然后主体就是UC文档,首先需要有个总的用例图来对系统给出高级可视化的表示,说明各个UC之间的关系,UML中有相关的内容。上个图感觉一下。

本篇简单说一下单个用例要描述哪些事情。


====== 看不清猛击图片看大图 ======

首先是UC概述(括号中举例说明每项内容):

用例的唯一标识UC_ordermeal);

用例名称(点菜);

业务描述(为什么要做这个UC?小明工作一周辛苦了,周末晚上去吃一顿好的补补。);

需求描述(这个UC要做什么?去餐馆,点一个菜,之后等烧好了吃掉)

行为者(小明);

前置条件(是周末,……);

后置条件(服务员接受订单,去厨房,……);

UC主体:

界面描述(小明的例子中好像没有,对于网页,我们对界面的描述经常占UC的很大篇幅,甚至链接上demo。当然还有一种做法是单独写界面文档,然后与UC文档互相引用);

业务规则(比如限制条件:小明不吃辣,小明口袋里只有100块);

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

其他内容,额外的一些针对项目特定的需求。

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