需求分析与产品需求文档

产品的需求里面，经常有这三个概念：业务需求、用户需求、功能需求，引用一下比较官方的解释：

业务需求（ Business requirement ）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。

用户需求（ user requirement ）描述的是用户的目标，或用户要求系统必须能完成的任务。用例、场景描述和事件――响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。

功能需求（ functional requirement ）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求

三者之间的关系

业务需求和用户需求，只有经过需求分析的转化，变成产品的功能需求后，才能得到实现。

需求实例

用一个简单的实例来进行说明：

案例：用户自助寄件的需求

业务建设方：某快递公司

需求描述：目前很多城市的小区都已经有了快递柜，但快递柜主要是用于送件使用，而对于快递公司收件，用得比较少，某快递公司，就希望利用快递柜，来实现用户自助寄件的需求。

首先，分析其业务需求

这个案例的业务建设方是：快递公司，其业务需求也很明确，就是：用户自助寄件。

业务方之所以要建设这个需求，其目的是：希望利用快递柜，实现更高效的收件服务，减少人工上门收件的等待、低效、人力投入成本高等问题。

其次，看用户需求

这个案例的用户，就是每一个要寄快递的人，那么他们的需求是什么了？

他们的需求，其实就是在进行“自助寄件”的过程中，你尽量让我简单、易用，高效、快捷。

第三、需求分析转化

需求分析的转化，核心是两个点，一是对这个业务的场景进行充分的理解和认知，二是想明白业务场景中需求点，要通过何种方式来满足它。

业务需求是“用户自助寄件”，这个业务要实现，我们结合寄快递的实际场景，其实还是蛮容易就能想到，有3个关键环节：

1.用户要填写单据：即填写收发件人的相关信息；

2.用户要能找到周边的快递柜，并且能打开它；

3.还需要进行计量、支付快递费的问题

这三个环节，基本把这个业务的三个关键阶段说明出来了，它就是：填单——>找柜子放件——>支付。

然后，逐一对三个阶段进行具体的分析：

填单阶段：

·业务方需求：必须收件人、联系电话、寄件人信息清楚、明确等等。

·用户需求：能选的就选，能简单填写的就简单填。

转化为功能需求，你发现，无非是通过表单形式让用户把相关信息填上来，而为了满足用户需求，你肯定需要设计对收件人的记忆功能，让用户填写一次，后续每次只需要选择而已（相关的细节还很多，这里只做举例）。

找柜子放件阶段：

·业务需求：把最方便最合适的柜子告诉用户，并确保用户能安全、准确的找到快递柜、放入快递件；

·用户需求：我就想知道我要把快递件放到哪里，别让我多走；

这个业务需求和用户需求说起来简单，转化成功能需求时，其实里面还蛮多细节的：

1.位置服务肯定需要，一是为满足发现柜子的需求，二是也有导航的需求；

2.如何打开柜子呢？从我们的产品经验或者竞品参考来看，可以有扫描开启、验证码等方式；

3.如何保证用户去到快递柜，一定就有其空的柜子可以给他放了，这里面就涉及一个快递柜忙闲资源的管理；

所以，这里转化为功能需求时，你发现：有位置服务功能、扫描开启/验证码开启功能，柜子资源分配管理功能等；

支付阶段：

·业务需求：根据收费标准，准确无误、及时收到用户快递费。

·用户需求：支付方便。

·功能需求：

1.如何来计量，由于是自助寄件，称重显然不合适，那么按体积是一种较简便的方式，而如何按体积了，其实根据可快递柜的柜子；

2.如何支付，这个还简单，可以使用比较常用的几种支付方式就好；

以上，都只是简单的需求分析和转化的过程，实际的需求过程中，我们经常讲需要结合业务场景、用户场景把一些关键细节挖掘出来，并能在产品设计时考虑进去，以给用户一个良好的体验。

如何把需求写过文档里

通常需求文档的框架分为四部分：通用部分、场景流程、需求集合、其他说明。

通用部分

1、阅读者介绍：简要说明阅读用户是谁即可，这里点明产品的使用用户及角色做一个定义。

2、业务名称解释：对于项目中涉及的业务流程中出现的业务名词做相应解释。

3、项目综述：

• 项目背景：围绕整个项目的背景进行说明，着重描述业务场景。

• 项目范围：业务场景中所涉及到的主线、支线业务流（模块）全面覆盖；这里包括伴生性（延伸性）需求。

• 项目目标：点出产品实现的目的，而不是产品人揣摩设计出来的（这里说的揣摩是指优化性需求，并非实际需求）

场景流程

1、总（核心）业务流程：

水务行业协会会务组织人员能在会务系统上编写和发布会议通知、酒店信息、房间信息等。

参会人员能从电脑、手机上查看会议通知和报名，报名后可以在网站上缴费、订房、填写发票信息、网上签到，其中这几个部分的操作没有任何强关联和限制，不分先后。

业务流可以有以下几种情况，例如：

2.1、参会人员报名后可以进行缴费，之后预定房间，网上签到；

2.2、参会人员可以不缴费、直接预订房间，网上签到；

2.3、参会人员可以不缴费、不预定房间，直接网上签到；

2.4、参会人员可以报名后直接去现场签到；

2.5、参会人员可以不提前报名，直接到现场签到，一同办理：报名、缴费、订房、现场签到多项内容。

其中现场签到前进行网上签到是有好处的，签到后可以查看最新的会议动态。不进行网上签到的必须现场签到后才可以查看会议动态；

现场签到后，就可以按照分配的房间，办理入住。并且领取资料和查看最新会议动态。最新会议动态可以在网页上和手机上查看，内容包括：最新议程、酒店信息变更、房间信息更新等。

业务场景：

1、前台：会务管理系统中，前台的用户角色以及对应业务模块的交互关系；

2、后台：在会务管理后台中，用户可分为五类

2.1、会务组领导：会务组的领导一般只需要查询信息，看会议的报名、缴费、签到等情况。后续还会增加统计功能。

2.2、会务组信息编辑人员：主要是在会前编辑会议通知，会中发布通知变更，会后查看报名、缴费信息，退款审核等。

2.3、会务组现场服务人员：主要负责现场签到，查看、修改报名及缴费信息，会后负责退款的审核等。

2.4、会议组财物人员：主要查看缴费和发票信息，更改缴费状态，按照退款审核结果完成退款等操作。

2.5、信息录入人员：线下报名过多，会务组人员需要协助录入时就需要本角色的进入，主要负责录入报名和缴费的信息。如需要也可录入签到信息。

需求合集

根据业务需求而来的模块，以前台“网上报名”为例，举例说明。

每一模块的结构是这样的：

1、业务流程图：

2、需求说明：

参会人员可以通过手机、电脑浏览看到会议通知，点击报名入口，进入报名流程；报名通道选择：网站的原始会员可以通过会员通道报名，不是会员的用户可以通过非会员通道报名

2.1、会员报名：

如果已经是本站的会员，可通过会员登录的通道进入报名页面；登录方式可以支持会员账号和手机号。

会员登录后可以根据情况选择，是要“为自己报名”还是“为他人报名”。

会员登录后可以为自己报名，填写相应的报名信息即可完成报名。

报名信息包括：会员账号、姓名、性别、手机号、单位、职位、省市信息、是否入住、是否接受拼房、是否参观等信息，以上信息都为必填项。

2.2、非会员报名

如果还不是本网站的会员，可以选择非会员报名的通道进行报名。

非会员报名要实现不用注册和登录，只要通过验证即可进行报名。

报名人需要填写的信息包括姓名、单位、手机号码，需要验证身份方可通过。比如，可以通过手机号码进行验证，此处需要提示填写正确的手机号码，以便收取验证码等等。

为了让非会员报名成功后，能够查询自己的报名信息并增加网站的会员数量，非会员报名成功后应按照所填写的手机号码生成一个新的会员账号，报名人可以用此账号登录本网站，并收到“新账号”的短信提醒，希望新账号的初始密码是简单的数字。

此时报名人已经成为会员，后续的操作与会员报名基本相同；可以根据情况选择，是要“为自己报名”还是“为他人报名”。

其他说明

此部分为“数据说明”（记录与业务相关的资料及样式）。