软件需求_[美]Karl Wiegers, Joy Beatty著，李忠利李淳霍金健孔晨辉译_9787302426820

作为经典的软件需求工程畅销书，经由需求社区两大知名领袖结对全面修订和更新，覆盖新的主题、实例和指南，全方位讨论软件项目所涉及的所有需求开发和管理活动，介绍当下的所有实践。书中描述实用性强的、高效的、经过实际检验的端到端需求工程管理技术，通过丰富的实例来演示如何利用最佳实践来减少订单变更，提高客户满意度，减少开发成本。书中的用例、业务规则和商业工具全面修订以体现现状和未来的趋势。本书尤其适合具备一定软件开发过程经验的业务分析师、需求分析师、项目经理和其他软件项目涉众。

目录第Ⅰ部分软件需求的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用户界面和SRS167软件需求规范说明模板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三层分级法284MoSCoW286100美元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

第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章中，将进一步介绍业务分析师这个角色。---------------　　　　------------------------------------------------------------　　　　---------------　　　　------------------------------------------------------------

你还可能感兴趣

我要评论