原文链接：http://www.51testing.com/?103489/action_viewspace_itemid_70804.html
之前一个朋友问起我，说做了那么多年开发，谈谈有些项目为何失败。朋友说项目失败很大的原因是在合同问题，合同没有很好的列出项目范围。其实，合同的范围只是一般的范围，详细内容应该不属于合同的一部分。所以我觉得项目最大的问题还是需求没做好。需求没有做好，主要表现在以下几个方面：
一、需求采集与分析
1、需求采集分析时，没有从完整的业务流程出发，容易关注主要业务需求，而造成次要业务需求块的遗漏。
之前检查了我们公司一个重要项目的需求做得咋样，光看需求提问单，就发现大部分问题是关于功能需求的。而问起业务需求时，他们说都很清楚了，但问起业务上细节处理时，大家都恍然大悟：“哦，这里需要再问下客户...”。
2、开发人员除了关注采集功能需求、外部接口需求、性能需求和一般的标准需求外，往往容易忽略系统领域的背景、操作环境需求、用户特殊需求（例如用户熟练使用的工具与方法）等。
二、需求定义与确认
需求规格说明书是将人们思想中的概念和目标转换成正式的文档，在这个过程中，很容易产生错误，例如表达不完整，不正确的事实，不一致或模糊的需求等。因此，一定要正确详细的进行需求定义与验证，确保规格化的内容确实是用户所需求的东西。
三、需求变更
需求变更管理有两个方面，一是与客户就怎样变更达成一致，一个是进行变更流程控制活动。在这两个方面都容易出错。
1、与客户达成一致方面，需要让客户意识到变更对项目影响的后果，要技巧性+友好性的将变更加入到协商条款中。在评估需求变更达到一定的影响时，要试图协商控制变更，以保证在需求变更下，项目可以继续成功。
2、变更流程控制活动，包括怎么进行变更请求，怎么进行变更批准等过程控制，还要考虑为处理变更估计留出时间等等方面的问题。这方面不遵循过程控制流程来走，很容易导致花大功夫补救的后果。
我们公司已经对变更没有做很好的控制，就吃了很多亏。我们项目组是驻客户所在地办公，开发人员经常接到客户电话来提出一些功能性的小变更，考虑到是小变更，又受“客户是上帝、提高客户满意度”等思想的影响，也就痛快答应，甚至当场修改程序发布。客户是高兴了，短期来看，效率高，而且还与客户打好关系。可长期来看，上此以往，这种行为就变成“没有跟客户计算成本”的花费，这还是小事，更严重的问题是，这种没有经过整体评估、影响分析、风险识别与分析的行为，有可能改了东家，拆坏了西家，到最后要花费更大的财力去弥补，吃力不讨好，更甚的后果是因为这些漏洞，迟迟拖延项目验收时间，从而导致项目失败。