CMM需求管理实践经验记录谈

在做了近四个多月的CMM翻译及文档整理资料工作后，为了验证CMM理论是否真正适合本部门的开发过程及引导提升的作用，最近参与一个项目的需求调研工作，这时候所处的角度就与原先处于开发人员的角度有所差异，此时，考虑的是如何在开发过程中加入CMM的KPA过程活动，在这个不大不小的项目中，在近一个多月的需求调研中，确确实实存在一些问题，值得我们开发人员去思考，这不仅仅涉及是否要按CMM要求去做，更涉及了如何做好需求，如何在需求调研中少走弯路，如何更能准确地制定需求;需求过程中的控制点、操作规程、协同运作等等。

　　分析阶段：“准备需求采集和分析”

　　管理要求：

　　① 阅读有关行业/技术概念上的背景资料或相关标准、公文、规则等等

　　② 熟悉客户的操作流程

　　③ 确定信息采集和分析的方法

　　④ 确定用户组和评审组，及评审方式

　　⑤ 项目风险的评估

　　大部分的需求调研中，以上的准备工作常常被忽略，在这次的操作中，虽然注意了该方面的运作，但还是出现了一些问题，影响了需求调研的工期。首先，确定信息采集和分析的方法，由于该系统是客户方的一个类似商务操作流的控制系统，在收集信息过程中，我们过于相信客户方最初提供的资料，在熟悉客户的流程后，依照客户方提供的资料进行项目的初步成本、工期、资源的核算。但是，在后面的调研时，客户业务流程发生较大的变动，细化点众多，功能点较原先估计的繁杂。出现这样的问题原因在于：1、客户原先手工操作无任何限制，而系统约束性较高。2、在需求调研中客户方发现其流程存在不合理的地方即产生变动，变动性大(该点我们无法控制)。3、与我们进行沟通的客户方人员无决策权。双方在讨论一个流程的实现过程中，对方无权对流程的简、繁进行决策，往往讨论半天实现该功能后，其部门经理一句话就推翻原先拟定的流程，在这点上浪费了许多时间，这也是我们准备过程中的一个失误，当初应该事先申明，沟通人员必须有一定的决策权(这是在确定用户组上的失策)。

　　当在熟悉、确定客户操作流程上，我们浪费了很多时间，至后来双方在沟通及决策上达成一定的协议后，后期的调研工作顺利很多，但最终产生的系统需求与原先客户提供的需求已经是截然不同的了，最终需求得出的成本、工期、使用资源都已翻了好几番。

　　分析阶段：“收集和分辨需求”

　　管理要求：

　　① 分辨技术(功能点)与非技术(交货日期、里程碑、协议条件等)需求

　　② 建立系统目标和范围

　　③ 收集相关技术需求(功能点、约束、处理等)

　　④ 收集用户特殊需求

　　⑤ 分析用户工作流程

　　⑦ 准备原型

　　该阶段工作较顺利，基本上按要求完成，其实该阶段与第一阶段―――“准备需求采集和分析”基本上可融合，故在双方按一定要求达成沟通协议后，在业务流程及功能点收集上进展较顺利，准确性也较高。

　　分析阶段：“分析—编写文档—评审”

　　根据收集到的功能需求，接下来，项目组各人分工进行模块功能需求的分析工作，按模块的操作角色、模块功能、输入、处理流程、输出等进行技术需求的细分析，该部分与编写文档同步进行。在进行分析及编写文档时，为了确定较准的最终功能需求，分析做得比较细，可以避免后期与客户的纠缠不清。分析时用UML画的业务流图在与客户沟通时发生一点问题，客户无法看懂其图内容，故建议以后项目内部沟通分析时采用UML用例图及流程图，与客户进行沟通时使用通用的流程图较方便。当各模块的分析文档完成时，单单模块功能就写了160多页，其中还不包括近五十张报表的分析数据。此时的功能需求与原先客户给的9页的需求已经大相径庭了。最终整合的需求依照“CMM系统需求规格说明书模板”进行编写，由于在每个模块分析时均注上标号，便于其后需求变更的跟踪及修改。

　　评审时准备采用CMM软件质量保证过程要求的“系统需求分析过程评审检查列表”，实际评审中与列表要求的还是会有一定的距离，标准度及执行度暂无法做到CMM完全要求的，只能尽量往其中的要求点靠拢了。其中“系统需求分析过程评审检查列表”的基本内容要求如下：

　　____软件需求分析被记录在软件需求说明书或者其他经核准的正式文档中

　　____软件来源的明确性

　　____对于用户给定的需求，文档记录是否完整及有遗漏项

　　____软件需求在配置管理下维持(配置标识)

　　____文字说明清晰、适当

　　____前后一致，变更依据是否充分，是否有正常的记录

　　____功能的可测试性

　　____评估需求的可行性，是否适用于软件实现

　　____软件开发计划、工作产品，以及活动的变更与软件需求的变更相一致

　　____验收被制定，并且使用来确定需求管理的状态

　　在评审中，以上的要求可以起到一定的引导作用。

　　分析阶段：“交付验收”

　　在交付给用户验收时，所需附上的产品有：各模块的功能分析文档、整合的需求规格说明书、需求验收文档。

　　管理要求：

　　① 客户对确定的需求无疑异，在验收文档上签字

　　② 若客户提出相应的变更，则为变更做好记录，修改后的变更依然应通过评审才能交付用户。

　　③ 客户签收的需求作为系统的需求基线确立下来，

　　分析阶段：“需求变更过程”

　　该过程主要针对确立需求基线后的变更。目前该项目还未涉及(待续!)

　　管理要求：

　　① 提出变更请求(变更项、变更原因)

　　② 变更可行性评估

　　③ 变更评审

　　④ 更新基线

　　CMM过程中有一个详细的“日常工作变更请求过程样例”，日后有机会再细谈该变更的管理过程及实现方式。

原文转自：http://www.ltesting.net