第二章 需求工程之从客户角度审视需求

第二章 从客户角度审视需求

期望落差

• 与客户代表频繁的沟通
• 收集用户反馈

谁是客户

干系人

• 指积极参与项目的某个人、群体、或组织，他们可能会收到项目过程和结果的影响，或影响项目的过程和结果。
• 干系人可以在项目团队和开发组织的内部或者外部

客户

• 客户是干系人的一个子集
• 客户是能够直接或间接从产品中收益的个人或组织

用户

用户需求应该来自于直接或间接使用产品的人，这些用户通常称为“终端”用户，是客户的子集

• 直接用户会动手使用产品
• 间接用户不使用产品，但会收到系统的输出。

需求

• 提供业务需求的客户有时会替实际用户说话，存在与实际需求相去甚远
• 业务系统应该来自原最终产品业务价值负责人
• 用户需求则应该来自原具体实际操作或接收系统输出的人。
• 客户和用户之间有严重的脱节，会出大问题。

客户-开发的合作关系

干系人共同的目标：构件一个实现业务价值又可以使所有干系人受益的产品。
卓越的软件产品来自卓越的需求卓越的设计。卓越的需求根植于开发人员与客户的协作。

软件客户的需求责任权利

权利	责任
1. 期望业务分析师用自己的语言进行交流	1. 给业务分析师和开发人员传授自己的业务知识
2. 期望业务分析师了解自己的业务和目标	2. 准备足够的时间来澄清需求
3. 希望业务分析师用了解合适的形式记录需求	3. 提供具体而准确的需求
4. 收到需求实践和交付物的相关解释	4. 尊重开发人员针对需求可行性和成本估算
5. 变更需求	5. 和开发人员协作设置服务实际的需求优先级
6. 期望一个相互尊重的环境	6. 评审需求和评审原型
7. 聆听关于需求以及解决方案的建议和替代方案	7. 设定验收条件
8. 描述能够提高产品易用性的[[第一章 软件需求的本质#特性	特性]]
9. 了解调整哪些需求可以实现复用，加速产品开发	9. 及时沟通需求变更
10. 收到满足自己功能需求和质量预期的系统	10. 尊重需求开发流程

建立尊重需求的企业文化

对流程和文化改变的抵触大多来自于恐惧、不确定性或知识的缺乏。
企业必须把高效业务分析和需求工程能力作为自己的战略核心竞争力

识别决策者

让一个代表各个关键领域（如管理、客户、商业分析、开发和市场部）的小组来做决定通常更有效

决策小组

决策小组需要指明决策领导并选择一个决策规则，该规则描述了他们如何做决定

• 决策领导做决定，不管是否已经和其他人讨论过
• 小组投票，少数服从多数
• 小组投标，但结果必须一致通过
• 小组讨论和协商达成共识。每个人都拥护这个决定，并承诺支持它
• 决策领导授权一个人做决定
• 小组达成一个决策，但是一些人有权否决小组决定。

需求基线

需求基线是一组需求，在评审和确认后作为后续开发的基础。

我同意当前这组需求代表我们对项目下一阶段需求最深入的理解，并且基于目前我们对问题的理解，这个解决方案能够满足我们的需求。我同意在未来使用项目定义好的变更流程基于这个基线对需求进行修改。我清楚变更可能导致我们重新讨论项目成本，涉及的资源以及对时间表的承诺。

一个有意义的基线确定流程可以在以下几个方面为主要干系人带来信心

• 客户管理层、市场营销人员相信项目可控，客户会为范围变更买单
• 用户代表相信开发团队和他们一起工作，交付正确的解决方案，即使没有考虑清楚所有需求
• 开发部门的信息建立在开发团队由业务伙伴保证项目始终聚焦于其目标上，业务伙伴也考虑平衡项目计划、成本、功能和质量。
• 业务分析师和项目经理有信心有效控制项目变更带来的风险，并使风险最小化
• 质量保证和测试团队有信心开发测试脚本并且为自己在项目中的各种活动做好准备。

达不成共识怎么办

• 在当前需求基线上推进工作。
• 持续跟进这些未达成共识的人
• 让其了解，虽然没有批准，但为了保证进度，仍然使用这些需求作为基线。
• 让他们知道，可以通过一个现成的流程进行变更。
• 保持密切的沟通

对敏捷项目的需求达成共识

• 敏捷项目没有正式签字环节
• 敏捷项目使用backlog管理需求。
• 产品负责人和团队一起在计划会议上针对下一个迭代团队要做的用户故事达成一致。
• 在需求集合达成一致后，迭代中包含的用户故事江北冻结。
• 新出现的变更在未来迭代中再考虑。