软件需求-(第3版)

相关资料

[

专家推荐： “业务分析领域的经典著作之一，第3版尤其体现了这一专业领域过去十年的进展和最新趋势。”
——kevin brennan， iiba（国际业务分析师协会）首席业务分析师兼执行副总裁
“软件需求的百科全书。”
——清华大学教授，中国软件行业协会过程改进分会名誉副会长好书热评
《软件需求（第3版）》是目前最有用的需求指南。两位作者wiegers和beatty覆盖了目前业务分析师应该知道的实践全景。无论是需求规范的老手，还是刚开始做项目的新手，都可以将本书作为桌边案头的必备参考书。
——gary k. evans，evanetics公司敏捷教练和用例专家.

这简直就是三连冠，karl wiegers和joy beatty携第3版再创佳绩。从1999年第1版起，《软件需求》提供的指南就已经成为我在需求咨询工作中的实践基础。我要向新手和有经验的从业人员鼎力推荐此书。
——roxanne miller，requirements quest总裁

需求方面最好的书，又更上了一层楼！在第3版中，新主题的范围延展到覆盖整个项目场景。在敏捷环境中使用需求最有意义，因为所有相关人员都要了解新系统的基本功能和用途，并且敏捷开发人员现在也是受众，必须好好掌握书中的内容。
——stephen withall，《软件需求模式》作者

《软件需求（第3版）》终于问世，长久的等待是值得的。这是一本完整的实践指南，读者可以从中学到许多对工作有用的实践。我特别喜欢书中包含的例子和很多实操方案，可以方便地在真实生活场景中实践它们。
——christof ebert博士，vector consulting services管理总监

karl和joy升级了软件需求领域的开创性著作，对上一版择其优并加以改进。这一版保留了此前版本中所有业内人员必备的参考，还扩展到足以应对当今复杂商业和技术环境所面临的挑战。不论什么技术、业务领域、方法论或项目类型，都可以借助本书向客户交付更好的成果。
——shane hastie，software education首席知识工程师

karl wiegers和joy的这本有关需求的新书对前一版进行了精彩的补充。大型软件应用的需求是本世纪最难以解读的业务话题之一。此书有助于解读这一粗略的主题。
——t. capers jones，namcook analytics公司副总裁兼cto

简单地说，对于每个参与定义和管理软件开发项目的人（这本书既是必读之书，又是一本重要的参考。在今天的现代软件开发世界中，太多人认为需求实践是用于“无障碍”敏捷的。karl和joy对渐进管理需求的方法进行详细说明，并阐述了如何采用日新月异的方法实现软件交付。
——mark kulak，borland公司软件开发总监

我看到karl wiegers和joy beatty全面更新了这本有关软件需求的书。我特别喜欢其中如何在敏捷项目中使用高效需求实践的最新话题，因为近日来，我们这方面的咨询服务越来越多。这些在不同需求实践中的实践指南和真实案例是无价之宝。
——doreen evans，robbins gioia公司需求和业务分析实践管理总监

作为karl经典好书《软件需求》的早期用户，我对新版早就迫不及待，望穿秋水了，而且它绝对没有让我失望。多年以来，从大型的、新型的零起点项目，到采用现成的商业现货方案和快速发布敏捷实践，it开发的重点已经发生很大的变化。在第3版中，karl和joy探讨了这些新开发方法在需求过程中的内涵，还给出了宝贵的建议，这些建议不是基于教条的，而是从他们在需求领域广泛而深入的经历提炼出来的有效实践。
——howard podeswa，noble公司ceo，《业务分析师手册》作者

如果要找一本实践指南来了解什么是软件需求、如何创建需求以及如何使用需求，《软件需求（第3版）》是首选。这本书的内容有用、易懂，可以带你完整了解如何应对需求相关的一般场景。结合许多故事、案例研究、趣闻轶事和实例，这本书读起来引人入胜。
——laura brandenburg，cbap（认证业务分析师），bridging the gap站长

怎样才能使好需求容易理解？在添加内容时，可以像karl和joy所做的那样，确立全面的产品愿景，处理敏捷方面的问题，尽可能重用需求，处理软件包和外包项目，确定具体用户类别。可以由表及里查看需求，解决流程和风险的问题，而不只是确定功能。
——donald j. reifer，reifer consultants公司总裁

本书新版随业务的发展与时俱进，既在第2版的基础上进行了深化，又让分析师真切了解到如何应对敏捷开发的大潮，如何使用特性进行范围控制，如何提升需求收集技术，如何开展建模。wiegers和beatty联袂打造的这本书是专业人士的必读经典。
——keith ellis，enfocus solutions公司总裁兼ceo，《业务分析标杆》作者

《软件需求》读后感系列之一-无题乱弹
作者：淡淡如菊

好几年前，当我转型成为一名业务分析师时，我苦恼于自己并不十分懂得这个职位究竟要做什么，要怎么做，要怎么做好。所以我在网络上搜寻所有可以买得到的相关书籍，以求获得一些指导，其中也包括《软件需求》（第2版）。在那个时候，这本著作系统的知识点给了我很多启发，我尽量从似懂非懂到有样学样，在实践中去思考如何改进，然后再次去实践。不仅仅是最初阅读的时光，后续这几年的工作过程中，当我遇到一些需求相关的问题的时候，我也会重新打开这本书，翻阅相关的章节，以求回到最初的状态，去理解本源，并再次出发去解决当下的问题。这次拿到新鲜出炉的第三版，我的感受是，第三版很好地保留了之前的精髓，并在其基础上补充了很多关于敏捷开发流程的观点。这次也有非常强大的翻译团队，阅读的感觉更流畅，这是一本非常适合软件开发领域的从业人员阅读的书籍，尤其是对需求分析感兴趣的朋友。我的个人观点是业务分析师都应该拥有一本以备随时参考。

这次十多位朋友一起读这本书，大家在微信上展开了很多讨论，也激发了我的灵感，所以想提笔写一写打动我的一些章节。我不知道自己能否写一个系列，但我今天打算从业务分析师的培养说起，呼应本书第四章的内容。

书中提到业务分析师的培养可以是前用户，前开发人员和测试人员，前（或兼职）项目经理，主题专家或者菜鸟（新人）。不管哪一种角色，转型成为业务分析师，都会有各自的优势或者劣质，如果能发挥优势，改进薄弱环节，那么在成为一名成功的业务分析师的道路上就有了好的开始。现在我也有带领一个业务分析师团队，我们的团队成员有前开发人员，前测试人员，也有新人。我本人也是半路出家，是一名软件开发程序员转型过来的。我的理解是，软件开发过程中的每个角色都要或多或少具备软件需求分析的功能，而其中的业务分析师当然是最应该具备这个技能的工作。那么除了文中提到的不同的人员转型到这个工作的优势劣势以外，我就随便谈几点的想法吧：
为用户画像的潜意识
需求分析的工作离不开和用户沟通，我们常常会说需求获取，但和用户沟通并不是一个简单的单方向从用户获取需求的过程。不同的业务分析师去和同一个用户聊，也许会得到完全不一样的需求。我还在做程序员的时候，因为当时的团队没有ba这个角色，所以老板派我去用户现场了解他们的工作内容。那会完全是菜鸟出场，也没有需求获取的技巧和技术可言。当我去到现场，接待我的是一位热情的前辈，因为对方很配合，所以进展还不错，然后有一天我决定在工作之余约她出去一起吃饭。吃饭的时候，大家都很放松，她跟我聊了很多，她从哪里来，为何选择了我们公司，她对工作的看法和期许，她每天花很多时间在上班路上的困扰，甚至还有她的宠物。饭局后，我还在现场呆了一段时间，我明显感觉到我的工作进展的更加顺利了，说不出是什么原因，但很显然彼此的信任增加了。后来，当我们开始去设计这个系统的时候，我会常常想到她，想象如果是她在用这个系统，她的反应会是怎样，她会觉得好用吗，她会困扰吗？当年的我并不明白，这个和用户沟通的过程就是一个实实在在为用户画像的过程，除了明白她的工作，我们更应该去了解用户真实的面目，不是要刨根问底，但你要理解她自身的一些和系统有关的状况。比如她的教育背景，她对电脑的熟悉程度，她对工作的成就感在哪里，如果系统能帮到她，她的幸福感在哪里。如果你在和用户沟通的过程中， 会为了这样的发现而喜悦，那么我想你会适合往业务分析师这个方向发展的。
解决需求问题的成就感
我的第一份工作是软件工程师，当年有幸进入了一家提供电信行业解决方案的知名公司。加入公司一个月后，因为前辈们纷纷被挖角，我们几个菜鸟被迫上了第一线。当时摆在我们眼前的项目，就是某通信公司引入了全新制式的交换机，话单的采集和分拣程序需求需要重新梳理并参与测试评比。当时的新交换机厂商是北电网络，他们在国内的工程师只负责设备调试，对于系统的软件问题只能帮忙联系加拿大的工程师进行中间协调。我们能拿到的所有的文档都是英文的，内部更是充斥着大量的通信术语，语言的障碍以及对这个领域的不熟悉，是否能如期完成需求梳理，当时的我们觉得任务艰巨。为了尽快搞定这个需求工作，我一页页翻看这份文档，不懂的字句求助google，不能理解的设计用邮件求助外国工程师，最后总算理出了话单生成的机制，采集的要求，以及话单的构成，并整理出详细的数据字典。后续的故事就是，我们一帮菜鸟基于自己的需求理解，开发完成了话单采集及分拣程序，我们的程序在各大厂商对新交换机处理能力的测评中，获得了处理速度快、准确度高的评价，荣登三甲。所以说，需求分析的工作，程序员也可以做好的。如果你是一位对于需求分析工作特别有兴趣的程序员，如果你也确实觉得这样的工作能给你带来成就感，那么不如适当的往这个方向历练一下吧。你可以选择转型，也可以只是将其作为自己成为项目经理必备的技能。我的理解是，不会分析需求的程序员不是好的项目经理。
所谓菜鸟
有谁不是从菜鸟开始的呢？对于刚刚走出校门的人来说，成为一名业务分析师是进入信息技术领域的一个很好的切入点，优点在于他或者她对需求流程的工作原理几乎没有什么先入为主的概念。毕业生要学习的东西很多，工作职责，开发流程，理解开发人员、测试人员，了解用户，掌握基本的业务知识，懂得如何有效的获取需求。我们无法奢求一个刚走出校门的孩子，既懂得需求分析的知识，又掌握了实际的技巧。菜鸟要做的是，保持对这份工作的热忱，快速学习，快速成长。成为一名业务分析师所基本的知识，本书能给你最好的解答。至于技能吗，要在实践中掌握，希望本学习小组的各位能多点分享这部分啦。但最最重要的，是菜鸟的心，可以是决心，信心，恒心，世上无难事只怕有心人。

(原文链接：http://www.jianshu.com/p/86437a10783d?utm_campaign=hugo&utm_medium=reader_share&utm_content=note&utm_source=weixin-friends&from=singlemessage&isappinstalled=1)

]

本书特色

[

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

]

内容简介

[

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

封面

书名:软件需求-(第3版)

作者:魏格斯

页数:546

定价:¥99.0

出版社:清华大学出版社

出版日期:2016-03-01

ISBN:9787302426820

PDF电子书大小:39MB 高清扫描完整版