软件需求管理：统一方法 (2009 年度畅销榜NO.2529 )

近年来，需求管理在软件项目中开始占据显著地位并且得到人们的普遍重视，本书可以说是第一本关于需求管理的实用手册。全书语言平实生动，并且采用大量实例和图表，以作者亲历的项目开发为例，全面探讨了软件开发过程中与需求有关的活动。本书是作者对近二十年的软件工程、需求工程、面向对象等领域成熟的思想、方法、技术及实践经验的总结，全书内容围绕着作者认为团队在需求管理中必须掌握的六大重要的团队技能进行组织和展开，这六大技能是：分析问题、理解用户需要、定义系统、管理广度、细化系统定义和构建正确系统。\r\n本书提出了应对软件项目开发中需求管理挑战的全方位解决方案，对于实际的需求管理具有非常强的指导意义和实用价值，本书可作为计算机专业高年级本科生及研究生学习软件需求管理的教材，也可作为软件开发人员开发过程中随时参考的手册。\r\n\r\n
\r\n

\r\n第一部分 引 言\r\n第1章 需求问题 3\r\n1.1 目标 3\r\n1.2 有关数据 3\r\n1.3 项目成功和失败的根本原因 4\r\n1.3.1 需求错误的频率 5\r\n1.3.2 需求错误的高昂代价 6\r\n1.3.3 结论 7\r\n第2章 需求管理简介 9\r\n2.1 定义 9\r\n2.1.1 什么是需求 9\r\n2.1.2 什么是需求管理 9\r\n2.2 需求管理技术的应用 10\r\n2.2.1 软件应用程序的类型 10\r\n2.2.2 系统应用程序 10\r\n2.3 路线图 11\r\n2.3.1 问题领域 11\r\n2.3.2 风险承担人的需要 11\r\n2.3.3 向解决方案领域前进 12\r\n2.3.4 系统的特征 12\r\n2.3.5 软件需求 12\r\n2.3.6 用例介绍 12\r\n2.4 小结 13\r\n第3章 软件团队 14\r\n3.1 把软件开发作为一种团队活动 14\r\n3.1.1 有效需求管理所需要的团队技能 15\r\n3.1.2 团队成员具有不同的技能 15\r\n3.1.3 软件团队的组织 16\r\n3.2 个例研究 16\r\n3.2.1 个例研究的背景 16\r\n3.2.2 HOLIS软件开发团队 17\r\n3.3 小结 17\r\n第二部分 团队技能之一—分析问题\r\n第4章 问题分析的五个步骤 21\r\n4.1 第一步：在问题定义上达成共识 22\r\n4.2 第二步：理解根本理由—\r\n问题背后的问题 23\r\n4.3 第三步：确定风险承担人和用户 25\r\n4.4 第四步：定义解决方案系统的界限 26\r\n4.5 第五步：确定加在解决方案上的约束 27\r\n4.6 小结 29\r\n4.7 展望 29\r\n第5章 商业建模 31\r\n5.1 商业建模的目的 31\r\n5.2 利用软件工程技术进行商业建模 32\r\n5.2.1 选择正确的技术 32\r\n5.2.2 统一建模语言UML 32\r\n5.2.3 利用UML的概念进行商业建模 33\r\n5.3 从商业模型到系统模型 34\r\n5.4 何时使用商业建模 35\r\n5.5 小结 35\r\n5.6 展望 35\r\n第6章 软件密集型系统的系统工程 36\r\n6.1 什么是系统工程 36\r\n6.1.1 系统工程的实用准则 37\r\n6.1.2 复杂系统的组合和分解 37\r\n6.2 系统工程中的需求分配 38\r\n6.2.1 关于派生的需求 39\r\n6.2.2 无声的演化 39\r\n6.2.3 冲突何时产生：资深系统工程师碰上年轻程序员 40\r\n6.2.4 避免“烟囱”系统问题 41\r\n6.2.5 当子系统是转包合同时 41\r\n6.2.6 使系统正确实现 41\r\n6.3 个例研究 42\r\n6.3.1 基本用户需要 42\r\n6.3.2 问题分析 43\r\n6.3.3 HOLIS：系统. 参与者和\r\n风险承担人 44\r\n6.3.4 HOLIS系统工程 45\r\n6.3.5 HOLIS子系统 46\r\n团队技能之一小结 47\r\n第三部分 团队技能之二\r\n—理解用户的需要\r\n第7章 需求启发的挑战 51\r\n7.1 启发的障碍 51\r\n7.1.1 “是的, 但是”综合症 51\r\n7.1.2 “尚未发现的遗址”综合症 52\r\n7.1.3 “用户和开发人员”综合症 52\r\n7.2 需求启发的技术 53\r\n第8章 产品或系统的特征 54\r\n8.1 风险承担人和用户的需要 54\r\n8.2 特征 54\r\n8.2.1 通过对抽象级别的选择来管理复杂度 56\r\n8.2.2 产品特征的属性 56\r\n第9章 面谈 58\r\n9.1 面谈的背景 58\r\n9.2 增值背景 59\r\n9.3 真实的时刻：面谈 61\r\n9.4 编辑需要数据 62\r\n9.4.1 分析人员的总结：10＋10＋10≠30 62\r\n9.4.2 个例研究 62\r\n9.5 对问卷调查的注解 63\r\n第10章 需求专题讨论会 65\r\n10.1 加速决策过程 65\r\n10.2 专题讨论会的准备 65\r\n10.2.1 推销概念 66\r\n10.2.2 确保真正的风险承担人的参与 66\r\n10.2.3 后勤保障 66\r\n10.2.4 “热身材料” 66\r\n10.3 联络员的作用 68\r\n10.4 安排日程 68\r\n10.5 举行专题讨论会 69\r\n10.5.1 折衷的问题与技巧 69\r\n10.5.2 自由讨论和意见精简 70\r\n10.5.3 成果和监督执行 71\r\n第11章 自由讨论和意见精简 72\r\n11.1 现场自由讨论 72\r\n11.2 意见精简 74\r\n11.2.1 修剪 74\r\n11.2.2 把意见归类 74\r\n11.2.3 特征定义 75\r\n11.2.4 确定优先次序 75\r\n11.3 基于万维网的自由讨论 76\r\n11.4 个例研究：HOLIS 2000需求\r\n专题讨论会 77\r\n11.4.1 参加人员 77\r\n11.4.2 专题讨论会 77\r\n11.4.3 会议 77\r\n11.5 结果分析 79\r\n第12章 情节串联板制作 80\r\n12.1 情节串联板的类型 80\r\n12.2 情节串联板做什么 81\r\n12.3 情节串联板制作的工具和技术 82\r\n12.4 情节串联板制作的几点提示 82\r\n12.5 小结 83\r\n第13章 应用用例 86\r\n13.1 构建用例模型 86\r\n13.2 应用用例启发需求 87\r\n13.3 个例研究：HOLIS的用例 88\r\n13.4 小结 89\r\n第14章 角色扮演 90\r\n14.1 如何扮演角色 90\r\n14.2 与角色扮演类似的技术 91\r\n14.2.1 脚本预演 91\r\n14.2.2 CRC卡 91\r\n14.3 小结 92\r\n第15章 原型开发 93\r\n15.1 原型的类型 93\r\n15.2 需求原型 93\r\n15.3 原型的对象 95\r\n15.4 构建原型 95\r\n15.5 评估结果 95\r\n15.6 小结 96\r\n团队技能之二小结 96\r\n第四部分 团队技能之三—定义系统\r\n第16章 组织需求信息 99\r\n16.1 组织复杂硬件系统和软件系统的需求 100\r\n16.2 组织产品系列的需求 102\r\n16.3 关于“未来”需求 102\r\n16.4 商业和市场需求与产品需求的比较 103\r\n16.5 个例研究 103\r\n16.6 小结 104\r\n第17章 前景文档 105\r\n17.1 前景文档的组件 105\r\n17.2 “d前景”文档 107\r\n17.2.1 1.0版本的前景文档 108\r\n17.2.2 2.0版本的前景文档 108\r\n17.3 遗留系统环境中的d前景文档 110\r\n第18章 负责人 111\r\n18.1 产品负责人的作用 111\r\n18.2 软件产品环境中的产品负责人 112\r\n18.3 IS/IT商店里的产品负责人 113\r\n团队技能之三小结 114\r\n第五部分 团队技能之四—管理广度\r\n第19章 项目广度问题 117\r\n19.1 项目广度的组件 117\r\n19.2 难题 119\r\n第20章 建立项目广度 120\r\n20.1 需求基线 120\r\n20.2 设定优先级 121\r\n20.3 评估工作量 121\r\n20.4 加入风险因素 122\r\n20.5 缩小广度 123\r\n20.6 个例研究 125\r\n第21章 管理客户 128\r\n21.1 促使客户管理他们的项目广度 128\r\n21.2 交流结果 128\r\n21.3 与客户协商 128\r\n21.4 管理基线 129\r\n21.4.1 正式变更 130\r\n21.4.2 非正式变更 130\r\n第22章 广度管理和软件开发过程模型 131\r\n22.1 瀑布模型 131\r\n22.2 螺旋模型 133\r\n22.3 迭代方法 134\r\n22.3.1 生命周期阶段 135\r\n22.3.2 迭代 135\r\n22.3.3 工作流程 136\r\n22.4 做什么, 做什么…… 137\r\n团队技能之四小结 137\r\n第六部分 团队技能之五—细化系统定义\r\n第23章 软件需求 141\r\n23.1 软件需求的定义 142\r\n23.2 特征和软件需求之间的关系 143\r\n23.3 需求的两难问题：做什么与如何做 143\r\n23.3.1 排除项目信息 144\r\n23.3.2 排除设计信息 144\r\n23.4 更多有关需求与设计的讨论 145\r\n23.5 需求的其他特性 146\r\n23.5.1 功能性软件需求 147\r\n23.5.2 非功能性软件需求 147\r\n23.5.3 设计约束 150\r\n23.5.4 设计约束是真正的需求吗 151\r\n23.6 采用父-子需求提高确切性 152\r\n23.7 展望 153\r\n第24章 细化用例 154\r\n24.1 要问的问题 154\r\n24.1.1 什么时候应该采用用例方法 154\r\n24.1.2 什么时候用例不是最佳选择 154\r\n24.1.3 冗余问题 155\r\n24.2 细化用例的规格说明 155\r\n24.2.1 用例是如何演变的 156\r\n24.2.2 用例的广度 157\r\n24.3 个例研究：一个简单用例的解剖 157\r\n24.3.1 定义参与者 157\r\n24.3.2 通过命名用例来定义用例 157\r\n24.3.3 写一个简明的描述 158\r\n24.3.4 定义事件流程 158\r\n24.3.5 确定前置条件和后置条件 159\r\n24.4 展望 160\r\n第25章 现代软件需求规格说明 161\r\n25.1 现代SRS包 161\r\n25.1.1 现代SRS包归谁所有 163\r\n25.1.2 组织现代SRS包 163\r\n25.2 为功能性需求建档 165\r\n25.3 展望 166\r\n第26章 歧义性和确切性 167\r\n26.1 找到“最佳击球点” 167\r\n26.2 玛丽有只小羊羔 169\r\n26.3 消除歧义的技术 170\r\n26.4 做什么 171\r\n第27章 软件需求的质量度量 172\r\n27.1 九个质量度量 172\r\n27.1.1 正确的需求 172\r\n27.1.2 无歧义的需求 173\r\n27.1.3 需求集的完备性 173\r\n27.1.4 需求集的一致性 175\r\n27.1.5 根据重要性和稳定性给需求分级 175\r\n27.1.6 可验证的需求 176\r\n27.1.7 可修改的需求集 177\r\n27.1.8 可跟踪的需求 177\r\n27.1.9 可理解的需求 178\r\n27.2 用例模型的质量度量 178\r\n27.2.1 用例规格说明 178\r\n27.2.2 用例的参与者 179\r\n27.3 现代SRS包的质量度量 180\r\n27.3.1 好的目录 180\r\n27.3.2 好的索引 180\r\n27.3.3 修正记录 181\r\n27.3.4 词汇表 181\r\n第28章 说明需求的技术性方法 182\r\n28.1 说明需求的技术性方法 182\r\n28.1.1 伪代码 182\r\n28.1.2 有限状态机 183\r\n28.1.3 决策树和决策表 184\r\n28.1.4 图形决策树 185\r\n28.1.5 活动图 185\r\n28.1.6 实体联系模型 186\r\n28.1.7 面向对象建模 187\r\n28.1.8 数据流图 188\r\n28.2 规格说明的维护 189\r\n28.3 个例研究 189\r\n团队技能之五小结 189\r\n第七部分 团队技能之六—构建正确系统\r\n第29章 正确地构建正确系统：概述 193\r\n29.1 不断证实开发沿着正确的方向 193\r\n29.1.1 软件验证的原则 193\r\n29.1.2 验证的耗费 194\r\n29.1.3 在所有层次上进行验证 194\r\n29.1.4 验证的原因 195\r\n29.2 证实开发结果是正确的 195\r\n29.3 学习处理开发过程中出现的变更 196\r\n29.4 展望 196\r\n第30章 从需求到实现 197\r\n30.1 把需求映射到设计和代码 197\r\n30.1.1 不相关问题 197\r\n30.1.2 面向对象 198\r\n30.1.3 把用例作为需求 199\r\n30.1.4 管理过渡 199\r\n30.1.5 软件系统建模 199\r\n30.1.6 用例模型在体系结构中的作用 201\r\n30.2 在设计模型中实现用例 201\r\n30.2.1 协作的结构方面和行为方面 202\r\n30.2.2 利用协作实现个体需求集 203\r\n30.3 从设计到实现 203\r\n30.4 小结 204\r\n30.5 展望 204\r\n第31章 利用可跟踪性支持验证 205\r\n31.1 需求验证中可跟踪性的作用 205\r\n31.1.1 隐式跟踪与显式跟踪 206\r\n31.1.2 其他要考虑的可跟踪选项 207\r\n31.2 使用跟踪工具 207\r\n31.3 在没有跟踪工具条件下进行 210\r\n31.3.1 被忽略的验证关系 211\r\n31.3.2 过度的验证关系 211\r\n31.4 有关验证和可跟踪性的思考 213\r\n31.5 展望 213\r\n第32章 确认系统 214\r\n32.1 确认 214\r\n32.1.1 验收测试 214\r\n32.1.2 确认测试 215\r\n32.1.3 确认跟踪 215\r\n32.1.4 基于需求的测试 216\r\n32.2 个例研究：测试用例 216\r\n32.2.1 测试实例1描述 216\r\n32.2.2 跟踪测试实例 217\r\n32.3 测试离散需求 217\r\n32.3.1 被忽略的确认关系 218\r\n32.3.2 过度的确认关系 219\r\n32.4 测试设计约束 220\r\n32.5 展望 220\r\n第33章 利用投资收益决定V&V工作量 221\r\n33.1 深度与覆盖 221\r\n33.1.1 V&V深度 221\r\n33.1.2 V&V覆盖 222\r\n33.2 验证和确认什么 222\r\n33.2.1 第1种选择：验证和确认一切 222\r\n33.2.2 第2种选择：利用冒险分析来\r\n决定V&V的必要性 223\r\n33.2.3 把冒险分析作为投资收益 224\r\n33.3 展望 224\r\n第34章 管理变更 225\r\n34.1 为什么需求会变更 225\r\n34.2 外部因素 225\r\n34.3 内部因素 226\r\n34.4 “我们已经遇到了敌人, 而且敌人\r\n就是我们自己” 226\r\n34.5 管理变更的过程 227\r\n34.5.1 第1步：认识到变更是不可避免的并为\r\n变更制定计划 227\r\n34.5.2 第2步：确定需求的基线 228\r\n34.5.3 第3步：建立控制变更的惟一渠道 228\r\n34.5.4 第4步：使用变更控制系统来\r\n捕获变更 229\r\n34.5.5 第5步：分层次地管理变更 231\r\n34.6 需求配置管理 231\r\n34.6.1 基于工具的变更管理 233\r\n34.6.2 变更所影响的元素 234\r\n34.6.3 变更记录的审计追踪 235\r\n34.6.4 配置管理和变更管理 235\r\n34.7 小结 235\r\n团队技能之六小结 236\r\n第八部分 开 始\r\n第35章 开始 240\r\n35.1 致词 240\r\n35.2 已经学到的主要内容 240\r\n35.2.1 引言 240\r\n35.2.2 团队技能之一：分析问题 241\r\n35.2.3 团队技能之二：理解用户的需要 241\r\n35.2.4 团队技能之三：定义系统 242\r\n35.2.5 团队技能之四：管理广度 242\r\n35.2.6 团队技能之五：细化系统定义 243\r\n35.2.7 团队技能之六：构建正确系统 243\r\n35.3 需求管理的方案 244\r\n35.3.1 简化的假设 244\r\n35.3.2 方案 244\r\n35.4 现在开始下一个版本 246\r\n附 录\r\n附录A HOLIS制品 248\r\n附录B 前景文档模板 272\r\n附录C 现代SRS包模板 279\r\n附录D SEI-CMM和ISO 9000\r\n中的需求管理 285\r\n附录E Rational统一过程中的需求管理 290\r\n参考文献 299\r\n索引 \r\n
\r\n

近年来, 需求工程逐渐成为软件工程的一个重要而活跃的领域, 需求管理在软件项目开发中开始占据显著地位并且得到人们的普遍重视. 国际上有关需求工程的研究与论著方兴未艾, 而本书可以说是第一本关于需求管理的实用手册. 全书语言平实生动, 采用大量实例和图表, 以作者亲历的项目开发为例, 全面探讨了软件开发过程中与需求有关的活动, 涉及大量实用技术, 本书是作者对近二十年来软件工程. 需求工程. 面向对象等领域内成熟的思想. 方法. 技术及实践经验的重要而有益的总结.
本书一个最重要的思想是, 在需求管理中强调团队的作用, 提出“高效的需求管理只能通过一支高效的软件团队来实现”. 在此基础上, 全书内容围绕着作者认为团队在需求管理中必须掌握的六个最重要的团队技能进行组织和展开. 管理需求的这六大团队技能分别是：分析问题. 理解用户需要. 定义系统. 管理广度. 细化系统定义和构建正确系统.
全书内容丰富. 详实. 实用, 把需求管理的活动渗透到软件项目生命周期的全过程. 在对多种方法和技术的讨论中, 注重在需求管理的背景下讨论团队实施的方法. 技巧以及实施时要注意的问题. 同时, 书中还提供了大量经过证明十分有效的文档模板和实用技巧, 这足以体现出作者在需求管理和项目开发方面具有丰富的实践经验和深厚的功底.
本书提出了应对软件项目开发中需求管理挑战的全方位解决方案, 对于实际的需求管理具有非常强的指导意义和实用价值, 本书可以作为软件开发人员在开发过程中随时参考的手册, 同时也是全体项目团队成员必读的一本书.
本书由蒋慧. 林东主译, 孙泉. 蒋蓓和赵承参与翻译了第3章到第18章的内容, 全书由蒋慧统稿.
由于时间仓促, 译者水平有限, 书中翻译的错误和不妥之处在所难免, 欢迎读者多多批评指正.


译者于北京
2001年8月

环境和感谢
本书所传达的知识代表了一群优秀的业内人士所积累的宝贵经验, 他们曾经定义. 开发和交付了许多世界一流的软件系统. 本书并不是关于需求工程的学术讨论. 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