软件需求管理：用例方法（第2版）
[特价中]
点击看大图基本信息
- 作者： [美]Dean Leffingwell,Don Widrig [作译者介绍]
- 译者： 蒋慧
- 丛书名： 软件工程系列
- 出版社：中国电力出版社
- ISBN：7508321901
- 上架时间：2004-5-10
- 出版日期：2004 年5月
- 开本：16开
- 页码：317
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件需求
编辑推荐
作者Dean Leffingwell是前Rational公司的总经理，公认的需求领域的权威，采用一种非形式化、易于接受的风格，讲述他们自己的实战经历，列举大量的个例研究，向我们展示了设计和开发人员如何把用例技术和传统的软件表达形式相结合，高效地确定需求。书中还介绍了一些经过实践证明的用以确定、实现和确认需求的技术。作者在第一版的成功基础上，结合了众多读者的反馈，对内容进了大幅改写和精简，使其更实用、更易读，对读者的实际工作更具指导意义。
内容简介回到顶部↑
当今，尽管有关开发的知识和经验不断丰富，可利用的工具也不断增多，但仍然有相当比例的软件项目失败，原因常常是因为在开始时没有正确地确定和定义需求，或者随着项目的展开没有正确地管理需求、本书是畅销书《软件需求管理》的第二版，聚焦于这一导致项目失败的关键原因，提出了一个经过证明的实用方法，帮助我们在预算内按时提交一个符合客户需要的系统。
作者采用一种非形式化、易于接受的风格，讲述他们自己的实战经历，并通过大量的个例研究，向我们展示了设计和开发人员如何把用例技术和传统的软件表达形式相结合，高效地确定需求。书中还介绍了一些经过实践证明的用以确定、实现和确认需求的技术。书中给出了在整个项目生命周期中，管理需求的六大团队技能：分析问题，理解用户需要，定义系统，管理范围，细化系统定义和构建正确的系统。本书特别强调不断地管理变更，描述了一个过程，确保成功定义项目范围，并使所有涉众达成共识。
书中讨论的主要问题包括：
·问题分析的五个步骤
·业务建模和系统工程
·从客户和涉众那里启发需求的技术
·建立和管理项目范围
·应用和细化用例
·产品管理
·从需求到设计和实现的过渡
·从用例到测试用例的过渡
·敏捷需求方法
Dean Leffingwell是软件业务开发顾问和原Rational软件公司总经理，一位公认的软件需求方法的权威。他曾是Requisite公司的共同创始人和首席执行官，开发了极其成功的需求管理软件工具RequisitePro，并开设了RequirementsCollege课程，这是Rational软件公司最受欢迎的需求管理职业发展系列课程的基础。
Don Wirig是一位独立技术作家和顾问—他曾规划并开设了Rational软件公司的“RequisitePro工具培训课程”，直到1997年才“退隐”科罗拉多的丛林。现在他正忙于看管他院子里的麋鹿，为他的一份当地报纸撰写专栏和为镇上的人们做些公益事务，帮助他们使用计算机。他曾是RELA公司研发部的副总裁，RELA公司主要生产安全性要求较高的实时系统。
作者采用一种非形式化、易于接受的风格，讲述他们自己的实战经历，并通过大量的个例研究，向我们展示了设计和开发人员如何把用例技术和传统的软件表达形式相结合，高效地确定需求。书中还介绍了一些经过实践证明的用以确定、实现和确认需求的技术。书中给出了在整个项目生命周期中，管理需求的六大团队技能：分析问题，理解用户需要，定义系统，管理范围，细化系统定义和构建正确的系统。本书特别强调不断地管理变更，描述了一个过程，确保成功定义项目范围，并使所有涉众达成共识。
书中讨论的主要问题包括：
·问题分析的五个步骤
·业务建模和系统工程
·从客户和涉众那里启发需求的技术
·建立和管理项目范围
·应用和细化用例
·产品管理
·从需求到设计和实现的过渡
·从用例到测试用例的过渡
·敏捷需求方法
Dean Leffingwell是软件业务开发顾问和原Rational软件公司总经理，一位公认的软件需求方法的权威。他曾是Requisite公司的共同创始人和首席执行官，开发了极其成功的需求管理软件工具RequisitePro，并开设了RequirementsCollege课程，这是Rational软件公司最受欢迎的需求管理职业发展系列课程的基础。
Don Wirig是一位独立技术作家和顾问—他曾规划并开设了Rational软件公司的“RequisitePro工具培训课程”，直到1997年才“退隐”科罗拉多的丛林。现在他正忙于看管他院子里的麋鹿，为他的一份当地报纸撰写专栏和为镇上的人们做些公益事务，帮助他们使用计算机。他曾是RELA公司研发部的副总裁，RELA公司主要生产安全性要求较高的实时系统。
作译者回到顶部↑
本书提供作译者介绍
Dean Leffingwell：是软件业务开发顾问和原Rational软件公司总经理，一位公认的软件需求方法的权威。他曾是Requisite公司的共同创始人和首席执行官，开发了极其成功的需求管理软件工具RequisitePro，并开设了Requirements College课程，这是Rational软件公司最受欢迎的需求管理职业发展系列课程的基础。
Don Widrig：是一位独立技术作家和顾问。他曾规划并开设了Rational软件公司的“RequisitePro工具培训课程”，直到1997年才“退隐”科罗拉多的丛林。现在他正忙于看管他.. << 查看详细
Don Widrig：是一位独立技术作家和顾问。他曾规划并开设了Rational软件公司的“RequisitePro工具培训课程”，直到1997年才“退隐”科罗拉多的丛林。现在他正忙于看管他.. << 查看详细
目录回到顶部↑
序 言
第二版前言
第一版前言
第一部分 引 言
第1章 需求问题
1．1 软件开发的目标
1．2 有关数据
1．3 项目成功和失败的根本原因
1．4 小结
第2章 需求管理简介
2．1 定义
2．2 需求管理技术的应用
2．3 路线图
2．4 小结
第3章 需求和软件生命周期
3．1 传统软件过程模型
3．2 迭代方法
3．3 迭代模型中的需求
3．4 小结
第4章 软件团队
第二版前言
第一版前言
第一部分 引 言
第1章 需求问题
1．1 软件开发的目标
1．2 有关数据
1．3 项目成功和失败的根本原因
1．4 小结
第2章 需求管理简介
2．1 定义
2．2 需求管理技术的应用
2．3 路线图
2．4 小结
第3章 需求和软件生命周期
3．1 传统软件过程模型
3．2 迭代方法
3．3 迭代模型中的需求
3．4 小结
第4章 软件团队
前言回到顶部↑
第二版前言
从1999年本书第一版出版以来发生了很多事情。20世纪90年代后期“dot．com”泡沫经济(部分是由互联网、软件和相关技术引起)的破灭，给许多人的生活带来很大的破坏、经济的不确定和混乱。然而，一个看起来“失去理智”很长时间的自由市场大概已经恢复了有序和稳健。
但是，软件技术的创新却没有衰退，软件业作为一个整体仍然成长迅速。遍及全球的互联网不断改变我们的生活，并驱动多种多样新的通信形式，从方便货物和服务交换的全球电子市场，到似乎占用孩子们过多家庭作业时间的课后即时消息聊天服务，这些服务也似乎占用了昂贵的过去十年大量铺设的互联网带宽。
我们以每周7天、每天24小时的方式与我们的商业合作者、朋友、家人保持联系。互联网网吧一天24小时开放，不管是在澳大利亚、苏格兰，还是在阿拉斯加边界上的巡逻舰上。我们在食品杂货店里自己的PDA上接收电子邮件。如果不和软件打交道，我们就不能做早餐，不能开车上班，不能乘电梯，或者不能进入办公大楼。软件已经成为世界上许多智力和知识的化身，开发和部署软件的业务已经显现为世界上最重要的一种产业。
软件开发的实践还在向前推进。统一建模语言(UML)于1997年被采纳，现在已经成为事实上的表达架构、模式和设计机制的手段。Rational统一过程和类似基于UML的过程被业内许多人采纳作为应对软件开发挑战的标准方式。
我们的个人生活也改变了。在Rational软件公司工作四年后，我最近进入IBM转而帮助独立的软件公司达到他们的目标。有的团队希望改变世界；有的希望通过提高卫生保健来对个人生活产生显著影响；其他人则希望提高其客户的制造效率或希望通过把产品数据翻译成其他语言来帮助业务增长。但是，所有这些团队都有一个共同点：他们都在接受一个困难的挑战，即以一种可以被他们自己、他们的客户、他们的市场团队、他们的内部开发部门和测试团队所理解的方式定义软件解决方案——事实上，所有这些人必须在正确的详细程度上理解所建议的解决方案从而达到恰当的结果。做不到这个他们就完不成使命。由于他们的使命对于他们个人以及其产品要帮助的人们的生活的重要性，所以绝不能失败。
因此，尽管在短短几年内软件业的许多方面都改变了，但有的事情，包括管理软件需求的挑战，仍然大致相同。所以我们的工作在这个第二版中在继续。
关于第二版
改变第二版内容的动机是基于几个不同的但非常集中的因素。
第一组因素是基于本书在市场上的成功，我们得到了很多正面的评价和鼓励以及建设性的批评。评价涉及面很广，其中有两个非常一致的主题：
“更多用例”主题。第一版(副标题为“统一方法”)把有关需求技术的两种主要观点结合起来。第一种，大概是更为传统的一种，描述了如何采用描述性技术(“系统应该……”)来创建和细化需求规格说明，从而指定系统行为。第二种，用例方法，描述了如何使用用例来定义系统的大部分功能性行为。我们在第一版中把这些技术结合到一起，是为了产生一种共同的、希望是更全面的方法。根据得到的反馈，在这一点上我们取得了一些成功。但是对此的批评在于，尽管我们推荐和描述了用例方法，却没有足够深入地帮助读者开发或应用这一技术。而且，为了同时说明这两种技术，我们还使一部分想了解什么时间采用什么技术的读者产生了疑惑。
“这是一本有大多技术的巨著，能否更具有指导性”主题。本书第一版的意图是成为一本更全面的著作，为可能需要为任意类型的系统定义需求的任何技术读者提供“一站式”的参考手册。我们希望这为读者提供了帮助，因为我们坚信，对每个特定软件工程的挑战来说，绝对没有一个“包治百病”的解决方案。而且，读者的主题仍然是：“这真是这样困难吗?你能否更有指导性一些?”
第二组驱动同一种主题的因素来源于我自己为一些公司工作并帮助他们实现软件开发的目标时使用本书的经验。有的公司的软件应用系统需要多种技术；有的公司能够执行相当严格的需求管理制度：而另一些公司需要为特定软件应用系统记录特定的需求，并且在短时间内应用，比如明天。他们没有时间也没有兴趣争论关于什么技术最有效或者技术之间的细微差别，他们说：“给我一种最简单的技术，让我可以立刻开始工作。”
值得庆幸的是，这两组输入非常集中，答案也非常明确。对多数团队来说，在大多数情况下，下面的组合对于管理软件就是足够和适当的了：①一个考虑深入的前景文档；②确定和细化要实现的关键用例；③对于非功能需求的补充规格说明。此外，如果可能成为一种选择的方法的话，细化的用例可以直接成为系统测试的基础。
到此为止，这本书的第二版就有了新的内容、新的主题和新的副标题：“用例方法”。在这一版，用例技术是基本技术，并且我们采用了一种更具指导性的方法和表示。例如，增加了第14章“用例入门”，为理解和应用用例奠定基础。这一章作为一个指南，使一个没有任何知识的读者能够学习并开始应用这一技术。我们对HOLIS个案研究也做了改动，反映出一种更以用例为中心的方法。另外我们还增加了第26章“从用例到测试用例”，来展示用例如何直接派生出完整的测试策略以及用例本身如何直接作为测试用例的输入。
此外，我们还纯粹为了一个想法做了一个实质性的提高。第17章(在第一版中是第18章“负责人”)已经被更名为“产品管理”，内容上也增加了新的材料，目的是帮助团队理解如何把一个软件应用系统变成我们所谓的“整体产品解决方案”。因为需求的“正确”本身不能保证商业的成功，所以这一章为这些活动(如定价、许可证、定位和宣传)以及其他把一个有用的软件应用转变成一个人们想购买的软件产品的商业因素提供洞察和指南。
而且，因为现代软件开发过程的迭代性更强了，所以我们决定把第一版许多章节重新定位于质量。这一版的章节将在现代软件过程这一背景下，对质量进行更全面的观察。因此，第29章“在迭代开发过程中评估需求质量”，直接讨论在整个迭代开发的框架下，获取和提高需求的迭代技术。
最后，我们借机谈到了业界的一种新动态，向所谓的更轻(lighter)的、不太形式化的方法发展。最极端的是Beck等人主张的极限编程(Extreme Programing，XP)，可以解释为完全排除过程。更准确一点，XP合并了某些核心过程，如把客户需求直接放到到编程过程中，但要注意到这里有意回避“软件过程”和“M”(方法论)概念。大概不太极端并被一些人认为更实用的是Cockbum等人倡导并已经扎根的敏捷方法(AgileMethods)。虽然经过几轮争论，但不能忽略这几种轻型方法，我们将在需求这一背景下展开讨论，参见新增加的第30章“敏捷需求方法”。
当然，没有哪本书可以为所有人提供所有需要的信息。为了尽可能使这一版更具可读性，我们删除去了上一版的一些题目和章节，并缩短了某些章节的篇幅。
我们衷心希望这一版更容易理解、更容易使用和应用，从而更有助于你和你的团队管理你们的需求。
从1999年本书第一版出版以来发生了很多事情。20世纪90年代后期“dot．com”泡沫经济(部分是由互联网、软件和相关技术引起)的破灭，给许多人的生活带来很大的破坏、经济的不确定和混乱。然而，一个看起来“失去理智”很长时间的自由市场大概已经恢复了有序和稳健。
但是，软件技术的创新却没有衰退，软件业作为一个整体仍然成长迅速。遍及全球的互联网不断改变我们的生活，并驱动多种多样新的通信形式，从方便货物和服务交换的全球电子市场，到似乎占用孩子们过多家庭作业时间的课后即时消息聊天服务，这些服务也似乎占用了昂贵的过去十年大量铺设的互联网带宽。
我们以每周7天、每天24小时的方式与我们的商业合作者、朋友、家人保持联系。互联网网吧一天24小时开放，不管是在澳大利亚、苏格兰，还是在阿拉斯加边界上的巡逻舰上。我们在食品杂货店里自己的PDA上接收电子邮件。如果不和软件打交道，我们就不能做早餐，不能开车上班，不能乘电梯，或者不能进入办公大楼。软件已经成为世界上许多智力和知识的化身，开发和部署软件的业务已经显现为世界上最重要的一种产业。
软件开发的实践还在向前推进。统一建模语言(UML)于1997年被采纳，现在已经成为事实上的表达架构、模式和设计机制的手段。Rational统一过程和类似基于UML的过程被业内许多人采纳作为应对软件开发挑战的标准方式。
我们的个人生活也改变了。在Rational软件公司工作四年后，我最近进入IBM转而帮助独立的软件公司达到他们的目标。有的团队希望改变世界；有的希望通过提高卫生保健来对个人生活产生显著影响；其他人则希望提高其客户的制造效率或希望通过把产品数据翻译成其他语言来帮助业务增长。但是，所有这些团队都有一个共同点：他们都在接受一个困难的挑战，即以一种可以被他们自己、他们的客户、他们的市场团队、他们的内部开发部门和测试团队所理解的方式定义软件解决方案——事实上，所有这些人必须在正确的详细程度上理解所建议的解决方案从而达到恰当的结果。做不到这个他们就完不成使命。由于他们的使命对于他们个人以及其产品要帮助的人们的生活的重要性，所以绝不能失败。
因此，尽管在短短几年内软件业的许多方面都改变了，但有的事情，包括管理软件需求的挑战，仍然大致相同。所以我们的工作在这个第二版中在继续。
关于第二版
改变第二版内容的动机是基于几个不同的但非常集中的因素。
第一组因素是基于本书在市场上的成功，我们得到了很多正面的评价和鼓励以及建设性的批评。评价涉及面很广，其中有两个非常一致的主题：
“更多用例”主题。第一版(副标题为“统一方法”)把有关需求技术的两种主要观点结合起来。第一种，大概是更为传统的一种，描述了如何采用描述性技术(“系统应该……”)来创建和细化需求规格说明，从而指定系统行为。第二种，用例方法，描述了如何使用用例来定义系统的大部分功能性行为。我们在第一版中把这些技术结合到一起，是为了产生一种共同的、希望是更全面的方法。根据得到的反馈，在这一点上我们取得了一些成功。但是对此的批评在于，尽管我们推荐和描述了用例方法，却没有足够深入地帮助读者开发或应用这一技术。而且，为了同时说明这两种技术，我们还使一部分想了解什么时间采用什么技术的读者产生了疑惑。
“这是一本有大多技术的巨著，能否更具有指导性”主题。本书第一版的意图是成为一本更全面的著作，为可能需要为任意类型的系统定义需求的任何技术读者提供“一站式”的参考手册。我们希望这为读者提供了帮助，因为我们坚信，对每个特定软件工程的挑战来说，绝对没有一个“包治百病”的解决方案。而且，读者的主题仍然是：“这真是这样困难吗?你能否更有指导性一些?”
第二组驱动同一种主题的因素来源于我自己为一些公司工作并帮助他们实现软件开发的目标时使用本书的经验。有的公司的软件应用系统需要多种技术；有的公司能够执行相当严格的需求管理制度：而另一些公司需要为特定软件应用系统记录特定的需求，并且在短时间内应用，比如明天。他们没有时间也没有兴趣争论关于什么技术最有效或者技术之间的细微差别，他们说：“给我一种最简单的技术，让我可以立刻开始工作。”
值得庆幸的是，这两组输入非常集中，答案也非常明确。对多数团队来说，在大多数情况下，下面的组合对于管理软件就是足够和适当的了：①一个考虑深入的前景文档；②确定和细化要实现的关键用例；③对于非功能需求的补充规格说明。此外，如果可能成为一种选择的方法的话，细化的用例可以直接成为系统测试的基础。
到此为止，这本书的第二版就有了新的内容、新的主题和新的副标题：“用例方法”。在这一版，用例技术是基本技术，并且我们采用了一种更具指导性的方法和表示。例如，增加了第14章“用例入门”，为理解和应用用例奠定基础。这一章作为一个指南，使一个没有任何知识的读者能够学习并开始应用这一技术。我们对HOLIS个案研究也做了改动，反映出一种更以用例为中心的方法。另外我们还增加了第26章“从用例到测试用例”，来展示用例如何直接派生出完整的测试策略以及用例本身如何直接作为测试用例的输入。
此外，我们还纯粹为了一个想法做了一个实质性的提高。第17章(在第一版中是第18章“负责人”)已经被更名为“产品管理”，内容上也增加了新的材料，目的是帮助团队理解如何把一个软件应用系统变成我们所谓的“整体产品解决方案”。因为需求的“正确”本身不能保证商业的成功，所以这一章为这些活动(如定价、许可证、定位和宣传)以及其他把一个有用的软件应用转变成一个人们想购买的软件产品的商业因素提供洞察和指南。
而且，因为现代软件开发过程的迭代性更强了，所以我们决定把第一版许多章节重新定位于质量。这一版的章节将在现代软件过程这一背景下，对质量进行更全面的观察。因此，第29章“在迭代开发过程中评估需求质量”，直接讨论在整个迭代开发的框架下，获取和提高需求的迭代技术。
最后，我们借机谈到了业界的一种新动态，向所谓的更轻(lighter)的、不太形式化的方法发展。最极端的是Beck等人主张的极限编程(Extreme Programing，XP)，可以解释为完全排除过程。更准确一点，XP合并了某些核心过程，如把客户需求直接放到到编程过程中，但要注意到这里有意回避“软件过程”和“M”(方法论)概念。大概不太极端并被一些人认为更实用的是Cockbum等人倡导并已经扎根的敏捷方法(AgileMethods)。虽然经过几轮争论，但不能忽略这几种轻型方法，我们将在需求这一背景下展开讨论，参见新增加的第30章“敏捷需求方法”。
当然，没有哪本书可以为所有人提供所有需要的信息。为了尽可能使这一版更具可读性，我们删除去了上一版的一些题目和章节，并缩短了某些章节的篇幅。
我们衷心希望这一版更容易理解、更容易使用和应用，从而更有助于你和你的团队管理你们的需求。
序言回到顶部↑
石头问题
我的一个学生把本书所讨论的问题总结为“石头”问题。她是某研究实验室的软件工程师，她的客户常常会交给她一些项目，她称之为“给我一块石头”。可是当你把石头交给客户时，他们会看着“石头”一会儿，然后说：“是的，但是……实际上我想要的是一块小一点的蓝色石头”。而当你交出一块小一点的蓝色石头时，又会引发“一块圆的小一点的蓝色石头”的要求。
最终的结果可能是，客户一直都在想要一块小一点的蓝色大理石——或者，他也许根本不能确定他到底要什么，一块小小的蓝色大理石——甚至是猫眼大小的蓝色大理石就已经足够满足他的需要了。而他会在你交出第一块(最大的)石头和第三块(蓝色的小)石子之间不断改变他的要求。
开发人员在与客户会谈时总会提这样的问题：“你想要它做什么?”当开发人员按照客户预先的需求，经过艰苦努力终于交出一块大石头却得不到客户的肯定时，总是感到非常沮丧；而客户也同样沮丧，因为即使他可能也发现很难说清白己真正的要求，他还是觉得自己已经讲得很明白，只是开发人员不理解罢了!
大多数实际的项目会涉及更复杂的情况，而不只是涉及到两个人。除了客户和开发人员外——他们当然有不同的头衔和名字——此外还有市场营销人员、测试和质量保证人员、产品经理、总经理，以及一大堆“涉众”(stakeholder)，他们的日常工作将受到所开发的新系统的影响。
这些人都会为如何指定一个大家都能接受的“石头”而头疼，尤其在当今快节奏的充满竞争的商业世界，谁都没有时间争论一个2年期的“石头项目”，并且重头来过。我们必须使它在第一次就是正确的，同时为客户提供一个迭代的过程，在这个过程中使他们最终发现他们真正想要的石头。
对付石头这样有形的物理实体，已经很难了，而现在多数商业机构和政府部门都是“信息密集”型的，即使名义上他们是从事构建和销售“石头”的工作，也很有可能涉及计算机。即便与计算机无关，也有可能需要利用计算机来跟踪它们的电子商务“石头”销售、客户、对手、供应商等等使它在“石头”商务中保持竞争力的信息。而且，对于当今成千上万个业务是开发和销售软件产品的公司来说，其整个业务都集中在使他们的无形和抽象的产品成为他们的客户能购买、评估和应用的有形的石头。
软件系统天生就是无形、抽象、复杂的，并且，至少从理论上说它们是无限可改变的。所以，如果客户对“石头系统”的需求从一开始就是含糊的，并且总认为随着时间的推移，自己能对细节进行澄清、改变和补充的话，那么，开发人员以及所有创建、测试、部署和维护人员很难在零时间内以零耗费完成系统开发。
事实是：当今，有一半以上的软件系统项目超出预算并且推迟进度，有25％-33％的项目在完成之前就被放弃了，并且耗费惊人。
本书的目的是提供一种合理的方法来构造客户真正需要的系统，从而避免以上失败。但是，本书并不是一本有关程序设计的书，它也不仅仅是为软件开发人员写的。这是一本有关管理复杂软件应用系统的需求的书。因此，本书是为软件开发团队的所有成员(包括分析人员、开发人员、测试人员、质量保证人员、项目经理、文档经理以及文档管理人员等等)，还有外部“客户”团队(用户以及其他的涉众，包括市场人员、管理人员)——所有对最终的需求有要求和需要的人而写的。
你会发现，让包括外部团队的非技术成员在内的所有团队成员，都掌握定义和管理需求所需要的技能，是非常关键的。原因很简单，因为是他们首先创建需求并且最终决定系统成功与否。让程序员英雄们孤军奋战是过去那个时代的错误，愿他们安息吧。
一个简单的比喻：盖房
如果你是一位建筑承包商，你一定认为有必要和房主进行一系列详细讨论，否则，你会造一座两居室的房子，而客户要求的却是三居室。但是，与负责建筑条例及地区规划的政府当局讨论和协商这些“需求”同样重要，假如要砍掉建房地皮上的树的话，你还得再和邻居商量一下。
建筑督察员、邻居以及要买房和住房的人都是涉众，他们将最后决定盖好的房子是否符合所有的需求。显然在这个系统中有很多非用户(房主)的重要涉众，如邻居和地区规划的官员，同样，他们对这个系统的看法将会有很大的不同。
再次强调，本书讨论的是软件应用，而不是房子或石头的问题。房子的需求(至少部分)可以用一组草图和工程制图来描述；类似地，也可以用模型和图来描述软件系统。但是，就像房子的草图是工程师和外行人员——包括律师、督察人员、邻居等之间进行协商和交流的手段一样，软件系统的技术图也可以以一种“普通人”能够理解的方式创建出来。
许多关键的重要需求根本不需要用图表示，比如，未来的购房客户可以简单地写道：“我的房子必须有三个卧室，还得有一个能容纳两部汽车和六辆自行车的车库。”在本书中，你也会看到，软件系统的多数重要需求都可以用自然语言来描述。在其他情况下，有一张关于户主想要壁炉的图可能更有用。
为了迎接这一挑战，你需要掌握一些重要的团队技能(team skill)，有些技能可用实用的常识性建议表述。对于一个盖房新手，我们可能会建议他“一定要在挖地基之前，而不是在浇铸水泥并开始修墙和房顶后，和建筑督察人员谈谈”。而对于一个软件项目，我们也会有类似的建议：“务必向正确的人提正确的问题，务必理解系统将如何使用，不要假定100％的需求都是重要的，因为你不可能有时间在最后期限之前把它们全部完成。”
关于本书
在这本书中，Lrgginherll和Widrig采取了一种实用的方法来描述石头问题的解决方案。他们把全书分成八个部分。“引言”部分为后面的章节提供了环境、背景和定义；第1章回顾系统开发这一“挑战”。数据显示有些软件项目的失败是因为编程马虎造成的，但最近大量的研究确切地表明，不良的需求管理可能是项目失败的惟一的最主要原因。在这个序言里我用不严格的、非正式的方式描述了需求管理的基本概念，本书作者将在第2章详细地定义这一概念，从而为后续章节奠定基础。第3章概述了当今使用的一些软件开发模型，并在结论部分推荐了一种推动需求发现的迭代过程。第4章对现代软件团队的特性做了简明介绍，从而把要开发的技能与技能所要应用的团队环境联系起来。
后面的六大部分是为了帮助你和你的团队理解掌握有效需求管理所需要的六大团队技能：
我的一个学生把本书所讨论的问题总结为“石头”问题。她是某研究实验室的软件工程师，她的客户常常会交给她一些项目，她称之为“给我一块石头”。可是当你把石头交给客户时，他们会看着“石头”一会儿，然后说：“是的，但是……实际上我想要的是一块小一点的蓝色石头”。而当你交出一块小一点的蓝色石头时，又会引发“一块圆的小一点的蓝色石头”的要求。
最终的结果可能是，客户一直都在想要一块小一点的蓝色大理石——或者，他也许根本不能确定他到底要什么，一块小小的蓝色大理石——甚至是猫眼大小的蓝色大理石就已经足够满足他的需要了。而他会在你交出第一块(最大的)石头和第三块(蓝色的小)石子之间不断改变他的要求。
开发人员在与客户会谈时总会提这样的问题：“你想要它做什么?”当开发人员按照客户预先的需求，经过艰苦努力终于交出一块大石头却得不到客户的肯定时，总是感到非常沮丧；而客户也同样沮丧，因为即使他可能也发现很难说清白己真正的要求，他还是觉得自己已经讲得很明白，只是开发人员不理解罢了!
大多数实际的项目会涉及更复杂的情况，而不只是涉及到两个人。除了客户和开发人员外——他们当然有不同的头衔和名字——此外还有市场营销人员、测试和质量保证人员、产品经理、总经理，以及一大堆“涉众”(stakeholder)，他们的日常工作将受到所开发的新系统的影响。
这些人都会为如何指定一个大家都能接受的“石头”而头疼，尤其在当今快节奏的充满竞争的商业世界，谁都没有时间争论一个2年期的“石头项目”，并且重头来过。我们必须使它在第一次就是正确的，同时为客户提供一个迭代的过程，在这个过程中使他们最终发现他们真正想要的石头。
对付石头这样有形的物理实体，已经很难了，而现在多数商业机构和政府部门都是“信息密集”型的，即使名义上他们是从事构建和销售“石头”的工作，也很有可能涉及计算机。即便与计算机无关，也有可能需要利用计算机来跟踪它们的电子商务“石头”销售、客户、对手、供应商等等使它在“石头”商务中保持竞争力的信息。而且，对于当今成千上万个业务是开发和销售软件产品的公司来说，其整个业务都集中在使他们的无形和抽象的产品成为他们的客户能购买、评估和应用的有形的石头。
软件系统天生就是无形、抽象、复杂的，并且，至少从理论上说它们是无限可改变的。所以，如果客户对“石头系统”的需求从一开始就是含糊的，并且总认为随着时间的推移，自己能对细节进行澄清、改变和补充的话，那么，开发人员以及所有创建、测试、部署和维护人员很难在零时间内以零耗费完成系统开发。
事实是：当今，有一半以上的软件系统项目超出预算并且推迟进度，有25％-33％的项目在完成之前就被放弃了，并且耗费惊人。
本书的目的是提供一种合理的方法来构造客户真正需要的系统，从而避免以上失败。但是，本书并不是一本有关程序设计的书，它也不仅仅是为软件开发人员写的。这是一本有关管理复杂软件应用系统的需求的书。因此，本书是为软件开发团队的所有成员(包括分析人员、开发人员、测试人员、质量保证人员、项目经理、文档经理以及文档管理人员等等)，还有外部“客户”团队(用户以及其他的涉众，包括市场人员、管理人员)——所有对最终的需求有要求和需要的人而写的。
你会发现，让包括外部团队的非技术成员在内的所有团队成员，都掌握定义和管理需求所需要的技能，是非常关键的。原因很简单，因为是他们首先创建需求并且最终决定系统成功与否。让程序员英雄们孤军奋战是过去那个时代的错误，愿他们安息吧。
一个简单的比喻：盖房
如果你是一位建筑承包商，你一定认为有必要和房主进行一系列详细讨论，否则，你会造一座两居室的房子，而客户要求的却是三居室。但是，与负责建筑条例及地区规划的政府当局讨论和协商这些“需求”同样重要，假如要砍掉建房地皮上的树的话，你还得再和邻居商量一下。
建筑督察员、邻居以及要买房和住房的人都是涉众，他们将最后决定盖好的房子是否符合所有的需求。显然在这个系统中有很多非用户(房主)的重要涉众，如邻居和地区规划的官员，同样，他们对这个系统的看法将会有很大的不同。
再次强调，本书讨论的是软件应用，而不是房子或石头的问题。房子的需求(至少部分)可以用一组草图和工程制图来描述；类似地，也可以用模型和图来描述软件系统。但是，就像房子的草图是工程师和外行人员——包括律师、督察人员、邻居等之间进行协商和交流的手段一样，软件系统的技术图也可以以一种“普通人”能够理解的方式创建出来。
许多关键的重要需求根本不需要用图表示，比如，未来的购房客户可以简单地写道：“我的房子必须有三个卧室，还得有一个能容纳两部汽车和六辆自行车的车库。”在本书中，你也会看到，软件系统的多数重要需求都可以用自然语言来描述。在其他情况下，有一张关于户主想要壁炉的图可能更有用。
为了迎接这一挑战，你需要掌握一些重要的团队技能(team skill)，有些技能可用实用的常识性建议表述。对于一个盖房新手，我们可能会建议他“一定要在挖地基之前，而不是在浇铸水泥并开始修墙和房顶后，和建筑督察人员谈谈”。而对于一个软件项目，我们也会有类似的建议：“务必向正确的人提正确的问题，务必理解系统将如何使用，不要假定100％的需求都是重要的，因为你不可能有时间在最后期限之前把它们全部完成。”
关于本书
在这本书中，Lrgginherll和Widrig采取了一种实用的方法来描述石头问题的解决方案。他们把全书分成八个部分。“引言”部分为后面的章节提供了环境、背景和定义；第1章回顾系统开发这一“挑战”。数据显示有些软件项目的失败是因为编程马虎造成的，但最近大量的研究确切地表明，不良的需求管理可能是项目失败的惟一的最主要原因。在这个序言里我用不严格的、非正式的方式描述了需求管理的基本概念，本书作者将在第2章详细地定义这一概念，从而为后续章节奠定基础。第3章概述了当今使用的一些软件开发模型，并在结论部分推荐了一种推动需求发现的迭代过程。第4章对现代软件团队的特性做了简明介绍，从而把要开发的技能与技能所要应用的团队环境联系起来。
后面的六大部分是为了帮助你和你的团队理解掌握有效需求管理所需要的六大团队技能：
加载中...
