从软件开发的整个流程来讲，需求变更是软件行业，最令人忌惮的问题，一直困扰着我们的研发人员。南辕北辙的道理，每个人都明白。同样，需求变更的代价，会随着项目的进展成倍增长。按行业统计数据，如果在需求阶段只需要花费1个时间单位就能改正的错误，拖到设计阶段来改正需要5倍的时间，到了编码阶段将是10倍，测试阶段可能达到20-50倍，而到了运行或维护阶段或许达到200倍。这就好比盖房子，如果在设计阶段提出变更，只需要修改图纸，如果房子已经完工，却要推倒重来。
软件公司大部分成本是人力成本，研发周期越长，项目成本越高。需求错误，势必造成研发周期的延长，过长的研发周期正在吞噬企业的利润。而需求变更的根源，在需求捕获上，开始获得的需求如果是错误的，后续再好的设计都无济于事。捕获用户需求不像设计和编码那样纯技术化，不容易建立标准，多少会有一些个人经验主义。有不少企业的需求人员，把客户需求理解成，客户想做成什么样一个产品，果真是这样吗？为什么有些人拿来的需求，很少变更，其他人获得的需求却频繁的变更。我们来看看，很多人认为正确，并且还依然这么做的需求捕获方法：很多需求人员在和客户谈需求时，淡化业务，更多希望客户告诉他要做什么。有些有“经验”的需求人员过早的提供页面设计：“我给你做成这样的吧”，拿出笔和纸开始和客户讨论起页面显示什么内容，最后不忘让用户签字确认。
希望用户告诉他们要做什么，直接把对系统的呈现方式交给了用户。也有不少客户，因为不懂软件开发行业，所以会把需求理解成，系统做成什么样，直接告诉我们的需求人员，给我实现什么样一个功能。如果用户选择的方案不是最合适的，是拍脑袋想出来的，必将引发后续的需求变更。我见到的很多客户，提出的需求，拍脑袋得来的成分更多。
需求人员获得的这种需求，向研发传递的往往不是业务，而是某某功能能否实现。需求文档看中不到业务，而是项目背景，功能描述，页面显示栏位等内容。这种带界面的“需求“（实际上不是需求）本身会非常脆弱。后续任何界面的改动都会引起“需求”（实际上不是需求）的变动。同时也剥夺了ＵＩ设计人员的机会。到了编码阶段，程序员发现不合理的“需求”（实际上不是需求），提出的改进反而变成了“需求”（实际上不是需求）变更。
让客户在需求文档上签字确认，公司要求这么做，需求人员也热衷于这么做。客户签字，可以让客户慎重的提出的需求。但是，如果一开始捕获的需求就是错的需求，这种签字是否有约束力呢？签完字，最后改变的需求比比皆是。谁也不愿冒和客户关系闹僵的风险。没有良好的客户关系，项目注定也不会成功。这种签字更多的是为了一种流程（客户不签字，项目不能进行下去，客户没有其他选择）。客户怎能做到，在没有使用软件前，分析清楚系统是否符合业务要求呢。本人从事软件研发Ｎ年，自认为项目经验还算丰富，常为一个需求的实现方式，考虑很久。软件行业是公认的，高脑力劳动的行业，专业人士需要考虑很久的事情，让客户来精准的完成，太不现实。所以客户签字不代表需求正确，只要是错误的需求，就会变更。
其实，许多需求的变化是假的，真正的需求，至始至终一直在那里，根本就没有变。只是开始我们就没有找到，拍脑袋得来假的需求。如果用户使用很长一段时间后，才提出变更，才是真正的需求变更。作为需求人员，应该把注意力放在业务上，业务是相对稳定的。通过对业务的分析，产生出软件系统的需求。如果客户提出，需要实现某个功能。需求人员，可以通过询问客户为什么要做这个？客户工作上的困惑是什么？把客户对功能的实现引导到实际业务，这时候真正的需求或许已经呈现。软件是为了解决问题，用户的目的不同，解决方式也会不同，完全存在有更好更合理的方式解决用户的问题。但不明确真正的问题，谈何解决问题的正确。
业务分析通行的做法是，建立业务模型（推荐潘加宇老师的《软件方法》这本书）。如果需求人员没有开发背景，也没有需求分析的经验，或者就是商务人员，那就原原本本传递客户的业务，解决方案的最佳人员应该是设计和开发人员。需求分析完成后，由设计人员提供原型，客户来判断这个原型是否符合需求。需求文档中不应去描述页面的操作，而是以业务为中心分析业务，找到系统对业务的支撑点，寻找“需求”背后那个真正的需求。