软件需求文档怎么分析,软件需求分析怎么做

1. 写文档先看人

需求文档与产品经理前期做用户调研时的用户画像很相似。

在做用户画像时，通过与目标群体各种方式的沟通，获取用户的基本信息、兴趣、习惯、家庭情况、对产品相关业务的了解程度、接受程度、烦恼和期待等等，从而建立用户档案，输出用户的判断结果。

在写需求文档前，面对我们的用户——相关协同人员，产品经理需要去了解他们。了解他们的工作方式、工作习惯、工作态度、工作认知、工作能力等与工作相关的内容，同时，对他们与人相处的方式、生活习惯、兴趣爱好等等的了解，有助于产品经理更全面的了解，从而建立更加立体的用户画像。

在输出判断结果时会更准确，写需求文档会更有侧重点——哪些是他们需要知道的，哪些是他们需要特别详细表述的，哪些是需要特殊标注的，哪些是省略表述即可的。

2. 文档规范

（1）版本记录

1. 谁：该文档是谁编写的，便于快速找到对应的负责人员，同时，后期有助于在需求文档库中建档分类。
2. 时间：什么时间编写的该文档，旨在告知该功能是什么时间要开始做，便于后期溯源时，快速定位。
3. 事件：针对什么产品、什么功能做的规划，其实就是文档标题。
4. 版本号：便于记录产品不同版本的节点做了什么内容及调整，同时，针对不同的系统，有助于使用统一的版本号做管理。
5. 上线计划：依据上线计划倒推测试周期、开发周期、设计周期，从而给参与该项目的协同人员约定好时间，便于更好的把控项目进度。
6. 评审及修改：项目完成后的需求评审建议和结果，针对初稿内容做了哪些修改。此处一定要详细，后续调整内容时，评审建议和修改事项是很重要的可参考的细节点。

（2）版本说明

1. 项目背景：清楚地写出为什么要做该项目，谁要求做的。
2. 核心需求：为了解决什么冲突。
3. 预期目的：想达到什么结果，后续有什么进一步的规划。

详细的项目背景有助于所有参与人员快速地了解项目是怎么回事。

（3）设计规范

设计规范来源于产品经理对该产品的整体了解：在做完市场分析、行业分析、竞品机构分析、用户调研之后，针对自己要做的产品，产品经理会形成自己的整体构思和产品走向模型。

而这个构思就是需要表达给设计师的理念——要做一款什么样的产品，要达到什么效果。

关于设计理念的表达，不同的公司有很大的差别，以及整个行业对这块内容都没有统一的观点。

一种观点认为，产品经理只需要输出黑白灰原型图即可，其他的都交给设计师处理，给设计师足够的发挥空间；

另一种观点认为，设计师对要做的产品，不了解缘由，直接去设计会有偏差，最终交付的产品大部分都不符合；

还有种观点认为，要看设计师的水平再来决定，水平高的不需要产品经理说什么，都可以交付足够让人惊艳的设计，水平低的说再多，也做不出效果，而大部分公司都属于第二种情况。

综上所述，岗位不同、职位不同、个人认知的不同，以及最重要的信息接收到处理个人间都是有差异的，最终呈现在产品上的内容就会有很大的差异。

而规避这类问题，最好的方式还是沟通。充足且有效的沟通，确保产品经理与设计师间的已知信息达到一致，双方的理念、想法、建议等越碰撞越容易做出更好的产品。

主要对接的内容包含两个部分：

1. 信息与意向：传递产品信息，告知设计师关于该产品的设计原因、行业情况、要做的产品对标竞品是哪些，以后对产品的规划是什么、产品经理的意向是什么。
2. 基础设计理念：产品主题、整体色调、各样式的字号、色号、全局页面的建议等。

（4）功能列表

功能列表为产品经理在经过足够多的调研和分析，从汇总的产品需求池中筛选出的当前应处理需求列表。

功能列表的作用为便于相关人员全面了解产品的功能，从而评估项目周期、处理优先级等。

功能列表主要表述都做什么功能，哪些重要且紧急。列表参数包含：

1. 模块
2. 功能点
3. 功能点描述
4. 优先级（高、中、低）

（5）角色列表

角色列表为表述清楚该产品上线后，参与到该产品中的群体有哪些。列表参数包含：

1. 角色名称
2. 职责：在产品参与中的简要说明
3. 备注：特殊情形

（6）框架图

框架图为该产品包含什么内容：模块、功能。便于开发人员快速、便捷的了解产品全局。

框架图没必要做的很高大上，高大上固然很好，会让使用的人赏心悦目。但是，功能介绍简单易懂和开发人员能看懂、看明白更重要，千万不能舍本逐末。

（7）流程图

流程图分两个部分：

1. 整体流程图：整体流程为将产品各大模块之间的交互流程，一般做正向流程居多，辅助以部分判断流程和异常处理机制
2. 功能流程图：功能流程为涉及到具体的功能点的交互流程，包含：正向流程、规则、判断流程、异常流程。

（8）功能需求

功能需求为具体的各功能点，是需求文档的核心。主要是详细的分解各功能点，包含两个方面：

1. 前端：针对前端部分，页面如何来、页面元素、各功能点的规则、交互、跳转规则、非常规流程的页面元素、交互、跳转规则等等。
2. 后台部分：前端功能的实现，依靠后台的哪些逻辑和数据，是否需要做新功能模块、新功能模块的内容、数据的调用、存储、接口数据传值等等。

（9）非功能需求

非功能需求为用户常规操作产品时的极端情况，涉及很多内容，以下列举几个比较重要且常规规划中需要考虑的点：

1. 产品性能：产品对用户操作的响应、对群体操作的并发预防等。
2. 安全性：公司数据、用户信息的保密性处理，不同角色的权限设置、使用中的限制等。
3. 可靠性：用户操作中出现异常情况，是否可继续操作，遇到异常情况时数据或使用状态是否可被恢复等。
4. 拓展性：拓展性主要针对公司内部而言，产品完成后，无论是设计师、开发人员，还是测试人员，针对产品所做的工作，是否可以被复用到其他地方。用户在产品中的使用情况是否可被系统获取后用作不同维度的分析等。

需求文档中，对于功能的表述是尤为重要的，针对各功能点考虑的越详细，越有利于开发人员评估实现难度、评估时间、顺利达到所要的效果。

需求文档不是越详细越好，很多没必要的说明，不用耗费大量时间去编写，最核心的依旧是：让自己公司的相关人员能快速看懂，全面了解。

尽信书不如无书，各公司均不一样。产品经理应更多的站在自己公司的角度，在对相关协同人员充分了解后，输出他们需要的需求文档。

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

题图来自Unsplash，基于CC0协议