近年来，需求管理在软件项目中开始占据显著地位并且得到人们的普遍重视，本书可以说是第一本关于需求管理的实用手册。全书语言平实生动，并且采用大量实例和图表，以作者亲历的项目开发为例，全面探讨了软件开发过程中与需求有关的活动。本书是作者对近二十年的软件工程、需求工程、面向对象等领域成熟的思想、方法、技术及实践经验的总结，全书内容围绕着作者认为团队在需求管理中必须掌握的六大重要的团队技能进行组织和展开，这六大技能是：分析问题、理解用户需要、定义系统、管理广度、细化系统定义和构建正确系统。
本书提出了应对软件项目开发中需求管理挑战的全方位解决方案，对于实际的需求管理具有非常强的指导意义和实用价值，本书可作为计算机专业高年级本科生及研究生学习软件需求管理的教材，也可作为软件开发人员开发过程中随时参考的手册。
环境和感谢
本书所传达的知识代表了一群优秀的业内人士所积累的宝贵经验，他们曾经定义、开发和交付了许多世界一流的软件系统。本书并不是关于需求工程的学术讨论。20世纪80年代，Don Widrig和我是一家为客户提供软件解决方案的小公司的业务主管。当我们开发了许多本书所介绍的需求管理实践时，我们的着眼点在于既保证我们所开发软件系统的质量又保证客户的利益。因为所交付软件的性能对于这个商业风险本身的成功至关重要，所以我们不鼓励在其中掺杂些许成见、个人喜好或采用不成熟的技术进行实验。
过去十年中，技术在不断演化并且不断由新的经验增强，被不同公司的专家在不同的环境下加以扩展。但本书提及的所有技术都经过现实世界的证明并经受了时间的考验。更为重要的是，它们还经受住了这一时期行业内发生的技术变革。事实上，本书中的许多原理都不受软件技术潮流变化的影响，因此我们希望这里所表述的知识能具有更长久的利用价值。
为其他行业制作软件得到的需求经验和教训
一开始，我讨厌计算机。（“什么？我必须整晚呆在这里，把这批作业再做一遍只是因为我漏了一个“空格”？你疯了吗？让我在呆在那个房间里……”。）我的第一台“真正的计算机”是一个小型计算机，尽管按照今天的标准它的性能无法想像地低，但它对我却是惟一的，我可以触摸它、用它来编程、让它做任何我想让它做的事，它是我的。
我最早的研究是用计算机分析来自人体的生理信号，主要是EKG，对于这项工作，计算机是一个奇妙的工具。此后，我开始把我的程序设计技能和实时软件系统的经验应用到行业需要中。
最后，我组建了RELA股份有限公司，开始了一个漫长而异常艰难的职业：软件开发承包商的首席执行官（CEO），本书的合作作者Don Widrig也加入我的RELA，最早是研究和开发部的副总裁，他为我们开发的许多系统的成功做出了重要贡献。
随后几年，公司蓬勃发展。今天，公司已经有几百名员工，业务也从只提供软件扩展到提供完整的医疗设备和系统，包括软件、机械、电子、光学和射流处理等子系统。在每个患者的心脏处和每台机器包括最新临床诊断实验室的DNA识别仪，都有一台或多台的计算机，通过一个实时的多任务处理系统的调节可靠而例行地传递出患者稳定的心律。
开始，我们为任何人编任何程序，从天线定位软件到激光标签游戏、为游乐园做的自动导航汽车、教育产品、焊接机器人以及自动机械控制。我们甚至开发了一个大型分布式计算机系统，该系统能够自动检测和计算电视上广告片的数量（那时，我们的座右铭是“让计算机来看广告片，把你解放出来！”）。我们做的所有软件的共同点大概在于，我们是为别人开发的—我们不是这些领域的专家，并且我们无法负担自己必需的工资。我们完全依靠客户的满意度来决定最终成果。在许多方面，这种环境非常有助于有效的需求管理，原因在于：
●我们对领域了解得很少，因此我们要依靠客户提出需求。把这些需求组织起来很乏味；我们必须提问，并且必须学会在正确的时间用正确的方式问正确的问题。
●客户通常对计算机知道得很少，所以他们依靠我们来把他们的需要和希望解释成技术需求。
●金钱在开发人员和客户之间易手的事实在两者之间建立一种严格的界面。
●质量很容易度量：我们要么获得报酬要么一文不名。
第一个重要问题：“这个软件到底要做什么？”
就是在这种环境下，我们发现了软件开发人员在所有项目中都会面对的两个最基本问题。这两个问题主宰我们的行为很多年，并且今天可能仍然是所有软件项目中最难回答的问题。第一个大问题：“这个软件到底要做什么？”
在团队技能之一—分析问题，团队技能之二—理解用户的需要，团队技能之三—定义系统中出现的原理和技术已经有十多年的历史了，它们就是用来回答这一重要问题的。这些技术本身证明了它们自身的价值并且在许多实际的项目中显示了它们的有效性。也正是在这期间，我第一次注意到Donald Gause和Jerry Weinberg的著作，尤其是他们的书：《Exploring Requirements: Quality Before Design》（《探讨需求：设计之前的质量》）（1989）。因为他们的著作很大程度地影响了我们的工作，所以本书中许多概念也取自这本著作，不仅因为这些概念的确有用，而且我们认为您也能分享Gause和Weinberg的成果才算公平。
构造高质量保证系统得到的经验和教训
随着时间的推移，RELA逐渐在开发基于计算机的医疗设备和系统方面走向专业化：手提式通气装置（呼吸机），注射泵，起搏器程序装置，临床诊断系统，血泵，病人监视设备，以及其他许多诊断和治疗设备。
正是在呼吸机项目的开发中，才使我们为自己正在做的工作而震惊：哇，如果我们把它拧紧点的话，有人就会没命了！我们主要关注的是与这台仪器紧紧系在一起的病人以及病人家属，这台仪器是我们做的也是世界上最早的时限最严的资源限制软件。（想像一下a测试和b测试的挑战。你去第一个接受测试吧！）
显然，这种高风险的工作使我们在嵌入式系统业发展的早期就非常注重软件的质量。很快，我们就明白持续的成功需要以下几方面的结合：
●一个能够定义和管理软件需求的实用的过程。
●一个用于设计和开发软件的具体的方法。
●验证和确认软件安全和高效的多种经过证明的创新技术的应用程序。
●软件开发团队和软件质量保证团队两者成员的高超技能和承诺。
那时我非常相信今天甚至也更加确信，要交付任何重要领域中合理的、可靠软件系统，这些因素都是必需的。在RELA公司，只有通过这种方式我们才能确保每个病人的生命安全、我们的公司的生存、公司的员工以及他们的家庭的经济前景。
第二个重要问题：“我们怎么才能知道软件完成了所要求的而不是其他的工作？”
过去我们成功地开发和应用了多种回答第一个重要问题的技术，现在我们来看一下全世界软件开发团队所面临的第二个基本问题：“我们怎么才能知道软件完成了所要求的而不是其他的工作？”
回答这个问题的技术组成了团队技能之五—细化系统定义和团队技能之六—构建正确系统的基础。
可以确信的是，本书给出的技术都是坚实的并经过证明的。而且，即使不是开发安全性要求非常高的系统，这些技术也提供了非常有效、实用和划算的建议，可以用于开发高质量的软件系统。
尽管我们在RELA公司用来解决这两个重要问题所借用、修改、开发和应用的技术非常有效，但必须承认，存在一种令人烦恼的不确定性，在项目的最严重的关键时刻使我们保持清醒：“由于需求处理带有高度手工的特点，多久我们会出一个具有潜在危险的错误？”
当然也有成本的问题，因为手工验证和确认费用昂贵并且容易出错。在这一期间，机械工程学科已从机械绘图仪进步为3D计算机辅助设计系统。同期，软件的进步是有限的，在程序设计语言中为达到实用的目的增加了抽象层次：从某种意义上是一件好事，但故障率、代码行生产率以及质量度量的情况相对不变。这一时期我们使用CASE工具的试验得到了一些混合的结果。坦率地说，作为一个软件工程师和软件企业家，我认为“软件工程”的现状令人尴尬。
尽管自动化永远不能替代软件开发中的重要的思考技能，但我确信，把该过程中的手工记录、变更管理等内容自动化可以解放宝贵的资源进行具有更高价值的活动。当然，我们希望开发的成本更低而可靠性更高!
需求管理业务中得到的经验和教训
所以，REQUISITE公司在1993年诞生了，我们中的许多人都参与开发和推销一种新的需求管理工具：RequisitePro。在这期间，随着我们不断地帮助客户解决他们的需求管理问题，本书中许多增补材料产生了。为此，我们要向我们的客户以及RELA的客户表示感谢，是他们从本质上教会了我们在这个主题上知道的任何事情。
我的职业生涯的这一时期受到Alan Davis博士的很大影响，他是《IEEE Software》杂志的主编，是位于科罗拉多斯普林斯的科罗拉多大学埃尔·波马尔基金会的软件工程的主席。Alan早期是作为董事和顾问加盟公司的，对公司的技术和商业方向起着重要的影响作用。另外，他以其在需求工程领域的领导才能而著名，他从事这方面的咨询活动并开发了帮助公司提高需求处理的大量技术。这些技术与RELA开发的一些技术合并并成为一项称为“需求学院”的职业培训的基础，也是本书的部分基础。
此外，在一种目前还不太流行的商业理论—“永远都不可能获得太多的职业帮助”的指导下，我们还吸收了著名的软件作家和专家Ed Yourdon参加公司的董事会。Ed对指导公司的技术和商业方向上也具有重要的影响。Ed和Alan都是本书早期的撰写人，本书中使用的许多词汇都是他们创造的。事实上，我们本想在几年前联合出版这本书但是几经改变，而Ed和Alan都把他们的早期的工作无私地贡献给我们。然而，通过这寥寥数语，读者将会经常想起他们。
在Rational软件公司的经验
Rational软件公司于1997年收购了Requisite公司。在Rational公司，我们在把需求管理应用于开发和发布一组完整的应用开发工具集并继续帮助客户解决需求问题的过程中又获取了很多重要的经验。Don继续和我们一起奋战，帮助改进技术。此外，在Rational，我还有幸和一些著名的软件专家和作者一起工作，包括Grady Booch，Ivar Jacobson，James Rumbaugh，Walker Royce，Philippe Kruchten等，他们对我形成有关需求管理挑战的想法都有重要的影响，Walker和Philippe最早还对本书进行了审阅。
我们也开始使用用例技术来获取需求，并在设计模型中利用用例概念来提供一条共同的主线来驱动体系结构、实现和测试。
我也是Rational的软件开发的迭代方法的忠实宣传者，它是一种完整的生命周期软件开发过程，我认为我们在RELA和Rational的统一过程中都实践了这种方法。
Rational帮助我完成了这本书，为此我表示衷心感谢，并且Rational还慷慨地许可我使用它的一些重要思想、文本和图表。
最后，我们想感谢本书的审阅人员以及其他许多为本书的出版做出贡献的人，他们是Alan Davis，Ed Yourdon，Grady Booch，Philippe Kruchten，Leslee Probasco，Ian Spence，Jean Bell，Walker Royce，Joe Marasco，Elemer Magaziner，Addiso·Wesley公司以及以下审阅人员（排名按字母顺序）：Ag Marsonia，Granville Miller，Frank Armour，Ralph R. Young博士（Litton PRC系统和过程工程公司软件工程部主任），David Rine教授（George Mason大学）和Dan Rawsthorn（ACCESS）。
小结
本书中的思想即使有也很少是我们自己创造的。事实上，它代表了20年来获得的共享软件开发经验，并且以需求的挑战作为集中、连贯和度量的重点。这样做，我们希望本书能融汇业界中有关需求这一特殊和困难的软件挑战中最好的经验和思想。我们坚定地相信，本书的成果—高效地管理需求所要求的六大团队技能—将有助于在预算内按时提交高质量软件系统。
Dean Leffingwell
石头问题
我的一个学生把本书所讨论的问题总结为“石头”问题。她是一个研究实验室的软件工程师，她说客户常常会交给她一些项目，她称之为“给我一块石头”。可是当你把石头交给客户时，他会看一会“石头”，然后说：“是的，但是……，实际上我想要的是一块小一点的蓝色石头。”而当你交出一块小一点的蓝色石头时，又会引发“一块圆的小一点的蓝色石头”的要求。
最终的结果可能是，客户一直都在想要一块小一点的蓝色大理石—或者他也许根本不能确定他到底要什么，而不是一块小小的蓝色大理石—甚至是猫眼大小的蓝色大理石就已经足够了。而他会在你交出第一块（大的）石头和第三块（蓝色的小）石子之间不断改变对需求的想法。
开发人员在与客户会谈时总会提这样的问题：“你想要它做什么？”当开发人员按照客户预先的需求经过艰苦努力终于交出一块石头却得不到客户的肯定时，总是感到非常沮丧；而客户也同样沮丧，因为即使他可能也发现很难说清自己真正的要求，他还是觉得自己已经讲得很明白，只是开发人员没理解罢了！
大多数实际的项目会涉及更复杂的情况，而不只是涉及到两个人。除了客户和开发人员外—他们自然有不同的头衔和名字—还有市场营销人员、测试和质量保证人员、产品经理、总经理以及一大堆“风险承担人”，他们的日常工作将受到开发新系统的影响。
所有的人都会为如何指定一个大家都接受的“石头”而头疼，尤其在当今快节奏竞争的商业世界，谁都没有时间废弃一个耗时两年的“石头项目”，并且从头再做一次。我们必须使它在第一次就是正确的，同时为客户提供一个迭代的过程，在这个过程中使他们最终发现他们真正想要的石头。
对付石头这样有形的物理实体时已经很难了，而现在多数商业机构和政府部门都是“信息密集型”的，即使他们名义上是从事构建和销售“石头”，也有“石头”包含一个嵌入式计算机系统的机会。即便不是如此，也有可能需要利用计算机来跟踪它们的电子商务“石头”销售、它的“石头”客户、它的“石头”对手、它的“石头”供应商等等使它在“石头”商务中保持竞争力的信息。
软件系统天生就是无形、抽象、复杂的，并且—至少从理论上说—它们是可无限改变的。所以，如果客户的“石头系统”的需求从一开始就是含糊的，并且他总认为随着时间的推移，自己能对细节进行澄清、改变和补充的话，那么，开发人员以及所有创建、测试、推广使用和维护人员很难在零时间内以零耗费完成系统开发。
事实是：当今，有一半以上的软件系统项目严重超出预算并且推迟进度，有25%到30%的项目在完成之前就被放弃了，并且耗费惊人。
本书的目的是：提供一种合理的方法来构造客户真正需要的系统，从而避免以上失败。但是，本书并不是一本有关程序设计的书，它也不仅仅是为软件开发人员写的，意识到这一点很重要。这是一本有关管理复杂软件应用的需求的书。因此，本书是为软件开发团队的所有成员（分析人员、开发人员、测试人员和质量保证人员、项目经理以及建立文档人员等）还有外部“客户”团队的成员（用户以及其他的风险承担人、市场人员、管理人员）——所有有促成需求最终解决的需要和要求的人而写的。
你会发现，如果让包括外部团队的非技术成员在内的所有团队成员都掌握定义和管理需求所需要的技能是非常关键的。原因很简单，因为他们是首先创建需求并且最终决定系统成功与否的人。孤立的、英雄的程序员是过去那个时代的错误：愿他安息吧。
有一个简单的比喻：如果你是一个建筑承包人，你一定认为有必要和房主进行一系列详细的讨论，否则，你可能会造一座两居室的房子，而客户要求的却是三居室。但是，与负责建筑条例及地区规划的政府当局讨论和协商这些“需求”同样重要，假如要砍掉要建房的地皮上的树，你还得再和邻居商量一下。
建筑督察员和邻居都是风险承担人，他们将同要购房和住进房子的人一道确定最后盖好的房子是否符合所有的需求。显然，在这个系统中有很多非用户（房主）的重要风险承担人，如邻居和地区规划的官员，同样，他们对这个系统的看法将会有很大的不同。
再强调一次，本书讨论的是软件应用，而不是房子或石头。房子的需求（至少部分）可以用一组蓝图和工程图样来描述；类似地，也可以用模型和图来描述软件系统。但是，就像房子的蓝图是工程师和外行人员—律师、督察人员、邻居—之间进行协商和交流的手段一样，与软件系统相关的技术图也可以以一种“普通人”能够理解的方式做出来。
许多至关重要的需求根本不需要用图表示，比如，未来的购房客户可以简单地写道：“我的房子必须有三居室，还得有一个能容纳两部汽车和六辆自行车的车库。”正如你在本书中将会看到的那样，软件系统的多数重要需求都可以用自然语言来描述。
为了迎接这一挑战，你需要掌握的一些重要团队技能中很多可用实用的常识性建议表述。对于一个盖房新手，我们可能会建议他“一定要在挖地基之前而不是在浇铸水泥并开始垒墙和房顶后同建筑督察人员交流”。对于一个软件项目，我们也会有类似的建议：“务必要提出正确的问题，务必按轻重缓急提出需求，并且不要让客户告诉你所有需要都是重要的，因为在最后期限之前，你不可能有时间把它们全部完成。”
关于本书
在这本书中，Leffingwell和Widrig采取了一种实用的方法来描述石头问题的解决方案。他们把全书分成七个部分。引言部分为后面的章节提供了环境、定义和背景。第1章回顾系统开发“挑战”。数据显示有些软件项目的失败的确是因为编程马虎造成的，但最近大量的研究确切地表明，不良的需求管理可能是项目失败的惟一的最主要原因。在这个序言里我用不严格的非形式化的方式描述了需求管理的基本概念，本书作者将在第2章详细地定义这一概念，从而为后续章节奠定基础。第3章对现代软件团队的特征做了简明介绍，从而在团队开发的基础上，讨论团队必须应用的一些团队技能。
本书根据有效的需求管理所必需的六个团队技能加以组织
后面的六个主要部分是为了帮助你和你的团队理解掌握有效需求管理所需要的六大团队技能：
●自然，在开始时，你要正确地理解新软件系统所要解决的问题。这是就团队技能之一—分析问题所强调的内容。
●团队技能之二—理解用户和风险承担人的需要是非常重要的，这些技能形成团队技能之二的基础；
●团队技能之三—定义系统，描述为处理这些需要而定义系统的最初过程；
●团队技能之四—管理广度，介绍一个绝对重要、但却常常被忽略的管理项目广度的过程。
●团队技能之五—细化系统定义，说明为把系统描述到足以驱动设计和实现的详细程度而使用的关键技术，从而使整个团队确切知道你要构造什么样的系统。
●团队技能之六—构建正确系统，讨论构建满足需求的系统的过程。团队技能之六还讨论了用来确认系统是否符合需求、帮助确保系统不会对用户有任何恶意、避免出现任何需求没有定义的不愉快行为的技术。同时，由于应用系统的重要需求不可能一成不变，因此作者还讨论了一些团队用来积极地管理变更而不破坏已设计和构造的系统的方法。
最后，在对全书内容做了简单总结之后，作者还给了一个你和你的团队用来在以后的项目中管理需求的方案，这就是第35章的内容：开始。
我们希望，在这些新获得的团队技术的武装下，你也能雕刻出完美的大理石。但这个工作永远都不是易事，即使用最好的技术和过程并且有自动化工具的支持，你仍然会发现这是一项艰苦的工作；这也是风险很大的工作，即便掌握了团队技能，有些项目仍然会失败，因为我们在为机构开发项目时总想冲开许多组织机构的面罩，企图在更短的时间内构造更复杂的系统。本书所给出的技能能够大大降低开发项目的风险，帮助你到达成功的彼岸。
Ed Yourdon
(美)Dean Leffingwell,Don Widrig：暂无简介
蒋慧 林东 等：蒋慧: 蒋慧，女，1973年2月出生。1995年毕业于南京通信工程学院计算机系，获计算机应用专业工学学士学位。1998年于南京通信工程学院计算机软件专业毕业，并获硕士学位。1998年9月至今，于解放军理工大学攻读博士学位。自1995年以来，在国内外重要学术刊物和会议上发表8篇论文，其中2篇论文被IEEE国际会议录用。已出版3本有关网络的译作。目前从事软件需求工程、网络协议验证形式化方法以及函数式语言等方面的研究。
林东: 于军事科学院获军事运筹学博士学位。1999年至2001年，于国防大学从事军队指挥学博士后工作。参加过多项国家863攻关课题、自然科学基金、国防预研基金项目，主攻方向是C3I工程、指挥与控制科学、战略运筹、需求工程。1991年以来，在国内外重要学术刊物和会议上发表40多篇论文，其中2篇论文被收入SCI、EI检索，主要译著有《数据与计算机通信》、《理清纷乱的世界——跨世纪战略评估》
近年来，需求工程逐渐成为软件工程的一个重要而活跃的领域，需求管理在软件项目开发中开始占据显著地位并且得到人们的普遍重视。国际上有关需求工程的研究与论著方兴未艾，而本书可以说是第一本关于需求管理的实用手册。全书语言平实生动，采用大量实例和图表，以作者亲历的项目开发为例，全面探讨了软件开发过程中与需求有关的活动，涉及大量实用技术，本书是作者对近二十年来软件工程、需求工程、面向对象等领域内成熟的思想、方法、技术及实践经验的重要而有益的总结。
本书一个最重要的思想是，在需求管理中强调团队的作用，提出“高效的需求管理只能通过一支高效的软件团队来实现”。在此基础上，全书内容围绕着作者认为团队在需求管理中必须掌握的六个最重要的团队技能进行组织和展开。管理需求的这六大团队技能分别是：分析问题、理解用户需要、定义系统、管理广度、细化系统定义和构建正确系统。
全书内容丰富、详实、实用，把需求管理的活动渗透到软件项目生命周期的全过程。在对多种方法和技术的讨论中，注重在需求管理的背景下讨论团队实施的方法、技巧以及实施时要注意的问题。同时，书中还提供了大量经过证明十分有效的文档模板和实用技巧，这足以体现出作者在需求管理和项目开发方面具有丰富的实践经验和深厚的功底。
本书提出了应对软件项目开发中需求管理挑战的全方位解决方案，对于实际的需求管理具有非常强的指导意义和实用价值，本书可以作为软件开发人员在开发过程中随时参考的手册，同时也是全体项目团队成员必读的一本书。
本书由蒋慧、林东主译，孙泉、蒋蓓和赵承参与翻译了第3章到第18章的内容，全书由蒋慧统稿。
由于时间仓促，译者水平有限，书中翻译的错误和不妥之处在所难免，欢迎读者多多批评指正。
译者于北京
2001年8月
第一部分 引 言
第1章 需求问题 3
1.1 目标 3
1.2 有关数据 3
1.3 项目成功和失败的根本原因 4
1.3.1 需求错误的频率 5
1.3.2 需求错误的高昂代价 6
1.3.3 结论 7
第2章 需求管理简介 9
2.1 定义 9
2.1.1 什么是需求 9
2.1.2 什么是需求管理 9
2.2 需求管理技术的应用 10
2.2.1 软件应用程序的类型 10
2.2.2 系统应用程序 10
2.3 路线图 11
2.3.1 问题领域 11
2.3.2 风险承担人的需要 11
2.3.3 向解决方案领域前进 12
2.3.4 系统的特征 12
2.3.5 软件需求 12
2.3.6 用例介绍 12
2.4 小结 13
第3章 软件团队 14
3.1 把软件开发作为一种团队活动 14
3.1.1 有效需求管理所需要的团队技能 15
3.1.2 团队成员具有不同的技能 15
3.1.3 软件团队的组织 16
3.2 个例研究 16
3.2.1 个例研究的背景 16
3.2.2 HOLIS软件开发团队 17
3.3 小结 17
第二部分 团队技能之一—分析问题
第4章 问题分析的五个步骤 21
4.1 第一步：在问题定义上达成共识 22
4.2 第二步：理解根本理由—问题背后的问题 23
4.3 第三步：确定风险承担人和用户 25
4.4 第四步：定义解决方案系统的界限 26
4.5 第五步：确定加在解决方案上的约束 27
4.6 小结 29
4.7 展望 29
第5章 商业建模 31
5.1 商业建模的目的 31
5.2 利用软件工程技术进行商业建模 32
5.2.1 选择正确的技术 32
5.2.2 统一建模语言UML 32
5.2.3 利用UML的概念进行商业建模 33
5.3 从商业模型到系统模型 34
5.4 何时使用商业建模 35
5.5 小结 35
5.6 展望 35
第6章 软件密集型系统的系统工程 36
6.1 什么是系统工程 36
6.1.1 系统工程的实用准则 37
6.1.2 复杂系统的组合和分解 37
6.2 系统工程中的需求分配 38
6.2.1 关于派生的需求 39
6.2.2 无声的演化 39
6.2.3 冲突何时产生：资深系统工程师碰上年轻程序员 40
6.2.4 避免“烟囱”系统问题 41
6.2.5 当子系统是转包合同时 41
6.2.6 使系统正确实现 41
6.3 个例研究 42
6.3.1 基本用户需要 42
6.3.2 问题分析 43
6.3.3 HOLIS：系统、参与者和风险承担人 44
6.3.4 HOLIS系统工程 45
6.3.5 HOLIS子系统 46
团队技能之一小结 47
第三部分 团队技能之二—理解用户的需要
第7章 需求启发的挑战 51
7.1 启发的障碍 51
7.1.1 “是的，但是”综合症 51
7.1.2 “尚未发现的遗址”综合症 52
7.1.3 “用户和开发人员”综合症 52
7.2 需求启发的技术 53
第8章 产品或系统的特征 54
8.1 风险承担人和用户的需要 54
8.2 特征 54
8.2.1 通过对抽象级别的选择来管理复杂度 56
8.2.2 产品特征的属性 56
第9章 面谈 58
9.1 面谈的背景 58
9.2 增值背景 59
9.3 真实的时刻：面谈 61
9.4 编辑需要数据 62
9.4.1 分析人员的总结：10＋10＋10≠30 62
9.4.2 个例研究 62
9.5 对问卷调查的注解 63
第10章 需求专题讨论会 65
10.1 加速决策过程 65
10.2 专题讨论会的准备 65
10.2.1 推销概念 66
10.2.2 确保真正的风险承担人的参与 66
10.2.3 后勤保障 66
10.2.4 “热身材料” 66
10.3 联络员的作用 68
10.4 安排日程 68
10.5 举行专题讨论会 69
10.5.1 折衷的问题与技巧 69
10.5.2 自由讨论和意见精简 70
10.5.3 成果和监督执行 71
第11章 自由讨论和意见精简 72
11.1 现场自由讨论 72
11.2 意见精简 74
11.2.1 修剪 74
11.2.2 把意见归类 74
11.2.3 特征定义 75
11.2.4 确定优先次序 75
11.3 基于万维网的自由讨论 76
11.4 个例研究：HOLIS 2000需求专题讨论会 77
11.4.1 参加人员 77
11.4.2 专题讨论会 77
11.4.3 会议 77
11.5 结果分析 79
第12章 情节串联板制作 80
12.1 情节串联板的类型 80
12.2 情节串联板做什么 81
12.3 情节串联板制作的工具和技术 82
12.4 情节串联板制作的几点提示 82
12.5 小结 83
第13章 应用用例 86
13.1 构建用例模型 86
13.2 应用用例启发需求 87
13.3 个例研究：HOLIS的用例 88
13.4 小结 89
第14章 角色扮演 90
14.1 如何扮演角色 90
14.2 与角色扮演类似的技术 91
14.2.1 脚本预演 91
14.2.2 CRC卡 91
14.3 小结 92
第15章 原型开发 93
15.1 原型的类型 93
15.2 需求原型 93
15.3 原型的对象 95
15.4 构建原型 95
15.5 评估结果 95
15.6 小结 96
团队技能之二小结 96
第四部分 团队技能之三—定义系统
第16章 组织需求信息 99
16.1 组织复杂硬件系统和软件系统的需求 100
16.2 组织产品系列的需求 102
16.3 关于“未来”需求 102
16.4 商业和市场需求与产品需求的比较 103
16.5 个例研究 103
16.6 小结 104
第17章 前景文档 105
17.1 前景文档的组件 105
17.2 “d前景”文档 107
17.2.1 1.0版本的前景文档 108
17.2.2 2.0版本的前景文档 108
17.3 遗留系统环境中的d前景文档 110
第18章 负责人 111
18.1 产品负责人的作用 111
18.2 软件产品环境中的产品负责人 112
18.3 IS/IT商店里的产品负责人 113
团队技能之三小结 114
第五部分 团队技能之四—管理广度
第19章 项目广度问题 117
19.1 项目广度的组件 117
19.2 难题 119
第20章 建立项目广度 120
20.1 需求基线 120
20.2 设定优先级 121
20.3 评估工作量 121
20.4 加入风险因素 122
20.5 缩小广度 123
20.6 个例研究 125
第21章 管理客户 128
21.1 促使客户管理他们的项目广度 128
21.2 交流结果 128
21.3 与客户协商 128
21.4 管理基线 129
21.4.1 正式变更 130
21.4.2 非正式变更 130
第22章 广度管理和软件开发过程模型 131
22.1 瀑布模型 131
22.2 螺旋模型 133
22.3 迭代方法 134
22.3.1 生命周期阶段 135
22.3.2 迭代 135
22.3.3 工作流程 136
22.4 做什么，做什么…… 137
团队技能之四小结 137
第六部分 团队技能之五—细化系统定义
第23章 软件需求 141
23.1 软件需求的定义 142
23.2 特征和软件需求之间的关系 143
23.3 需求的两难问题：做什么与如何做 143
23.3.1 排除项目信息 144
23.3.2 排除设计信息 144
23.4 更多有关需求与设计的讨论 145
23.5 需求的其他特性 146
23.5.1 功能性软件需求 147
23.5.2 非功能性软件需求 147
23.5.3 设计约束 150
23.5.4 设计约束是真正的需求吗 151
23.6 采用父-子需求提高确切性 152
23.7 展望 153
第24章 细化用例 154
24.1 要问的问题 154
24.1.1 什么时候应该采用用例方法 154
24.1.2 什么时候用例不是最佳选择 154
24.1.3 冗余问题 155
24.2 细化用例的规格说明 155
24.2.1 用例是如何演变的 156
24.2.2 用例的广度 157
24.3 个例研究：一个简单用例的解剖 157
24.3.1 定义参与者 157
24.3.2 通过命名用例来定义用例 157
24.3.3 写一个简明的描述 158
24.3.4 定义事件流程 158
24.3.5 确定前置条件和后置条件 159
24.4 展望 160
第25章 现代软件需求规格说明 161
25.1 现代SRS包 161
25.1.1 现代SRS包归谁所有 163
25.1.2 组织现代SRS包 163
25.2 为功能性需求建档 165
25.3 展望 166
第26章 歧义性和确切性 167
26.1 找到“最佳击球点” 167
26.2 玛丽有只小羊羔 169
26.3 消除歧义的技术 170
26.4 做什么 171
第27章 软件需求的质量度量 172
27.1 九个质量度量 172
27.1.1 正确的需求 172
27.1.2 无歧义的需求 173
27.1.3 需求集的完备性 173
27.1.4 需求集的一致性 175
27.1.5 根据重要性和稳定性给需求分级 175
27.1.6 可验证的需求 176
27.1.7 可修改的需求集 177
27.1.8 可跟踪的需求 177
27.1.9 可理解的需求 178
27.2 用例模型的质量度量 178
27.2.1 用例规格说明 178
27.2.2 用例的参与者 179
27.3 现代SRS包的质量度量 180
27.3.1 好的目录 180
27.3.2 好的索引 180
27.3.3 修正记录 181
27.3.4 词汇表 181
第28章 说明需求的技术性方法 182
28.1 说明需求的技术性方法 182
28.1.1 伪代码 182
28.1.2 有限状态机 183
28.1.3 决策树和决策表 184
28.1.4 图形决策树 185
28.1.5 活动图 185
28.1.6 实体联系模型 186
28.1.7 面向对象建模 187
28.1.8 数据流图 188
28.2 规格说明的维护 189
28.3 个例研究 189
团队技能之五小结 189
第七部分 团队技能之六—构建正确系统
第29章 正确地构建正确系统：概述 193
29.1 不断证实开发沿着正确的方向 193
29.1.1 软件验证的原则 193
29.1.2 验证的耗费 194
29.1.3 在所有层次上进行验证 194
29.1.4 验证的原因 195
29.2 证实开发结果是正确的 195
29.3 学习处理开发过程中出现的变更 196
29.4 展望 196
第30章 从需求到实现 197
30.1 把需求映射到设计和代码 197
30.1.1 不相关问题 197
30.1.2 面向对象 198
30.1.3 把用例作为需求 199
30.1.4 管理过渡 199
30.1.5 软件系统建模 199
30.1.6 用例模型在体系结构中的作用 201
30.2 在设计模型中实现用例 201
30.2.1 协作的结构方面和行为方面 202
30.2.2 利用协作实现个体需求集 203
30.3 从设计到实现 203
30.4 小结 204
30.5 展望 204
第31章 利用可跟踪性支持验证 205
31.1 需求验证中可跟踪性的作用 205
31.1.1 隐式跟踪与显式跟踪 206
31.1.2 其他要考虑的可跟踪选项 207
31.2 使用跟踪工具 207
31.3 在没有跟踪工具条件下进行 210
31.3.1 被忽略的验证关系 211
31.3.2 过度的验证关系 211
31.4 有关验证和可跟踪性的思考 213
31.5 展望 213
第32章 确认系统 214
32.1 确认 214
32.1.1 验收测试 214
32.1.2 确认测试 215
32.1.3 确认跟踪 215
32.1.4 基于需求的测试 216
32.2 个例研究：测试用例 216
32.2.1 测试实例1描述 216
32.2.2 跟踪测试实例 217
32.3 测试离散需求 217
32.3.1 被忽略的确认关系 218
32.3.2 过度的确认关系 219
32.4 测试设计约束 220
32.5 展望 220
第33章 利用投资收益决定V&V工作量 221
33.1 深度与覆盖 221
33.1.1 V&V深度 221
33.1.2 V&V覆盖 222
33.2 验证和确认什么 222
33.2.1 第1种选择：验证和确认一切 222
33.2.2 第2种选择：利用冒险分析来决定V&V的必要性 223
33.2.3 把冒险分析作为投资收益 224
33.3 展望 224
第34章 管理变更 225
34.1 为什么需求会变更 225
34.2 外部因素 225
34.3 内部因素 226
34.4 “我们已经遇到了敌人，而且敌人就是我们自己” 226
34.5 管理变更的过程 227
34.5.1 第1步：认识到变更是不可避免的并为变更制定计划 227
34.5.2 第2步：确定需求的基线 228
34.5.3 第3步：建立控制变更的惟一渠道 228
34.5.4 第4步：使用变更控制系统来捕获变更 229
34.5.5 第5步：分层次地管理变更 231
34.6 需求配置管理 231
34.6.1 基于工具的变更管理 233
34.6.2 变更所影响的元素 234
34.6.3 变更记录的审计追踪 235
34.6.4 配置管理和变更管理 235
34.7 小结 235
团队技能之六小结 236
第八部分 开 始
第35章 开始 240
35.1 致词 240
35.2 已经学到的主要内容 240
35.2.1 引言 240
35.2.2 团队技能之一：分析问题 241
35.2.3 团队技能之二：理解用户的需要 241
35.2.4 团队技能之三：定义系统 242
35.2.5 团队技能之四：管理广度 242
35.2.6 团队技能之五：细化系统定义 243
35.2.7 团队技能之六：构建正确系统 243
35.3 需求管理的方案 244
35.3.1 简化的假设 244
35.3.2 方案 244
35.4 现在开始下一个版本 246
附 录
附录A HOLIS制品 248
附录B 前景文档模板 272
附录C 现代SRS包模板 279
附录D SEI-CMM和ISO 9000
中的需求管理 285
附录E Rational统一过程中的需求管理 290
参考文献 299
索引
