不重视需求分析的项目团队将自食其果，需求分析的缺陷将给项目带来极大的隐患，下面将讨论不合格的需求分析引起的一些风险。

1．需求不明确导致产品无法被接受在某些情况下，开发人员与实际使用产品的用户直接接触很困难，因此开发人员只能根据自己的理解来开发产品；另外，有些客户也不太明白自己的真正需求。为防止此种情况带来的风险，具有代表性的用户应在项目早期直接参与到开发队伍中，并一同经历整个开发过程。

2．用户需求增加造成过度耗费导致产品质量降低

在开发中若不断地补充需求，项目就会越变越大，最终超出其计划及预算范围。一旦原计划中的项目需求规模、复杂性、风险、开发生产率及其他需求发生明显变更，问题将更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所做的修改。

如果想要将需求变更范围控制到最小，开始阶段必须对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承担者理解业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。

产品开发中不断变更需求会使其整体结构日渐紊乱，补丁代码也使整个程序难以理解和维护。插入补丁代码使模块违背高内聚、低耦合的设计原则，特别是如果项目配置管理工作不完善，收回变更和删除特性会带来问题。如果尽早地区别这些可能带来变更的特性，就能开发一 个更为健壮、适应性更强的结构。这样，设计阶段的需求变更就不会直接导致补丁代码，同时也有利于减少因变更导致的质量下降。

3．模棱两可的需求说明可能导致时间的浪费和直接返工

模棱两可是需求规格说明中最麻烦的问题，既可能指诸多读者对需求说明产生不同的理解，又可能指单个读者用不止一个方式来解释某条需求说明。

模棱两可的需求带来不可避免的后患，70%～85%的返工、重做是需求方面的错误所导致的。

仅仅简单浏览需求文档难以发现模棱两可的问题，一种有效方法是组织从不同角度审查需求的队伍。不同的评审者从不同的角度对需求说明给予解释，使每个评审人员都真正了解需求文档，这样二义性就不会直到项目后期才被发现。

4．用户要求一些不必要的功能或开发人员画蛇添足

“画蛇添足”是指开发人员力图增加一些功能，但需求规格说明中并未涉及这些功能。开发

人员需要在客户所需和允许时限内的技术可行性之间求得平衡，努力使功能简单易用，而不要

未经客户同意，擅自脱离客户要求，自作主张。同样，客户有时也可能要求一些看上去很“酷”，

但缺乏实用价值的功能，而实现这些功能会徒耗时间和成本。

5．过分简略的需求说明导致遗漏某些关键需求

有时客户并不明白需求分析的重要性，于是只做一份简略的规格说明，然后让开发人员在项目进展中去完善，结果很可能是开发人员先建立产品的结构再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况。在大多数情况下，这会给开发人员带来不确定性问题，也会给客户带来不必要的麻烦（无法获得所设想的产品）。

6．忽略用户分类导致客户的不满

不同的人会使用同一产品不同的功能，使用这些功能的频繁程度有差异，使用者受教育程度和经验水平也不尽相同。如果不能在项目早期针对这些主要用户进行分类，必然导致有些用户对产品感到失望。例如，菜单驱动操作对高级用户来说太低效，但含义不清的命令和快捷键又会使不熟练的用户感到困惑。

7．不完善的需求说明使得项目计划和跟踪无法准确进行

客户简略地说明需求之后便会询问开发人员的开发时间，最终双方预估出一个不准确的时间。许多开发人员都会遇到需求不完善的难题，对需求分析缺乏理解会导致过分乐观的估计， 最终，不可避免的超支会带来颇多麻烦。

对客户所提问题的正确响应是待双方明确需求之后再予以答复。基于不充分信息和不成熟需求的估计很容易被一些因素左右。当需要做出估计时，最好给出一个范围（如最好情况下、很可能、最坏情况下）或一个可信赖的程度（如 90%的把握、能在 8 周内完成）。