写作目的
接上一篇《报表需求分析的那些事儿》。近来发现一些做软件或需求的流程不规范而导致落地结果不尽人意的点。思来想去，我想把一些软件需求分析已成体系化的流程总结出来，供银行、互联网公司以外的行业参考。
软件需求分析都干什么
在招聘网站上找了比较普遍的岗位职责：
1.负责指定产品的需求分析工作
1）需求深入挖掘。这个比较好理解，就是业务提的需求可能是1个点，你需要在大脑中搜索与这个点相关的面或立体，从而引导业务需求
2）需求质量保障。基本的要求是产出的PRD（产品需求文档）既覆盖业务需求又能有效指导开发
3）系统分析。当需求涉及到不同系统接口调用、数据流转、状态更新等情况时，需求分析师需要一定的逻辑思维周全的考虑每一步流程节点，为后续开发做指导
4）需求管理。这是项目管理的一部分，就是需求控制，一方面满足各相关方增删改查的需要，另一方面，对需求蔓延做修正预防，给可怜的开发人员留有喘息的空间
2.参与业务需求讨论与设计，根据产品需求实现详细需求分析并形成标准文档（业内叫PRD）；
3.与开发测试团队一起保证最终产品发布。
这里我想介绍一下压力不小于程序员的软件测试人员，ta处于质量把控最重要的关卡，ta的职责是检验所有需求是否实现或检验预测结果与实际结果有多大偏差
4.保障产品目标和产品需求的正确性、合理性、以及在各线条上准确一致的传递和实现；
这点可以参考传话游戏，考验的是软件需求分析人员与不通角色的沟通能力，至少要准备2套语言，一套跟业务交流，保证你充分理解业务需求，另一套跟技术（程序员、软件测试员）交流，保证技术了解业务想实现什么具体功能要求
5.需求迭代。
大多数情况是前4项工作没有完美的落地（例如，业务发现还有衍生需求，技术发现程序漏洞、测试发现BUG没有修复。。。）这时你要对用户，研发部门，测试部门等相关人员和部门反馈的问题进行收集，并整理成需求，如此循环；
为什么有软件需求分析这个岗位
前面讲的工作职责，大致可以猜到这个岗位是业务和技术中间的沟通桥梁。为什么呢，大多数业务不懂技术，大多数技术不了解业务，两者沟通时往往是“鸡同鸭讲”，在这种情况下产生了“软件需求分析”，ta来有效的将业务需求理解转化成规范的“语言”与开发讲解，确保信息一致性，从而拉近理想与现实的差距（此处的梗，请见上一篇文章的配图，^_^）。
