STC（美国技术通信学会）卓越奖获得者,国际业务分析师协会CBA兼执行VP推荐。敏捷开发和大数据时代的软件需求百科全书！一流业务分析师，项目经理，产品经理/产品负责人，创业CEO，商业顾问/咨询的权威工具和参考书。

 

作者简介：
 Karl Wiegers（卡尔•魏格斯）博士 全球公认的软件需求工程、过程改进和软件质量专家，享有盛誉的技术作家，他发表很多文章，他的经典著作《软件需求》系列版本对需求领域有着举足轻重的影响。
Karl在伊利诺大学获得有机化学博士学位。除了计算机，他的爱好还包括品酒、弹吉他、写歌录歌和参与公益活动。  

目    录 第Ⅰ部分  软件需求的3W（什么、为什么和谁）
第1章  软件需求的本质 3软件需求的定义 5关于“需求”的一些解释 5字典中的“需求” 6需求的层次和种类 6处理三种层次的需求 11产品需求与项目需求 13需求开发和管理 14需求开发 15需求管理 16每个项目都有需求 17人对了，得出的需求却很糟糕 18用户参与度不够 18规划不当 19用户需求蔓延 19需求模棱两可 19镀金 20忽视干系人 20高质量需求过程带来的好处 20第2章  从客户角度审视需求 22期望落差 23谁是客户 24客户-开发的合作关系 26软件客户的需求权利法案 28软件客户的需求责任法案 30建立尊重需求的企业文化 32识别决策者 33对需求达成一致 34需求基线 35达不成共识怎么办 36对敏捷项目的需求达成共识 36第3章  需求工程优秀实践 38需求开发过程框架 40优秀实践：需求获取活动 42优秀实践：需求分析 44优秀实践：需求规范说明 45优秀实践：需求验证 46优秀实践：需求管理 47优秀实践：知识 49优秀实践：项目管理 50开始新的实践 51第4章  业务分析师 53业务分析师的角色 54业务分析师的职责 55基本的分析技巧 56基本的分析知识 59业务分析师的培养 60前用户 60前开发人员或测试人员 61前（或兼职）项目经理 61主题专家 62菜鸟 62敏捷项目中的分析师角色 63打造一个协作型的团队 64

第Ⅱ部分  需 求 开 发
第5章  建立业务需求 67定义业务需求 67确定预期业务收益 68产品愿景和项目范围 68业务需求冲突 69愿景和范围文档 711. 业务需求 722. 范围和限制 773. 业务背景 79范围表示技巧 80关联图 81生态系统图 82特性树 83事件列表 84聚焦于范围 85使用业务目标来做范围决策 85评估范围变更的影响 86敏捷项目的愿景与范围 86使用业务目标来确定完成 87第6章  倾听用户的心声 89用户类别 90用户分类 90识别用户类别 92用户画像 94与用户代表取得联系 95产品代言人 96外部产品代言人 97产品代言人的期望 98多个产品代言人 99推广产品代言人理念 100产品代言人要避免的陷阱 101敏捷项目的用户表达方式 102处理需求冲突 103第7章  需求获取 105需求获取技巧 106访谈 107工作坊 108焦点小组 110观察 111问卷调查 112系统接口分析 113用户界面分析 113文档分析 114制定项目需求获取计划 114准备需求获取 116执行获取活动 117需求获取后的跟进 119整理和分享会议笔记 119记录提出的问题 120对客户的输入进行分类 120如何知道已经完成 123需求获取的注意事项 123假设的需求和隐晦的需求 124找出遗漏的需求 125第8章  理解用户需求 127用例和用户故事 128用例方法 131用例和使用场景 133识别用例 139探索用例 141验证用例 142用例和功能需求 143用例要避免的陷阱 145“以使用为中心”的需求有何好处 145第9章  照章办事 147业务规则分类法 148事实 149约束 150触发规则 151推理 152运算 152原子业务规则 153记录业务规则 154发现业务规则 156业务规则与需求 157把一切串起来 158第10章  记录需求 160软件需求规范说明 162标识需求 164处理不完整性 166用户界面和SRS 167软件需求规范说明模板 1681. 引言 1692. 整体描述 1704. 数据需求 1725. 外部接口需求 1736. 质量属性 1747. 国际化和本地化需求 1758. ?[?其他需求?] 175附录A：词汇表 175附录B：分析模型 176敏捷项目的需求规范说明 176第11章  写出优秀的需求 178优秀需求的特点 178需求陈述的特点 179需求集合的特点 180需求编写指南 181系统或用户的角度 182写作风格 183细化程度 185表述技巧 187避免歧义 188避免不完整性 191改进前后的需求示例 192第12章  一图胜千言 196需求建模 197从客户需求到分析模型 198选择正确的表达方式 199数据流图 201泳道图 204状态转换图和状态表 206对话图 209判定表和判定树 212事件-响应表 213小议UML图 216敏捷项目中的需求建模 216最后提示 217第13章  具体指定数据需求 218对数据关系进行建模 218数据字典 221数据分析 224报表的规范说明 225获取报表需求 226对报表需求规范的几点思考 227报表规范说明模板 228仪表盘报表 230第14章  功能需求以外 233软件质量属性 234探究质量属性 235定义质量需求 239外部质量属性 239内部质量属性 251用Planguage指定质量需求 256质量属性的平衡 258质量属性需求的实现 259约束条件 260如何处理敏捷项目的质量属性 261第15章  通过原型来减少风险 264原型的定义及其动机 265实物模型和概念证明 266抛弃型原型和演化性原型 267纸上原型和电子原型 270原型的使用 271原型的评估 274原型风险 275原型发布的压力 275受细节所累 276不现实的性能预期 277对原型投入过多 277原型成功的因素 277第16章  要事优先：设定需求优先级 279为什么要排优先级 280优先级排序实践 281人与优先级之间的博弈 282确定优先级的技术 283入选与落选 283两两比较并排序 284三层分级法 284MoSCoW 286100美元 287根据价值、成本和风险排优先级 288第17章  确认需求 293确认与验证 295需求评审 295审查流程 297缺陷检查清单 301需求评审提示 302需求评审面临的挑战 303需求原型 304需求测试 305使用验收条件确认需求 309验收条件 309验收测试 310第18章  需求的重用 312为什么要重用需求 313需求重用的维度 313重用范围 314修改范围 314重用手段 315哪些需求信息类型可以重用 316常见重用场景 317软件产品线 317再设计与替换系统 318其他可能的重用机会 318需求模式 319促进重用的工具 319使需求可重用 320需求重用的障碍与成功要素 322重用的障碍 322重用的成功要素 323第19章  需求开发之外 325估算需求工作量 326从需求到项目计划 329根据需求估算项目规模和工作量 329需求和排期 331从需求到设计和代码 332架构与分配 332软件设计 333用户界面设计 334从需求到测试 336从需求到成功 337
　　第Ⅲ部分  具体项目类别的需求
第20章  敏捷项目 341瀑布的局限性 341敏捷开发方法 343敏捷方法中需求的基本面 343客户参与 343文档的细节 344Backlog和排优先级 344确定时机 344史诗、用户故事和特性 345期待变更 346根据敏捷项目调整需求实践 347敏捷转型，怎么办 347第21章  改进型和替换型项目 349预期的挑战 350基于现有系统的需求技术 350按业务目标来排优先级 351当心差异 352维持性能水平 353找不到原有需求怎么办 353应当指定哪些需求 354如何发现现有系统的需求 355鼓励使用新系统 356是否可以迭代 357第22章  软件包方案项目 359进行软件包方案选型的需求 360开发用户需求 360考虑业务规则 361识别数据需要 361定义质量要求 361评估方案 362实施软件包方案的需求 364配置需求 364集成需求 364扩展需求 365数据需求 365业务过程变更 365软件包方案的常见挑战 366第23章  外包项目 367需求的详细程度恰当 368需求方-供应方的互动 369变更管理 371验收条件 371第24章  业务过程自动化项目 372业务过程建模 372基于当前过程推导出需求 373首先设计未来的过程 375业务绩效指标建模 375业务过程自动化项目的良好实践 376第25章  业务分析项目 378业务分析项目概述 378业务分析项目的需求开发 380对决策的使用排优先级 381定义如何使用信息 381指定数据需求 383定义转换数据的分析 385分析的演进本质 386第26章  嵌入式和其他实时系统项目 388系统需求、架构和分配 388实时系统建模 390环境图 390状态转换图 390事件响应表 391架构图 392原型 394接口 394有时限的需求 395嵌入式系统的质量属性 396嵌入式系统的挑战 400
　　第Ⅳ部分  需 求 管 理
第27章  需求管理实践 403需求管理流程 403需求基线 405需求版本控制 405需求属性 407跟踪需求状态 408解决需求问题 410度量需求投入 411敏捷项目的需求管理 412为什么要管理需求 414第28章  需求变更 415为什么要管理变更 415管理范围蔓延 416变更控制政策 417变更控制流程的基本概念 418变更控制流程说明 4181. 目的和范围 4192. 角色和职责 4193. 变更请求状态 4204. 准入标准 4205. 任务 4216. 退出标准 4217. 变更控制状态报告 421附录：为每个请求保存的属性 422变更控制委员会 422CCB的组成 423CCB章程 423重新协商承诺 424变更控制工具 424度量变更活动 425变更影响分析 426影响分析过程 426影响分析模板 429敏捷项目的变更管理 430第29章  需求链中的链接 432需求跟踪 432需求跟踪的动机 434需求跟踪矩阵 435需求跟踪工具 438需求跟踪过程 439需求跟踪可行吗？有没有必要 440第30章  需求工程工具 442需求开发工具 443获取工具 444原型工具 444建模工具 444需求管理工具 445使用RM工具的好处 445RM工具的能力 446挑选和实现需求工具 448选择工具 448建立工具和流程 449引导用户采用 450
　　第Ⅴ部分  需求工程的实施
第31章  改进需求过程 455需求如何关联到其他项目过程 456需求与不同的干系人群体 457获得对变革的承诺 458软件过程改进基础 460根因分析法 461过程改进循环 463评估当前实践 463规划改进行动 463过程的创建、试点和推行 465评估结果 465需求工程的过程资产 466需求开发过程资产 468需求管理过程资产 468我们达到目标了吗 469创建需求过程改进路线图 470第32章  软件需求和风险管理 472软件风险管理基础 473风险管理的要素 473用文档记录项目风险 474对风险管理进行规划 476需求相关风险 477需求收集 477需求分析 479需求指定 479需求确认 479需求管理 480风险管理是你的朋友 480尾声 483附录A  当前需求实践自评 485附录B  需求问题问诊指南 491附录C  范例需求文档 507词汇表 525参考文献 533作者简介 547

推荐序：软件需求的百科全书郑人杰　　　　当前，软件承载着人类的专业知识和实践经验，进入了社会生活的各个领域，它已经深入到人们的工作和日常生活，呈现出无处不在的景象。而软件产业己成为社会经济发展的先导性和战略性产业，成为信息产业和国民经济新的增长点和重要支柱。与此同时，人们对软件开发的产品也相应地提出了更高的要求，包括高质量、低成本和易用性，等等。　　经过多年的实践，我们开始认识到，确定软件需求是软件产品生命周期中最关键的一个环节。对于软件这一不可见的逻辑实体来说，它的研发和传统产业的产品相比有着很大差别。软件需求决定着产品开发的目标，同时，软件需求也是开发项目策划的依据。然而，做好软件需求工作并不容易。如果项目开始时需求工作做得不到位，开发项目的大厦就将建立在不牢固的基础上。自从上世纪七十年代开始，本人在软件工程领域的教学、科研和开发实践中深深地理解到软件需求工作的重要意义，也曾亲身经历过一些软件开发项目由于在初期阶段对需求工作不够重视，就匆忙开展后续工作，致使项目最终受到严重后果的惩罚。例如，用户对交付的产品不满意，由于不适用不得不返工，延期再交付。然而，返工导致的额外成本投入不仅会使开发组织的高管人员失望，开发人员也因要付出更多的劳动而怨声载道，最终导致开发组织的声誉受到影响。实际上，这种人们不愿看到的事件不断发生，也有着它的客观原因。比如，软件人员对项目提出的业务领域知识和相关技术并不熟悉，并且软件人员通常并不只是面对一个应用领域，而是常常在开发一个产品，初歩熟悉一个领域之后，下一个开发任务又会面临另一个全新的领域。此外，当今各应用领域的技术和市场情况大多处于迅速发展和演变之中。另一方面，主观上经常出现的情况则是，软件开发人员未能在项目的需求阶段很好地和用户配合，充分吸收和听取用户的意见，或是接受应用领域知识和技术的培训，等等。　　据本人了解，多年以来，市面上也有不少有关软件需求领域的专业书籍。但本书第3版在我读后，确实令我感到它的与众不同，令我赞叹。没有想到，这本书竟然对软件需求工作提供了如此全面、系统、详尽和具体的阐述。过去很长时间以来，人们对软件需求工作的理解是片面的，常常称其为“需求分析”，以为需求工作只是对需求进行分析。其实，需求分析固然重要，但还有更为重要的。那就是需求获取、需求说明、需求验证和需求管理等。许多软件项目的教训表明，问题出现的根源恰恰在于需求获取和需求验证方面存在缺陷。　　本书的另一特点是不仅讲原则、方法，而且还对软件项目的工作提供了具体的指导。比如，不同项目类型的需求（第Ⅲ部分）、需求工程的实施（第Ⅴ部分）以及在附录部分给出的“需求实践自评”、“问题问诊指南”和“范例需求文档”都具有很强的指导性、可操作性和可遵循性。无疑，在这些实践性指导的部分中渗透着作者多年的工作经验，甚至是亲历的教训，非常值得广大读者认真地学习和吸取。　　本人以为，在软件需求方面本书如此全面详尽，又是具有相当深度的指导性读物，称之为“软件需求手册”并不为过，甚至可以堪称“软件需求的百科全书”。　　高校信息技术类专业的研究生完全可以用本书作为学习参考书。对于高校教师和科研机构的研究人员以及软件开发机构的开发人员和管理人员都会将其作为必备的参考。　　正是基于对本书的上述评价，本人愿意积极向广大读者推荐，并且充分相信本书必将在一定程度上促进他们的专业工作，最终成为他们的良师益友。　　　　　　　　译序：试问需求从何而来译者团队代表李淳　　　　这是一个全民创业、万众创新的时代。无论初创企业还是大型企业，无论互联网巨头还是传统行业公司，都在思考这样的问题：“我们的风口在哪里？”　　随着大数据、O2O、移动互联、物联网、开放平台、云计算等技术术语越来越快速地进入公众的视野，为商业创新带来了巨大的机遇，更为新时代的软件开发提出了机会和挑战。我们看到，微博、微信、手机打车等一批新兴商业模式如雨后春笋般渗入到人们的生活，为人们带来极大的便利。然而，我们还看到，在这些成功的商业模式身后，流淌着无数“失败者”的血泪。大量新企业、新项目劳神费力，投入大把时间，大把烧钱，上线后却发现提供的产品和服务无人问津。　　为什么？因为我们需要的并不是“等风来”，闭门坐在办公室里等需求是行不通的。 　　以往，一切都源自老板的一个想法。然后大家便会在办公室里讨论，各种头脑风暴，然后选择其中认为不错的方案来写需求文档，进行技术评估……（中间省略一千步）……直至最后交付。然后，就有了大家都知道的然后，简直让人痛心疾首！　　在我看来，闭门造出来的需求通常都有这样的共同特性。　　1. 希望在上线的一刹那一举形成可行的商业模式　　通常，当一个成功的商业模式被大众所接受时，人们看到的便是一个具有百万千万级规模的市场群体在进行消费。然而，人们看不到的是这些商业模式成功之前所遭受的屡屡失败。无疑，这些成功的商业模式在给人们设立了标杆之后，也给人们带来了不切实际的幻想：“一定要交付能够一举成功的产品或服务。”　　2. 假设最初的想法是正确的　　不切实际的预期伴随着一种扭曲的力场，让人误将想法假设为事实。于是，几乎没有人认真思考最初的想法是否真的正确？　　信息洪泛使得未来是愈发不可精确预知，试问每个想法能有多大的可能性是正确的呢？　　3. 认为专家就在办公室里　　头脑风暴，讨论，最终民主集中为办公室里的权威人士，可能是老板、上级甚至在办公室里工作年头最长的那个人。他们的决策依据往往是经验。然而，当你满怀希望想要创新的时候，就已经意味着没有人会有经验，所有意见决策都往往是靠猜的。　　4. 上线之前，知道这个想法的客户数量为0　　为了确保我们“一举成名”，让那个不切实际的幻想变成现实，我们会对外严格保密，一出办公室便绝口不提。因为我们害怕这个想法被别人抢走，更害怕客户否定尚未达到我们心中“完美标准”的产品。然而，飞得越高摔得越痛，当上线时才开始寻找客户，我们的幻想将宣告灾难性的破灭。　　幸运的是，近十年间，人们开始意识到这一问题，发现正确的需求变得愈发重要，各种新的创新方法不约而同地向人们传达出下面这四大新的理念。 　　1. 成功的商业模式需要依靠对正确需求的持续积累　　商业模式的成功需要一个从0到1的过程，而非一蹴而就。在这个过程中，失败的可能性远远超过成功，所以为了更快地成功，就要快速而频繁地失败，更快速从失败中学习，更快地积累点滴成功。抛弃不切实际的幻想，不要再苛求“完美”，主动拥抱失败，让商业模式自然生长出来！　　2. 要获得正确的需求，需要专家不断否定你的猜想　　拥抱失败不等于鲁莽地冒险，漫无目的地四处挖井，而是要使需求不再失败。因此，最好办法就是让专家频繁地对你的猜想证伪，用反馈和数据来指导接下来的行动，直到需求无限趋近于恰到好处。　　3. 真正的专家是会购买你的产品或服务的客户　　需求之所以有存在的意义，归根结底是因为有客户愿意为此买单。因此，要想做到拥抱失败，持续证伪，你要做的便是不断与客户沟通，找出这两个问题的答案：1）为什么你的产品无法吸引他们的注意力？2）为什么他们不会为你所假设的需求买单？　　真正的专家不是办公室中的权威，客户才是！主动和他们沟通，积极向他们提问，收集他们的数据，聆听他们的心声，让他们告诉你什么是错，什么是对。　　4. 走出办公室　　既然客户不在你的办公室，世界那么大，何不出去看看呢？走出办公室，找到客户，发现真正的需求！　　在此，我想对本书的作者Karl Wiegers和Joy Beatty致敬，他们一直在告诉我们一个道理：“正确的需求高于正确地需求。”我还要衷心感谢一同翻译此书的译者、编辑、设计等，感谢清华大学出版社为我们带来如此经典而权威的著作。　　再次，愿所有读者能与我们一起共勉：“不要等风来，走出办公室，去找风！”　　　　　　　　前    言　　几十年过去了，许多软件组织仍然难以了解、记录和管理自己的产品需求。之所以如此多的信息技术项目无法完全成功，主要原因在于用户输入匮乏、需求不完整、需求变化以及对业务目标的误解。一些软件团队疏于从客户和其他来源收集需求。客户往往没有时间或耐心参与需求工作。在许多情况下，项目参与人员甚至无法就“需求的确切含义”达成共识。正如有作者所指出的：“工程师宁愿破译Kingsmen 1963年的经典派对歌曲Louie Louie，也不愿意破译客户需求。”（PerterSon 2002）　　十多年前，《软件需求（第2版）》出版发行。十年对技术界而言真的是一段漫长的时间。许多事情在这期间已经发生了变化，但仍然有一些没有变。过去十年中，软件需求主要呈现出以下几个趋势。* 业务分析被认为是一门专业的学科，专业认证和组织已经兴起，比如“国际业务分析师协会”和“国际需求工程协会”。* 基于数据库的需求管理工具和需求开发辅助工具（如原型、建模和仿真）日趋成熟。* 敏捷开发方法的使用越来越广泛，处理敏捷项目需求的技术也在不断演进。* 可视化模型越来越广泛地应用于阐述需求知识。　　那么，哪些不曾发生变化呢？这一话题重要而且意义深远，原因有两个。其一，许多软件工程和计算机科学的本科教材依然不够重视需求工程（包括需求开发和需求管理）的重要性。其次，我们这些软件领域从业人员骨子里一直痴迷于通过技术和过程方案来应对挑战。其实有时并未意识到需求收集以及许多软件和系统项目工作中，普遍面临的最大挑战是人与人如何互动。尽管许多工具都可以用于帮助地理分散的人们展开有效的协作，但没有哪一种神奇的新技术能够将此自动化。　　我们相信，第2版中提到的实践依然广泛有效并适用于软件项目的需求开发和管理。为了满足具体情况的需要，业务分析师、产品经理或产品负责人需要发挥自己的创造力，对这些实践进行精心调整和测量。在第3版中，新增一章介绍敏捷项目中的需求把控，其他几章中也增加有新的内容，介绍如何在敏捷开发环境中使用和调整需求实践。　　在软件开发中，沟通总是重于计算机操作，但在教学课程和项目工作中，却往往注重计算机操作而忽视人际沟通。本书提供数十种工具用于加强沟通和帮助软件从业人员、管理人员、市场营销人员以及客户使用更有效的需求工程方法。这里提及的技术是一套工具包，其中包含主流的“优秀实践”，而非奇炫的新技术或某种声称能解决所有需求问题的复杂方法论。本书讲了无数趣闻轶事和八卦故事，都是真人真事，讲述着典型的需求相关经历，你可能也曾有过相关的经历。可以找到“真实故事”图标，了解精选自各种项目经历的真人真事。　　自从本书1999年第1版问世以来，我们历经项目无数，并且已授课好几百场，为来自不同规模和类型的企业和政府机构的学员传授软件需求知识。我们发现，无论是本地团队还是分布式团队，无论使用传统开发方法还是敏捷开发方法，这些实践对任何项目几乎都有帮助。这些技术不只适用于软件项目，还适用于硬件和系统工程项目。与其他任何技术性实践一样，需要凭借良好的判断力和经验了解如何才能最有效地使用这些方法。要将这些实践想象成工具，借助于这些工具，可以确保在项目中与合适的人进行有效的沟通。本书的价值　　在所有可以采取的软件过程改进中，让人们收获最多的就是改进需求实践。我们介绍的技术都是实践证明有效的，能够从以下几个方面提供帮助。* 从项目开始，写高质量的需求，尽可能减少返工，尽可能提升生产率。* 交付高质量的信息系统和商业产品，实现业务目标。* 管理范围蠕变和需求变更，既紧盯目标，又确保可控。* 获得更高客户满意度。* 降低维护、改进和支持成本。　　我们的目标是帮助改进所使用的需求流程，更好地收集和分析需求、编写和确认需求规范以及在整个软件开发周期中管理需求。我们所介绍的技术全部都是务实求真的。我们两人已经多次使用这些技术，而且每次这样做，总是能够得到很好的结果。本书的读者　　包括软件在内的任何系统，只要需要定义或了解其需求，任何人都能从这本书中找到有用的信息。本书主要面向开发项目中担任业务分析师或需求工程师的个人或群体，既包括全职专家，也包括临时填补分析师角色的其他团队成员。第二个读者群体包括架构师、设计师、开发人员、测试人员以及必须了解与满足用户预期并参与创建和评审有效需求的其他技术团队成员。负责制定（使产品获得商业成功的）功能和属性规范的市场人员和产品经理会发现这些实践非常有用。项目经理能从本书中学到如何对项目需求工作进行规划和跟踪，如何处理需求变更。此外，干系人也属于本书读者群体，为了满足业务、功能和质量需要，他们也会参与产品定义工作中。对于最终用户、需要购买或承建软件产品的客户以及许多其他干系人，本书能够帮助他们了解需求流程的重要性及其所扮演的角色。内容概览　　本书共五个部分。第I部分从相关定义切入。如果是企业内部的技术人员，请与关键客户分享第2章中的“客户开发伙伴”小节。第3章概述几十种需求开发和管理的优秀实践以及一个需求开发流程整体框架。业务分析师的角色是第4章的主题，这一角色还有很多其他的名称。　　第II部分首先讲项目的业务需求定义技术。接着专门介绍如何找到正确的客户代表，如何从他们那里收集需求，如何记录用户需求、业务规则、功能性需求、数据需求以及非功能性需求。第12章介绍许多可视化模型，从不同角度阐述需求并对自然语言文本加以补充。第15章讲述使用原型降低风险。随后介绍需求排优先级、需求确认、需求重用的方法。最后介绍需求如何影响项目工作的其他方面。　　第III部分属于新增内容，各章为各种具体类型的项目推荐最有效的需求方法，具体类型包括：开发任何类型产品的敏捷项目、改进型和替换型项目、引入软件包方案的项目、外包项目、业务过程自动化项目、业务分析项目以及嵌入式和其他实时系统。　　需求管理的原则和实践是第IV部分的主题，重点讲述用于处理需求频繁变更所需的技术。第29章介绍如何进行需求跟踪，如何将独立的需求与原始需求连接起来，如何将需求与下游的开发交付物连接起来。第V部分最后介绍用户改进团队需求开发和需求管理行为的商业工具。　　本书的最后一部分是第V部分，这一部分帮助你从概念走向实践。第31章帮助你向团队开发流程中导入新的需求技术。第32章介绍项目中一些需求相关的常见风险。附录A的自我评估能够帮助你选择改进时机成熟的领域。其他两个附录包括一个疑难解答和一些需求文档样例，以便你能够看到全景。案例学习　　为了说明本书所介绍的方法，我们提供若干事例，这些事例来自我们做过的真实项目，尤其是化学品追踪系统这个中型信息系统。别担心，了解这个项目不需要懂化学。案例过程中的讨论贯穿全书始终。无论组织要构建什么软件，这些对话都能与你产生共鸣。
从原则到实践　　鼓起勇气，克服障碍进行变革，并将新知识付诸于行动，是很困难的事情。为帮助进行需求改进，大多数章都在最后给出行动练习，帮助你立即开始学以致用。许多章都提供建议模板，包括各种需求文档、评审检查清单、需求排优先级电子表格、变更控制流程以及许多其他的流程资源。这些内容可以在本书配套内容网站下载，网址为http://aka.ms/SoftwareReq3E/files，可以通过它们马上上手。从小的改进开始，从现在开始，宜早不宜迟。　　有些人不愿意尝试新的需求技术。使用本书来教一教自己的同行、客户以及经理。提醒他们以往项目中所遇到的需求相关问题，并和他们讨论尝试使用新方法能带来哪些潜在的收益。　　要想使用更好的需求开发实践，无需启动一个新的开发项目。第21章讨论了各种技术在改进型和替换型项目中的用法。增量实施需求实践是一种低风险的过程改进方法，可以为你的下一个重要项目做足准备。　　需求开发的目标是积累一系列足够好的需求，使团队能够以可接受的风险水平设计和构建产品的下一个部分。需要对需求工作投入足够的重视，才能降低返工、产品验收不通过以及计划“爆炸”所带来的风险。本书提供的工具能够让正确的人落实到行动上，为正确的产品开发正确的需求。勘误&本书支持　　我们已经力求确保本书及其辅助内容的准确性。在本书出版发行之后，书中的任何错误都将列在以下网址：http://aka.ms/SoftwareReq3E/errata。　　如果发现未列出的错误，同样可以在这里进行报告。　　如果需要其他支持，请发送电子邮件至微软出版社图书支持邮箱：[email protected]。　　请注意，上述地址不提供对微软软件产品的支持。让我们聆听你的心声　　在微软出版社，读者的满意是我们的头等大事，读者反馈是我们最有价值的资源。请告诉我们你对本书的想法：http://aka.ms/tellpress。　　调查很短，我们会阅读您的每一个评论和想法。先感谢您的贡献！保持联系　　让我们保持顺利的沟通！我们的推特地址是http://twitter.com/MicrosoftPress。
　　致    谢　　写这样一本书离不开整个团队的努力，远远不只是我们两位作者的贡献。很多人花时间对书稿进行评审，提出无数改进建议，我们对此深表感谢。我们特别感谢Jim Brosseau、Joan Davis、Gary K. Evans、Joyce Grapes、Tina Heidenreich、Kelly Morrison Smith以及Joyce Statz博士为我们提出宝贵意见。其他评审人员还包括Kevin Brennan、Steven Davis、Anne Hartley、Emily Iem、Matt Leach、Jeannine McConnell、Yaaqub Mohamed以及John Parker。我们还要感谢Tanya Charbury、Mike Cohn、Alex Dean博士、Ellen Gottesdiener、Shane Hastie、James Hulgan、Phil Koopman博士、Mark Kulak、Shirley Sartin、Rob Siciliano以及Betsy Stockdale，他们从各自的专业角度对具体章节提供了非常详尽的意见。我们特别感谢Roxanne Miller和Stephen Withall，感谢他们深刻的见解和无私的参与。　　我们与许多人就书中的主题进行了探讨，从他们的个人经验和他们发给我们的资源材料中，我们学到很多东西。我们对Jim Brosseau、Nanette Brown、Nigel Budd、Katherine Busey、Tanya Charbury、Jennifer Doyle、Gary Evans、Scott Francis、Sarah Gates、David Gelperin博士、Mark Kerin、Norm Kerth、Scott Meyers博士、John Parker、Kathy Reynolds、Bill Trosky、Ricardo Valerdi博士以及Ian Watson博士的贡献表示赞赏。我们还要感谢让我们在“真实故事”中分享其趣闻轶事的人。　　Seilevel公司的许多工作人员也为本书提供了大力支持。他们对具体章节进行评审、参与快速意见和体验调查、分享他们写的博客、编辑定稿、绘图并帮助我们解答各类业务问题。在此我们要感谢Ajay Badri、Jason Benfield、Anthony Chen、Kell Condon、Amber Davis、Jeremy Gorr、Joyce Grapes、John Jertson、Melanie Norrell、David Reinhardt、Betsy Stockdale以及Christine Wollmuth。他们的工作为我们减轻了压力。我们特别赞赏Candase Hokanson对编辑工作的投入。　　还要感谢微软出版社的许多工作人员，包括组稿编辑Devon Musgrave和项目编辑Carol Dillingham，S4Carlisle Publishing Services的项目编辑Christian Holdener、编审人员Kathy Krasuse。感谢校对人员Nicole Schlutt、索引制作人员Maureen Johnson、排版人员Sambasivam Sangaran以及产品制作人员Balaganesan M.、Srinivasan R.与Ganeshbabu G.。作者Karl对Devon Musgrave和Ben Ryan长期以来建立的合作和友谊给予高度评价。在我们这么多年的需求培训班中，有上千名学员提供反馈和问题，激励着我们深入思考需求问题，我们从中得到了莫大的帮助。我们的咨询经历和读者提出的引人深思的问题，使我们不断了解到从业人员在日常工作中遇到的困难并帮助我们思考。请与我们分享你的经历，发送电子邮件到 [email protected] 或者 [email protected]。　　一如既往，Karl要感谢他的妻子Chris Zambito。一如既往，整个过程中她都很有耐心而且脾气极好。Karl还要感谢Joy鼓励他参与这个项目中以及Joy对这个项目听做的了不起的贡献。与Joy一起工作真的很开心，她还使这本书增添了很多价值。很高兴能够和她一起不断讨论、一起艰难决定并在交稿前一起对书稿进行精雕细琢。　　Joy特别感谢他的丈夫Tony Hamilton这么快就再次支持她的写作梦想；还有她的女儿Skye，让她每天轻松保持工作与生活的平衡；还有Sean和Estelle，让家庭时光充满欢乐。Joy还想专门感谢Seilevel的全体员工，感谢他们齐心协力推动软件需求领域向前发展。她特别感谢两位同事兼朋友：Anthony Chen对她写这本书提供了至关重要的支持；Rob Sparks不断鼓励Joy为此付出努力。最后，Joy重点感谢Karl允许她和他一起合著，每天都教她一些新知识，百分之百的愉快合作！

专家推荐：
 “业务分析领域的经典著作之一，第3版尤其体现了这一专业领域过去十年的进展和*趋势。”

第1章软件需求的本质　　“喂，Phil吗？我是人事部的Maria。我们在使用你开发的人事系统时遇到一个问题。有位职员刚刚把她的名字改成Sparkle Starlight，但我们无法在系统中改。你能帮个忙吗？”　　“那么她是结婚了，随老公姓Starlight？”　　“没有，她没结婚，只是改名字了，”Maria回答道，“问题就出在这里。好像我们只能在某人婚姻状况发生变化时才能在系统中改名。”　　“好吧，是，我从来没想过有人可能会改自己的名字。当初我们在讨论系统的时候，你可没告诉过我有这种可能性。” Phil答道。　　“我以为你知道任何人随时都可以合法更改名字呢，”Maria回应道，“我们得在星期五之前解决这个问题，否则Sparkle就领不到工资了。你可以在此之前修复这个bug吗？”　　“这不是什么bug，好吗？！” Phil反驳道，“我从没想过你们需要这项功能。我现在正忙着做一个新的绩效评估系统。你所说的问题我只能在月底修复，但周五之前肯定不行，抱歉。下次如果再有类似情况，请早点告诉我，并请提供书面材料。”　　“那我怎么和Sparkle说呢？”Maria追问道，“如果她领不到工资，会很难过的。”　　“嗨，Maria，这不是我的错，”Phil抗议道，“如果当初你早提醒我你需要能够随时更改某人的姓名，这种事情就不会发生。你不能因为我没猜透你的想法就怪我。”　　Maria怒了，但又无可奈何，只好厉声说：“是，你说的都对！好吧，这种破事儿让我对电脑简直是恨之入骨。问题解决好了，就马上打电话告诉我，可以吗？”　　　　如果你是以上对话中的客户一方，就会明白无法使用软件系统来完成一项基本任务多么令人沮丧。你会痛恨自己得求着开发人员，因为关键变更请求最终掌握在他们手中。另一方面，开发人员也很沮丧，因为他们只有在系统开发完成之后才会明白用户期待有哪些基本功能。对于开发人员来说，更恼火的是，得中断手头的项目去修正以前已经完成的系统（因事先未被明确告知而疏忽的需求）。　　软件中的很多问题大多数来源于人们了解、记录、协商和修改产品需求的方法不当。就Phil和Maria这个例子而言，问题就包括：信息收集不正规；功能隐晦；对假设功能有理解上的分歧；需求指定不明确以及变更过程不正规。很多研究表明，软件产品中发现的缺陷有40%～50%是在需求阶段埋下的“祸根”（Davis 2005）。在具体说明客户需求和管理客户需求过程中用户输入不足和有误，是造成项目失败的罪魁祸首。尽管证据确凿，但很多组织仍然在实行这些没有什么成效的需求方法。　　在软件项目中，所有干系人的利益交接点主要集中在需求方面。（更多干系人方面的内容，参见第2章）这些干系人包括客户、用户、业务分析人员和开发人员等。如果处理得当，这种交接既可以让客户满意，又能鼓舞开发人员。若处理不当，则会引发误解和摩擦，最终降低产品质量和业务价值。正是由于需求是软件开发和项目管理活动的基础，因此所有干系人都应该致力于需求实践活动，这是打造一流产品的前提。　　但开发和管理需求确实很难！既没什么捷径，也没有任何灵丹妙药。另外，很多组织都在朝着一个目标努力，要找到一种能适应不同情景但又有共性的技术。本书后面将讲到很多这样的实践。这些实践假定你正在开发一种全新的系统。但是，它们中的多数也可用于改进、替换以及重构项目（详见第21章），还可以用于融合商业现成品的（COTS）打包解决方案项目（详见第22章）。即使项目团队遵循敏捷开发过程渐进式构建产品增量，团队也要理解每一个增量所涉及的需求（详见第20章）。
　　本章将帮助你：* 理解软件需求领域所用的一些关键术语；* 区分产品需求和项目需求；* 区分需求开发和需求管理；* 警惕可能出现的与需求相关的一些问题。给自己的需求把把脉　　要想对组织中现有的需求实践做一次快速体检，就对比下列问题，看看有多少条出现于你最近的项目中。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。* 从来没有清晰制定过项目的业务目标、愿景和范围。* 客户太忙，没有时间与分析师或开发人员共同处理需求。* 团队无法与用户代表直接互动，不理解他们的具体需要。* 客户认为所有的需求都很关键，因此没有对需求排定优先级。* 开发人员在写代码时遇到了模棱两可或者遗漏的信息，所以只能靠猜。* 开发人员与干系人沟通的重点集中于用户界面展示或者特性，并没有关注用户要使用软件完成的具体任务。* 需求从来没得到过客户的认可。* 客户认可了某个发布或者迭代的需求，但事后又不断更改。* 不断接受客户的需求变更请求，项目范围随之扩大，由于没有增加资源或者删减功能，进度最后完全被打乱。* 有人提出了变更请求，但被忽略，没人知道特定变更请求的具体状态。* 客户提出特定的功能要求，而且开发人员也建好了，但就是没有人用过。* 在项目接近尾声时，虽然满足规范说明，却不满足客户或业务的目标。软件需求的定义　　人们在讨论需求时，开始经常会遇到专业术语问题。人们从不同的角度阐述同一样东西，例如：用户需求、软件需求、业务需求、功能需求、系统需求、产品需求、项目需求、用户故事、特性或者约束条件。人们又赋予了不同的需求交付物多种称谓。对于开发人员来说，客户所定义的需求听起来更像是一种高级产品概念。对于用户来说，开发人员所说的需求理念可能听起来更像一种具体的用户界面设计。这种理解上的偏差让人困惑，令人沮丧。关于“需求”的一些解释　　即使计算机编程技术已经有很多年头，软件从业者仍然在激辩“需求”的准确定义。我们不想在本书中继续这种争论，只想从实用定义的角度简单表述一下。　　顾问布莱恩·劳伦斯（Brian Lawrence）认为，需求是“任何能够驱动设计做出选择的东西。”这种口语化定义不错，因为很多信息都印证了他的说法。毕竟，开发需求的目的就是要做出合适的设计选项，最终满足客户需要。另外一种定义认为需求是产品所必备之属性，目的是向干系人提供价值。这也没错，但不太准确。我们比较倾向于Ian Sommerville and Pete Sawyer （1997）所提出的观点：　　　　需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。　　　　这个定义认为“需求”是多种不同类型的信息的统称。需求涵盖来自客户视角的外部系统行为以及来自开发人员视角的一些内部特征。它们包含系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手。
字典中的“需求”　　字典对“需求”的解释为：“被命令或者强制性的东西；需要或者必要。”这与软件界所使用的“需求”不是一个含义。人们有时会怀疑是否有必要对需求进行优先级排序，因为有的低优先级需求可能永远不会被实现。人们认为如果对某些东西的需求不是太强烈，就说明它们不是需求。可能是这样，但我们管这类信息叫什么？如果将当前项目中的需求推迟到未来某个不确定的发布之中，它还是需求吗？当然是。　　软件需求包含一个时间维度。它们可能是描述目前系统性能的现在时。或者它们可能是近期（高优先级）、中期（中等优先级）或者想象中（低优先级）的未来。甚至可能是过去时，也就是那些曾经被人指定但后来又被舍弃的需要。我们没必要浪费时间争论某个东西是否是需求，即使知道自己会为了某个合理的业务原因而永远不执行它。需求就是需求。需求的层次和种类　　由于有很多不同类型的需求信息，所以我们现在需要用一组形容词来修饰一下被人们赋予太多意义的“需求”。表1-1列出了需求领域的一些常用术语。　　表1-1  一些类型的需求信息术语 定义业务需求开发产品的组织或者获取产品的客户所需的高层次业务目标业务规则策略、纲领、标准或者制度，能够定义或者约束某些方面的业务。虽然本身并不是软件需求，但它却是一些类型的软件需求的鼻祖约束对开发人员在产品设计和构建上的限制条件外部界面需求对软件系统和用户、其他软件系统或硬件设备间的关联进行说明特性单个或者多个为用户提供价值的、有逻辑关系的系统性能，可以通过一个功能需求集合进行描述功能需求描述系统在特定条件下展现的行为?   续表术语 定义非功能需求描述系统必须展现的属性或者特性，或者必须遵守的约束质量属性一种非功能需求，描述的是服务或者一个产品的性能特征系统需求包含多个子系统的产品的顶层需求，子系统可以是软件，也可以是软硬件用户需求特定用户群必须能够用系统所完成的目标或任务，或者是用户期望有的产品属性　　　　软件需求有三种不同的层次：业务需求、用户需求和功能需求。此外，每个系统都包含某种类别的非功能需求。不同种类的需求如图1-1中的模型所示。正如统计学家乔治E.?P.?巴克斯（George E. P. Box）的一句名言所述：“从本质上讲，虽然一切模型都是错误的，但有些还是有作用的。”（Box and Draper 1987）。这句话用来形容图1-1真是恰如其分。这个模型也许并不全面，但提供的方案非常实用，可以帮助组织需求方面的知识。　　图1-1所示椭圆中的内容代表需求信息的种类，长方形表示储存信息的文件。实线箭头表示具体类型的信息通常储存于所示文件之中。（业务规则、系统需求应与软件需求独立存储，例如存储在业务规则目录或者系统需求规范说明之中。）虚线箭头代表一种信息起源于或者受另外一种信息的影响。此图没有具体展示数据需求。数据受控于功能，因此数据需求贯穿于这三个层次的需求之中。第7章有很多这些不同种类的需求信息的示例。
 图1-1  各类需求之间的关系。实线代表“被存储于”；虚线代表“起源”?或“影响”

　　　　业务需求描述组织为什么要执行系统（组织希望获得的业务收益）。其关注点在于组织或者提出系统要求的客户有哪些业务目标。我们假设有家航空公司打算把机场的柜台工作人员成本降低25%。为此，人们通常想到的是建一个自助服务终端，供乘客在机场自行检票。项目的出资方、目标客户、实际用户的管理层、市场部门或者产品规划部门一般都会有业务需求。我们喜欢将业务需求记录在愿景或者范围文件之中。还有一些战略性指导文件有时也会用于此目标，包括项目图表、业务实例以及市场（或者营销）需求文件。第5章的主要内容是对业务需求进行详细说明。考虑到本书的主旨，我们假定已经确定了业务需求或市场机遇。　　用户需求描述了用户使用产品必须完成的目标或者任务，并且这个产品要能够为人提供价值。用户需求主要还包括对用户满意度最为关键的产品特性或特征的描述。用例（Kulak and Guiney 2004）、用户故事（Cohn 2004）以及事件响应表都是用户需求的表示方式。理想状态下，这种信息由实际用户代表提供。用户需求表达的是用户通过系统来完成哪些具体工作。通过航空公司网站或者机场自助检票机“办理登机手续”是“用例”的典型例子。如果将其写为“用户故事”，同样的用户需求可能是这样的：“作为一名乘客，我想办理登机手续，以便能够登机。”还有一点我们不能忘记，即大多数项目都有若干个用户类别和其他干系人，我们还必须获取它们的需求。第8章将对这种层次的模型进行解释。有些人喜欢用“干系人的需求”这个更广义的术语来说明各类干系人比直接客户更能提供需求。这当然没有问题，但是我们要在这个层级集中注意力，理解实际用户要用这个产品完成哪些具体目标。　　功能需求说的是产品在特定条件下所展示出来的行为，主要描述开发人员需要实现的功能以便用户能够完成自己的任务（用户需求），进而满足业务需求。这三种需求环环相扣，对项目的成功至关重要。人们经常将功能需求记录为传统意义上的“应当”句式：“乘客应当能够随时打印自己已经办好登机手续的所有航段的登机牌”或者“如果乘客信息没有指定座位偏好，航班预订系统就应当为它分配。”　　业务分析师（BA）①将功能需求记录在软件需求规范说明（software requirements specification，SRS）之中，尽可能详尽地描述人们对软件系统的预期行为。SRS用于开发、测试、质量保障、项目管理和相关项目功能。它的称谓很多，包括业务需求文件、功能规范说明、需求文件等。SRS可以是一个报告，由存储在需求管理工具中的信息所生成。由于它已成为一种行业标准术语，所以我们在本书中将其统称为“SRS”（ISO/IEC/IEEE 2011）。要想进一步了解SRS，请参见第10章。　　系统需求描述了人们对某个产品的需求，而这个产品由多个组件或者系统子集组成（ISO/IEC/IEEE 2011）。“系统”在此不单单是信息名义上的系统。所有软件或软件、硬件系统子集都可以算是系统。甚至人和过程也是系统的一部分，因此某些特定的系统功能可以分配给人。有些人使用“系统需求”这个词来表达对软件系统的具体需求，但我们在本书中并不这样使用该术语。　　超市收银员的工作台算是“系统”的一个典型例子。超市里有与称重设施相连的条形码扫描仪和手持式条形码扫描仪。收银员有键盘、显示器和现金抽屉。我们在超市里面还可以发现用于刷积分卡、信用卡或者借记卡的读卡器和PIN盒，甚至还有自动找零机。甚至还可以看到三台打印机分别打印购物小票、信用卡签单和优惠券，只不过这些对你来说无关紧要。这些硬件设备都在软件控制下互相关联。随后，业务分析师根据系统或者产品的整体需求提取具体功能，将其分配给这些组件系统子集中的某一个，同时了解它们之间的接口。　　业务规则包括公司政策、政府法规、工业标准以及计算算法。在第9章中，将说明业务规则本身并不是软件需求，因为它的存在已经超出了任何特定软件应用的范围。然而，它们又经常决定着系统为了切合相关规则而必须包含哪些功能。正如公司安全策略一样，业务规则有时又引申出具体的质量特性，这些特性又以功能的方式由开发人员实现。因此，特定的功能需求可以追溯到具体的业务规则。　　除了功能需求，SRS还包含某些类别的非功能需求。质量属性也被人们称为质量因子、服务需求质量、约束以及“***性”。它们从不同角度描述产品特征，例如性能、安全性、易用性和可移植性，这些对于用户、开发人员和维护人员来说都非常重要。还有一些非功能需求描述系统与外部世界的接口，包括与其他软件系统、硬件组件、用户以及沟通界面的关联。在创建产品的过程中，开发人员的选择受限于设计和实现约束。
非功能需求到底是什么？　　要想对组织中的现有需求实践做一次快速体检，就需要对比下列问题，看看有多少条出现于你最近的项目。如果其中有三四条以上与你的经历相符，那么本书就是为你量身定做的。　　在项目接近尾声时，虽然满足了规范说明，却不满足客户或业务的目标。　　多年以来，人们从广义上将软件产品需求分为功能需求或者非功能需求。功能需求理解起来很容易，它们描述的是系统在不同条件下能够被用户观察到的行为。然而，大多数人都不喜欢“非功能”这个术语。因为这个形容词强调的是需求不是什么，并没有说明需求是什么。很遗憾，对于这个问题，至今没有一个令人满意的答案。　　功能之外的需求强调的并不是系统要做什么，其重点在于系统做得有多棒。它们对系统最重要的特征或属性进行描述，包括系统的易用性、易用性、安全性和性能等很多特征，这些都在第14章中有所体现。有些人将非功能需求等同于质量属性，但这过于狭隘。例如，设计和实现约束也是非功能需求，外部接口需求也是。　　还有其他一些非功能需求，它们描述的是系统运行环境，例如平台、可移植性、兼容性和约束。很多产品还受兼容性、监管和发行许可的影响。我们甚至还要考虑到产品的地域性需求，例如用户的文化、语言、法律、货币、专有名词、拼写和其他特征。虽然此类需求被归入功能需求，但业务分析师仍然可以从中获得大量的功能，确保系统的所有行为和属性符合用户的预期。　　尽管有其局限性，但由于没有一种合适的替代选项，所以我们在本书中仍使用“非功能需求”这一术语。这类信息的名称是否准确并不重要，但要保证将它们纳入需求获取和分析活动。交付的产品虽然囊括所有预想的功能，但用户还是不喜欢，因为它不符合人们对其产品质量（通常未明确表达）的预期。　　　　　　一个特性包含一个或者多个逻辑上有关联的系统功能，能够为用户提供价值，这些由一组功能性需求来共同描述。客户预想的产品特性清单与描述客户的任务相关的需求不能画等号。网页浏览器的书签、拼写检查、为运动器械设定定制锻炼程序、杀毒软件中病毒库的自动升级，这些都是典型的特性。特性包含多种用户需求，每种需求都表示特定的功能需求必须实现，以便用户能完成用户需求中所描述的任务。图1-2就是一个特性树，也可以说是一个分析模型，展示的是特性如何层层分解为更小的特性组，这些小特性与具体的用户需求关联，最终引出功能需求（Beatty and Chen 2012）。

　　图1-2  特性、用户需求和功能性需求之间的关系　　为了解释这些不同类型的需求，我们假设在开发某个文本编辑程序的新版本。“在6个月内将非美国地区的销量增加25%”可以算是一种业务需求。市场部发现参与竞争的产品只有英语拼写检查器，因此他们决定新版本要包括一个多语种拼写检查器特性。对应的用户需求可能包含诸如“为拼写检查器选择语言”“发现拼写错误”和“将词添加到字典”这样的任务。拼写检查器有很多独立的功能需求，涉及的操作包括高亮拼写错误的单词、自动纠错、显示建议替代选项、用正确的单词整体替代拼写错误的单词。易用性需求明确指定如何使用特定语言和字符集来定位软件的使用区域。处理三种层次的需求　　图1-3向我们展示了不同的干系人如何参与获取三种层次的需求。不同组织对参与到这些活动中的角色称呼各异，考虑一下组织内部的这些活动。根据开发组织是一个公司内部实体性质还是一个开发商用软件的公司，角色的名称可能有所不同。　　根据特定的业务需求、市场需求或者某个新奇的产品概念，经理或者市场部门确定软件的业务需求，使公司运营更加高效（对信息系统而言）或具有很强的市场竞争力（对商业产品而言）。在企业环境中，业务分析师通常与用户代表协同工作，确定客户需求。而开发商业产品的公司通常让产品经理决定新产品应当包含的具体特性。每个用户需求和特性必须向完成业务需求看齐。从用户需求角度出发，业务分析师或者产品经理引出能够使用户实现任务目标的功能。开发人员根据功能和非功能需求来设计解决方案，执行必要的功能，但要在约束的限制范围之内。测试人员决定如何验证需求是否已经正确实现。
　　图1-3  不同干系人如何参与需求开发　　我们还要认识到以共享方式记录关键需求信息的重要性，而不应只是用传统的口述形式。我曾经参与过一个项目，其中的开发团队互相推诿。首席客户被折磨得欲哭无泪，因为每个新团队都单独找他谈话：“我们得谈一谈贵方的需求。”对于我们这个要求，他的第一反应就是：“我已经将我的需求给了你们的前任。现在我只要你们给我编个系统！”不幸的是，没人记录下任何需求，因此每个新团队都得从头开始。如果只有一堆邮件和留言信息、便条、会议记录和跟客户在走廊里短暂谈话的模糊回忆就宣称“已经有了需求”，简直就是自欺欺人。BA必须做到心中有数，能够综合考虑如何为特定的项目确定需求文档　　本章前面所提到的图1-1显示了三种主要的需求交付物：愿景和范围文档、用户需求文档和软件需求规范说明。无需为每个项目都创建三种独立的需求交付物。但将这类需求信息融合在一起（特别是对于小型项目），还是有必要的。然而，还要注意这三种交付物包含着不同的信息，要在项目的不同点进行开发，开发人员也可能不同，目的和目标受众也不相同。　　图1-1所示的模型为我们展示了一个简单的自上而下的需求信息流。在现实生活中，我们见到的是以业务、用户和功能需求为中心的循环和迭代。只要有人提出某个新特性、用户需求或者一点点功能，分析师肯定会问：“这在范围内吗？”如果答案为“是”，就将此需求归入规范说明。如果答案是“不”，就算了，起码不会放到下一个发布或者迭代之中。还有一种可能的回答：“不，但它支持业务目标，所以应该算是吧。”在这种情况下，不管是谁负责项目范围——项目发起方、项目经理或者是产品负责人——都必须当机立断，决定是否增加当前项目或者迭代的范围以适应新的需求。这种业务决策对项目的计划和预算都有着很大的影响，可能要对其他功能做出妥协。高效的变更过程包含“影响分析”以保证合适的人做出可靠的业务决策，确定哪些变更可以接受，解决时间、资源或特性权衡所关联的成本。产品需求与项目需求　　到目前为止，我们讨论的需求主要描述软件系统的属性。我们将其称为产品需求。当然，项目还包含有其他的诉求和产出，不在团队执行的软件范围之内，但对项目的整体成败尤为关键。这些都是项目需求而非产品需求。SRS包含产品需求，但不包括设计或执行细节（不同于已知的约束）、项目计划、测试计划或者类似信息。要将这类事项独立出去，使需求开发活动聚焦于理解团队要开发的内容。项目需求包括以下具体内容。* 开发团队的物质需求，比如工作站、专用硬件设备、测试实验室、测试工具和设备、团队办公室和视频会议设备。* 员工培训需求。* 用户文档，包括培训材料、教程、参考手册和发行说明。* 支持文件，例如帮助资源、硬件的现场维护和服务信息。* 操作环境中所需要的基础设施变更。* 需求和流程，用于发布产品，在实际操作环境中安装产品，对它进行配置和测试。* 针对从旧系统迁移到新系统所做的需求和规则，例如数据合并和转换、安全设置、产品切换以及为弥补技术空白而做的培训，我们有时称之为迁移需求（IIBA 2009）。* 产品认证和合规需求。* 修改的策略、过程、组织结构和类似文档。* 第三方软件和硬件组件的采购、收购和许可。* Beta测试、生产、包装、市场和发行需求。* 客户服务等级协议。　　针对与软件相关的知识产权，为获取法律保护（专利、商标或者版权）所做的需求。　　本书不对这类项目需求做过多的论述。但这并不是说它们不重要，只是超出了我们的范围，我们侧重的是软件产品需求的开发和管理。识别这些项目需求是业务分析师和项目经理的共同责任。他们在获取产品需求时经常涉及这方面的内容。项目需求信息最好存储在项目管理计划之中，详细列出全部预期项目活动和交付物。　　特别是针对业务应用，人们有时认为“解决方案”包含产品需求（业务分析师的主要责任）和项目需求（项目经理负主要职责）。他们使用“解决方案的范围”这个术语来表达“为胜利完成项目而必须完成的一切工作。”但在本书中，我们主要讨论产品需求，不管最终的交付物是某个商业软件产品、带嵌入式软件的硬件设备、企业信息系统、政府定制软件还是其他任何东西。需求开发和管理　　人们对需求术语的困惑甚至延伸到整个学科的称谓上。有些作者将整个范围都称为“需求工程”（我们赞同此观点）。有些人统称为“需求管理”。还有些人认为这些活动属于广义上的业务分析的一个分支。　　我们发现，最好将需求工程分为需求开发（参见本书第II部分）和需求管理（参见第IV部分），如图1-4所示。不管项目遵循什么样的开发生命周期——纯瀑布法、分阶段开发方法、迭代开发、增量开发、敏捷方法或者混合各种开发方式——这些需求工作都要完成。根据项目生命周期，在项目的不同阶段实施这些活动，只不过深度或广度有所差异。
　　图1-4  软件需求工程的细分
需求开发　　如图1-4所示，我们将需求开发细分为：获取、分析、规范说明和验证（Abran et al. 2004）。这些细分囊括的活动涉及产品需求的开发、评估、记录和确认。下面介绍每个细分中的一些基本活动。　　获取　　需求获取涵盖需求发现的所有活动，例如访谈、研讨会、文档分析、原型等。主要活动如下所示。* 识别产品的预期客户群和其他干系人。* 理解客户任务、目标以及与这些任务相关的业务目标。* 了解新产品的应用环境。* 与每一类客户群的代表一起工作，理解他们对功能有哪些需要以及对质量有怎样的预期。以用途为核心还是以产品为核心？　　虽然有多种策略可用，但我们在进行需求获取活动时，通常采取以用途为核心或者以产品为核心的方法。以用途为核心的策略强调的是对用户目标的理解和探求，以便提取必要的系统功能。以产品为核心的方法侧重于特性，目的是领先市场或者业务取得成功。以产品为中心的策略，其风险在于开发人员辛辛苦苦实现的特性并没有得到很高的利用，虽然它们当时看似都是奇思妙想。我们建议先理解业务目标和用户目标，然后根据自己得出的见解来确定合适的产品特性和特征。　　分析　　分析需求涉及深入并准确理解每个需求，然后将各个需求以不同的方式表达出来。下面是一些基本活动。* 分析来自用户的信息，将其任务目标与功能需求、质量预期、业务规则、建议解决方案和其他信息区别开。* 将概要需求进行适当的细分。* 从其他需求信息中引出功能需求。* 理解质量属性的相对重要性。* 将需求分配给系统架构所定义的软件组件。* 协商需求实现的优先级别。　　找出需求中的遗漏的或多余的、不必要的需求，以便定义范围。　　规范说明　　需求规范说明以一种连贯并结构清晰的方式来表达和存储收集到的需求知识。主要活动如下。* 将收集到的用户需求转换为书面形式的需求和图表，供目标读者理解、检查和使用。　　验证　　需求验证是指确认需求信息是正确的，能使开发人员制定出能满足业务目标的解决方案。其中心活动如下所示。* 检查记录下来的需求，在交给开发团队认可之前解决所有问题。* 开发验收测试和标准，保证产品的开发是建立在需求基础之上的，能够满足客户需要并达成业务目标。　　迭代是成功需求开发的关键。规划出多周期的需求探究活动，我们要逐步优化概要需求，使其进一步准确和细化，并与用户共同确认得出正确的需求。这可能是费力不讨好的活儿。但如果想解决新软件系统的不确定性，这个工作就是不可避免的。
需求管理　　需求管理活动如下所示。* 及时确定需求基线，提交一个供当前时间段使用的参考，提出一套大家商定的、经过评审和批准的功能需求与非功能需求，通常针对具体的产品发布或者开发迭代。* 评估提议需求变更可能产生的影响，然后以可控方式将获准的变更融入项目。* 随着需求的演化，保持项目计划与需求同步。* 根据预估的需求变更可能带来的影响，商定新的承诺。* 定义各个需求之间存在的关系和依赖。* 跟踪每个需求到它们各自对应的设计、源代码和测试。* 在整个项目过程中跟踪需求状态和变更活动。　　需求管理的目标不是抑制变更或加大其难度，而是为了预测和协调不可避免且实际存在的变更，最终最小化变更对项目的破坏性影响。　　图1-5从另外一个视角为我们阐明需求开发与需求管理之间的区别。本书有许多需求获取、分析、规范说明、验证和管理方面的具体实践。

　　图1-5  需求开发和需求管理的界限每个项目都有需求　　布鲁克斯（Frederick Brooks）在他1987年发表的经典论文“没有银弹：软件工程的根本问题和次要问题”中对需求在软件项目中扮演的角色做出以下精彩的论述：　　　　开发软件系统最困难的部分是准确判断开发什么。最难的概念性工作便是确定详细的技术需求，包括所有面向用户、机器和其他软件系统的接口。这项工作一旦做错，就会削弱系统性能。后期的修改工作也会更困难。　　　　软件涉及的相关系统都有对其依赖的干系人。花一些时间理解他们的需要，这对项目的成功是一种高杠杆投资。如果项目团队写的需求得不到干系人的认可，开发人员如何确定自己的工作可以使干系人满意呢？　　我们通常不太可能也没有必要在开始设计和执行之前就指定全部功能需求。在这种情况下，可以采用迭代或者渐进式方法，一次只执行一部分需求，然后获取客户的反馈，然后再进入下一个循环。敏捷开发的精髓就在于此：充分理解需求，制定周全的优先级排序和发布计划，使团队尽快开始交付有价值的软件。但这并不意味着下一个增量的需求还未被深思熟虑之前就有借口写代码。相较于对概念进行迭代，对代码进行迭代所付出的代价更高。　　人们有时不愿花时间写软件需求。但核心问题并不在于写需求，而在于判断需求。写需求只是在对自己所了解的内容进行分类、阐述和记录。只有对产品需求有充分的认识，团队才能正确处理问题，并针对问题设计出最佳的解决方案。如果不了解需求，就不知道项目何时完工，也不知道是否满足目标，在必须修改范围时，也无法做出权衡。与其担心在需求方面浪费时间，还不如想一想如果项目对需求的关注度不够会浪费掉多少银子。人对了，得出的需求却很糟糕　　如果需求出了问题，最大的恶果就是返工——重复以为已经完成的工作——尤其是在开发末期或者发布之后。返工通常会占到开发总成本的30%～50%（Shull, et al. 2002; GAO 2004），而需求错误占返工成本的70%～85%（Leffingwell 1997）。有些返工确实能增加价值和改进产品，但大量的返工不仅是一种浪费，还会挫伤士气。设想一下如果能将返工量砍掉一半，人们的生活会变成什么样子？团队成员可以更快开发出更好的产品，甚至可能按点下班了。确定更精准的需求是一种投资，并不只是成本。　　相较于在缺陷刚开始“显山露水”的时候就修复，在项目末期纠正缺陷成本显然更高。假设在处理需求时发现和修复一个需求问题要耗费1美元。如果在设计时发现问题，则要花1美元去修复需求问题，还要花2美元或3美元重构基于错误需求的设计。但我们假设没人发现错误，一直到某位用户提出问题。根据系统类型，纠正运行中所发现的需求缺陷可能要100美元甚至更多（981; Grady 1999; Haskins 2004）。我的一位咨询客户发现：如果使用一种优秀的软件检查技巧——同行审查，发现并修复其信息系统中的缺陷需要花200美元的人工费用（Wiegers 2002）。相反，如果由客户来反馈，单单一个缺陷的修复，其平均成本就要4200美元，放大了21倍。预防需求错误并在早期将其准确捕获对降低返工量有着巨大的杠杆效果。　　需求实践的不足会对项目的成功造成很多风险，这里的成功指的是在规定的成本和时间内交付符合预期功能和质量的产品。第32章将描述如何管理这一类风险以免搞砸项目。下面要介绍一些最常见的需求风险。用户参与度不够　　用户通常不明白为什么获取需求和确保质量要花费那么多功夫。开发人员也可能不重视用户的参与，也许是因为他们觉得已经明白用户的具体需要了。在某些情况下，与实际使用产品的用户直接接触很难，而用户代表并不总能理解用户的真实需要。用户参与度不足会引发新的需求，造成返工并延误工期。　　用户参与度不足的另一个风险是业务分析师无法理解并准确记录实际业务或者客户需要，特别是在检查和验证需求时。有时，业务分析师制定的需求似乎“完美无缺”，开发人员也开发了这些需求，但由于业务问题被误解，所以解决方案仍然无人问津。如果想消除风险，就得与客户保持沟通，但如果客户检查需求时不够仔细，问题仍然在所难免。规划不当　　“我对新产品的想法就这些。你什么时候能完成？”除非对讨论内容有更充分的了解，否则这个问题没人能够答得上来。如果不能彻底理解需求，就会得出过于乐观的估算，而真出现超支后你又该挠头了。做估算的人算得快听起来更像是对听者的一种承诺。软件成本估算不当的主要原因有：频繁的需求变更、需求遗漏、与用户沟通不足、低质量的需求规范和不完善的需求分析（Davis 1995）。如果围绕需求来估算项目工作量和时间，就需要了解需求的规模和开发团队的生产效率。要想进一步了解如何对需求进行估算，可以参见第5章（Wiegers 2006）。用户需求蔓延　　随着需求在开发过程中的不断演化，项目经常会超出计划的时间和预算（计划几乎总是过于乐观）。为了管理范围蔓延，必须一开始就对项目的业务目标、战略愿景、范围、边界和成功标准给予明确说明。以此为参照，对所有的新特性或者需求变更进行评估。需求会变，会发展。项目经理应当在时间表中设置应急缓冲区，以免打乱时间表（Wiegers 2007）。敏捷项目采用的方法就是对特定的迭代范围进行调整，使其符合迭代中规定的预算和时间。随着新需求的涌现，我们可以将其植入到未完工的条目之中，然后根据优先级别分配到未来的迭代之中。变更也许决定着项目成败，但它总是有代价的。需求模棱两可　　需求模棱两可的一大特征就是读的人可以用许多种方式来解读需求说明（Lawrence 1996）。另外一个信号是读的人不同，对需求的理解也各不相同。第11章将列举诸多会造成歧义的单词和短语，它们模棱两可，让人很难准确理解。　　模棱两可的需求会使不同干系人产生不同的期望。有些人会对交付物感到惊讶。当开发人员为错误问题而实施解决方案时，模棱两可的需求就会造成时间上的浪费。测试人员对产品的预期表现与开发人员开发出来的东西完全是两回事，解决这种差异肯定是浪费时间的。　　要想找出模棱两可的需求，一个办法是让那些具有不同视角的人来检查需求（Wiegers 2002）。正如第17章所提到的那样，非正式的同行检查只是从自己的角度来阅读，一般看不出模棱两可的需求。如果不同的检查者只按照自己的理解从不同角度理解需求，也看不出歧义性需求。因此，干系人应作为小组以工作坊的形式来讨论和解读需求，共同获取和验证需求。为需求写测试或者建原型也可以帮助我们找出歧义性需求。镀金　　所谓镀金，是指开发人员增加的功能并不在需求规范说明之中（或者超出范围），但开发人员却自认为“用户肯定喜欢。”如果客户对这个功能并不在意，那么实现这个功能就是在浪费时间。开发人员和业务分析师不应只是简单插入新的特性，而应向干系人展示创意，供他们参考。开发人员应当尽可能简而精，不要未经干系人同意就自作主张。　　客户有时提出一些看似合理的特性或者用户界面要求，但这些实际对产品增加不了什么价值。开发的每一个东西都有时间成本和金钱成本，因此需要将交付的价值最大化。为了降低镀金的风险，就要对每一个功能单元跟踪溯源，让大家了解为什么要有这些功能。确保规范和开发的东西都包含在项目范围之内。忽视干系人　　大多数产品都有若干个不同的用户群，他们使用不同的特性，使用频率也有所差异，经验水平也不尽相同。如果无法在早期为产品确定主要的用户分类，某些用户的需要可能就无法满足。确定所有的用户分类之后，还要保证倾听用户的声音，相关论述可以参见第6章。除了显而易见的用户，还要考虑维护人员和现场支持人员，他们也有自身的需求，包括功能需求和非功能需求。必须将数据从遗留系统中转换出来的人会有转换需求，虽然这对最终产品软件没有影响，但肯定会影响解决方案的成败。有些干系人甚至不知道项目的存在，例如制定标准并影响系统的政府机构，但你需要了解他们及其对项目的影响。高质量需求过程带来的好处　　有些人错误地认为花时间讨论需求纯粹是耽误按时交付。这种论点认为，花在需求活动上的投资不会有回报。实际上，在优秀需求上的投资真的总会让你事半功倍。　　有效的需求过程强调的是协同开发产品，并在整个项目过程中将干系人视为合作伙伴。通过需求获取活动，开发团队可以更好地了解用户或市场，这是成功的一个关键要素。如果团队强调的是用户任务，而不是局限于一些“浮华”的特性，就不会出现代码写出来却没人用的情况。用户的参与能够弥补其实际需要与开发人员交付物之间的“鸿沟”。最终你会了解客户的想法，相对于在开发产品之前而不是交付之后再意识到问题，付出的代价要小得多。第2章将讨论客户-开发合作关系的本质。　　准确将系统需求分配给不同的软件、硬件和人工子系统是一种构建产品的系统方法。有效的变更控制过程可以最小化需求变更可能带来的负面影响。将需求清晰记录下来对系统测试有着极大的帮助。上述所有这些好处会大大增加交付高质量产品的几率，满足各方干系人。谁也无法保证使用有效的需求实践就能获得具体的投资收益。但是，可以进行分析思考，想象一下优秀的需求对团队有哪些帮助（Wiegers 2006）。要得到更优准的需求，需要的成本包括开发新程序和文档模板、培训团队和购买工具。最大的投资是项目团队花在需求工程任务上的实际时间。潜在收益如下。* 需求中的缺陷和交付产品中的缺陷更少。* 开发的返工减少了。* 开发和交付更快。* 不必要和无用的特性更少。* 减少成本追加。* 信息错误传达的现象减少了。* 范围蔓延减少了。* 项目的混乱现象减少了。* 客户和团队成员的满意度更高了。* 产品按照人们当初的设想顺利运行。　　即使无法对上述好处进行量化，但也能看出它们的效果。
　　　　　　　　第2章从客户角度审视需求　　Contoso制药公司的高级经理Gerhard正在和公司的IT部门经理Cynthia开会。“我们需要构建一个可以跟踪化学制剂的信息系统，” Gerhard首先说，“这个系统应该能够跟踪我们仓库和实验室里所有的化学制剂。这样一来，药剂师就能够使用其他人剩余的化学制剂而不是总去购买新的。这会为我们节省大量经费。与此同时，健康与安全部门希望这个系统能够帮助他们大大减少向政府提供化学品使用和处理报告的工作量。你们能在五个月内及时开发出符合这些要求的系统吗？”　　“我明白这个项目有多重要了，Gerhard，” Cynthia说，“但在我提上日程之前，我们还要进一步了解这个所谓的化学品跟踪系统。”　　Gerhard很困惑，问：“什么意思？刚才我不是已经把需求告诉你了吗？　　“实际上，你只是大致介绍了一下项目的业务目标，” Cynthia解释说，“这并没有给我足够的信息确定软件究竟要实现哪些具体功能，更无法得知需要多久才能够完成。我想派一个我们这边的业务分析师实际参与用户的日常工作，了解一下究竟他们需要哪些功能。”　　“药剂师都很忙，”Gerhard反对说，“他们没时间在你们开发之前确定所有的细节。你们的人难道就不能自己想想究竟该做什么吗？”　　Cynthia回答说：“如果我们仅靠猜测来确定用户需要哪些功能，不可能把系统做好。因为我们是软件开发人员，不是药剂师。我所知道的是，如果我们不花一些时间理解问题，不会有人对结果表示满意的。”　　“我们没有时间做那些事，”Gerhard坚持自己的看法，“我已经告诉你需求了。现在就请开工吧。把你们的进度通报给我。”　　　　这样的对话在软件世界里经常发生。需要新系统的客户常常不理解从实际用户以及其他干系人那里获取信息的重要性。有伟大产品概念的营销人员坚信他们可以充分代表未来买家的利益。但是，从产品的实际使用者那里直接挖掘需求依然是无可替代的。一些敏捷开发方法就建议有一个驻厂的客户代表（有时也叫产品负责人）与开发团队一起紧密工作。一本有关敏捷开发的书中曾经如此描述：“项目的成功离不开客户和开发人员的紧密合作。”（Jeffries, Anderson, and Hendrickson 2001）　　部分需求问题源于混淆了不同的需求层面，就是第1章提到的业务、用户和功能层面。Gerhard描述了Contoso在使用新的化学品跟踪系统后可以达成的业务目标和收益。虽然业务目标是业务需求的一个核心要素，但是由于Gerhard不是这个系统的目标用户，所以它无法完整描述用户需求。同理，用户虽然能够描述他们要通过系统完成哪些任务，但无法完整描述为完成这些任务而需要开发人员实现的所有功能需求。业务分析师需要与用户紧密合作以获得对需求更深入的理解。　　本章所阐述的客户-开发人员关系是软件项目成功的关键要素。我们提出了软件客户所拥有的权利清单以及与之对应的义务清单。这些清单重点强调客户（特别是终端用户）参与需求开发的重要性。本章同时还讨论了在一次具体的发布或是开发迭代中如何对需求集合达成一致的关键性问题。第6章将详细描写各种类型的客户和用户以及各种让合适的用户代表参加需求挖掘的方法。交付物被拒收　　有一次在访问一家公司IT部门的时候，我听到了一个惨痛的故事。开发人员最近刚刚完成了一个供企业内部使用的新的信息系统。从始至终，他们获得的用户需求少得可怜。当他们最终骄傲地发布新系统时，用户却拒收系统，并认为它完全不可接受。开发人员觉得非常震惊，为了实现他们所认为的那些用户需求，他们付出了巨大的努力。随后怎么办？只能修改这个系统。在发现搞错需求之后，公司总是得修复，但是相比一开始就让用户代表加入进来，成本无疑高出很多。　　开发人员原本没有预见到需要花时间修复有缺陷的信息系统，因此团队需求队列中的下一个项目就只好先放一放了。这是一个“三输”的境地：开发人员感到苦恼；用户也很失望，因为在需要的时候新系统不可用；高管也很失望，项目花了很多钱，同时其他项目被推迟也造成大量机会成本被浪费。如果一开始就有广泛而持续的用户参与，就会避免这种不幸而常见的项目结果。期望落差　　如果没有足够的客户参与，当项目结束时一个无法避免的结果就是期望落差，用户的真实需求和开发人员根据项目之初所听到的需求开发出的产品之间的巨大鸿沟 （Wiegers 1996）。图2-1中虚线标示出了这个鸿沟。正如之前故事中描述的那样，期望落差对所有干系人来说都是一个残酷的“惊喜”。根据我们的经验，软件中的出现“惊喜”从来都不是什么好消息。与此同时，需求也很容易由于业务变化而过时，所以与客户持续沟通至关重要。　　缩小期望落差的最好方法是与合适的客户代表频繁沟通。这些沟通可以是正式访谈，对话，需求评审，用户界面设计走查，原型评估以及敏捷开发中在可执行软件每个小的增量功能上收集的用户反馈。每次沟通都是一个缩小预期差距的机会，让开发人员所开发的软件能够更贴近用户所需。　　当然，每次接触之后，随着开发的推进这个缺口又将会扩大。越频繁沟通，越容易让开发工作保持在正确的轨道上。就像图2-1中所示的逐步收缩的渐变灰色三角形，一系列的沟通将在项目最后带来小得多的预期差距，同时也能够让我们得到一个更接近用户实际需求的解决方案。这就是为什么敏捷方法的一个指导性原则是开发人员要与客户保持持续沟通。对于任何项目，这都是一个非常棒的原则。
　　图2-1  频繁的用户参与能减少期望落差谁是客户　　在讨论客户之前，我们首先讨论干系人这个角色。干系人是指积极参与项目的某个人、群体或组织，它们可能会受项目过程和结果的影响或影响项目的过程和结果。干系人可以在项目团队和开发组织的内部或者外部。图2-2标示了许多类型的潜在干系人。当然，并不都适用于所有的项目和场景。　　干系人分析是需求开发的一个重要部分（Smith 2000; Wiegers 2007; IIBA 2009）。为一个项目寻找潜在干系人的时候，应该广撒网以免忽略一些重要的群体。然后将候选干系人列表缩小为核心人选，这些人能够带给你所需的信息，确保你理解所有项目的需求和约束，使团队能够交付正确的解决方案。　　客户是干系人的一个子集。客户是能够直接或间接从产品中获益的个人或组织。软件客户可能提出需求，出钱，选择，说明，使用或者接收软件产品的输出。图2-2中包含直接用户、间接用户、上级主管、采购人员和收单机构等客户。一些干系人不是客户，比如法务人员，设计人员，供应商，承包商和风投。Gerhard，我们先前提到的那个经理，代表为这个项目付钱的上级主管。像Gerhard这样的客户提供业务需求，建立项目的指导框架以及启动项目的业务理念。我们将在第5章中探讨业务需求描述的是客户、公司或是其他干系人想要达成的业务目标。其他所有的产品需求都必须有助于达成这个预期的业务目标。
　　图2-2  项目团队、开发组织和外部组织里的潜在干系人缺失干系人的一个案例　　用户需求应该来自于直接或者间接使用产品的人，这些用户（通常称为“终端用户”）是客户的子集。直接用户会动手使用产品。间接用户虽然不动手使用，但也会收到系统的输出，例如仓库主管会收到自动发送的每日库存活动报告邮件。用户通常能够描述他们需要用产品执行的具体任务、他们需要的输出以及他们希望产品达到的质量标准。　　我知道有一个项目，当时需求引导马上就要结束了，在评审一个工作流时，业务分析师询问干系人：“你确定工作流程中的税务计算步骤是正确的么？”干系人回答：“哦，我不知道，税务不归我管。那是税务部门的事。”在随后项目推进的几个月中，研发团队没有跟税务部门的任何人进行过交流。他们甚至都不知道还有一个税务部门。在最终接触税务部门后，业务分析师发现已实现的税务相关功能在法律含义方面遗漏了一连串的需求。结果，项目延期交付好几个月。用一个组织关系图来找出所有可能受系统影响的干系人，以免产生类似的不愉快经历。　　提供业务需求的客户有时会试图替实际用户说话。然而这些内容常常和真实用户的需求相去甚远。对于企业信息系统，合同制定或者定制应用开发，业务需求应该来自于最终的产品业务价值负责人。用户需求则应该来自于按下按键、点击屏幕或是接收输出的人。如果为项目买单的人和最终用户之间有严重的脱节，肯定会出大问题。　　商业软件开发与此不同，客户和用户通常是同一个人。客户代理（例如营销人员或是产品经理）常常试图决定客户想要什么。但即使是开发商业软件，也应该尽力让终端用户加入用户需求开发过程，就像第7章里描述的。如果不这么做，那些原本可以通过充分用户参与避免的缺陷就会出现在评审报告里。　　项目干系人之间可能会出现矛盾。业务需求有时会反映用户不可见的组织战略或预算约束。通过管理手段强迫他们使用新的信息系统会使用户感到痛苦，因而他们不愿意和开发人员进行合作并把他们当作悲惨未来的先驱。这样的人常常被称作“失败者”（Gause and Weinberg 1989）。为了管理这样的潜在冲突，可以尝试基于项目目标和约束的沟通策略，创造更多的接纳，消除争论与埋怨。客户-开发的合作关系　　卓越的软件产品来自基于卓越需求的卓越设计。卓越的需求则根植于开发人员与客户（特别是终端用户）高效协作的土壤中。协同合作要想取得成果，需要所有干系人都清楚自己的需要并且理解并尊重其他合作者的需求。当项目压力上升时，很容易忘记所有干系人共享的同一个目标：构建一个既实现业务价值又可以使所有干系人受益的产品。通常需要业务分析师建立这种合作伙伴关系。　　表2-1所示的软件客户权利清单列出了十项用户权利。在项目的需求工程阶段，用户可以在与业务分析师和开发人员的互动中享有这些权利。其中每项权利都隐含着一项与之对应的业务分析师和软件开发人员义务。其中，权利和义务清单中的“你”指的是一个软件开发项目中的客户。　　因为权利的另一面代表着责任，因此，表2-2也列出了需求阶段中客户对业务分析师和开发人员应尽的十项义务。也可以认为这是开发人员的权利清单。如果这个列表并不完全适用于你的组织，可以在此基础上进行修改，使其适合具体情况。　　表2-1  软件客户的需求权利权利1. 期望业务分析师用自己的语言进行交流2. 期望业务分析师了解自己的业务和目标3. 希望业务分析师用了解合适的形式记录需求4. 收到需求实践和交付物的相关解释5. 变更需求6. 期望一个相互尊重的环境7. 聆听关于需求以及解决方案的建议和替代方案8. 描述能够提高产品易用性的特性9. 了解调整哪些需求可以实现复用，加速产品开发10. 收到满足自己功能需求和质量预期的系统　　表2-2  软件客户的需求责任责任1. 给业务分析师和开发人员传授你的业务知识2. 准备足够的时间用来澄清需求3. 提供具体而准确的需求4. 及时对需求的进行确认5. 尊重开发人员针对需求可行性和成本的估算6. 和开发人员协作设置符合实际的需求优先级7. 评审需求和评估原型8. 设定验收条件9. 及时沟通需求变更10. 尊重需求开发流程　　　　在开发公司内部系统、合同型项目或是为已知的重要客户定制系统时，上述权利和义务比较适用于实际客户。对于大众市场的产品开发，这个权利和义务更适用于产品经理这样的客户代表。　　作为项目计划的一部分。关键用户和开发干系人应该讨论这两个列表并且达成一致意见。确保需求开发过程中的参与者理解并且接受他们的责任。这种理解能够在后来减少冲突和摩擦，特别是当某个角色希望从其他角色处得到一些东西而对方却不愿或无法提供的时候。 

软件客户的需求权利法案　　下面详细介绍出现需求问题时客户可以享有的十项权利。　　权利1. 期望业务分析师使用自己的语言　　需求讨论应该以你的业务需要和任务为中心，使用业务术语。可以使用术语表的方式把业务术语介绍给业务分析师。在和业务分析师进行交流的时候，不要听到晦涩难懂的技术术语。　　权利2. 期望业务分析师了解自己的业务和目标　　通过与你互动获取需求，业务分析师能够更好地理解你的业务工作以及系统如何融入使用场景。这也能帮助开发人员建立真正符合需求的解决方案。邀请业务分析师和开发人员来观察你和你的同事的做事方式。如果是基于老的系统进行开发，业务分析师应该像你一样使用当前的系统。这么做可以使其知道系统如何融入工作流以及哪里可以做得更好。不要假设业务分析师已经了解你们所有的业务操作方式和业务术语（参见权利1）。　　权利3. 希望业务分析师用适合的形式记录需求　　业务分析师会整理所有干系人提供的信息，之后通过各种问题来区分用户需求、业务规则、功能需求、质量目标和其他需要。分析阶段的交付物是以合适形式存储的优化需求集合，比如一个软件需求规范文档或者是记录在一个需求管理工具中。这个需求集合构成了干系人对功能、质量和产品约束的一致意见。需求应该用易于理解的方式写和组织。你对这些规范说明或其他需求呈现方式（例如可视化分析模型）的评审意见，能够帮助业务分析师确认他们是否准确记录你的需求。　　权利4. 收到需求实践和交付物的相关解释　　很多实践都能够让需求开发和管理变得高效，需求相关的知识也能够用多种形式呈现。业务分析师应该解释他所推荐的实践以及每个交付物都包含哪些信息。例如，业务分析师会用一些图表来补充文本描述的需求。你也许对这些图表不太熟悉，它们也许看起来比较复杂，但标记并不难以理解。业务分析师需要解释每个图表的目的、每个符号代表的意义以及如何通过图表发现错误。如果业务分析师不提供这种解释，请直接询问他们。　　权利5. 变更需求　　业务分析师或开发人员期望你一开始就考虑清楚需求或指望这些需求在整个开发周期中保持不变，显然并不现实。随着业务的不断发展，团队接收到干系人提供的信息不断增多，或自身更深入地考虑了自己的需要，就有权变更之前提出的需求。但变更总是有代价的。有时增加一个新功能就必须在其他功能或项目整体计划和预算之间进行艰难的取舍。业务分析师的一个重要责任是评估、管理和沟通变更所带来的影响。可以在项目中和业务分析师一起摸索，确定一个简单有效的需求变更处理流程。　　权利6. 期望有一个彼此尊重的环境　　客户和开发人员之间的关系有时会变得很对立。如果参与者不理解对方，需求讨论就会令人沮丧。一起工作可以让每个参与者看到其他人所面对的问题。参与需求开发的客户有权让业务分析师和开发人员尊重自己并且感谢自己为项目成功所投入的时间。类似，客户也应该尊重开发团队成员，彼此同舟共济才能达成项目成功这一共同目标。大家是在同一战线上的。　　权利7. 聆听关于需求以及解决方案的建议和替代方案　　让业务分析师了解现有系统不适合当前业务流程的地方，确保新的系统不自动化那些低效或废弃的工作流程。也就是说，应该避免“一错再错”。业务分析师常常会对业务流程提出不少改进建议。有创造力的业务分析师甚至会提出客户未曾想到的可能性。　　权利8. 描述能提高产品易用性的特性　　业务分析师应该询问软件功能需求之外的特性。这些特性或质量属性能够确保软件更易用或更好用，使得用户能够更高效地完成其本职工作。用户有时要求产品更友好或者更健壮，但这样的描述太主观，对开发没有什么帮助。所以，分析人员应该询问哪些具体特性是对“用户友好”或者“健壮”的。还可以告诉业务分析师现在的应用在哪些方面对用户友好（哪些方面不好）。如果不和业务分析师讨论这些特性，将来的产品可能很难达到你的期望。　　权利9. 了解调整哪些需求可以实现复用，加速产品开发　　需求通常较为灵活。业务分析师也许知道当前软件组件或需求里哪些与你描述的需求接近。在这种情况下，业务分析师应该提出需求的修改方案以减少不必要的定制，让开发人员就能够复用这些组件。存在合适的重用机会时调整需求可以有效节省时间和成本。如果想集成一些现成的商业软件包，需求就得灵活，因为它们很少能够精确提供你想要的特性。　　权利10. 收到满足自己功能需求和质量期望的系统　　这是最根本的用户权利，但要实现这一点，需要清晰地表达开发正确产品所需要的所有信息，需要开发人员不断和你沟通备选方案与约束，还需要当事各方能够达成一致。确保你陈述了所有假设和期望，否则开发人员很难掌握这些信息。客户有时候并不会清楚说出他们认为是常识的信息。因而在项目团队里，验证共识与提出新的想法同样重要。
软件客户的需求责任法案　　权力对应的是责任，以下十项责任是客户代表在为项目定义和管理需求时需要履行的。　　责任1：向业务分析师和开发人员传授自己的业务知识　　开发团队需要你向他们传授业务概念和业务术语。这么做的目的并不是让业务分析师变成业务专家，而是帮助他们理解你的问题和目标。业务分析师通常并不掌握你和你的同事认为理所当然的知识。　　责任2：准备足够的时间用来澄清需求　　客户都是大忙人，参与需求梳理工作中的人往往也是最忙的人。尽管如此，你有责任为需求讨论会、访谈或者其他的需求引导和验证等活动留出时间。有时业务分析师可能认为自己已经了解你的想法，但后来却发现需要进一步澄清需求。请耐住性子接受这种迭代式开发和精炼需求的方式，因为这是复杂的人类沟通的特性，也是软件成功的关键。相比一次讨论一点且历时数周的讨论，集中几个小时的讨论更有效。　　责任3：提供具体而准确的需求描述　　让需求模糊不清很有诱惑力，因为确定细节通常都很琐碎，相当花时间（或者因为有些人想逃避责任而不愿意确认）。即便如此，必须有人解决这些模糊不清的问题。你是做这个决定的最佳人选。否则，你只能依赖业务分析师或开发人员的猜测是正确的。为需要进一步探讨的需求临时打上“待确定”标签是合理的。有时，“待确定”被用在一些难以确认的或没人愿意解决的需求上。尝试描述每个需求的潜在目的，使业务分析师能够把它准确呈现出来。这是确保产品能够满足真正需要的最好方式。　　责任4：被问到有关需求的问题时及时做出决策　　就像为你建造房子的承包商一样，业务分析师会让你做出很多决定。包括解决多个客户之间需求的冲突，在不兼容的质量属性间进行选择，评估信息的准确性。有权做出决策的客户必须及时回复。通常，开发人员在你做决定之前无法前进，所以迟迟未决会造成项目进度的延迟。如果觉得不厌其烦，请牢记系统是为你开发的。业务分析师通常都很善于引导客户做决定，所以当你难以抉择的时候可以向他们寻求帮助。　　责任5：尊重开发人员对需求可行性和成本的估算　　开发所有功能都要付出成本。开发人员是对成本进行预估的最佳人选。一些特性可能无法实现或实现成本很高。某些需求可能希望系统在运行环境中达到无法达到的性能或要求访问系统无法获得的数据。开发人员会带来这些可行性或者有关成本的坏消息。你应该尊重这些评估，即使这意味着你可能无法获得完全符合你期望的功能。有时，你可以重写需求使其变得可行或成本可接受。例如，让系统实时响应可能无法实现，但是换成精确的时间需求（50?ms内）也许可以实现。　　责任6：和开发人员协作设置符合实际的需求优先级　　很少有项目能够有足够的时间和充足的资源实现用户想要的一切。所以，决定哪些功能是核心，哪些有用，哪些需求对用户不是最重要的，这是需求分析中最重要的几点。你需要成为主角，为需求设置优先级。开发人员能够提供每个需求或是用户故事的成本和风险来帮助确定最终的优先级。设置务实的优先级，就是帮助开发人员用最低的成本在最合适的时间交付最大化的价值。协作确定优先级是敏捷项目的核心，使开发人员能以最快的速度交付最有价值的软件产品。　　对于团队在可用的时间和资源约束下能完成多少所需的功能，应该充分尊重开发团队的判断。如果你所需的功能无法完全放入项目，决策者就会根据优先级缩小项目范围、延长时间或者提供额外的资金或者人力。简单粗暴地把所有需求都设置为高优先级，这样做既不符合现实，也不是一种合作的态度。　　责任7：评审需求和评估原型　　正如在第17章中将看到的，同行评审是保障软件质量最有效的方法之一。让客户参与评审是评估软件在需求方面是否满足完整性、正确性和必要性的关键方法。评审也是客户代表评估业务分析师工作是否满足项目需要的一个重要时机。忙碌的客户通常不愿意花时间参与需求评审，但其实这样做是值得的。业务分析师应该在需求引导的过程中经常向你提供适量需求进行评审，不要在需求“完成”以后才将一大本需求手册放到你的桌子上。　　仅仅依靠写好的需求，很难“脑补”出软件如何工作的画面。为了更好地理解你的想法并探索最佳的实现方式，业务分析师或开发人员有时会构建一个目标产品的原型。针对这个初级的、不完备的或是探索性原型给出的反馈，可以为开发人员提供非常有价值的信息。　　责任8：设定验收条件　　开发人员如何知道开发完成了呢？他们如何知道开发的软件符合客户期望呢？作为客户，你有设定验收条件的责任，预先定义好未来如何评估产品的条件。这些条件包括验收测试，可以用它们来评估用户执行业务操作时产品是否能够正确执行。其他的验收条件还可以针对可能存在的缺陷、特定操作下的表现或是能够满足外部系统的验证需求等。敏捷项目使用验收条件来充实用户故事细节，而不使用书面记录的需求。测试人员虽然能够判断某个需求是否正确实现，但是他们并不见得总是了解你能够接受什么样的产出。　　责任9：及时沟通需求变更　　不断改变需求会给开发团队按时交付高质量产品带来严重的风险。虽然改变难以避免，而且通常也有望增加价值，但是越晚引入变更，造成的冲击越大。应该在发现需求需要改变的时候尽早通知业务分析师。为了能把影响降到最低，要遵从项目定义的需求变更流程，以确保所有提出的变更不会丢失，每个变更影响都要考虑到，并且所有变更都要用相同的方式考虑。最后，由业务干系人判断在哪个阶段将哪些需求变更添加到项目中。　　责任10：尊重需求开发流程　　引导和制定需求是软件开发中最有挑战的活动之一。业务分析师进行需求开发时有一个基本原理。虽然可能使人沮丧，但是花在理解需求上的时间依然是一种很好的投资。如果你能够尊重业务分析师所使用的技巧，整个过程就会轻松许多。可以询问业务分析师他们为什么要获取某些信息，为什么要你加入某些需求开发实践。互相理解并尊重其他人的做事方法和需要，有利于建立一个有效而愉快的合作关系。建立尊重需求的企业文化有家公司需求部门的领导曾经提出一个问题：“我遇到了如何让我们开发人员同意加入需求开发过程的问题，”她说，“我怎样才能让他们理解参与这一过程的价值呢？”在另一个部门，一名业务分析师经历过这么一次冲突：开发人员想要为一个会计系统梳理需求细节，但是IT经理只想做一个简单的头脑风暴，不希望使用其他方法。“你的读者会面临文化冲突吗？”这个业务分析师问我。　　这些问题都是让业务分析师、开发人员以及客户协作进行需求开发时所面临的挑战。你会觉得用户应该很清楚这一点：“提供需求信息有利于使其得到他自己想要的”。开发人员会发现，相比收到一堆不知从哪里来的需求文档，加入这个过程会使其工作更轻松。显然，并不是让每个人都像你一样对需求如此感兴趣，如果是这样，他们可能都已经是业务分析师了。　　团队一起从事需求开发时文化冲突会频繁出现。有些人认为基于太少或是靠心灵感应式沟通所获取的需求来开发软件存在大量风险。也有一些人认为需求并不是非做不可的。像替换遗留系统这样的项目，如果用户觉得这与自己工作没有太大关系，不值得浪费时间，那么争取业务人员的合作会非常困难。理解人们抵触参与需求开发的原因，是解决问题的第一步。　　一些反对者可能并没有具体接触过需求实践。或者他们经历过令人失望的需求引导过程，参与的项目产出了规模庞大、不完整、被忽视的需求说明。这一定会让每个人都留下糟糕的印象。即使工作很有效，反对者也理解不到这些实践的价值。他们也许没有意识到在随意的、缺乏条理的环境中工作所付出的代价。这种代价通常体现在出现意料之外的返工、延期或软件品质低劣。这样的返工隐藏在项目参与者的日常工作中，所以他们意识不到它竟然如此低效。　　如果想把开发人员、经理和客户拉在一起，就必须让每个人都了解公司和客户之间曾经因为需求问题而经历的痛苦。如果他们感受不到这样的痛苦，可以找一些具体的案例。量化它们对组织造成的浪费，可以用钱、时间、客户投诉或者失去的商机来衡量。开发经理并不总是能够意识到糟糕需求对团队生产力所产生的影响。可以向他们展示糟糕的需求如何减慢设计并在修正产品方向时花费巨大的成本。　　开发人员也是项目干系人，但他们的需求有时并没有得到过任何考虑，使其成为被强加需求的受害者。开发人员应该提供关键信息以确保需求文档能够真正发挥作用。我喜欢让开发人员参与需求评审，让他们知道接下来会发生什么并且指出哪些地方需要进一步澄清。用户看不到的内部质量属性通常需要由开发人员提供。开发人员经常能够提供其他人想不到的信息，比如如何用更简单的方式完成任务；什么功能实现起来非常耗时；哪些是不必要的设计约束；是否有遗漏的需求，比如异常处理；如何利用技术创造机遇，等等。　　质量保障人员和测试人员也是优秀需求的贡献者。不要等到项目后期再让他们加入，让这些“眼尖”的人尽早加入迭代的需求评审。他们善于发现歧义与冲突，非常关心如何基于需求来开发测试用例和场景。测试人员也能够提出可验证的质量属性方面的需求。　　对流程或文化改变的抵触大多来自于恐惧、不确定性或知识的缺乏。如果能识别出这种抵触，你就能通过保障、澄清和教育的方式应对。让人们了解他们的参与不仅对他们个人有益，同时也会在整体上产生更好的效果。　　领导必须理解这一点：组织需要把高效业务分析和需求工程能力作为自己的战略性核心竞争力。虽然项目范围内基层人员的努力非常重要，但如果没有高层的投入，这些改进和收益在项目结束或团队重组后将很难保持。识别决策者在软件项目中，需要做很多决定，而且往往都是在向前发展的关键路径上。必须解决一些冲突，接受（或拒绝）某个需求变更或者批准一组即将发布的需求。在项目早期，就要确定由谁来做决定以及如何做决定。我的朋友Chris（一个经验丰富的项目经理）指出:“我发现项目中通常有一个主要的决策人，通常是组织的出资人。我必须找出这个人，然后让他关注整个项目的进度。究竟谁负责做决定，有时没有唯一的答案。让一个代表各个关键领域（比如管理、客户、商业分析、开发和市场部门）的小组来做决定通常更有效。第28章将描述如何让变更控制委员会作为决策者来处理需求变更。　　决策小组需要指明决策领导并选择一个决策规则，该规则描述了他们如何做决定。有很多决策规则可以选择，下面是一些（Gottesdiener 2001）：* 决策领导做决定，不管是否已经和其他人讨论过* 小组投票，少数服从多数* 小组投票，但是结果必须获得一致通过* 小组讨论和协商达成共识。每个人都拥护这个决定并承诺支持它* 决策领导授权一个决策人* 小组达成一个决策，但是一些人有权否决小组决定　　没有普适的决策规则。单一的决策规则通常也不普遍适合于每个场景，所以小组必须建立一套指导原则，让他们知道什么时候该投票，什么时候该达成一致，什么时候该授权代理人等。在每个项目的第一个重大决策点出现之前，需要做需求决策的人都必须事先确定好一个决策规则。对需求达成一致　　对在建产品的需求达成一致或是在某部分达成一致是客户-开发人员关系的核心。涉及的多个角色应形成如下共识：* 客户承认需求描述了他们的需要* 开发人员承认理解需求并且认为它们是可实现的* 测试人员承认需求是可验证的* 管理层承认需求可以达成他们的业务目标　　许多组织用签字的方式来代表干系人认可需求。所有需求确认流程的参与者都清楚签字的含义及其结果。一个常见问题是客户代表或是经理认为自己在需求上签字是毫无意义的例行公事“我拿到了需要我签字的纸，我签了，因为如果不这样，开发人员就不会开始编码。”将来当某个角色希望改变需求或者交付物不符合预期时，他们就会说：“虽然我在文档上签字了，但是我并没有足够的时间仔细阅读这些文档，我非常信任你们，可是你们却让我大失所望！”　　另一个问题是开发经理把签字视作需求冻结的一种手段。每次提出需求变更，他都会表示抗议：“你已经在文档上签字了，我们也是按照这个开发的，如果希望我们开发其他内容，你应该早点说。”　　这些态度都忽略了一个事实，即我们不可能在项目早期就知道所有的需求，而且毫无疑问，需求会随着时间的变化而变化。虽然批准一组需求是结束某个需求开发阶段的常用方法，但是每个参与需求开发过程的角色都应该明白签字的真正含义。
需求基线　　比签字仪式更重要的是确立一条需求基线，一个特定时间点的需求快照（Wiegers 2006）。需求基线是一组需求，在评审和确认后作为后续开发的基础。不论团队使用正式的签字流程或其他方式对需求达成一致，潜在的含义都应该如下所述：　　　　“我同意当前这组需求代表我们对项目下一阶段需求最深入的理解，并且基于目前我们对问题的理解，这个解决方案能够满足我们的需求。我同意在未来使用项目定义好的变更流程基于这个基线对需求进行修改。我清楚变更可能导致我们重新讨论项目的成本、涉及的资源以及对时间表的承诺。”　　　　一些组织与这段话类似的内容放在签名页上，让需求审批人在签字的时候清楚签字的真正含义。　　随着项目的进行，发现需求有遗漏或者市场和业务需求有变化时可能会出现冲突，对以上内容达成共识将有助于减少这种冲突。一个有意义的基线确定流程可以在以下几个方面为主要干系人带来信心。* 客户管理层或者市场营销人员相信项目不会超出可控范围，因为客户会为范围变化的决定负责。* 用户代表相信开发团队会和他们一起工作，交付正确的解决方案，即使他们在开发开始之前没有考虑清楚所有的需求。* 开发部门的信心建立在开发团队有业务伙伴保证项目始终聚焦于其目标上，同时业务伙伴也和开发团队一起平衡项目计划、成本、功能和质量。* 业务分析师和项目经理有信心有效控制项目变更带来的风险，并使风险最小化。* 质量保证和测试团队有信心开发测试脚本并且为自己在项目中的各种活动做好准备。　　在决策者定义基线以后，业务分析师需要在需求变更上施加控制。团队可以在分析每个变化对项目计划和其他的关键因素的影响之后重新调整项目的范围。在达成一致之后结束初始的需求开发活动，可以有效推进协作式客户-开发人员关系，使产品走上成功之路。
达不成共识怎么办　　让所有干系人达成一致并签字是很困难的。障碍包括后勤、忙碌的日程以及某人不愿意承诺（害怕在日后承担责任）等。如果干系人担心批准需求以后不可以再改，就会拖延审批时间。这无疑会导致需求分析工作陷入瘫痪。许多团队尝试发邮件说：“如果不在下周五前回复修改意见或是签字确认，我们将会假定你已经同意了这些需求。”这也是一种选择，不过这等同于没有达成一致。同时，这么做还会让你和那个“被同意”的干系人关系紧张。试着了解一下他们不愿意签字的原因并当面提出来。　　在这种场景下，最好先小心地推进项目，不过要假定你没有得到这些有抵触情绪的干系人的同意。在风险列表中做记录，说明有些干系人没有在需求文档上签字（把它和遗漏或错误的需求可能带来的影响同等对待）。作为风险管理的一部分，持续跟进这些人。用一种积极的态度让他们了解，虽然他们没有批准需求，但是为了保证进度，项目仍然使用这些需求作为基线。让他们知道，如果他们想改变需求，可以通过有一个现成的流程。基本上是在假定干系人同意需求的状态下工作，但是需要与他们保持密切的沟通。对敏捷项目的需求达成共识　　敏捷项目没有正式的签字环节。通常，敏捷项目使用产品Backlog（待办事项）中放入用户故事的形式来管理需求。产品负责人和团队一起在计划会议上针对下一个迭代团队要做的用户故事达成一致。选择实现哪些用户故事主要取决于故事的优先级和团队速率（生产力）。在需求集合达成一致后，迭代中包含的用户故事将被冻结。新出现的需求变更留在未来的迭代中再考虑。敏捷项目不会一开始就试图让干系人就项目所有需求达成一致。虽然产品愿景和其他业务需求仍然需要一开始就明确，但是在敏捷项目中，功能全集是逐渐得以明确的。第20章将具体讨论敏捷项目如何进行需求管理。　　我曾经遇到过一个客户，他虽然在使用敏捷生命周期却要求对需求进行签字确认。团队需要在这种不需要签字的非传统流程中以创造性的方式解决这个问题。业务分析团队和用户一起挖掘和评审需求，使用用户故事或工作流程、状态表等其他形式来记录需求。我们让用户对这些产出签字。其时，他们会知道没有遗漏大的需求，同时由于用户亲身参与了需求相关的实践，因而也知道我们写下来的内容不会出大问题，随后的开发工作自然不会有大的偏差。但是使用签字方式仍然保证用户有权在未来增加新功能或修复发现的问题。　　不同于过去签字意味着“需求通过审批并同时被冻结”，这种新的方式不会让任何人觉得签字就是让自己对大量看不懂的需求文档负全责。同时也不会强迫客户同意需求已经近乎完美，所有的事情在一开始就已经完全定义清楚。这种签字符合敏捷的思想。就像前面介绍的签字过程那样，签字的本质是就需求的特定部分达成一致，它为下个开发周期中要实现的需求定义了一个基线，同时所有人都明白这种达成一致意味着什么。　　通常，在敏捷项目中，产品负责人为迭代选择或拒绝需求，需求包括一系列用户故事以及相应的验收条件和验收测试。最终的签字就是接收迭代所产出的经过测试的可工作的软件。　　就像顾问布朗（Nanette Brown）所说：“即使在一个敏捷环境中，签字的理念也可以填补一个空白，敏捷告诉我们要‘拥抱变化’，但变化总是基于某个参照点而存在的，即使是一个沟通紧密的团队，人们对当前的计划和状态也会有不同的认识。一个人对需求的变更可能会被别人认为是先前已经确定好的东西。但是，如果用签字作为一个轻量级的确认方式来标示‘我们在这里’，我认为是一件好事情，今天‘我们到这里’不代表了我们明天不能去其他地方，而是代表我们找到了一个参照点。”　　
　　①  “业务分析师”（简称BA）在项目中主要负责领导项目中与需求相关的活动。BA还有很多其他称呼。在第4章中，将进一步介绍业务分析师这个角色。—————　　　　————————————————————　　　　—————　　　　————————————————————