软件生产一般包括“需求管理”、“流程设计管理”、“开发管理”、“测试管理”等主要过程。那么，软件的质量管理是从哪一个环节开始的呢？不是从设计阶段，更不是开发阶段，而是从软件需求阶段就开始了。在软件生产过程中，“软件需求”的调查报告是一个生产过程的开始，软件质量的管理之路也就随之开始了。

为什么要管理软件需求

简单讲，软件开发团队的成功就是满足软件项目的需求。当今世界对软件的依赖程度急剧增长，面对质量和交付周期的固有矛盾以及各种动态因素的综合作用，软件需求日益复杂，软件开发成为一项跨越技能、职责范围和时间阶段的综合团队活动，协调统一是成功的必要条件。软件需求是统一的核心线索，需求管理正是协调的必由之路。

严格意义上，需求是系统或软件必须达到的目标和能力；需求管理是一种系统方法，用来获取、组织和记录需求，建立并维护客户、用户和开发机构之间针对需求变化的协议。

众多的实践证明，良好的需求管理对于降低开发成本和保障项目成功至关重要。根据权威机构的统计，在全世界范围，仅有1/4的软件开发项目能在规定的时间和预算内达到客户的目标。纵观这些项目各自总结出的十项首要成功经验，我们总能找到三个要素: 有效的用户参与，明确的业务目标和稳定的基本需求。这三个要素的核心内容是软件需求，其核心活动是需求管理。

CMM2对软件需求管理的指导

针对如何提高软件质量和开发效率，CMM为我们提供了一套的综合见解和完整的框架，CMM对软件开发机构投入产出比(ROI)的卓著贡献已经得到业界的广泛认可。

需求管理是CMM2级的首要关键过程领域(KPA)，是软件开发活动中不可或缺的组成部分。需求管理的目的是在客户和开发机构之间建立一个共识，形成软件工程所必须的管理基线，从而对需求实施有效的控制。在软件开发活动中，所有的活动计划，日程安排，交付工件都要直接或间接地和需求保持一致，这是贯穿于CMM体系中的一个重要理念和准则。只有基于这种准则，软件开发组织才有可能进入浑然一体的境界：软件的技术需求，项目计划以及各项相关活动协调一致，井井有序。为了实现这一目标，开发组织需要付出的努力是多方面的。

最基本地，经过相关涉众（涉众：会受到作为结果的目标软件系统实质性影响的个人。）审阅的软件需求必须形成"文档"。对"文档"的理解不应仅局限于平面化的文字文档，文档的存在形式可以是多种多样的，关键是文档所记录的内容能够为不同工种提供可用的信息依据。软件需求规约(SRS)作为项目的核心文档，用以全面详实地定义软件需求的要素。另外，面向客户和最终用户的通用词汇，描述软件产品"做什么和为什么做"的高层次规约也很重要。

为了达到有效管理软件需求的目标，开发机构必须投入必要的人力、资金和管理层支持。软件工程团队的成员和不同工种的团队成员应当接受必要的培训，以便完成与角色相应的需求管理任务。培训的内容要覆盖过程方法，标准以及针对应用领域的一些特殊问题。

软件需求的变更应当作为项目计划的有机组成部分被审阅。需求变更所牵涉的人员能够通过有效的机制来磋商和评估由于变更导致的影响。针对磋商和评估活动中的权衡和分析工作，CMM建议我们至少要掌握三个方面信息: 软件需求的状态，软件需求的变更内容和累计变更次数，待决定的、被建议的、被批准的以及被融入基线的软件需求变更的个数统计信息。

CMM3对软件需求管理的指导

根据CMM的建议，不应将需求管理当作瀑布式的简单文档化流程。CMM的一个显著的特征是将软件需求作为一个活跃的实体贯穿于整个开发过程之中，实施有效的需求管理事实上渗透在CMM的不同层次(Level)和众多关键过程领域之中。

对于那些准备通过CMM3级评测的开发机构而言，基于一种被定义和文档化的标准实践流程从事软件开发活动是工作的重点，该级别涉及到七个关键过程领域。其中"软件产品工程"一项旨在有机整合各项活动，目标是快速有效地生产高质量的软件产品。该关键过程领域中明确指出: "软件需求的获取、维护、归档和校验有赖于系统化的分析，这种分析要以项目所定义的软件开发流程为根据。"该分析过程的目的是保证软件需求自身的有效性。

关键过程领域"软件产品工程"中还明确指出: "一致性的维护要贯穿软件开发过程中的各种类型的工件（工件：由软件开发流程所生成或使用的一组信息。），包括软件开发计划，过程描述，需求信息，软件设计，编码，测试计划，以及测试流程。"根据CMM的指导，各种有价值的软件工件都需要归档和维护以确保其可用。

根据CMM的建议，软件需求的变更被接受为软件开发活动中的一个必然组成部分。“冻结需求规约"的做法显然已经不能适应当今的商业环境和技术环境。取而代之的做法是建立相对稳定的软件需求基线，并将其融合到系统化的开发活动当中，以确保对需求变更的控制能够跨越不同工种和覆盖整个生命周期。

CMM给出了几点针对性的指导建议: 变更需要经过提请，分析并且在合适的条件下被整合；需求的变更得到批准并加以整和之后，相应的工件和活动才能变更；在变更发生之前确定该变更所带来的影响，团队之间要针对变更进行必要的沟通和协商；所有的变更从始至终被跟踪。在以需求为核心线索的开发过程中，确保所有的需求变更从始至终被跟踪是掌握开发活动来龙去脉的基本保证。需求的修订要被一组具有代表性和权威性的涉众代表审阅并认可后方可得到批准，这样能够确保在修订的需求中体现出不同背景和立场的影响力。涉众包括客户，最终用户，项目管理人员以及软件测试人员等。

根据CMM的要求，所有被批准的变更都要被从始至终地记录在案，用作记录相关信息的文档也要接受控制和管理。此外，我们还需要掌握用以确定软件产品功能、质量及开发活动状态的信息。 总 结

作为一种广泛的和具有影响力的软件过程控制和评估框架，CMM只有映射到一个具体的系统化软件流程中才能体现出其真正的价值。换言之，准备通过CMM评估的开发机构应该以现有的流程和方法作为改进和优化其流程的基本出发点。

在软件需求管理方面，对于准备通过CMM2级评测的开发机构，团队应将注意力放在以下几个方面:

* 软件需求必须形成文档；

* 软件需求必须能被控制，进而建立工程和管理的基线；

* 成员必须接受需求管理培训；

* 建立衡量需求状态的信息。

对于准备通过CMM3级评测的开发机构，应将注意力放在以下几个方面:

* 对需求进行系统化分析，确保软件需求完整性，一致性和可测试性；

* 软件需求、设计、编码和测试用例都能够回溯到相应的源头，在需求发生实质变更之前能够判别该变更所带来的潜在影响；

* 需求的修订应遵从统一的流程，需求的变更应从始至终被跟踪，软件需求文档应当通过配置和变更管理工具进行管理。

最后要强调的是，过程成熟度水平是衡量机构开发流程成熟度的标准，不应该被当作开发流程改进的奋斗目标。开发机构切忌本末倒置，应该以现有流程为基础，实事求是地改进、优化各项具体工作，参照过程成熟度模型全面提升开发机构的需求管理能力。

（责任编辑 尤北）