理顺软件开发各个环节-4（需求管理-软件需求-1）
4.4 软件需求分析
软件需求分析，对开发团队而言，是软件开发工作的起点。
软件需求分析，是非常重要的节点，但实际情况是，在敏捷开发时代，很多研发团队错把产品需求作为软件需求。产品需求是以用户的语言表述的，而软件需求是开发人员的语言表达的，两者的受众是不同的。因此，软件需求分析不可省略。
不做软件需求分析，我认为有以下问题：
- 开发人员在开发软件时，根据产品需求，自己脑子里仍然有做软件需求分析，或者在草稿纸涂涂写写，梳理一下，这种“线下”的做法没有经过评审环节，质量难以保障，返工的情况很多；
- 不同开发人员自己做的“线下”需求分析，相互之间沟通成本很高，软件需求碎片化，导致软件需求的完整性很成问题，开发的软件容易埋下更多的坑；
- 没有文档化的软件需求分析，软件产品的维护成本很高。
责任人：开发项目经理。
执行人：系统分析员、高级程序员或架构师。
关键行为：分析和沟通。
-
分析：对产品需求进行分析，或者说对每个用户故事进行分析；
-
沟通：
-
与产品经理沟通；
-
必要时，与最终用户沟通；
-
与产品的上下游接口方沟通；
-
开发团队内部的讨论沟通。
-
输入：
-
产品需求规格书；
-
UI&UE交互设计原型（如果有）；
-
用户故事；
-
相关标准化文件：
-
国际标准、规范；
-
国家标准；
-
行业标准；
-
企业标准。
-
-
相关外部接口文档。
输出：
-
软件需求规格书（SRS）；
-
数据字典（DD）；
-
相关接口文档。
职责要求：
-
完整地分析产品需求；
-
分析每个产品需求项或用户故事：
-
需求表达是否清晰？
-
有无需要澄清的问题？如有，通过反复沟通来澄清；
-
技术可行性：是否存在较大的未知技术风险，必要时预研一下；
-
用户故事要素是否完备？
-
特别是验收标准，如无，与产品经理一起商定，验收标准要合理。
-
较高的标准：意味着较高的代价；
-
较低的标准：用户体验差。
-
-
暂不开发的需求项：需简单地评估技术可行性，避免依据局部需求而做出的设计方案不能满足未来需求；可以不详细展开分析。
-
-
提请软件需求评审：
-
需求分析人员：主讲人，负责讲解和答复各种质询和疑问；
-
产品经理：评估产品需求是否被清晰、完整、无差错地表述，有无技术障碍；
-
用户代表（市场、销售、客服）：最好对业务比较熟悉，对代表的角色的需求较明晰，评估需求的完整性、准确性；
-
项目经理：了解需求的相关方，便于协调开发、测试、部署资源；
-
开发技术人员：了解软件需求，便于开发时对业务的理解；
-
测试技术人员：了解软件需求，便于测试时对业务的理解，重点是需求的可验证性；
-
运维人员：了解软件需求，对产品部署的需求。
-
