欢迎光临本店     登录 注册   加入收藏
  •   
欢迎光临清华大学出版社第三事业部!

此页面上的内容需要较新版本的 Adobe Flash Player。

获取 Adobe Flash Player

当前位置: 首页 > 外版图书 > 计算机与互联网 > 软件需求(第3版)

浏览历史

软件需求(第3版)

软件需求(第3版)

prev next

  • 商品货号:20160218002
  • 商品重量:0克
    作者:(美)魏格斯(Wiegers, K.E.), (美)贝蒂(Beatty, J.)著;李忠利,李淳,孔晨辉,霍金健译
    出版社:清华大学出版社
    图书书号/ISBN:978-7-302-42682-0
    出版日期:2016-03-01
    开本:16开
    图书页数:572
    图书装订:平装
    图书规格:185mm×260mm
    版次:3
    印张:35.75
    字数:656000
    所属分类:TP311.52
  • 上架时间:2016-02-18
    商品点击数:2047
  • 定价:¥99元
    本店售价:¥99元
    注册用户:¥99元
    vip:¥94元
    黄金等级:¥89元
    用户评价: comment rank 5
  • 商品总价:
  • 购买数量:

内容简介:

商品附加资源

容简介

 

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

本书尤其适合具备一定软件开发过程经验的业务分析师、需求分析师、项目经理和其他软件项目涉众。

 

推荐序:软件需求的百科全书

郑人杰

  

  当前,软件承载着人类的专业知识和实践经验,进入了社会生活的各个领域,它已经深入到人们的工作和日常生活,呈现出无处不在的景象。而软件产业己成为社会经济发展的先导性和战略性产业,成为信息产业和国民经济新的增长点和重要支柱。与此同时,人们对软件开发的产品也相应地提出了更高的要求,包括高质量、低成本和易用性,等等。

  经过多年的实践,我们开始认识到,确定软件需求是软件产品生命周期中最关键的一个环节。对于软件这一不可见的逻辑实体来说,它的研发和传统产业的产品相比有着很大差别。软件需求决定着产品开发的目标,同时,软件需求也是开发项目策划的依据。然而,做好软件需求工作并不容易。如果项目开始时需求工作做得不到位,开发项目的大厦就将建立在不牢固的基础上。自从上世纪七十年代开始,本人在软件工程领域的教学、科研和开发实践中深深地理解到软件需求工作的重要意义,也曾亲身经历过一些软件开发项目由于在初期阶段对需求工作不够重视,就匆忙开展后续工作,致使项目最终受到严重后果的惩罚。例如,用户对交付的产品不满意,由于不适用不得不返工,延期再交付。然而,返工导致的额外成本投入不仅会使开发组织的高管人员失望,开发人员也因要付出更多的劳动而怨声载道,最终导致开发组织的声誉受到影响。实际上,这种人们不愿看到的事件不断发生,也有着它的客观原因。比如,软件人员对项目提出的业务领域知识和相关技术并不熟悉,并且软件人员通常并不只是面对一个应用领域,而是常常在开发一个产品,初歩熟悉一个领域之后,下一个开发任务又会面临另一个全新的领域。此外,当今各应用领域的技术和市场情况大多处于迅速发展和演变之中。另一方面,主观上经常出现的情况则是,软件开发人员未能在项目的需求阶段很好地和用户配合,充分吸收和听取用户的意见,或是接受应用领域知识和技术的培训,等等。

  据本人了解,多年以来,市面上也有不少有关软件需求领域的专业书籍。但本书第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
愿景和范围文档 71
1. 业务需求 72
2. 范围和限制 77
3. 业务背景 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
软件需求规范说明模板 168
1. 引言 169
2. 整体描述 170
4. 数据需求 172
5. 外部接口需求 173
6. 质量属性 174
7. 国际化和本地化需求 175
8. ?[?其他需求?] 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
三层分级法 284
MoSCoW 286
100美元 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
文档的细节 344
Backlog和排优先级 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
变更控制流程说明 418
1. 目的和范围 419
2. 角色和职责 419
3. 变更请求状态 420
4. 准入标准 420
5. 任务 421
6. 退出标准 421
7. 变更控制状态报告 421
附录:为每个请求保存的属性 422
变更控制委员会 422
CCB的组成 423
CCB章程 423
重新协商承诺 424
变更控制工具 424
度量变更活动 425
变更影响分析 426
影响分析过程 426
影响分析模板 429
敏捷项目的变更管理 430
第29章  需求链中的链接 432
需求跟踪 432
需求跟踪的动机 434
需求跟踪矩阵 435
需求跟踪工具 438
需求跟踪过程 439
需求跟踪可行吗?有没有必要 440
第30章  需求工程工具 442
需求开发工具 443
获取工具 444
原型工具 444
建模工具 444
需求管理工具 445
使用RM工具的好处 445
RM工具的能力 446
挑选和实现需求工具 448
选择工具 448
建立工具和流程 449
引导用户采用 450
 
  
第Ⅴ部分  需求工程的实施
 
第31章  改进需求过程 455
需求如何关联到其他项目过程 456
需求与不同的干系人群体 457
获得对变革的承诺 458
软件过程改进基础 460
根因分析法 461
过程改进循环 463
评估当前实践 463
规划改进行动 463
过程的创建、试点和推行 465
评估结果 465
需求工程的过程资产

商品标签

购买记录(近期成交数量0)

还没有人购买过此商品
总计 0 个记录,共 1 页。 第一页 上一页 下一页 最末页

用户评论(共0条评论)

  • 暂时还没有任何用户评论
总计 0 个记录,共 1 页。 第一页 上一页 下一页 最末页
用户名: 匿名用户
E-mail:
评价等级:
评论内容:
验证码: captcha
新手上路
售后流程
购物流程
订购方式
配送与支付
货到付款区域
配送支付智能查询
支付方式说明
服务保证
退换货原则
售后服务保证
产品质量保证
联系我们
网站故障报告
选机咨询
投诉与建议