在软件开发的传统瀑布模型中，需求分析的第一个阶段也是最重要的阶段。这个阶段包括以最清楚的形式搜集与客户要求和定义有关的信息以及希望产品解决的问题。
这种分析包括了解客户的商业背景和限制、产品必须执行的功能、它必须实现的性能水平、以及它必须兼容的外部系统。用来了解这些问题的技巧包括客户面谈、使用情况和软件特性“购物清单”。分析结果一般以正式需求规范的形式呈现，并作为下一个步骤的输入。
至少，这是它理论上的应用情况。实际上，这个理论模型存在着许多问题，这些问题可能给分析过程的其它步骤造成延迟或连锁性错误。本文讨论项目经理在这个阶段中遇到的一些常见问题，并提出可能的解决方案。
问题1：客户并不（确切地）知道他们需要什么
在需求分析阶段，可能最常见的问题就是客户对于他们的需要仅有一个模糊的概念，而要由你提出合适的问题、进行必要的分析，把这个不确定的概念转化成一个正式文本化的软件需求规范；这个规范反过来又可用作一个项目计划和工程结构的基础。
要解决这个问题，你应当：
- 确保在项目开始之初，你用了足够的时间来了解项目的目标、交付成果和范围。
- 确定客户所使用的任何假设，用批评的眼光评估项目给终端用户可能带来的好处和风险。
- 尝试为项目写出一份具体的远景陈述，包括它提供的特殊功能或给用户带来的好处，以及希望它解决的所有商业问题。
- 让客户阅读、考虑并同意前面完成的软件需求规范，调整他们的期待，保证双方充分理解项目交付成果。
问题2：需求在项目进行过程中发生改变
软件开发项目中遇到的第二个问题是，随着项目的发展，在第一阶段定义的需求发生了变化。随着开发不断取得进展，软件原型得以确定，这时客户能够更加清楚的发现原始计划中存在的问题并做出必要的纠正，于是需求也因而改变。需求发生改变还可能是因为外部环境的变化要求改造原始的商业问题，并因此有必要开发一个与最初建议的解决方案全然不同的解决方案。优秀的项目经理意识到这些可能性，并往往制定了后备计划来应对这些变化。
要解决这个问题，你应当：
- 为变更请求的收集、分析和组合制定一个定义明确的过程，保证你的客户知道他/她的切入点。
- 为每个开发阶段设定转折点，超过这个转折点就不允许进行某些改变——例如，一旦一个模块完成75%，就不允许进行重大改变。
- 保证向所有股东清楚地通报变更请求（和变更批准），以及进行变更的根本原因，因而还要对主项目计划进行更新。
问题3：客户的时间表不合理
我们常常听到客户这样说：“这是一个非常紧迫的任务，我们需要项目在X周内完成。”常见的错误就是，没有进行详细分析，并了解项目的范围以及完成项目所必需的资源，就同意客户的要求。未经讨论就同意不合理的时间表，你实际上在给客户造成伤害：项目很有可能被延期（因为不可能按时完成），或存在质量问题（因为你在赶工，没有进行适当的检验）。
要解决这个问题，你应当：
- 把项目需求规范转化成一个项目计划、详细的任务和各阶段所需的资源，并为最佳情况、一般情况和最差情况建立模型。
- 保证项目计划考虑到有效资源的限制，并为检测和质量检验保留足够的时间。
- 与客户讨论最终期限问题，用你计划草案中的数据为你的陈述提供证据。如果你的计划是合理的，则很有可能随后的谈判会极为成效，并对双方有利。
问题4：沟通客户、工程师和项目经理间存在的隔阂
通常，客户和工程师之间由于背景差异以及理解技术条款的不同方式，他们无法进行有效地沟通。这可能导致混乱和严重的沟通问题；因此，项目经理的一项重要任务——特别是在需求分析阶段——就是保证双方能够准确了解交付成果以及必须完成的任务。
要解决这个问题，你应当：
- 在每次会议上做记录，并向整个项目团队分发这些记录。
- 注意用词一致。从一开始就列出一份你要使用的名词术语表，保证所有股东都有一份，并坚持使用这些术语。
问题5：开发团队并不理解客户组织的政治策略
Bolman和Deal这两位学者认为一位高效的项目经理是一个把组织看作一个“竞争舞台”的人，它理解权力、冲突、谈判和联盟的重要性。这样的经理不仅熟悉运作和职能任务，他或她还认识到为通用目标制定议程、建立观点一致的联盟以及向抗拒性的经理说明一个特定职位合法性的重要性。
在给大型组织执行大型项目时，这些技巧尤其重要，因为信息常常分散在各处，因此需求分析往往会受到信任问题、内部利益冲突和信息低效这些因素的阻碍。
要解决这个问题，你应当：
- 审查现有的网络，确定你需要的信息和可能拥有这些信息的人。
- 培养同盟，发展关系，并系统地考虑你在组织内的社会资产。
- 以符合他们自己经历的方式说明问题，说服客户组织内的反对者。
- 使用初始访问/支撑点来推动议程。
- 希望上述讨论能够让你意识到需求分析阶段存在的可能缺陷，并提供一些避免这些缺陷的指导方法。祝你好运！
