软件需求(第3版)

Karl Wiegers

出版时间

2016-01-31

ISBN

9787564149888

评分

★★★★★
书籍介绍

编辑推荐

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

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

特色主题:

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

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

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

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

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

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

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

第3版特色:

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

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

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

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

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

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

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

译者简介:

李忠利 精一天使公社CEO,CODEX中国创新委员...

(展开全部)

AI导读
核心看点
  • 本书系统阐述需求工程最佳实践,涵盖需求获取、分析、规范、验证及管理全流程。强调需求基线的重要性,指导读者如何确立经过评审和批准的需求快照,作为后续开发的基础,并通过严格的变更控制流程,防止范围蔓延,确保项目目标不偏离。
  • 深入解析业务分析师角色与职责,提供从业务需求到用户需求再到功能需求的分层分析方法。书中包含大量实操性强的模板与案例,帮助读者掌握如何识别关键利益干系人,明确业务目标,并将模糊的业务意图转化为清晰、可执行的技术需求规格说明。
  • 针对敏捷开发、外包、嵌入式系统等特殊项目类型,提供差异化的需求管理策略。强调在快速迭代环境中,如何通过原型、可视化模型及持续沟通来降低理解偏差,同时警示读者避免忽视干系人、需求模棱两可等常见陷阱,提升软件交付质量与合规性。
适合谁读
  • 适合从事B端产品开发、企业级软件架构及系统集成的产品经理与业务分析师。书中关于需求合规性、业务价值对齐及复杂系统需求管理的深度内容,能帮助专业人士建立严谨的需求思维,规避因需求不清导致的项目失败风险,提升职业竞争力。
  • 适合希望提升软件工程规范性的技术团队负责人与项目经理。通过阅读本书,管理者可以理解需求工程对成本控制、维护性及返工率的影响,学习如何建立尊重需求的企业文化,识别决策者,并在团队中推行标准化的需求开发与管理流程,保障项目顺利交付。
  • 适合对需求分析理论体系感兴趣的学生及初级开发人员。本书作为权威参考书,提供了完整的需求知识框架,帮助读者理解需求层次、客户权利与责任法案等基础概念,纠正‘重代码轻需求’的错误观念,为从事高质量软件开发奠定坚实的理论基础。
读前提醒
  • 本书理论性强且篇幅较大,建议不要通篇死读,而是作为工具书查阅。读者应重点关注需求开发流程中的具体模板、检查清单及案例,结合自身项目场景灵活裁剪应用。对于涉及敏捷或特定行业的内容,需结合其他专项书籍补充,避免生搬硬套传统瀑布模型流程。
  • 注意区分书中‘理想化’流程与实际工程落地的差距。国内互联网环境强调快速迭代,书中部分严格文档化要求可能不适用。读者应汲取其核心逻辑,如需求基线管理、变更控制及干系人沟通技巧,而非拘泥于形式。切勿将书中内容视为僵化教条,而应转化为提升沟通效率的思维工具。
  • 阅读时需警惕翻译质量可能带来的理解障碍,部分专业术语或长句可能存在歧义。建议结合英文原版或相关权威资料对照理解。同时,书中关于需求管理工具的描述可能滞后于当前技术现状,读者应关注其管理原则而非具体工具操作,自行适配现代化的需求管理平台。
读者共识
  • 读者普遍认为本书是需求分析领域的经典权威之作,体系完整,逻辑严密。尽管部分读者指出其内容过于理想化,与国内快速迭代的互联网实践存在脱节,且翻译质量参差不齐,错别字较多,但其提供的底层逻辑、合规意识及风险管理思路仍具有极高的参考价值,适合收藏备查。
  • 多数读者反馈本书对B端产品经理及业务分析师极具指导意义,特别是关于需求分层、业务价值对齐及防范范围蔓延的内容,能有效提升专业素养。然而,也有观点认为书中案例不够详细,需求管理部分仅停留在流程概述,缺乏深入的技术实现细节,需配合其他实战书籍共同学习。
  • 读者共识指出,本书不适合作为敏捷开发的唯一指南,其核心优势在于规范化的需求工程方法论。对于追求极致速度的C端产品或初创团队,书中内容可能显得繁琐。但对于追求系统稳定性、合规性及长期维护性的企业级软件项目,本书提供的框架是不可或缺的基石,有助于纠正‘口头需求’等恶劣习惯。

本导读基于书籍简介、目录、原文摘录、短评和书评生成,不等同于全文精读。

精彩摘录
  • "111"
  • "需求管理活动包含以下方面。 ·及时确定需求基线,提交一个供当前时间段使用的参考,提出一套大家商定的、经过评审和批准的功能需求与非功能需求,通常针对具体的产品发布或者开发迭代。 ·评估提议需求变更可能产生的影响,然后以可控方式将获准的变更融入项目。 ·随着需求的演化,保持项目计划与需求同步。 ·根据预估的需求变革可能带来的影响,商定新的承诺。 ·定义各个需求之间存在的关系和依赖。 ·跟踪每个需求对应的设计、源代码和测试。 ·在整个项目过程中跟踪需求状态和变更活动。 需求管理的目标不是抑制变更或加大其难度,而是为了预测和协调不可避免且实际存在的变更,最终最小化变更对项目的破坏性影响。"
  • "提供业务需求的客户有时会试图替实际用户说话。然而这些内容常常和真实用户的需求相去甚远。对于企业信息系统,合同制定或者定制内容开发,业务需求应该来自于最终的产品业务价值负责人。用户需求则来自于按下按键、点击屏幕或是接收输出的人。如果为项目买单的人和最终用户之间有严重的脱节,肯定会出大问题。 商业软件开发与此不同,客户和用户通常是同一个人。客户代理(例如营销人员或是产品经理)常常试图决定客户想要什么,但即使是开发商业软件,也应该尽力让终端用户加入需求开发过程,就像第7章里描述的。如果不这么做,评审报告中就有可能出现那些原本可以通过用户充分参与来避免的缺陷。 项目干系人之间可能会出现矛盾。业务需求有"
  • "比签字仪式更重要的是确立一条需求基线,一个特定时间点的需求快照(Wiegers 2006)。需求基线是一组需求,在评审和确认后作为后续开发的基础。不论团队使用正式的签字流程或其他方式对需求达成一致,潜在的含义都应该如下所述: “我同意当前这组需求代表我们对项目下一阶段需求最深入的理解,并且基于目前我们对问题的理解,这个解决方案能够满足我们的需求。我同意在未来使用项目定义好的变更流程基于这个基线对需求进行修改,我清楚变更可能导致我们重新讨论项目的成本、涉及的资源以及对未来时间表的承诺。”"
作者简介
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
第Ⅲ部分 具体项目类别的需求

显示全部
用户评论
真滴不错的一本书。自己一直做B端的产品,现在有点想开了,虽然团队环境不太好,但的确认识到了自己目前的基本功不够扎实,项目能力也欠佳,真的不如从一个需求分析师开始做起,或者真正的懂得一些研发知识。这本书会详细翻阅,整理笔记的。希望自己能够越来越好。
前辈推荐的书籍,没有系统学习过软件工程体系看一看还是能查漏补缺的
五星
国内注重商业模式,业务模式,快就是一切。感觉国外其实跟国内差不多,书籍里面的东西,终归是理想化了,现实只会是其子集,产品经理业务人员开发人员虽然有其专业性分工,但感觉大家做事硬技能上的专业性还是不足。希望有生之年能体验一把真正的软件工程的公司。
温故而知新!软件需求相关的知识体系指南,手册性书籍。
关于需求分析,很系统的书。中国要做出好的 to B 软件,系统化和规范化是必要条件。
前半部分讲理论,后半部分讲不同的项目类型如何应用这些理论。附录的需求样本真的感动得哭了,回头想想我们领导从来都是口头说需求,从不落到笔头,一到开发就扑街,最后测试背锅。这领导真nm垃圾
很实用诶。基础讲得很牢靠,除此之外还有很多敏捷开发过程中会遇到的问题和处理方式(特别是人的立场参与的部分),对实际工作非常有帮助。喜欢捏!
很不错
下载
收藏