参考博客https://www.cnblogs.com/alabo1999/p/12933811.html
软件需求分析
软件需求分析，对于开发团队而言，是软件开发工作的起点。
软件需求分析，是非常重要的节点，但是实际情况是，在敏捷开发时代，很多研发团队错把产品需求作为软件需求。产品需求是以用户的语言表述的，而软件需求是开发人员语言表达的，两者的受众是不同的。因此，软件需求分析不可省略。
不做软件需求分析，我认为有以下问题：
1开发人员在开发软件时，根据产品需求，自己脑子里仍然有做软件需求分析，或者在草稿纸涂涂写写，梳理以下，这种“线下”的做法没有经过评审环节，质量难以保障，返工的情况很多
2不同开发人员自己做的”线下“需求分析，相互之间沟通成本很高，软件需求碎片化，导致软件需求的完整性很成问题，开发的软件容易埋下更多的坑
3没有文档化的软件需求分析，软件产品的维护成本很高
对产品需求理解完整，然后用开发人员理解的语言将之表达出来，即软件需求分析，基于此的系统分析设计才有可能符合产品需求，而不至于因为对某些需求的忽视，在后期加入时发现系统结构失效的情况发生。
软件需求分析节点关键信息
责任人：开发项目经理
执行人：系统分析员、高级程序员或架构师
关键行为：分析和沟通
分析：对产品需求进行分析，或者说对每个用户故事进行分析
沟通：
与产品经理沟通；
必要时，与最终用户沟通；
与产品的上下游接口方沟通；
开发团队内部的讨论沟通
输入：
产品需求规格书
UI&UE交互设计原型
用户故事
相关标准化文件（国际标准 国家标准 行业标准 企业标准）
相关外部接口文档
输出：
软件需求规格书（SRS）
数据字典（DD）
相关接口文档
职责要求：
1完整地分析产品需求
2分析每个产品需求项或用户故事
需求表达是否清晰？
有无需要澄清的问题？如有，通过反复沟通来澄清
技术可行性：是否存在较大的未知技术风险，必要时，预研一下
用户故事要素是否完备
特别是验收标准，如无，与产品经理一起商定，验收标准要合理。
较高的标准：意味着较高的代价
较低的标准：用户体验差
暂不开发的需求项：需简单地评估技术可行性，避免依据局部需求而做出的设计方案不能满足未来需求；可以不详细展开分析。
提请软件需求评审：
需求分析员：主讲人，负责讲解和答复各种质疑和疑问
产品经理：评估产品需求是否被清晰、完整、无差错表述，有无技术障碍；
用户代表（市场、销售、客服）：最好对业务比较熟悉，对代表的角色的需求较明晰，评估需求完整性、准确性
项目经理：了解需求相关方，便于协调开发、测试、部署资源
开发技术人员：了解软件需求，便于开发时对业务的理解
测试技术人员：了解软件需求，便于测试时对业务的理解，重点是需求的可验证性
运维人员：了解软件需求，对产品部署的需求
软件需求分析的必要性
1 因为软件需求分析将产品转化为软件需求，即将用户（业务）语言表达的产品需求转化为开发人员语言表达的软件需求，使得开发、测试人员更能准确、完整的理解需求
2因为软件需求分析，清晰完整地表述软件需求，基于此开展的设计方案才能考虑得更加全面、更加有弹性，评审设计方案也有据可依。
3只有做了软件需求分析，才能了解软件的需求集合的实际规模，估算软件产品的开发工作量才能相对靠谱，再结合人力资源情况，给出开发计划。
只有产品需求清单，没有做软件需求分析的情况下，给出软件开发计划是困难的。此时很多模块是灰盒子，朦朦胧胧，软件需求没有明晰，工作量测算是拍脑袋定的。如果工作量算少了，后期开发时需频繁调整开发计划，开发团队加班加点还顶一个拖延进度的帽子，心情可想而知；如果工作量多算，管理者又不满意，认为没多少需求，怎么要这么多时间！因为没有软件需求分析，开发项目经理拿不出明细条目来，没法据理力争，结果开发计划往往是按领导的意思去做。
而做过软件需求分析后，情况就大不相同
首先，全部的需求集是明晰的，每个需求项的工作量也容易测算的，因此工作量的估算不会偏差很多。其次，可以根据需求的优先级，结合开发资源情况，规划版本计划，确定在哪个时间点开发完成哪些需求项，提供些什么功能，达到什么效果？
软件需求分析确实原因探讨
软件需求分析在瀑布式开发模式的时代，是不可逾越的阶段。而如今，敏捷开发大行其道之时，很多研发团队往往能省则省。为什么如此：
1 一部分管理者对软件需求分析的重要性理解不足，软件需求分析需要时间，这段时间只是纸面作业，看不到有形的输出，不愿意付出这些时间成本。
2 软件需求分析和设计阶段，不需要整个开发团队的成员全部参与，这段时间的工作安排，对开发管理者是个挑战，如果针对产品需求，直接编码实现，这样大家都有活干了。
3 需求变更时，软件需求分析文档的及时更新维护成本过高，经常没有及时更新，导致需求说明书最后版本与实际有所偏差，最后流于形式。