理顺软件开发各个环节-4

目录：

　　4.4 软件需求分析

　　　　4.4.1 软件需求分析节点关键信息

 

4.4 软件需求分析

　　软件需求分析，对开发团队而言，是软件开发工做的起点。　

　　软件需求分析，是很是重要的节点，但实际状况是，在敏捷开发时代，不少研发团队错把产品需求做为软件需求。产品需求是以用户的语言表述的，而软件需求是开发人员的语言表达的，二者的受众是不一样的。所以，软件需求分析不可省略。

　　不作软件需求分析，我认为有如下问题：

•  开发人员在开发软件时，根据产品需求，本身脑子里仍然有作软件需求分析，或者在草稿纸涂涂写写，梳理一下，这种“线下”的作法没有通过评审环节，质量难以保障，返工的状况不少；
•  不一样开发人员本身作的“线下”需求分析，相互之间沟通成本很高，软件需求碎片化，致使软件需求的完整性很成问题，开发的软件容易埋下更多的坑；
•  没有文档化的软件需求分析，软件产品的维护成本很高。

　　我认为，对产品需求的理解要完整，而后用开发人员理解的语言将之表达出来，即软件需求分析，基于此的系统分析设计才有可能符合产品需求，而不至于由于对某些需求的忽视，在后期加入时发现系统结构失效的状况发生。

4.4.1 软件需求分析节点关键信息

责任人：开发项目经理。

执行人：系统分析员、高级程序员或架构师。

关键行为：分析和沟通。

• 分析：对产品需求进行分析，或者说对每一个用户故事进行分析；

• 沟通：

  • 与产品经理沟通；

  • 必要时，与最终用户沟通；

  • 与产品的上下游接口方沟通；

  • 开发团队内部的讨论沟通。

输入：

• 产品需求规格书；

• UI&UE交互设计原型（若是有）；

• 用户故事；

• 相关标准化文件：

  • 国际标准、规范；

  • 国家标准；

  • 行业标准；

  • 企业标准。

• 相关外部接口文档。

输出：

• 软件需求规格书（SRS）；

• 数据字典（DD）；

• 相关接口文档。

职责要求：

• 完整地分析产品需求；

• 分析每一个产品需求项或用户故事：

  • 需求表达是否清晰？

  • 有无须要澄清的问题？若有，经过反复沟通来澄清；

  • 技术可行性：是否存在较大的未知技术风险，必要时预研一下；

  • 用户故事要素是否完备？

  • 特别是验收标准，如无，与产品经理一块儿商定，验收标准要合理。

    • 较高的标准：意味着较高的代价；

    • 较低的标准：用户体验差。

  • 暂不开发的需求项：需简单地评估技术可行性，避免依据局部需求而作出的设计方案不能知足将来需求；能够不详细展开分析。

• 提请软件需求评审：

  • 需求分析人员：主讲人，负责讲解和答复各类质询和疑问；

  • 产品经理：评估产品需求是否被清晰、完整、无差错地表述，有无技术障碍；

  • 用户表明（市场、销售、客服）：最好对业务比较熟悉，对表明的角色的需求较明晰，评估需求的完整性、准确性；

  • 项目经理：了解需求的相关方，便于协调开发、测试、部署资源；

  • 开发技术人员：了解软件需求，便于开发时对业务的理解；

  • 测试技术人员：了解软件需求，便于测试时对业务的理解，重点是需求的可验证性；

  • 运维人员：了解软件需求，对产品部署的需求。