推荐序：软件需求的百科全书 郑人杰 　　 　　当前，软件承载着人类的专业知识和实践经验，进入了社会生活的各个领域，它已经深入到人们的工作和日常生活，呈现出无处不在的景象。而软件产业己成为社会经济发展的先导性和战略性产业，成为信息产业和国民经济新的增长点和重要支柱。与此同时，人们对软件开发的产品也相应地提出了更高的要求，包括高质量、低成本和易用性，等等。 　　经过多年的实践，我们开始认识到，确定软件需求是软件产品生命周期中最关键的一个环节。对于软件这一不可见的逻辑实体来说，它的研发和传统产业的产品相比有着很大差别。软件需求决定着产品开发的目标，同时，软件需求也是开发项目策划的依据。然而，做好软件需求工作并不容易。如果项目开始时需求工作做得不到位，开发项目的大厦就将建立在不牢固的基础上。自从上世纪七十年代开始，本人在软件工程领域的教学、科研和开发实践中深深地理解到软件需求工作的重要意义，也曾亲身经历过一些软件开发项目由于在初期阶段对需求工作不够重视，就匆忙开展后续工作，致使项目最终受到严重后果的惩罚。例如，用户对交付的产品不满意，由于不适用不得不返工，延期再交付。然而，返工导致的额外成本投入不仅会使开发组织的高管人员失望，开发人员也因要付出更多的劳动而怨声载道，最终导致开发组织的声誉受到影响。实际上，这种人们不愿看到的事件不断发生，也有着它的客观原因。比如，软件人员对项目提出的业务领域知识和相关技术并不熟悉，并且软件人员通常并不只是面对一个应用领域，而是常常在开发一个产品，初歩熟悉一个领域之后，下一个开发任务又会面临另一个全新的领域。此外，当今各应用领域的技术和市场情况大多处于迅速发展和演变之中。另一方面，主观上经常出现的情况则是，软件开发人员未能在项目的需求阶段很好地和用户配合，充分吸收和听取用户的意见，或是接受应用领域知识和技术的培训，等等。 　　据本人了解，多年以来，市面上也有不少有关软件需求领域的专业书籍。但本书第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允许她和他一起合著，每天都教她一些新知识，百分之百的愉快合作！ 　　

• 暂无课件
• 暂无样章
• 暂无网络资源

扫描二维码
下载APP了解更多

版权图片链接