1.1 软件项目失败的根源
需求对于软件项目的成败影响非常高。
1.1.3 需求相关败因简要分析
1.1.3.1 不完整的需求
什么样的需求是完整的？
大部分情况下，用户代表比开发人员更适合对需求完整性进行评价。同样在大部分情况下，《需求规格说明书》大量充斥着技术词汇与结构，这样显然给用户代表带来障碍与困惑。因此
需求说明书必须放弃“技术导向”，采用“业务导向”，代入到业务场景中去。
当完成需求说明书时，项目经理就让一个人看完《需求规格说明书》中的所有内容，并指出错误，这是天真的想法，不会有一个角色既了解宏观战略，也了解一线操作。这个人通常会说“如果是签字，我可以签，但是以后如果有什么变更，你们还是要积极响应，一切以合同为准”。这样一个需求验证，就变成了一个程序上的签字流程。因此，
需求说明应该利用树形层次结构将宏观信息与微观信息进行有效剥离，以面向不同层面：决策者(高层)，事务管理层(中层)，操作层(基层)。将需求分成不同的部分，让合适的人验证适当的部分，然后再汇总起来。
所以，需求规格说明书，应该采用业务导向的树形层次结构来组织。
1.1.3.2 缺乏用户参与
缺乏用户参与背后有以下几个因素：
第一：事不关己，高高挂起。主动参与意识是与获得的利益成正比的。针对这种情况的措施是充分研究不同用户代表的关注点，利益点。具体方法参考“第4章 需求定义最佳实践”。
第二：逃离无趣。如果你不喜欢足球，而同事们都在讨论足球时你怎么办？肯定会离开讨论。用户也是一样，所以在需求上一定要以业务导向。
第三：被你赶走。不要使用技术语言，以免赶走客户。
所以，对于需求分析员而言，真正的专业主义是基于业务利益(解决问题，创造机会，提高管控力等)的沟通。
1.1.3.3 不切实际的用户期望
不切实际的用户期望，并不能归罪于客户。要解决这样的问题，更需要从业人员主动地帮助用户更好的理解软件的成本。简单地说做不到是无效的，要说明为什么做不到才能解决问题。(这也是我自己一直在提倡的，PM有教育客户的义务。)
1.1.3.4 需求变更频繁
对于很多认为需求变更的项目经理，都有一个难题：经常遇到的需求变更是哪种类型？也就是说，
在国内软件行业中，对变更进行分类，统计的做法非常少。
如果只是把所有变更中的每一个都单独作为一个问题来看待，就无法有效地找出问题的根源，也无法针对性地改进需求过程，提高设计弹性。
客户也没有意识到变更对软件项目的负面影响。(还是PM没有尽到对客户的教育义务)
绝大多数企业缺乏统一的变更处理渠道，
使得变更相对散落，不能集中体现。
1.1.3.5 提供了不再需要的
在功能模型的入口制作计数器，一段时间后就知道哪些功能是不需要的了。但这是马后炮的做法，可以用来分析结果，但无法防患于未然。
需求在最开始就应该有效地划分优先级。真正基于业务领域知识来衡量需求的必要性和充分性是需求优先级排序的解决之道。将在“第3章 软件需求与需求工程”进一步阐述。但优先级划分通常是拍脑袋的产物，没有原因也没有理由，它就是最高优先级。
1.1.4 一幅漫画带来的思考
1.1.4.1 沟通失真
在信息的传递过程中，如果没有采取任何措施，信息衰减可能最大高达60%。如何避免这种问题呢？关键手段有两个：
第一：文档。将达成共识的信息文档化。但这种方法只是用来辅助沟通，而不能代替沟通，这点在后面还会提到。
第二：review。review没有使用中文“评审”，因为评审长给人一种审核，批判是否通过的意思，但review在软件开发中，更多是回顾，再读一遍。最有效的review就是在用户阐述需求后，需求分析员用自己的语言在复述一遍。
缓解沟通失真最有效的方法是及时复述。
1.1.4.2 需求放大
比较图1和图10，用户通常在需求描述时，添砖加瓦，添油加醋。背后的原因主要有两个：
第一：客户希望成本尽量小，而收益尽量多。如果成本固定，就通过增加功能的方法来增加收益。要解决这个问题并不是容易的事，一方面要提升软件估算实践的有效性，另一方面则需要产业成熟度的提高。
第二：解决方案的选择权交给了不熟悉技术的客户。许多需求团队进行需求捕获活动时，长续期客户能够直接告诉他们要做什么(what)，而不太关心客户提出需求的真正动机(why)是什么。这就相当于把问题的解决方案选择权交给了客户。而对于同一个问题，备选的方案有很多，一旦客户选择的方案不是最合适的，后续一定就会带来需求变更。缓解这一现象的关键在于，在需求捕获的过程中多问为什么。
1.1.4.3 项目经理的需求控制
比较图1和图2，可以发现项目经理在对需求进行控制。问题在于控制的策略和方法。由于国内项目经理通常是一身兼多职，项目管理，需求分析，架构设计，因此在需求获取过程中，常常会不自主的规划技术框架和路线，然后从技术角度尽可能地控制需求范围。这样就造成无法形成对需求本质的有效理解。
所以项目经理应该以业务为线索来组织需求，基于why的层面对需求建立理解。具体做法在后续详细阐述。
1.1.4.4 分析人员的技术加工
当有技术人员参与到需求分析阶段时，一定要警惕他们基于技术做需求分析。
需求分析的本质在于业务分析，而非技术分析。
1.1.4.5 编码人员的断章取义
观察图3，绳子，木板需求需要的东西都准备好了，但实际上需求并没有实现。所以，
理解业务场景才是需求之魂
。
1.2 透过现象，分析本质
有中低级的观点是“软件项目失败的关键在于项目管理技能不足”。提高项目管理能力很重要，但管理不是万能的，现在许多软件项目问题，表面在于项目管理问题，实际根源是需求问题。下面我们来分析几种最常见的表象，简要地分析其背后的本质原因。
1.2.1 需求变更频繁
需求变更是许多软件项目的重大问题，但更大的问题是团队没有对需求变更做统计分析和管理。
需求变更频繁是一种统称，每一个变更的具体诱因不同，有的是对原需求的背离，有的是对原需求的补充，有的是业务流程变化引起等等。
》需求变更是对原需求的背离：说明需求描述与沟通有问题，导致需求失真。因此应该加强需求过程管理，加强沟通管理。
》需求变更是对原需求的补充：说明需求捕获不完整。因此应该加强需求捕获方法的应用，加强对业务模型的梳理。
》需求变更集中在流程间：说明需要采用工作流引擎。
》需求集中在用户界面：说明需要开发用户界面生成器。
与需求变更管理相关的更多内容，我们将在“第十章 变更管理操作要务”中讨论。
1.2.2 上线阻力大
通常都是行政因素的影响，常见的行政因素无外乎两类：
》利益冲突。由于信息系统会对业务流程产生一些影响，会提高业务数据的管控力，这样常常会伤害到某些部门的利益，导致新的利益冲突。因此在需求捕获过程中，就要细心发现和总结潜在的行政因素，在系统实施之前整理成文，提交给客户高层。
》工作量增大
对于基层而言，新的系统通常会增加他们的工作量，针对这样的问题，实际上从需求阶段就要开始解决：
第一，提高易用性。
第二，工作量价值比。基层工作人员是无法理解新增的工作量有什么意义的，因此在需求阶段应该标记出这些新增工作量对于实际业务带来的好处。
第三，将数据迁移，准备等工作独立出来，不使其成为基层人员的负担。
1.2.3 运行效果差
很多项目初验之后就被扔在一边，并没有勇气来，更无法谈及终验。这种现象是由于软件项目在开发过程中缺乏有效的目标作指引，与实际业务脱节。要缓解这类现象，在不同层面有不同方法：
》从问题或机会入手，提高管理人员的推动力。如果不能将系统与管理人员的利益联结起来，就很难从他们身上获得真正的支持。
》从障碍和困难出发，解决操作人员的积极性。有了管理人员的推动，可以从制度规范上要求操作人员，但要让他们自发地积极应用，还需要为他们解决一些困难。
1.2.4 完全崩溃
有时软件系统完全不可用，通常是因为忽略了某些非功能性需求，但非功能性需求一般都写在需求规格说明里，为什么会忽略呢？主要是因为无效信息传递，比如高可靠性，高扩展性，高可用之类定性词汇。在软件需求中，尽量使用定量词汇。更多相关内容，将在“第三章 软件需求与需求工程”中阐述。
1.3 方法论与需求工作
作为需求分析人员，应该更多地考虑方法论的适用性，而非先进性。
1.3.1 计算模式(c/s b/s)
应该从用户的角度分析cs还是bs更适用。
1.3.2 软件工程方法论
现代软件工程方法论大致分为重方法论和敏捷方法论两大阵营。重方法论强调前期设计，为未来设计；敏捷方法论更强调为现在设计，未来再来重构它。对预设计的需求是评判敏捷方法论是否适用的关键。因此需求人员应该基于对业务领域的了解，正确地评判项目特点，为开发团队选择合适的方法论。
1.3.3 开发思想
开发思想或工具总是层出不穷，作为需求分析人员不应过多的跟风到先进性的讨论上，而应该更加重视其成熟度，溯源，及局限性。