软件项目的需求变更管理
作者: 来源: 文字大小:[大][中][小]
软件项目的范围控制应该是在需求分析阶段就开始的，然而很多项目经理针对需求分析存在不少认识误区。
方法/步骤
误区1：开发商和用户仅就软件需求的基本轮廓达成一致即可，具体细节准备日后协商。
从项目管理角度分析，这是非常危险的，许多软件项目失败的最主要原因就是需求分析阶段对问题、流程、细节的描述不够准确，导致后期预算超支或者工期延误。
正确的方法是：在需求分析阶段，双方必须对项目的应用背景、功能需求、性能需求、
可靠性需求、可用性需求、操作界面需求、外部接口需求，以及项目评审的方法、标准、过程进行全面、细致地研究讨论，逐一进行明确。
误区2：软件需求是软件必需向用户提供的功能和界面，功能上满足需求就足够了。
从软件需求工程角度分析，这只是认识到了软件系统的功能需求，忽略了软件的非功能需求和设计约束，需求捕获不够全面。软件需求工程理论认为，软件需求包括功能需求、非功能需求和设计约束三方面内容。
正确的方法是：除了要明确软件的功能需求，还需要进一步明确非功能需求(即软件产品所必备的属性和品质，包括可靠性、可用性、安全性、可扩展性、可移植性等)和设计约束(即软件研发必须遵守的特定规约、限制条件、政策标准,如软件必须采用国内自主知识产权的数据库产品)。
误区3：需求调研的对象是用户，用户就是软件产品的最终使用人员。
从项目管理角度分析，该观点缺乏对项目相关人全面、系统的认识，对用户的概念理解不到位。“用户”是一种泛称，它可细分为客户、最终用户和间接用户三种类型。例如，很多企业的一把手并不直接参与软件的采购和操作，但是其对于软件项目实际上起到了关键意义的决定作用，属于最重要的间接用户。
正确的方法是：要充分认识用户的多重性、层次性、复杂性，在进行需求调研时应首先对用户进行分析、分类，根据重要性、优先级、特殊性对各类用户进行排序;其次，是针对不同类别的用户分别制订不同的需求调研计划，全面开展需求调研。需要重点指出的是，对于由多个业务部门共同参与的软件项目，在确认软件需求时一定要得到全部参与部门的共同认可。
误区4：按照“需求、设计、编程、测试”步骤研发出的软件不必考虑需求跟踪问题。
从软件工程角度分析，这是对于需求变更过程缺乏系统的认识的表现，严格线性顺序的开发模型并不能保证各个开发阶段的工作成果与需求保持一致。实际上，由于需求变更的不可预见性和必然性，各个阶段往往以螺旋的方式渐进。
正确的方法是：需求跟踪应该贯穿于整个软件需求管理阶段，需求跟踪的目标是实现《产品需求规格说明书》和软件产品之间的双向可追溯。
注意事项
有必要强调的是，在项目实施过程中，变更处理越早，难度越小，损失越小;变更处理越迟，难度越大，损失也越大。而且，任何变更都必须经过项目建设全部相关方(建设单位、承建单位和监理单位)多方确认后才能计划实施，严禁任何一方擅自变更。对项目变更的范围要有明确的界定，而且项目建设全部相关方对变更范围的理解上都没有任何异议。
最后，变更对项目质量、成本、进度都会产生影响,需要对变更过程加强监控，实施变更风险管理，不能因为变更而引发新的风险。项目管理人员在做出变更决策时，应及时将变更信息、变更计划方案公布于众，这样才能及时调整项目团队的工作，朝着新的方向努力。