编者按：
我们将围绕着“需求变更”这个主题展开讨论，希望对各位开发能有所帮助。让我们先来看一个需求变更的典型案例：
Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。
但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。
而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。
随后发生的事情让Steven更加为难：客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面， Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。
段落导航：
为了方便大家的阅读，我们将本期内容进行了合理的分类，您可以使用下面的链接浏览您感兴趣的主题。
对软件需求和需求变更的理解
需求变更的原因
需求变更的代价
减少需求变更
如何控制需求变更
需求变更的管理
实施需求变更管理需要遵循以下六大原则
应对之道
对软件需求和需求变更的理解
软件需求是整个软件项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，它不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的。软件需求是软件项目最难把握的问题，同时又是关系项目成败的关键因素，因此对于需求分析和需求变更的处理十分重要。
需求变更会给项目带来巨大的风险,会导致项目的成本费用增加、开发周期延长、产品质量下降及团队工作效率下降等不良后果，因而软件开发项目中应该尽量减少需求变更的出现频率。然而由于政府对特定软件的相关要求、用户部门市场战略的调整、工业界的发展等因素都可能带来需求的变更，而这些因素往往不可避免。在软件开发过程中如果只有一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。因而，对于需求变更应该正确的对待，尽量将其负面影响降低到最低。
需求变更的原因
需求包括业务需求、用户需求和功能需求。业务需求（Business Requirement ）反映了组织机构或客户对系统、产品高层次的目标要求，用户需求（User Requirement ）描述了用户使用产品必须完成的任务，功能需求（Functional Requirement ）定义了开发人员必须实现的软件功能。
项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~
http://www.leadge.com/pmqhd/index.html
