在传统软件开发的瀑布模型中，需求分析阶段虽重要，但存在诸多问题，可能导致项目延误和错误。
-
客户并不（真正）知道自己想要什么？
- 问题表现：客户对自身需求概念模糊，需项目方深入挖掘分析，将模糊想法转化为明确的软件需求规格说明书，作为项目计划和工程架构基础。
- 解决方法
- 项目开始时充分理解项目目标、可交付成果和范围。
- 明确客户假设，评估项目对最终用户的利弊。
- 撰写具体的项目愿景声明，涵盖功能、用户利益和要解决的业务问题。
- 让客户阅读、思考并签署软件需求规格说明书，确保双方对交付成果理解一致。
-
项目过程中需求发生变化
- 问题表现：项目推进中，第一阶段定义的需求可能因客户对原始计划有新认识或外部环境变化而改变，影响项目进程。
- 解决方法
- 建立明确的变更请求处理流程，让客户知晓如何提出变更。
- 为各开发阶段设定里程碑，限制特定阶段后的重大变更，如模块完成75%后不允许大改。
- 确保变更请求及审批信息连同理由清晰传达给所有利益相关者，并相应更新项目主计划。
-
客户设定不合理的时间表
- 问题表现：客户常要求项目在不合理的短时间内完成，若不深入分析项目范围和所需资源就接受，可能导致项目延迟或质量缺陷。
- 解决方法
- 将软件需求规格说明书转化为项目计划，详细列出各阶段任务和资源需求，并模拟最佳、中等和最差情况。
- 确保项目计划考虑资源限制，预留足够测试和质量检查时间。
- 依据项目计划数据与客户协商合理期限，以达成双方有利的结果。
-
客户、工程师和项目经理之间存在沟通差距
- 问题表现：客户和工程师因背景不同、对技术术语理解有差异，易导致沟通混乱和误解，影响项目交付。
- 解决方法
- 每次会议做记录并在项目团队内共享。
- 统一术语使用，制定术语表并确保所有利益相关者持有，始终如一地使用。
-
开发团队不了解客户组织的政治因素
- 问题表现：在大型组织项目中，信息分散，需求分析受信任、内部利益冲突和信息效率问题阻碍，开发团队需理解组织权力结构等因素。
- 解决方法
- 梳理现有关系网络，明确所需信息及可能的信息源。
- 培养盟友，建立关系，系统思考组织内社会资本。
- 以与对方经验相关的方式阐述问题，说服客户组织内的反对者。
- 利用初始接触点/影响力推动项目议程。
