软件需求阶段—质量全面管控

1.4.3 软件需求阶段

在软件需求阶段，要分析客户的业务活动，确定系统的目的、范围、定义和功能，明确在用户的业务环境中软件系统需要"做什么"，如图1-7 所示。需求人员要提交《需求规格说明书》用于评审、估算成本和总结，需求说明书中包含的业务流程图可以帮助项目组成员理解业务需求。测试人员也需要参与需求分析、评审和总结。如有需要，可以重新估算成本和资源投入。

图1-7 软件需求阶段

在一个项目中，任何人员，如项目经理、架构师、研发人员、测试人员、系统人员、DBA等都可以外包。立项阶段、研发阶段、测试阶段和运维阶段等也都可以外包，唯一不能外包的就是需求。国外软件机构有过统计，项目失败90%以上的原因是需求问题。

需求分析阶段的产出是《软件需求规格说明书》和用户界面原型设计，这里着重讲解用户界面原型设计。如图1-8所示就是一个超市订货单的用户界面原型设计，读者可以进行参考。

图1-8 超市订货单用户界面原型设计

需求也是项目的灵魂，有了需求才有项目开展的可能。但初期的用户需求并不能作为项目实施的依据，最多可以作为项目的指导性意见或者方向，因为初期的需求绝大部分是由业务部门提出的，不够具体，功能点不明确，没有逻辑，也没有具体流程，在实际的项目执行过程中并没有多大的参考意义。所以，在有了初期的用户需求后，接下来就要进一步丰富和细化需求，每个功能点、计算逻辑、数据来源、处理流程、角色、权限、配置等，分析落地的可能性，然后进一步进行需求梳理、整合和丰富，进而加工成可以系统化的内容，进行产品选型，然后用技术实现。

基于以上内容，在实际的项目实施过程中需要注意以下几点。

（1）需求的调研、挖掘和整理必须由项目经理牵头，由产品经理、业务需求方，甚至系统架构师一起完成需求的收集整理。当然，这里面要分甲方项目和乙方项目，基于笔者的经验，如果是甲方项目，建议需求完全由甲方的项目经理和产品经理负责跟业务需求方一起收集整理，收集整理完毕后可以交由供应商实施，也可交由自己的研发团队完成。如果是纯乙方项目，即甲方只有业务方，则乙方在收集整理甲方的需求时一定要注意需求范围的控制，如果需求过多过大，建议分多期、多个阶段实施完成，一方面减少乙方的项目验收风险，另一方面缩短项目周期，也有利于保持项目团队的战斗激情。

（2）功能点、数据计算逻辑、业务处理流程、权限控制和用户界面原型一定要跟业务部门相关需求方确认清楚，不管是甲方还是乙方的业务部门，让其对整理过的需求进行确认是很有必要的。

（3）针对需求部分着重强调一点，在需求收集整理和挖掘的过程中，作为技术实施方的代表，尤其是产品经理将直接决定后期的项目实施团队是否存在项目延期的风险。所以，产品经理或者项目经理要负责把控用户的需求，尤其要引导客户的需求，整个项目实施过程就会相对轻松很多。

表1-6定义了需求阶段的条件、活动、标准输入和标准输出，并且确定了责任人。

表1-6 需求阶段的活动和输入输出

1.4.4 变更管理

在整个软件开发过程中，需求变更会带来不确定性，但又不可避免。需求变更若无管理流程来引导和解决冲突，会导致开发测试得到的信息不完整，造成后续产品维护困难。

因此，既不能一概地拒绝需求变更要求，也不能一味地迁就变更要求，控制需求变更才是最好的应对策略。为了确保需求变更符合双方的利益，可以采取如下措施来控制需求变更。

分级管理需求变更

按照变更的影响程度和客户投入，可以分成关键性需求、后续关键性需求、后续重要需求、改良型需求和可选性需求。在时间优先级上进行管理和控制。

软件生命周期全过程需求变更管理

对一个需求分析做得很好的项目来说，需求规格说明书定义的范围越详细清晰，用户跟项目经理提出需求变更的几率就越小。

专人负责需求变更管理工作

使用需求管理 工具 来控制需求变更。设立专门的CCB（变更控制委员会）对需求变更进行评审、裁定和验证。CCB由项目所涉及的多方人员共同组成，包括用户方和开发方的决策人员，如项目经理、架构师、开发人员和测试工程师。

契约化管理需求变更

合作双方在签订协议之初，书面约定需求变更的提出方式、评价程序、修改要求、执行过程及验收要求等，只有这样才能确保需求变更按程序和要求有序进行。

需求变更信息化

需求变更必须提前沟通，双方要加强信息交换，防止搞突然袭击，更不能提出超越双方能力范围的需求变更。

如图1-9所示的变更管理流程运行图描述了各个角色在各个阶段的任务。

图1-9 变更管理流程运行图

表1-7定义了变更阶段的条件、活动、标准输入和标准输出，并且确定了责任人。

表1-7 变更阶段的活动和输入输出

1.4.5 设计阶段

软件设计的主要任务是把需求分析得到的结果转换为软件结构和数据结构，建立目标系统的逻辑模型，从而形成系统架构，明确软件系统应该"怎样做"。如图1-10所示列出了设计阶段各个角色的任务和产出。系统架构师和开发人员会做出一份《概要设计说明书》和《详细设计说明书》。

测试人员要根据需求文档细化系统测试、集成测试和单元测试的计划和用例设计， 参与评审和总结。当然如有需要，可重新估算成本、人力和时间。

图1-10 软件设计阶段

软件系统的设计是关系软件成败的重要因素。系统设计人员要专注于分析问题本身，挖掘重要的业务领域概念，并建立业务领域概念之间的关系，帮助用户及需求分析人员建立业务概念，确定用户业务的问题域和系统涉及的业务范围等，确定系统的整体架构，最终形成软件设计文档。

在设计阶段需要考虑如下因素:

· 从业务描述中提取名词；

· 从提取出来的名词中总结业务实体，区分名词中的属性、角色、实体、实例，形成问题域中操作实体的集合；

· 从业务实体集合中抽象业务模型，建立问题域的概念；

· 分析出模型实体，然后找出模型实体之间的关系；

· 用UML方法和图例进行领域模型设计，确定模型之间的关系；

· 在软件设计阶段需要保证各个模块的重用性和可扩展性；

· 运用 设计模式 封装变化，降低偶合，实现低耦合、高内聚；

· 通过面向对象思想解耦，将具体的东西抽象处理，分散的东西集中处理，解除对象之间的依赖。

表1-8定义了设计阶段的条件、活动、标准输入和标准输出，并且确定了责任人。

表1-8 设计阶段的活动和输入输出

1.4.6 构建阶段

开发人员将上一个阶段详细设计的处理过程转换成计算机源代码，单元测试后提交给测试人员执行必要的测试。测试人员需要协助开发人员对单元测试的计划和用例进行评审和指导，参与总结和重新估算。在构建阶段结束后，测试人员需要提供开发阶段的审计报告供项目经理做参考。如图1-11所示列出了构建阶段各个角色的任务和产出。

图1-11 构建阶段

构建的规模大、项目多、速度快、业务复杂度高，针对这些问题，读者可以采用如下方法避免构建中的复杂性：

· 采用MAVEN、ANT等构建工具进行自动化构建，避免人为操作失误；

· 软件的包、版本进行统一管理，避免不同版本的直接冲突；

· 注意各个环境的一致性，保证构建脚本执行成功；

· 降低软件工程中模块构建的耦合度，提高软件功能模块构建系统的灵活性；

· 引用构建平台，监控构建日志，及时发现构建时的错误；

· 对构建失败进行总结分析，优化构建流程。

表1-9定义了构建阶段的条件、活动、标准输入和标准输出，并且确定了责任人。

表1-9 构建阶段的活动和输入输出