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

以笔者当前的公司为例，协同人员包括以下群体：

1. 产品经理：大部分公司都会有不止一个产品经理。每个产品经理在负责自己的产品线时，所输出的需求文档对其他产品经理的工作是有必要性的。
2. 设计师：以做静态页面、gif图、交互设计等视觉体验的专业人员。
3. 前端开发：以输入静态页面、交互动效为主，包含各类判断逻辑，最终以HTML为输出样式的专业人员。
4. APP开发：用户能看到的APP的页面样式、交互样式、逻辑输出的专业人员。
5. 后台开发：后台建表、设定逻辑规则，接口传输数据、字段的专业人员。
6. 测试工程师：检测产品在常规环境、非常规环境，检测所有存在因素及隐患的专业人员，是确保产品上线无Bug的最后一道防线。

3. “阐述”与“满足协同人员”间的关系

凡事的存在，皆存在因果。满足协同人员，此为因，而为了满足协同人员，输出的需求文档，即为果。因果之间互相作用，促成了产品最终的交付及上线。

把正确的东西交给正确的人，满足协同人员的诉求，即是需求文档存在的意义。

如何写出满足协同人员诉求的需求文档？首先，需要观察不同的协同人员具体的工作场景，基于他们工作场景中的冲突，发现他们的需求，从而输出的解决方案，就是最好的需求文档。

1. 产品经理的诉求

（1）产品部门的版本需求讨论、需求评审会。

在版本任务的讨论中，在与其他产品经理讲述所规划的功能时， 版本记录、项目背景、项目框架图、流程图，可以快速让其他产品经理了解整体项目，并根据项目背景，给出意见。

（2）与其他产品经理所负责的内容有交叉点。

当一个完整项目，每个产品经理负责部分内容的时候，各自负责部分功能的需求文档有助于其他产品经理从文档中发现交叉点中的衔接是否合适，各功能模块的整体融合性。

（3）Bug处理。

再厉害的程序员也不敢保证产品上线后不出现任何问题，当产品上线后出现问题，需求文档有助于产品经理快速找到规划的初衷，根据之前的情境给出精准的解决方案。

（4）版本迭代。

当产品在不同时期，做不同的版本迭代时，之前的需求文档尤为重要，有助于负责该项目的产品经理快速熟悉往期规划的初衷、目的和当前的效果及不足，并在迭代版本中对往期问题进行修复，在新的规划中避免不必要的坑。

（5）人员异动。

如果出现人员异动（人员项目变更、人员离职等），有助于新接手的产品经理快速熟悉项目，确保项目规划不会因个人经验、个人喜好、习惯等原因，出现太大的偏差。

基于以上场景和目的，其他产品经理对需求文档的诉求需要得到的信息：谁、在什么时间、因为什么原因，做了什么内容，满足了什么人的需求，变动内容及节点、阶段性规划。

2. 设计师的诉求

设计师是项目实施阶段的第一步。确定版的需求在落地执行时，首先是由设计师开始制作设计图。项目的整体功能有哪些、基于什么背景、未来的规划方向，需要在文档中给出建议和说明，有助于设计师按照产品经理的设想，设计出符合或高于期待的产品设计图。

基于上述场景和目的，针对设计师角色，产品经理在编写需求文档时，需要告知的信息：因为什么原因，给什么特点的群体，做什么图，当前竞品什么情况、公司什么情况、市场什么情况，想达到什么效果，后期发展方向（业务、功能、设计方向等）。

3. 开发人员的诉求（前端、APP、后台、测试）

1. 前端开发：开发过程中，侧重了解涉及前端部分的页面功能、交互效果、交互逻辑；
2. APP开发：开发过程中，侧重了解页面元素、页面样式、功能、与后台间的接口参数传递；
3. 后台开发：开发过程中，侧重了解功能、这些功能在后台的数据结构搭建、如何建表、功能逻辑、与前台兼的接口参数传递；
4. 测试工程师：在产品实现过程中，侧重从产品规划中了解整体功能，从而写测试用例，以及产品上线前根据设计图的样式、文档表述的功能规则，做功能测试。

基于删除场景，产品经理在编写需求文档时，需要告知开发人员的信息：因为什么原因，针对什么项目，做什么功能，包含哪些页面元素、页面样式、交互逻辑、实现效果。

4. 注意事项

尽信书不如无书。各公司的组织架构、部门角色划分、业务开展的推动因素、公司发展所处的阶段均不相同，虽大道同源，但总有差异化表现。

需要产品经理针对协同人员做好分层、分类，切实与相关人员深入沟通，了解他们的习惯，了解他们的认知，输出他们需要的需求文档，才能够确保信息的透明化，保证开发人员全面了解规划的内容。

同时，辅助以良好的沟通机制和技巧，则有助于开发效率的提高和产品上线的进度保障。