内容简介
作为经典的软件需求工程畅销书,经由需求社区两大知名领袖结对全面修订和更新,覆盖新的主题、实例和指南,全方位讨论软件项目所涉及的所有需求开发和管理活动,介绍当下的所有实践。书中描述实用性强的、高效的、经过实际检验的端到端需求工程管理技术,通过丰富的实例来演示如何利用最佳实践来减少订单变更,提高客户满意度,减少开发成本。书中的用例、业务规则和商业工具全面修订以体现现状和未来的趋势。
本书尤其适合具备一定软件开发过程经验的业务分析师、需求分析师、项目经理和其他软件项目涉众。
推荐序:软件需求的百科全书
郑人杰
当前,软件承载着人类的专业知识和实践经验,进入了社会生活的各个领域,它已经深入到人们的工作和日常生活,呈现出无处不在的景象。而软件产业己成为社会经济发展的先导性和战略性产业,成为信息产业和国民经济新的增长点和重要支柱。与此同时,人们对软件开发的产品也相应地提出了更高的要求,包括高质量、低成本和易用性,等等。
经过多年的实践,我们开始认识到,确定软件需求是软件产品生命周期中最关键的一个环节。对于软件这一不可见的逻辑实体来说,它的研发和传统产业的产品相比有着很大差别。软件需求决定着产品开发的目标,同时,软件需求也是开发项目策划的依据。然而,做好软件需求工作并不容易。如果项目开始时需求工作做得不到位,开发项目的大厦就将建立在不牢固的基础上。自从上世纪七十年代开始,本人在软件工程领域的教学、科研和开发实践中深深地理解到软件需求工作的重要意义,也曾亲身经历过一些软件开发项目由于在初期阶段对需求工作不够重视,就匆忙开展后续工作,致使项目最终受到严重后果的惩罚。例如,用户对交付的产品不满意,由于不适用不得不返工,延期再交付。然而,返工导致的额外成本投入不仅会使开发组织的高管人员失望,开发人员也因要付出更多的劳动而怨声载道,最终导致开发组织的声誉受到影响。实际上,这种人们不愿看到的事件不断发生,也有着它的客观原因。比如,软件人员对项目提出的业务领域知识和相关技术并不熟悉,并且软件人员通常并不只是面对一个应用领域,而是常常在开发一个产品,初歩熟悉一个领域之后,下一个开发任务又会面临另一个全新的领域。此外,当今各应用领域的技术和市场情况大多处于迅速发展和演变之中。另一方面,主观上经常出现的情况则是,软件开发人员未能在项目的需求阶段很好地和用户配合,充分吸收和听取用户的意见,或是接受应用领域知识和技术的培训,等等。
据本人了解,多年以来,市面上也有不少有关软件需求领域的专业书籍。但本书第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。
如果发现未列出的错误,同样可以在这里进行报告。
如果需要其他支持,请发送电子邮件至微软出版社图书支持邮箱:mspinput@microsoft.com。
请注意,上述地址不提供对微软软件产品的支持。
让我们聆听你的心声
在微软出版社,读者的满意是我们的头等大事,读者反馈是我们最有价值的资源。请告诉我们你对本书的想法: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长期以来建立的合作和友谊给予高度评价。在我们这么多年的需求培训班中,有上千名学员提供反馈和问题,激励着我们深入思考需求问题,我们从中得到了莫大的帮助。我们的咨询经历和读者提出的引人深思的问题,使我们不断了解到从业人员在日常工作中遇到的困难并帮助我们思考。请与我们分享你的经历,发送电子邮件到 karl@processimpact.com 或者 joy.beatty@seilevel.com。
一如既往,Karl要感谢他的妻子Chris Zambito。一如既往,整个过程中她都很有耐心而且脾气极好。Karl还要感谢Joy鼓励他参与这个项目中以及Joy对这个项目听做的了不起的贡献。与Joy一起工作真的很开心,她还使这本书增添了很多价值。很高兴能够和她一起不断讨论、一起艰难决定并在交稿前一起对书稿进行精雕细琢。
Joy特别感谢他的丈夫Tony Hamilton这么快就再次支持她的写作梦想;还有她的女儿Skye,让她每天轻松保持工作与生活的平衡;还有Sean和Estelle,让家庭时光充满欢乐。Joy还想专门感谢Seilevel的全体员工,感谢他们齐心协力推动软件需求领域向前发展。她特别感谢两位同事兼朋友:Anthony Chen对她写这本书提供了至关重要的支持;Rob Sparks不断鼓励Joy为此付出努力。最后,Joy重点感谢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需求工程的过程资产