产品设计体会(7011)UML学习摘录

人治–>法治–>德治(无为而治),大公司多为第二种:法治。13外表很像,区别在于1无法,而3的法在每个人的心中而非纸上。这是产品和团队发展的必经阶段,我们的现状就是“1–>2”,开始规范化,正好有同学原来熟悉UML,所以大家也都开始学习一下。

UML就是统一建模语言,它试图将软件工程的过程给规范化,从产品设计的角度,我对它的简单理解就是用一系列的标准图把需求分析的过程串起来,充分体现了“字不如表,表不如图”的原则,我以单个用例的粒度为界,把相关的图为两个层面。

上层的图中,用例是最小单位,不涉及用例内部,主要有:

Ø 类图:感觉有点像实体关系图ERD,更接近现实世界的对象,类图更接近技术实现的对象),描述系统中出现的各个对象之间的关系,以及和外部系统的关系。这是对业务领域的描述,一个外行看了以后就应该了解系统是做哪方面事情的。还是用我最喜欢的“小明去饭店”为例,画个图练练。

Ø 用例图:各个用例之间的关系(include/extend)、用例包、用例和actor之间的关系(将一组相关用例打包成一个模块,画成“用例包”)。描述这个系统具体可以做哪些事情。

Ø 状态图:表达系统里实体的状态转换,这也是贯穿多个用例的。例图里描述的就是“小明”的状态转换。

上层的图包装一下就可以生成整个产品最顶级的业务逻辑图,描述整个系统的业务层面的事情,用于商业演示。业务逻辑图的画法现在团队内也没有统一的意见,比较随意,表达清楚就行,这也意味着最难画。

现在说说下层的图,描述的是一个用例内部的事务(用例内部不一定是“单个用例”内部,也可能有用例之间的关系),主要有:

Ø 时序图顺序图):描述事情变化在时间维度上的先后顺序,善于表达对象(比如多个页面之间)的交互。玩的好可以完全替代UC中对流程的文字表述。

Ø 活动图(比较接近传统意义上的流程图):描述各种动作如何引起系统变化,善于表达泳道较多、分支较多的情况。

Ø 协作图:表达不同对象之间是怎么互相影响的,这个图团队里用到的不多,就不画了,理论上他和时序图是可以等价转换的,时序图关注交互在时间上的步骤,协作图关注交互过程中各个对象间的关系。

这些图我们都是用Rational Rose画的,它最好的一个点是可以在不同层次间的图穿透,比如从用例包穿透看到用例图,再穿透进某个用例看活动图,再穿透进活动图的某一步看具体的时序图。

很多时候多种图都可以描述同一件事情,只是从不同的视角去表达一个系统,选用哪个关键是看针对特定的系统,从哪个角度来描述更容易让受众理解。另外还有表述软件实施的构件图、描述硬件结构的部署图,暂时用处不大,遵循性价比的原则直接跳过了。

融入了UML标准图元素以后,一个功能模块的PRD大约就是这样的:文档说明、类图+用例图;一个个的UCUC里包含时序图、活动图等等。

感慨一下Rational Rose真的太强大(建立了整个软件工程的RUPRational Unified Process,包括分析、设计、编码、测试、部署等等一切),我想绝大多数公司应该找一个轻一点的工具,谁好的方案?

最后,再强调,工具是给人用的,如果团队里其他成员都看不懂了,学习成本太高,那一定不要强推UML,寻找合适自己的工具吧,原则很简单:把事情说清楚!

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

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

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

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

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


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

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

用例的唯一标识UC_ordermeal);

用例名称(点菜);

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

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

行为者(小明);

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

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

UC主体:

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

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

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

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

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

产品设计体会(3009)PD的几种文档

今天看到一篇讲述产品设计中几种文档的文章(一个老外的blogMichael on Product Management & Marketing),感觉很好,结合工作的实际整理一下。按照那篇文章的思路,从产品的抽象到具体主要产出的文档有BRDMRDPRDFSD

BRDBusiness Requirements Document,商业需求文档。这是产品生命周期中最早的问的文档,再早就应该是脑中的构思了,其内容涉及市场分析,销售策略,盈利预测等,通常是和老大们过的ppt,所以也就比较短小精炼,没有产品细节。

MRDMarket Requirements Document,市场需求文档。获得老大的认同后,产品进入实施,需要先出MRD,具体来说要有更细致的市场与竞争对手分析,通过哪些功能来实现商业目的,功能/非功能需求分哪几块,功能的优先级等等。实际工作中,这个阶段PD可能的产出物有Mind Manager的思维图,ExcelFeature List等。

iamsujie补:我们的模式下,上两种文档会合并成为BRD,参见“4004资源与BRD”)

PRDProduct Requirements Document,产品需求文档。进步一细化,这部分是PD写得最多的内容,也就是传统意义上的需求分析,我们这里主要指UCuse case)文档。主要内容有,功能使用的具体描述(参见下一篇:UC写作),Visio做的功能点业务流程,界面的说明,demo等。Demo方面,可能用dreamweaverps甚至画图板简单画一下,有时候也会有UI/UE支持,出高保真的demo,开发将来可以直接用的那种。

FSDFunctional Specifications Document,功能详细说明。有一点像“概要设计”,这步就开始往开发衔接了,产品UI、业务逻辑的细节都要确定,细化文档并保持更新。相应的,有很多内容,比如表结构设计,要由架构师来编写了。

再往后,就到“详细设计”和编码了,就此打住。