第1章需求实践现状分析

软件项目失败的根源

CHAOS报告总结的“软件项目十大败因”中，有五项是与软件需求直接相关的。

用户可以对需求的完整性进行评价。

要想让用户代表能够更好地参与到完整性评价中来，就必须采用“业务导向”的组织结构，而不是让用户将一大堆技术动作翻译到自己的业务场景中去。

需求规格说明书应该采用业务导向的树型层次结构来组织。

对于需求分析员而言，真正的专业主义是基于业务利益（解决问题、创造机会、提高管控力等）的沟通。通过业务利益争取用户参与到需求活动中，始终让技术解决方案在冰山之下以使用户不中途离开，也许是缓解该问题的很重要的策略。

从业人员主动地帮助用户更好地理解软件的成本。简单地说，做不到是无效的，要说明为什么做不到才能解决问题。

如果只是简单地将所有的需求变更都当作一个问题来看待，那么是无法有效地找出问题的根源的，也无法有针对性地改进需求过程，提高设计的弹性。

真正基于业务领域知识来衡量需求的必要性和充分性是解决之道。

需求迷途

诫语：缓解沟通失真最有效的方法是及时复述。

客户的需求放大潜在原因：
- 客户希望支付的成本尽可能少，获得的效益尽可能多。要解决该问题并不是件容易的事，一方面需要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。
- 解决方案的选择权交给了不熟悉技术的客户。一旦客户代表选择的解决方案不是最合适的，就必将引发后续的需求变更。要缓解这一现象的关键就在于，在需求捕获的过程中多问“what、why”。
项目经理的需求控制项目经理经常会从技术的角度来对需求进行控制，这样就可能造成无法形成对需求的有效理解。
分析人员的技术加工需求分析的本质在于业务分析，而非技术分析。
编码人员的断章取义诫语：业务场景（对不同的用户使用场景进行说明）是需求之魂。