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

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

本文的“初期需求分析文档”不是产品经理工作中输出的产品需求说明书（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）**报名：

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

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

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

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

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

具体如下：

1. 有些人报名时填写的手机号码是明显错误的，现在填写的信息有“1”、“11111111”、“ajdiwk”等情况，希望可以提高准确率，比如可以限制位数、数字验证等方法。
2. 页面中“姓名”的位置有填写单位名称或多人姓名的情况，希望本次优化中可以减少此种情况的发生。由于参**人员中**有少数民族的情况，名字字数比较长，根据以往报名人的名字长度分析，一般都在8个汉字以内。
3. 很多人的性别和拼房信息是错误的，因为现在的方式是有一个默认选项，部分人就直接略过不去选择了，提交后也可报名成功，很容易被忽略。希望去掉现在的默认选项，必须选择才可以通过。
4. 为了实现报名情况按照省、市统计的功能，报名信息中还需要增加省市的信息，最好用下拉选择的方式。
5. **报名信息中需要带入本**已有的相关信息。

报名成功后希望可以收到短信提醒，说明报名的基本情况，内容可包含**议名称、**议地点、**议时间等内容。

注：关于**的登录方式，现在是**账号登录；现有的**注册包括两种情况，一部分是用户自己注册的，另一部分是我们的工作人员录入注册的，这部分主要是为了增加**数量，这种情况下更不容易记住用户名和密码，下次登录就成了问题，所以我们采取后置关联的方式，关联用户基本信息，如：手机号码、姓名及相关信息进行识别关联，覆盖之前用户信息；这样用户便可以使用手机号码登录。

为他人报名

**登录后还可以选择为他人报名，选择“为他人报名”后，填写参**人的报名信息即可完成报名。报名完成后还可以继续为他人报名，直到将所有需要参**的人员都报完为止。

2）非**报名

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

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

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

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

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

不一一举例了……等

4. 其他说明

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

例如：报名单（原线下使用）、回执单、**议小条、发票信息、现场签到表。

“**议小条”数据项包括序号、缴费金额、房间类型、数量、资料份数、房间号码；样式如下：

现场签到表；样式如下：

四、总结

一个小白能看的懂的需求分析文档，要搞定三点

1. 先明白文档读者是谁，对症下药，不盲目揣测、预言；设计经验固然有用，但请慎用，不要自以为，要用户以为。
2. 文档呈现的内容一定要够落地，让任何一个用户看见之后，能够清晰知道这个产品是做什么的，解决什么问题，存在的价值是什么。
3. 模板！模板！模板！任何一个文档模板都是可以自行定义的，你的工作方式不同，文档输出内容就一定**存在差异，以上模板只是一个举例，可以自己雕琢一番。

些许经验分享

很多产品人都很清楚，在过往经历中，一定存在这样的场景，需求到手，没有形成内容落地，直接进行设计；这里可能存在各种外在因素（项目紧急、赶进度、对行业深究不足，过于盲目…等）导致这一环节遗失，直接从需求过度到功能框架、原型设计；这可以理解，但不要掉以轻心，毕竟这是对原始需求的一种留痕。

在简单点说，可以把这个“小白版”的需求分析文档，当做一次**议记录，用最简单，最直白的大白话记录下来，未来翻过来看看，非常清晰的知道，当初的需求是什么，而不是资料的一层层翻阅。

每日一语

年少的时日从我身边滑过，而我从来不知道，那已是生活；

珍惜我们每一次的努力，每一次需求的探索，都是对未知的渴望，也是对自己的沉淀。

作者：逐流；微信公众号：Unique先森说产品（ID：Unique_Mr_z）

本文由 @逐流 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议