- 从客户角度审视需求
这样的对话在软件世界里经常发生。需要新系统的客户常常不理解从实际用户以及其他干系人那里获取信息的重要性。
部分需求问题源于混淆了不同的需求层面，业务、用户和功能层面。
客户-开发人员关系是软件项目成功的关键要素。我们提出了软件客户所拥有的权利清单以及与之对应的义务清单。
期望落差
缩小期望落差的最好方法是与合适的客户代表频繁沟通。这些沟通可以是正式访谈，对话，需求评审，用户界面设计走查，原型评估以及敏捷开发中在可执行软件每个小的增量功能上收集的用户反馈。每次沟通都是一个缩小预期差距的机会，让开发人员所开发的软件能够更贴近用户所需。
频繁的用户参与能减少期望落差
谁是客户？
干系人是指积极参与项目的某个人、群体或组织，它们可能会受项目过程和结果的影响或影响项目的过程和结果。
客户是干系人的一个子集。客户是能够直接或间接从产品中获益的个人或组织。软件客户可能提出需求，出钱，选择，说明，使用或者接收软件产品的输出。
用户需求应该来自于直接或者间接使用产品的人，这些用户（通常称为“终端用户”）是客户的子集。直接用户会动手使用产品。间接用户虽然不动手使用，但也会收到系统的输出。
提供业务需求的客户有时会试图替实际用户说话。然而这些内容常常和真实用户的需求相去甚远。对于企业信息系统，合同制定或者定制应用开发，业务需求应该来自于最终的产品业务价值负责人。用户需求则应该来自于按下按键、点击屏幕或是接收输出的人。如果为项目买单的人和最终用户之间有严重的脱节，肯定会出大问题。
通过管理手段强迫他们使用新的信息系统会使用户感到痛苦，因而他们不愿意和开发人员进行合作并把他们当作悲惨未来的先驱。
客户-开发的合作关系
卓越的软件产品来自基于卓越需求的卓越设计。卓越的需求则根植于开发人员与客户（特别是终端用户）高效协作的土壤中。协同合作要想取得成果，需要所有干系人都清楚自己的需要，理解并尊重其他合作者的需求。当项目压力上升时，很容易忘记所有干系人共享的同一个目标：构建一个既实现业务价值又可以使所有干系人受益的产品。
| 客户的权力 |
| 1.期望业务分析师用自己的语言进行交流 |
| 2.期望业务分析师了解自己的业务和目标 |
| 3.希望业务分析师用了解合适的形式记录需求 |
| 4.收到需求实践和交付物的相关解释 |
| 5.变更需求 |
| 6.期望一个相互尊重的环境 |
| 7.聆听关于需求以及解决方案的建议和替代方案 |
| 8.描述能够提高产品易用性的特性 |
| 9.了解调整哪些需求可以实现复用，加速产品开发 |
| 10.收到满足自己功能需求和质量预期的系统 |
软件客户的需求权利
| 客户的责任 |
| 1.给业务分析师和开发人员传授你的业务知识 |
| 2.准备足够的时间用来澄清需求 |
| 3.提供具体而准确的需求 |
| 4.及时对需求的进行确认 |
| 5.尊重开发人员针对需求可行性和成本的估算 |
| 6.和开发人员协作设置符合实际的需求优先级 |
| 7.评审需求和评估原型 |
| 8.设定验收条件 |
| 9.及时沟通需求变更 |
| 10.尊重需求开发流程 |
软件客户的需求责任
软件客户的需求权力法案
>权利1.期望业务分析师使用自己的语言
需求讨论应该以你的业务需要和任务为中心，使用业务术语。可以使用术语表的方式把业务术语介绍给业务分析师。
>权利2.期望业务分析师了解自己的业务和目标
邀请业务分析师和开发人员来观察你和你的同事的做事方式。
>权利3.希望业务分析师用适合的形式记录需求
分析阶段的交付物是以合适形式存储的优化需求集合，这个需求集合构成了干系人对功能、质量和产品约束的一致意见。需求应该用易于理解的方式写和组织。
>权利4.收到需求实践和交付物的相关解释
业务分析师应该解释他所推荐的实践以及每个交付物都包含哪些信息。
>权利5.变更需求
随着业务的不断发展，团队接收到干系人提供的信息不断增多，或自身更深入地考虑了自己的需要，就有权变更之前提出的需求。业务分析师的一个重要责任是评估、管理和沟通变更所带来的影响。
>权利6.期望有一个彼此尊重的环境
参与需求开发的客户有权让业务分析师和开发人员尊重自己并且感谢自己为项目成功所投入的时间。类似，客户也应该尊重开发团队成员，彼此同舟共济才能达成项目成功这一共同目标。
>权利7.聆听关于需求以及解决方案的建议和替代方案
应该避免“一错再错”。
>权利8.描述能提高产品易用性的特性
业务分析师应该询问软件功能需求之外的特性。这些特性或质量属性能够确保软件更易用或更好用，使得用户能够更高效地完成其本职工作。
>权利9.了解调整哪些需求可以实现复用，加速产品开发
存在合适的重用机会时调整需求可以有效节省时间和成本。如果想集成一些现成的商业软件包，需求就得灵活，因为它们很少能够精确提供你想要的特性。
>权利10.收到满足自己功能需求和质量期望的系统
这是最根本的用户权利，但要实现这一点，需要清晰地表达开发正确产品所需要的所有信息，需要开发人员不断和你沟通备选方案与约束，还需要当事各方能够达成一致。确保你陈述了所有假设和期望，否则开发人员很难掌握这些信息。
软件客户的需求责任法案：
>责任1：向业务分析师和开发人员传授自己的业务知识
业务分析师通常并不掌握你和你的同事认为理所当然的知识。
>责任2：准备足够的时间用来澄清需求
请耐住性子接受这种迭代式开发和精炼需求的方式，因为这是复杂的人类沟通的特性，也是软件成功的关键。相比一次讨论一点且历时数周的讨论，集中几个小时的讨论更有效。
>责任3：提供具体而准确的需求描述
尝试描述每个需求的潜在目的，使业务分析师能够把它准确呈现出来。这是确保产品能够满足真正需要的最好方式。
>责任4：被问到有关需求的问题时及时做出决策
通常，开发人员在你做决定之前无法前进，所以迟迟未决会造成项目进度的延迟
业务分析师通常都很善于引导客户做决定，所以当你难以抉择的时候可以向他们寻求帮助。
>责任5：尊重开发人员对需求可行性和成本的估算
某些需求可能希望系统在运行环境中达到无法达到的性能或要求访问系统无法获得的数据。开发人员会带来这些可行性或者有关成本的坏消息。
>责任6：和开发人员协作设置符合实际的需求优先级
你需要成为主角，为需求设置优先级。设置务实的优先级，就是帮助开发人员用最低的成本在最合适的时间交付最大化的价值。
对于团队在可用的时间和资源约束下能完成多少所需的功能，应该充分尊重开发团队的判断。如果你所需的功能无法完全放入项目，决策者就会根据优先级缩小项目范围、延长时间或者提供额外的资金或者人力。简单粗暴地把所有需求都设置为高优先级，这样做既不符合现实，也不是一种合作的态度。
>责任7：评审需求和评估原型
让客户参与评审是评估软件在需求方面是否满足完整性、正确性和必要性的关键方法。评审也是客户代表评估业务分析师工作是否满足项目需要的一个重要时机。
>责任8：设定验收条件
你有设定验收条件的责任，预先定义好未来如何评估产品的条件。这些条件包括验收测试，可以用它们来评估用户执行业务操作时产品是否能够正确执行。
>责任9：及时沟通需求变更
为了能把影响降到最低，要遵从项目定义的需求变更流程，以确保所有提出的变更不会丢失，每个变更影响都要考虑到，并且所有变更都要用相同的方式考虑。
>责任10：尊重需求开发流程
引导和制定需求是软件开发中最有挑战的活动之一。业务分析师进行需求开发时有一个基本原理。互相理解并尊重其他人的做事方法和需要，有利于建立一个有效而愉快的合作关系。
建立尊重需求的企业文化
领导必须理解这一点：组织需要把高效业务分析和需求工程能力作为自己的战略性核心竞争力。虽然项目范围内基层人员的努力非常重要，但如果没有高层的投入，这些改进和收益在项目结束或团队重组后将很难保持。
对需求达成一致
对在建产品的需求达成一致或是在某部分达成一致是客户-开发人员关系的核心。涉及的多个角色应形成如下共识：
>客户承认需求描述了他们的需要
>开发人员承认理解需求并且认为它们是可实现的
>测试人员承认需求是可验证的
>管理层承认需求可以达成他们的业务目标
即我们不可能在项目早期就知道所有的需求，而且毫无疑问，需求会随着时间的变化而变化。虽然批准一组需求是结束某个需求开发阶段的常用方法，但是每个参与需求开发过程的角色都应该明白签字的真正含义。
需求基线
比签字仪式更重要的是确立一条需求基线，一个特定时间点的需求快照(Wiegers 2006）。需求基线是一组需求，在评审和确认后作为后续开发的基础。
一个有意义的基线确定流程可以在以下几个方面为主要干系人带来信心。
>客户管理层或者市场营销人员相信项目不会超出可控范围，因为客户会为范围变化的决定负责。
>用户代表相信开发团队会和他们一起工作，交付正确的解决方案，即使他们在开发开始之前没有考虑清楚所有的需求。
>开发部门的信心建立在开发团队有业务伙伴保证项目始终聚焦于其目标上，同时业务伙伴也和开发团队一起平衡项目计划、成本、功能和质量。
>业务分析师和项目经理有信心有效控制项目变更带来的风险，并使风险最小化。
>质量保证和测试团队有信心开发测试脚本并且为自己在项目中的各种活动做好准备。
达不成共识怎么办？
在这种场景下，最好先小心地推进项目，不过要假定你没有得到这些有抵触情绪的干系人的同意。在风险列表中做记录，说明有些干系人没有在需求文档上签字（把它和遗漏或错误的需求可能带来的影响同等对待）。
发表回复