初期的需求分析文档如何写？

本文是一个“小白版”的需求分析文档，主要结合“会务管理系统 – 会议报名模块”的产品案例，对需求文档的框架展开了详细说明，与大家分享。

本文的“初期需求分析文档”不是产品经理工作中输出的产品需求说明书（prd），是为初期用研后的资料整理后进行输出的（更落地的需求分析），文档格式除了通用部分，都有相对的调整，与市面上的文档区别还是很多的；比如场景图、及文档内对业务及流程的落地说明，并非对企业内部协作使用的专业化文档，本文档主要用于初期的资料（数据）留痕。

如果文章中的文档进行深度分析，就会专业化，进而演变成需求分析文档（专业化：对内协作使用）、产品需求说明书（PRD）、概要设计等。

一、前言

本文从“会务管理系统 – 会议报名模块”的产品案例，说明初期的需求分析文档到底如何写，如何更落地；让自己及其他阅读伙伴更清晰的认知产品的场景、业务、流程，一步步形成完整的产品闭环，说用户懂的话，交出一份“小白版”的需求分析文档~

二、为什么写小白版的需求文档？

1. 文言文 PK 白话文

（1）“文言文”

很多产品人在初期产品调研后，做了信息收集及整理，输出需求分析文档，虽然这份文档输出是更好的铺垫接下来的工作，但往往太过于官方，或者过于业务化，对于阅读文档的目标用户没有做到同理心，领导看不懂，协作伙伴看不懂，这样的文档，价值何在呢？

产品人输出任何东西都要尽可能的有价值，而我们是最应该知道什么是价值的人，这对自己也是一种沉淀性的输出。

os：阅读文档的目标用户，这里面客户也算其一（偏B端）；在特殊情况下，文档输出的第一版是需要与用户核对，敲定很多业务规范及流程中的细节。

（2）“白话文”

在做内容输出时，谨记说人话，专业性语言少来，尽可能让阅读人员能够“小白化”的读懂，尽可能场景化，通俗易懂。

2. 明确文档的用户

不同角色（面向群体）：

1. 产品人：为产品部门内相关设计人员提供需求信息的展示，同时对自己为自查，对项目做留痕。
2. 用户/客户：这里的客户（B端）会与产品人进行输出文档的业务准确性做深入碰撞，敲定业务框架。
3. 团队成员：对接协作伙伴设计、程序；清晰明了，无需精细化宣讲

3. 明白文档价值

文档价值（文档目的）

1. 输出：把大脑中的构思落地出来，形成文档，给自己做自查，给伙伴清晰的视野反馈。
2. 留痕：把关键性的信息全部囊括在内，有可追溯性，对内对外皆可做到整个项目的管理。

4. 如何让文档更落地

让文档落地，我们首先要明白，写文档的本质是什么？

首先我们在输出文档时，对于我们目标用户必须要明确，而不是太过自我，很多业务细节延伸出来的伴生性功能需要雕琢一下，这些伴生性功能是否符合业务流、是否优化了业务流；

那么我们需要切换到用户的业务场景视角，去发现这些是否真的是用户需要的，围绕着业务场景及各个角色进行输出内容。

三、文档框架

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

os：框架的四个部分是本人泛指，自我定义，大家可以自己调整自己的文档框架

1. 通用部分

文档目的：

1. 阅读者介绍：简要说明阅读用户是谁即可，这里点明产品的使用用户及角色做一个定义。
2. 业务名称解释：对于项目中涉及的业务流程中出现的业务名词做相应解释。

项目综述：

1. 项目背景：围绕整个项目的背景进行说明，着重描述业务场景。
2. 项目范围：业务场景中所涉及到的主线、支线业务流（模块）全面覆盖；这里包括伴生性（延伸性）需求。
3. 项目目标：点出产品实现的目的，而不是产品人揣摩设计出来的（这里说的揣摩是指优化性需求，并非实际需求）

so：此部分为需求分析模板的通用部分，不做举例说明了；切记一点，尽可能让这部分足够落地的阐述；用户阅读文档的第一部分就如同天书，后面也不会详细去看。

2. 场景流程

业务流程：

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

（2）业务流程说明

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

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

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

1. 参会人员报名后可以进行缴费，之后预定房间，网上签到；
2. 参会人员可以不缴费、直接预订房间，网上签到；
3. 参会人员可以不缴费、不预定房间，直接网上签到；
4. 参会人员可以报名后直接去现场签到；
5. 参会人员可以不提前报名，直接到现场签到，一同办理：报名、缴费、订房、现场签到多项内容。

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

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

应用终端：Web、wap、H5；

业务场景：

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

如下图：

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

1. 会务组领导：会务组的领导一般只需要查询信息，看会议的报名、缴费、签到等情况。后续还会增加统计功能。
2. 会务组信息编辑人员：主要是在会前编辑会议通知，会中发布通知变更，会后查看报名、缴费信息，退款审核等。
3. 会务组现场服务人员：主要负责现场签到，查看、修改报名及缴费信息，会后负责退款的审核等。
4. 会议组财物人员：主要查看缴费和发票信息，更改缴费状态，按照退款审核结果完成退款等操作。
5. 信息录入人员：线下报名过多，会务组人员需要协助录入时就需要本角色的进入，主要负责录入报名和缴费的信息。如需要也可录入签到信息。

如下图：

3. 需求合集

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

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

（1）业务流程图：

（2）需求说明

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

1）会员报名：

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

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

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

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

本次需要优化的内容，主要是针对系统在使用过程中，遇到的一些问题；

（编辑：ASP站长网）