软件需求（第3版）

出版者:清华大学出版社

作者:Karl Wiegers

页数:572

译者:李忠利

出版时间:2016-2-1

价格:99

装帧:平装

isbn号码:9787564149888

具体描述

编辑推荐

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

特色：这本经典名著经过需求领域两大领军人物的联袂打造，得以全面升级和扩展，包含更多、更新的主题、实例和洞见。通过本书介绍的需求工程最佳实践、工具和技术，读者可以提升需求引导、捕获、开发、管理和分析能力，并把这些行之有效的技术与技巧运用到工作当中，在尽可能减少成本、增强维护性和避免返工的同时，交付定位更准确、质量更优良的软件产品/服务。

特色主题：

准确锁定关键的利益干系人并与他们展开合作

聚焦于业务目标，对需求进行引导和分析

需求的文档、优先级排定、验证和重用

原型和创建需求的可视化模型

管理变更申请、范围蔓延和需求风险

理解和明确指定客户质量需求

针对数据需求和报表类需求提供指导

第3版特色：

包含全新的实例、实践与技术，体现需求领域的最新进展

凝聚需求领域两大领军人物多年的心血，素材来自培训课程、演讲和工作坊，有实操性

循序渐进，阐述如何将有效需求实践应用于敏捷项目和其他各种特殊项目，比如业务流程自动化、软件包方案、外包、增强型、替换型和嵌入式系统等项目

重点聚焦于业务分析师的角色和成功业务分析师应该具备的核心竞争力

尤其适合业务分析师、开发人员、项目经理和其他软件项目干系人阅读和参考

作者简介

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

Joy Beatty（乔伊•贝蒂） 软件需求社区的领袖，曾经协助财富500强中很多企业建立卓越业务分析中心。Joy是IIBA《BABOK指南》的主要贡献者，CBAP（认证业务分析师）。她具有丰富的培训经验和表达能力，培训过几千名业务分析师，曾经发表很多文章和演讲。她还是《软件需求与可视化模型》的作者之一。Joy毕业于普渡大学，获得计算机科学与数学双学士学位。业余时间，她喜欢划船、游泳和野炊。

译者简介：

李忠利 精一天使公社CEO，CODEX中国创新委员会联合发起人。他拥有14年TMT行业经验，先后供职于用友、SYNNEX和百度等知名企业，历任技术管理、总经理助理和精益教练等工作。他擅长互联网创新业务/产品的孵化和指导，打造企业内部创新模式。曾亲自推动某外企400人规模的研发模式整体转型。作为布道者，在国内某知名ERP企业首创研发模式创新和带领敏捷教练团队成功使用创新方法来推动软件产品线的效率改进。代表译著有《管理3.0：培养和提升敏捷领导力》（被誉为“21世纪的管理圣经”） 《敏捷武士》和《Scrum敏捷产品管理》。

李淳 Agilean咨询顾问，敏捷和精益倡导者、实践者。通过的认证有Lean Kanban Advanced Practitioner、Certified Scrum Master、Certified Scrum Product Owner、PMP等。先后供职于用友和易车等公司，担任过程序员、研发经理、架构师和产品经理。自2011年至今，致力于在传统项目管理方式中推广敏捷理念、精益创业方法和看板方法，先后在项目研发和需求沟通过程中尝试引入敏捷和精益的价值观和开发实践，在缩短产品交付周期的同时项目质量，还增进了团队内、不同团队间、团队与客户之间的信任和沟通成效，在极短的时间内使客户刮目相看，项目取得了预期的效果。

霍金健 百度资深交付经理与敏捷教练，具有丰富的项目管理、敏捷实施、持续集成和配置管理的实战经验。目前致力于推动互联网创新产品管理和敏捷项目管理能力提升。2014年初加入百度，负责公司战略产品的敏捷改进和产品交付工作，通过运营和度量驱动的方式，结合业务目标和团队特点取得了突出的成效。多次受邀在敏捷中国、Scrum Gathering和敏捷之旅等专业大会分享企业研发实践心得。代表译著有《看板实战》。

孔晨辉 赛门铁克中国研发中心高级软件工程师，主要从事软件项目跟踪与管理解决方案的研究与开发工作。国家软件水平资格认证的高级信息系统项目管理师，PMBar项目管理社区成员。

目录信息

目 录 第Ⅰ部分 软件需求的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
· · · · · · (收起)

读后感

漫长的项目终于告一段落，满怀欣喜地回家休息两天。恰逢捧读完此书，比较于切身的经历，感触颇多。 程序员是这样一群人：聪明、敏锐、自我陶醉、乐观得近乎天真。本来是一种充满了理性和逻辑的职业，却是这样感性和自我的人们，但也许也只有这样的的人才能胜任这种...  

漫长的项目终于告一段落，满怀欣喜地回家休息两天。恰逢捧读完此书，比较于切身的经历，感触颇多。 程序员是这样一群人：聪明、敏锐、自我陶醉、乐观得近乎天真。本来是一种充满了理性和逻辑的职业，却是这样感性和自我的人们，但也许也只有这样的的人才能胜任这种...  

很多书在介绍需求分析的方法（比如UML，各种case和story的编写）等等，却忽略了其基础理论知识。 只有知晓基础后，才能更好的理解和理会其他方法论。 推荐这本书。可以买来收藏并时常温故知新。。。。。。。。。。 已经加入到我的书单中了，期待其他需求分析爱好者大家一起...  

最近因为要考试，把这本书作为教材很细致地读了一遍 内容总体来说还可以，不过和其它需求书相比，没有什么让人惊艳的地方 融入了作者很多的经验之谈，应该还算实用 至于翻译的质量，很一般，有些地方译的有点不知所云 校正的也一般，我发现了的错别字都有个十几个了，不过也...  

漫长的项目终于告一段落，满怀欣喜地回家休息两天。恰逢捧读完此书，比较于切身的经历，感触颇多。 程序员是这样一群人：聪明、敏锐、自我陶醉、乐观得近乎天真。本来是一种充满了理性和逻辑的职业，却是这样感性和自我的人们，但也许也只有这样的的人才能胜任这种...  

用户评价

这本书在“需求文档的撰写与管理”这一块的处理，展现了极强的实用主义色彩，完全避免了陷入僵化的文档规范泥潭。很多教材总强调要写出长篇大论的BRD，但这本书的重点显然不在于文档的厚度，而在于其有效性和可维护性。作者非常推崇“适度详尽”的原则，并清晰地界定了不同阶段文档的侧重点。例如，对于早期探索阶段，更倾向于使用高保真原型和用户故事的组合来驱动讨论；而到了设计实现阶段，则需要更精确的接口规范和数据字典。我特别欣赏它对需求的可追溯性的强调，并提供了多种实现追溯链的实践方法，从用户故事到测试用例，再到最终的代码模块，这种端到端的连接感，是确保我们交付的系统与最初的业务目标一致的关键。此外，书中关于如何管理需求版本和基线的技巧也非常实用，它教会我们如何优雅地“冻结”一个阶段的需求集，同时为未来的演进保留清晰的路径，而不是在文档的不断修改中迷失方向，这对于大型复杂系统的生命周期管理至关重要。

这本《软件需求（第3版）》的作者，简直是把需求工程的脉络梳理得如同精心编织的挂毯一般精妙。我记得我第一次接触需求工作时，那感觉就像是摸着一块巨大的、未经雕琢的璞玉，面对着客户模糊不清的愿景，心里充满了不确定。这本书一上来就没给我那些空泛的理论，而是直接深入到“为什么我们需要准确的需求”这个核心问题上。它用非常接地气的案例，展示了需求遗漏或误解带来的灾难性后果，那种痛感，每一个做过项目的人都能感同身受。尤其是关于利益相关者分析那一部分，简直是教科书级别的指导。它没有停留在简单的“识别”层面，而是深入探讨了如何平衡不同群体之间冲突的需求，如何使用更具穿透力的访谈技巧，挖掘出那些连客户自己都没意识到的潜在期望。我尤其欣赏作者在描述需求获取技术时的细致入微，比如角色扮演、原型法的使用时机和局限性，而不是简单地罗列工具。读完这部分，我感觉自己拿到了一个工具箱，里面装满了不同尺寸和形状的扳手，可以去应对各种不同型号的“螺丝钉”——也就是形形色色的需求挑战。它真正教会我的，是如何成为一个“需求翻译官”，将商业的模糊语言转化为系统的清晰蓝图，这份实操性远超我预期的收获。

最后，我想谈谈这本书对“需求验证与确认”的深度挖掘，这部分内容让我对“做对的事情”有了更深的理解。很多人将需求验证等同于简单的用户验收测试（UAT），但作者的视野显然更为宏大。他将验证过程分解为不同的层次：从早期的涉众确认、模型审查，到中期的原型测试，再到后期的系统集成测试。书中对“需求评审会”的设计和执行提供了非常具体的指导，如何避免评审会沦为形式主义的会议，如何引导参会者进行建设性的批判，而非仅仅是表面的点头称是，这些细节极其宝贵。我特别关注了关于测试用例与需求直接映射的讨论，它提供了一个非常清晰的量化指标来衡量需求的完备性。如果一个需求没有对应的测试用例，那它很可能就不是一个真正的、可验证的需求。这种“以测试驱动需求清晰度”的思维模式，极大地提升了我后续编写验收标准时的严谨性。这本书真正让我明白，好的需求工作不是在项目末尾被动地接受反馈，而是在整个生命周期中主动地、持续地与利益相关者进行沟通和校验，确保每一步都在正确的轨道上。

这本书对于“需求分析与建模”的阐述，可以说是将抽象概念具象化的典范。过去我总觉得UML图表是写给架构师看的，与我们这些偏向业务侧的需求分析师关系不大，但这本书彻底颠覆了我的看法。它没有把建模当作一种僵硬的规范来推销，而是将其定位为一种“思维的清晰化工具”。作者对用例图的解读尤其深刻，它不仅仅是记录功能，更是一种探索系统边界和用户交互流程的有力手段。我最喜欢的是它对活动图和状态图的对比分析，非常清晰地指出了在描述业务流程和系统响应时，二者各自擅长的领域和需要规避的陷阱。例如，书中提到，当流程涉及多个参与者协同工作时，活动图的泳道划分能够极大地增强沟通效率，这比单纯阅读一堆文字描述的流程文档要直观得多。更进一步，它对非功能性需求的建模讨论也令人耳目一新，没有把性能、安全这些要求当作附录，而是教我们如何将它们融入到用户故事或者具体的质量属性场景中去。这种将“软的”需求和“硬的”模型相结合的处理方式，为我提供了一个更高维度的视角去看待和记录系统的所有权，让最终交付的文档更有说服力和可追溯性。

关于需求变更管理这一章，简直是给身处“敏捷泥潭”中的我，注入了一剂强心针。在实际工作中，需求变更的频率高得令人发指，很多团队采取的策略要么是拒绝一切变更，要么是毫无章法地全盘接受，最后导致项目失控。这本书提出的那种结构化的变更控制流程，简直是艺术。作者详尽地描述了如何建立一个有效的变更控制委员会（CCB）的构成、决策机制，以及如何量化变更对时间、成本和质量的影响。它不仅仅是告诉你“要有一个流程”，而是手把手教你如何填写变更请求表单、如何进行影响分析的矩阵对比。我记得书中有一个关于“变更的经济学分析”的案例，用非常直观的图表展示了在项目不同阶段接受变更的成本曲线，那个曲线的陡峭程度让我心惊，也让我更坚定了在早期阶段就要尽可能锁定核心需求的决心。同时，它也没有忽视敏捷环境下的变更处理，讨论了在迭代内部如何进行“微小变更”的协商与吸收，使得变更不再是洪水猛兽，而是项目持续优化的自然组成部分，这对于提升我们团队的心理韧性大有裨益。

B端产品经理必读，有助于帮助自己快速找准角色定位。里面的「陷阱」部分可以多留意一下。

温故而知新！软件需求相关的知识体系指南，手册性书籍。

原版五星，翻译扣四星。翻译极烂，直接影响对概念的理解。

B端产品经理必读，有助于帮助自己快速找准角色定位。里面的「陷阱」部分可以多留意一下。

开卷有益。看了大半。