需求初体验——用例文档和需求四阶段

来到焦点正好一个星期，正式接触到互联网产品，以及尝试写了第一个需求，某系统下的一个二级子功能

 

关于需求分析，曾经在去年实习期间接触过外包软件的需求，基本是为客户做定制开发，而公司已经完成了OA产品的主体框架，所有只需要对现有系统进行描述，完善需求即可。当时需求分为：用户需求说明、需求分析说明书以及需求规格文档。而这次主要参与的文档主要是需求用例编写，俗称UC。可见互联网产品和客户定制产品还是有本质区别的。一个面向的是用户，一个面向的是客户。虽然客户大部分时候也是用户，但是跟互联网用户还是有本质区别的。

 

据说要写很多文档

《人人都是产品经理》上总结了PD要写的众多文档，主要有BRD、MRD、PRD和FSD，

BRD：Business Requirement Document商业需求文档

MRD：Market Requirement Document市场需求文档

PRD：Product Requirement Document产品需求文档

FSD：Function Specifications Document功能详细说明

网络上都有详细的说明，这里就不赘述了

个人感觉用例文档就是产品需求文档和功能详细说明文档的结合，当然了，除此之外还包括整体说明、产品界面（Demo）、业务逻辑的细节等。包括字符长度、输入限制、某数据的最大值等等。有点“概要设计”的成分。

 

文档整体结构

用例文档主要包括：用例（场景）描述、流程描述和界面描述。

用例（场景）描述：主要描述此功能的业务和需求，包括操作此功能的角色、前置和后置条件。

流程描述：此功能的活动图（Visio软件制作），以及相关的业务规则，也就是限制条件。若流程较多，可分为主流程和辅流程；或者称为基本流和扩展流。比如购买流程中，从浏览商品->下订单->付款购买->收货确认为一个主流程；查看/修改订单，取消订单等作为辅流程。

业务规则为整个用例的通用规则，应该和流程过程对应。若流程复杂，则业务规则会很多，大段文字会使读者看的不耐烦，包括自己都不想看。所以最好每一个流程对应一个业务规则，主流程的业务规则就是主流程活动图后面；辅流程的业务规则跟在辅流程的活动图后。

界面描述：界面截图，以及界面上各种元素、表单的说明。包括用户输入，用户动作，系统正常输出和出错提醒。界面截图是使用Axure制作的线框图，连低保真原型都不算哈。。。《启示录》中说，最好是制作高保真原型，所有的业务规则，逻辑等都可以通过高保真原型进行体现。Axure是个很强大的工具，还需要努力学习哈 。

 

需求四阶段

一个需求从点子，到形成完整文档，交给技术人员进行开发，需要经过四个阶段

一、需求生产，了解概念阶段：《人人都是产品经理》中将此阶段称为需求大生产运动，因为需求真的不全是PD一个人的工作，只要与此项目有干系的，都可以提出需求，一切为了产品本身吗。除此之外，还需要对用户进行深刻理解和分析，了解真正的目标用户，然后进行访谈、调查问卷、可用性测试、数据分析只要是对产品好，为了产品的，任何方法都可以采用。对了，此过程最少不了的就是“单项需求卡片”，甚至连客服都能提供出杀手级别的功能，谁知道呢。

二、构思策划：这个阶段和活动图制作联系起来，模拟用户如何操作，系统如何反应，确定此功能的主流程和辅助流程。需要考虑全面，跟别人讨论是一个很好验证流程是否合理的过程。

三、描述完善：原型制作，需求文档编写阶段。高保真原型的制作是麻烦一点，但是能够对所有细节进行充分的展示，而单纯的文字表述，始终感觉不给力，不能切中要害点。所谓文不如表，表不如图。需求文档要注意表达，不能有歧义，甚至可能、大概，可以这样的描述，确定就是确定，取消就是取消。

四、评审：目前木有亲自经历过，但是非常的重要以及一点点恐怖，需要对所有boss们讲述需求，还要面临被boss们左砍右砍，以及一堆问题的指出。不过这都是为了项目好，做PD就要做好这些准备。好的创意+完美的文档，应该是不怕评审的。

虽说过程比较复杂，但是就比如，假如你决定开始旅行，那你已经越过最大的障碍了。既然想做某个功能，就放手去做吧。。。

PS：四阶段是韩丽丽童鞋指导的，文字补充部分是个人看书的一个积累，所以大段摘抄自互联网和书本。

 

这就是一个阶段的工作总结，在培训材料里面看到卢学长分享的一个产品流程理想图，感觉蛮有收获，遂收藏了

最后感谢韩丽丽和卢学长最近的帮助和指导，特别是韩同学，一天麻烦她很多次，多次打断她真正进行的工作哈。

在此过程中遇到的问题总结：

1、经常会不自觉地考虑如果这样，会不会增加开发难度，增加系统复杂性。其实这个本身不是问题，应该权衡是否给用户带来方便，能否提示用户体验后，再选择最好的方法，我们要相信技术童鞋，不会有问题的；

2、原型制作，尽量完成高保真原型