软件需求 (2008 年度畅销榜NO.11589 )

多数IT系统的失败都与需求不明确有关。本书专门讨论如何更快、更准确地编写软件需求。本书以面向实践、案例教学的方式，介绍了当前需求工程的各项技术。本书面向软件供应链牵涉到的所有人员，分析人员、开发人员到最终用户都将从中学习到新技术，并从其他专家所编写的需求中得到启发。软件供应商将学习到如何协助客户和如何编写有竞争力的建议书 ；程序员及其他开发人员将学习到如何陈述需求而又不涉及到过多的技术细节，了解如何降低系统开发的风险；IT专业的学生将学习到需求工程的理论和实践经验，并为个案研究以及项目开发打下坚实的基础。 \r\n
\r\n

第1章 导言及基本概念 1 \r\n\r\n 1.1 需求所承担的任务 2 \r\n\r\n 1.2 项目类型 5 \r\n\r\n 1.3 规格说明的内容 7 \r\n\r\n 1.4 实践中的常见问题 10 \r\n\r\n 1.5 域层及产品层 11 \r\n\r\n 1.6 需求的不同层次 13 \r\n\r\n 1.7 典型的项目模型 18 \r\n\r\n 1.7.1 传统的方法：产品层的需求 19 \r\n\r\n 1.7.2 快捷法：域层的需求 21 \r\n\r\n 1.7.3 两步法：域层需求加设计层需求 22 \r\n\r\n 1.7.4 合同及价格结构 22 \r\n\r\n 第2章 数据需求的形式 25 \r\n\r\n 2.1 酒店系统实例 25 \r\n\r\n 2.2 数据模型 26 \r\n\r\n 2.3 数据词典 34 \r\n\r\n 2.4 数据表达式 37 \r\n\r\n 2.5 虚拟窗口 40 \r\n\r\n 第3章 功能需求的形式 44 \r\n\r\n 3.1 人. 机职责划分 44 \r\n\r\n 3.2 上下文图 45 \r\n\r\n 3.3 事件列表与功能列表 47 \r\n\r\n 3.4 特性需求 50 \r\n\r\n 3.5 屏幕显示及原型 52 \r\n\r\n 3.6 任务说明 55 \r\n\r\n 3.7 由任务说明到产品特性 61 \r\n\r\n 3.8 任务及支持 62 \r\n\r\n 3.9 场景说明 69 \r\n\r\n 3.10 恰当的任务 71 \r\n\r\n 3.11 高层任务 74 \r\n\r\n 3.12 用例 75 \r\n\r\n 3.12.1 用例图 76 \r\n\r\n 3.12.2 人. 机分工 77 \r\n\r\n 3.12.3 基本用例 78 \r\n\r\n 3.12.4 以计算机为中心的用例 79 \r\n\r\n 3.12.5 详细的产品活动 79 \r\n\r\n 3.13 带数据的任务 80 \r\n\r\n 3.14 数据流图 82 \r\n\r\n 3.14.1 数据流－域模型 84 \r\n\r\n 3.14.2 域模型, 第二层 85 \r\n\r\n 3.14.3 人. 机工作划分 85 \r\n\r\n 3.14.4 数据流－产品层 87 \r\n\r\n 3.15 标准作为需求 88 \r\n\r\n 3.16 开发过程作为需求 90 \r\n\r\n 第4章 功能细节 93 \r\n\r\n 4.1 复杂功能与简单功能 93 \r\n\r\n 4.2 表格及决策表 96 \r\n\r\n 4.3 文字过程说明 99 \r\n\r\n 4.4 状态图 101 \r\n\r\n 4.5 状态转移矩阵 103 \r\n\r\n 4.6 活动图 104 \r\n\r\n 4.7 类图 108 \r\n\r\n 4.8 协作图 113 \r\n\r\n 4.9 顺序图. 事件与消息 114 \r\n\r\n 第5章 特殊接口——需求的组合形式 118 \r\n\r\n 5.1 报表 118 \r\n\r\n 5.2 平台需求 120 \r\n\r\n 5.3 产品集成——非技术客户 121 \r\n\r\n 5.4 产品集成——主承包商 126 \r\n\r\n 5.5 技术接口 127 \r\n\r\n 第6章 质量需求 130 \r\n\r\n 6.1 质量因素 130 \r\n\r\n 6.2 质量因素表 133 \r\n\r\n 6.3 开放尺度与开放目标 135 \r\n\r\n 6.4 能力及准确度需求 138 \r\n\r\n 6.5 性能需求 140 \r\n\r\n 6.6 可用性 146 \r\n\r\n 6.6.1 可用性问题 147 \r\n\r\n 6.6.2 可用性测试 148 \r\n\r\n 6.6.3 启发式评价 150 \r\n\r\n 6.6.4 缺陷更正 150 \r\n\r\n 6.6.5 可用性因素 151 \r\n\r\n 6.7 可用性需求 152 \r\n\r\n 6.8 安全性 156 \r\n\r\n 6.8.1 威胁 157 \r\n\r\n 6.8.2 安全性风险评估 158 \r\n\r\n 6.8.3 威胁及防卫措施 159 \r\n\r\n 6.9 安全性需求 162 \r\n\r\n 6.10 维护 164 \r\n\r\n 6.11 可维护性需求 166 \r\n\r\n 第7章 需求与产品生命期 171 \r\n\r\n 7.1 项目驱动 173 \r\n\r\n 7.2 合同 173 \r\n\r\n 7.3 比较建议书 175 \r\n\r\n 7.4 需求的评分 178 \r\n\r\n 7.5 编写建议书 181 \r\n\r\n 7.6 设计与编程 184 \r\n\r\n 7.7 验收测试与交付 186 \r\n\r\n 7.8 需求管理 188 \r\n\r\n 7.9 版本规划 189 \r\n\r\n 7.10 追踪与工具支持 191 \r\n\r\n 第8章 需求的导出 193 \r\n\r\n 8.1 导出的问题 193 \r\n\r\n 8.1.1 导出的障碍 193 \r\n\r\n 8.1.2 中间工作成果 195 \r\n\r\n 8.1.3 用户参与 195 \r\n\r\n 8.2 导出技术调查 196 \r\n\r\n 8.2.1 相关人员分析 197 \r\n\r\n 8.2.2 访谈 197 \r\n\r\n 8.2.3 观察 198 \r\n\r\n 8.2.4 任务示范 198 \r\n\r\n 8.2.5 文档研究 199 \r\n\r\n 8.2.6 问卷调查 199 \r\n\r\n 8.2.7 集策讨论会 199 \r\n\r\n 8.2.8 重点问题讨论会 199 \r\n\r\n 8.2.9 域专题讨论会 200 \r\n\r\n 8.2.10 设计专题讨论会 200 \r\n\r\n 8.2.11 原型设计 200 \r\n\r\n 8.2.12 小规模试验 201 \r\n\r\n 8.2.13 研究类似公司 201 \r\n\r\n 8.2.14 询问供应商 201 \r\n\r\n 8.2.15 协商 202 \r\n\r\n 8.2.16 风险分析 202 \r\n\r\n 8.2.17 成本/效益分析 202 \r\n\r\n 8.2.18 目标－域分析 203 \r\n\r\n 8.2.19 域－需求分析 203 \r\n\r\n 8.3 相关人员 203 \r\n\r\n 8.4 重点问题讨论会 204 \r\n\r\n 8.5 业务目标 206 \r\n\r\n 8.6 成本/效益 209 \r\n\r\n 8.7 目标-域追踪 212 \r\n\r\n 8.7.1 质量功能部署 214 \r\n\r\n 8.8 域-需求追踪 216 \r\n\r\n 第9章 检查与确认 218 \r\n\r\n 9.1 规格说明的质量标准 219 \r\n\r\n 9.2 检查规格说明 222 \r\n\r\n 9.2.1 内容检查 222 \r\n\r\n 9.2.2 结构检查 224 \r\n\r\n 9.2.3 一致性检查与CRUD 225 \r\n\r\n 9.3 对照环境的检查 227 \r\n\r\n 9.3.1 审查 227 \r\n\r\n 9.3.2 测试 229 \r\n\r\n 9.4 核查表 229 \r\n\r\n 第10章 实战技术 233 \r\n\r\n 10.1 观察 233 \r\n\r\n 10.2 专门小组 234 \r\n\r\n 10.3 解决冲突 237 \r\n\r\n 10.4 目标-需求分析 238 \r\n\r\n 10.5 可用性测试 243 \r\n\r\n 10.6 击键层模型 246 \r\n\r\n 10.7 任务及支持技术 247 \r\n\r\n 第11章 丹麦船厂业务管理系统——合同及需求 254 \r\n\r\n 第12章 Midland医院工资管理及勤务规划系统需求 292 \r\n\r\n 第13章 West Zealand医院勤务规划系统需求——任务及支持技术 305 \r\n\r\n 第14章 Bruel & Kjaer噪声源定位系统需求 310 \r\n\r\n 第15章 纳税人联合会会员管理系统需求 317 \r\n\r\n 第16章 练习 325 \r\n\r\n 16.1 个案研究：期刊传阅 325 \r\n\r\n 16.2 个案研究：自动售票机 326 \r\n\r\n 16.3 个案研究：E-mail系统 326 \r\n\r\n 16.4 个案研究：项目管理 327 \r\n\r\n 16.5 个案研究：教育管理 327 \r\n\r\n 参考文献 338 \r\n
\r\n

随着计算机技术的发展, 软件规模已日益庞大, 软件开发也日益复杂. 随之而来的问题却是：许多IT系统都无法实现期望, 它们要么无法实现业务目标, 要么无法有效支持用户任务, 要么成本很难控制在预算之内. 究其根由, 相当多的软件失败是因需求不明白. 不确定而致. 自1991年J. Martin提出“需求工程”概念后, 需求开始成为软件工程的一项重要子过程. 软件需求的重要性在不断提高, 因为它是用户赖以预先知道将以什么样的成本获得什么样产品的途径.

目前, 软件需求领域的研究方兴未艾, 各种论著如雨后春笋, 大体都论述了六个方面：需求过程. 需求导引. 分析. 规范说明. 需求确认和需求管理. 然而, IT应用范围广. 编程背景多样（基于过程. 面向对象. 基于构件）, 致使从业者还是很难获得明确指导, 尤其是缺乏可作为需求规范的实践样本.

本书作者Soren Lauesen是哥本哈根信息技术大学的软件工程学教授, 他在人-机交互. 需求工程. 面向对象设计. 质量保证. 项目开发等方面有很深的造诣. 他集30多年软件开发. 管理和教学. 研究的经验, 编写了本书. 本书立足于软件开发实践, 探讨了编写软件需求的各种方法. 技术. 本书注重实用, 力图为从业者提供具体. 明确的指导, 例如：



● 在需求规格说明中应写些什么, 哪些技术可行, 哪些技术不可行

● 如何满足用户需要而又避免过于细致地陈述需求

● 如何在完整性以及可理解性之间取得平衡

● 如何在应用域以及计算机内部工作之间做权衡描述

● 如何降低客户及供应商双方的风险

● 如何编写可确认及可验证的需求

● 如何编写低成本的需求规格说明

● 如何保证需求正确反映了客户的业务目标

● 如何陈述关于质量因素（如可用性. 可维护性）的需求

● 如何提出具有竞争力的建议书



书中例子都选自真实问题, 包括两份完整的规格说明. 此外, 本书也从技术角度对需求工程中常遇到的“两难”问题做了透彻分析, 指出在实践中应如何灵活使用不同的需求技术, 从而得到相对精确的需求, 以提高软件质量. 降低开发成本. 缩短开发时间.

目前, 需求工程已不仅仅是专家们的任务, 而是许多人员, 包括用户. 客户. 供应商和程序员都参与的过程. 专家用户. 分析员. 设计人员. 项目经理和业务经理. 市场人员都在这一过程中承担自己的角色, 并相互配合, 所以本书对于软件开发和供应链中的所有相关人员都是有益的, 而且非常重要.

本书由麦中凡教授组织翻译, 敦请有多年软件开发经验. 目前定居新加坡的刘晓晖先生具体进行翻译. 在初步成书后, 由麦中凡教授对全书各部分做了仔细校订和修改. 最后由吕庆中博士再次审校. 译书力求既忠于原文, 又适于国内业者阅读. 张景. 胡斌. 程勇. 李烨为校对和编排打印付出了大量劳动. 夏小丹. 刘梅彦. 张航. 邓向明在成书过程中积极参与讨论校订, 验证代码的工作, 共同的感觉是参与本书工作后获益匪浅. 由于本书内容较新, 少量术语. 行规译法国内尚不统一, 不确之处欢迎指正. 我们的通信地址是：liuxh666@sina.com, mids@buaa.edu.cn.

你是否使用过一个新的软件, 却发现它达不到你的期望？如果是的话, 那也许是因为没有人准确地描述了这些期望的缘故. 软件需求工程, 是讲述如何使用正确的方法制定正确的需求.

现在, 有许多人员都在参与编写软件需求的工作, 这已不仅仅是专家们的任务, 许多用户. 客户. 供应商和程序员都参与其中. 在一些小公司, 我们甚至看到一些没有受过专门训练的员工, 也在为新的软件产品编写需求. 此外, 专家用户. 分析员. 设计人员以及程序员的任务, 已经越来越相互结合. 本书对于参与编写软件需求的各类人员都是有帮助的. 重要的.



分析员 作为需求工程师或开发顾问, 将在本书中学到各种技巧, 并将能够阅读其他专家编写的需求.

客户 将学到确保新产品实现业务目标的各种方法, 本书也提出了一些关于合同及招标处理方面的建议.

软件供应商 将学习到如何协助客户以及如何编写具有竞争力的建议书.

用户 将学习到如何与专家或开发人员协同工作, 你也将学会如何描述工作任务. 本书为用户提供了需求样本, 并对必要以及不必要的需求内容做了说明.

程序员及其他开发人员 将学习到如何描述需求而又不涉及具体的技术细节, 以及如何降低系统开发的风险.

IT学生 将学习到需求工程的理论和实践经验, 并为个案研究以及项目开发打下坚实的基础.

无须通读全书 本书为不同的读者提供了丰富的内容, 在学习完第一章之后, 就可以根据自己的需要, 选择阅读本书的某些章节.

背景

当我在1962年步入软件行业时, 软件需求相对来说并不重要, 因为当时硬件相当昂贵, 而软件却相对便宜. 租用计算机一小时的费用, 可以雇用一个员工工作30个小时, 而且当时的计算机比现在要慢5 000倍.

当时的软件开发往往是基于工时及材料的, 也只是作为重要任务（如开发更好的硬件）的一小部分. 用户不断付费——直到获得了能够输出结果的软件, 而且使用这些结果也需要费一番功夫. 当时, 没有人考虑到软件的可用性. 与计算机有关的工作, 都属于专家们的事情.

现在的情况已经完全不同了. 硬件便宜了, 而软件开发却是昂贵的, 而且很难控制在预算之内——尤其是要实现用户的期望. 正因为如此, 软件需求的重要性在不断提高, 因为它是用户赖以预先知道将花多少费用, 获得什么样产品的途径.

但是, 软件需求还是一个相当模糊的概念. 尽管有一些参考书籍, 但从业者还是很难获得应有的指导. 一个特别关键的问题就是缺乏可以作为需求规范的实例.

本书借助于软件开发实例, 探讨了在实践中说明软件需求的各种方法. 本书着重于解决实际问题, 包括：

● 分析员在实际的规格说明中应写些什么, 哪些方法可行, 哪些方法不可行.

● 如何满足用户的需要而又避免过细地说明需求.

● 如何在完整性以及可理解性之间取得平衡.

● 如何在应用领域以及计算机内部工作之间做权衡描述.

● 如何降低客户. 供应商双方的风险.

● 如何编写可以确认及验证的需求.

● 如何编写低成本的需求规格说明.



从事软件行业期间, 我先后做过程序员. 项目经理. 部门经理和质量管理经理. 我热爱编程, 并在程序开发过程的关键阶段承担过关键性任务. 我们开发了许多项目, 从商业应用. 科学应用. 过程控制系统到编译器. 操作系统以及分布数据库等.

我从20世纪70年代中期起成为开发人员, 我们的开发组需要编写软件需求, 但总感觉到难于确定要写的内容, 是该写软件要求还是设计说明？我们意识到软件需求是重要的, 但是对如何撰写又感到茫然, 而且, 尽管有一些公司的章程和指导准则告诉我们应该写些什么, 但是在我们这样一个跨国公司里竟没有人能够提供一个好的软件需求样本.

20世纪80年代中期, 我成为哥本哈根商学院全职的软件工程学教授. 抛开了那种编写代码和发布新产品的持续压力, 我得以有时间从其他角度——使用者的角度和客户的角度, 来研究软件产业.

在很长一段时间里, 我在研究人机交互, 并提出了开发有效用户界面的系统方法——这也正是用户分析与制作好的产品原型之间所缺少的环节. 令人遗憾的是, 当时的业界并不重视这个问题（现在Web的出现已经改变了这种观念）.

20世纪90年代初, 我决定改变研究方向. 我询问业内人士开发中最困难的问题是什么, 所得到的回答都是：“需求以及开发的前期工作. ”于是我对需求产生了兴趣.

我拜访了我的导师——纽约大学的Jon Turner. 我说：“Jon, 我想做一些关于软件需求的研究. ”他看了看我, 迟疑了几秒钟之后说道：“不要做. ”“为什么？”我问. 他回答说：“在这方面很难有所突破, 而且研究者过去所做的与企业界所需要的相去甚远. ”Alan M. Davis 在1992年也下过相同的结论.

这对我来说是一个很大的挑战. 首先, 在我想获得他人编写的软件需求时, 遇到了很大的困难. 我同许多公司的开发人员谈过, 我问：“你们编写软件需求吗？”回答通常是肯定的. 我接着问：“能不能让我看看你正在用的或正在写的软件需求？”在同样的一阵犹豫之后, 我得到了各式各样的回答. 例如, “不行, 这是商业机密, 要让你获准阅读似乎有些麻烦. ”或者是, “唔, 可是我们还没有完成, 也许再晚些时候吧. ”也会有一些奇怪的回答, 如, “唔, 我们正在做, 但眼下我们正忙于测试, 等测试完了, 我们会写软件需求的, 那时你可以看到. ”

有时我也获准阅读实际的软件需求. 它们通常都是基于IEEE 830指导原则的, 都包含了指导原则的所有介绍性部分, 例如“范围”. “针对的读者”等. 不过, 到具体软件需求时, 就有些混乱了, 因为IEEE 830没有给出这方面的指导原则. 其中的一些需求只是程序设计说明, 除了一些数据流图外, 其余的在我看来意义都不大. 到底软件需求是什么呢？

六个月后, 我得到了一些很好的软件需求并获益匪浅. 从Jens-Peder Vium那里, 得到了第一份好的软件需求. 我将它作为本书的一个实例（丹麦船厂案例, 第11章）. 尽管它比我所见到的其他需求好得多, 但也存在不足之处, 我们一起改进了涉及的各种技术. 不久, 我的研究获得了更多的支持, 得到了许多优秀的软件需求说明, 并将其中的一些作为本书的实例. 一年后, 由于太多的人都希望我能阅读他们写的软件需求, 我不得不拒绝了许多人的要求.

从这些初步研究中, 我得出了一个结论：人们都知道自己所编写的软件需求并不理想, 但又不知如何改进, 而且, 每份软件需求都有一些好的部分, 同时也存在一些严重缺陷. 如果将所有好的部分综合起来, 我们似乎就得到了通用的解决方案. 但实际的情况是, 有些重要的问题是大家都无法解决的, 例如：



● 如何避免赘述产品的所有细节而又不失软件需求的可验证性？

● 如何保证需求正确反映了客户的业务目标？

● 如何说明为可验证的方式指明质量要素, 诸如可用性. 可维护性？



研究. 试验加上运气, 使我能够就这些问题得出了答案. 本书的各个章节都探讨了这些答案, 例如第 3.8节. 第6.6节. 第6.11节及第8.7节.

可作为教科书

本书对早期版本做了相当的扩充, 我们曾成功地将它作为分析员. 开发人员. 计算机科学系的专业课程教材. 根据不同的授课对象, 选择不同的章节进行讨论. 我们也曾使用此书为没有编程知识的信息系统专业学生进行教学. 在这种情况下, 我们开设了结合一个简明的关于数据模型. 数据流以及软件开发基本过程的课程.

本书的图表都以PowerPoint格式绘成, 所有的核对表也都有Word文档. 教师们也可以获得部分练习的答案（作者的电子邮件地址是slauesen@itu.dk）. 大多数的图表都足够详尽, 可以用5~30分钟讨论一张图表. 典型的教程大约只需要讨论书中三分之一的图表.

本书给出了两种教学练习：讨论题及练习题. 讨论题是课堂教学的主题, 也可以作为课后作业. 练习题可以作为课后作业, 也可用于课堂教学的小组讨论研究.

练习及训练项目

练习可以有多种方法. 在职业培训课程中, 我们通常为3至5人的小组分配练习. 每一小组必须提出1至2个解答方案. 这应该能在1小时内完成, 取决于参与者的背景及知识水平.

对于大学课程, 练习可以作为课后作业, 我们也鼓励提出多种答案. 我们选取一两组为其他学生陈述解答方案, 陈述时间大约15分钟, 包括讨论时间, 由学生自行掌握. 他们应设想自己是开发人员或顾问, 将其他学生作为“客户”. 听取客户的意见是重要的, 在客户不能理解时, 应重复解释方案, 同时应留意自己的答案有哪些不足之处（即使是从成功的陈述中也可以找出许多不足之处）. 这种态度在实践中是尤为重要的, 但较难做到, 因为我们往往都会为自己的方案辩护.

对于软件需求工程训练来说, 只做练习是不够的. 从编程练习中我们可以获得充分的编程训练, 但软件需求工程并不如此. 发现真实要求以及说明正确需求的技巧是无法从书面练习中获得的. 因此, 有必要结合真实的公司项目进行实践. 对于大学课程, 我们总是将课程与实际的公司项目相结合. 学生必须自己与公司或机构联系, 此举能够训练他们学习如何与相关人员打交道——这也是软件需求工程的一个重要技巧.





致 谢





本书只有一位作者, 但书中大多数场合都使用“我们”二字, 这是因为本书所介绍的大多数经验, 都来源于与其他人的讨论. 合作, 我的许多同事都做出了贡献.

这里我要特别感谢以下人员：

Jens-Peder Vium （Innovation & Quality Management）, 感谢他准许我使用丹麦船厂案例（第11章）. 他是一位资深顾问, 在与他的讨论. 合作中, 我得到了许多启发, 也了解了许多不同类型的项目.

Susan Willumsen, 感谢她在攻读硕士期间对丹麦船厂案例所做的研究.

Houman Younessi （Swinburne大学）, 我们进行了许多关于软件需求理论. 实践的讨论, 这是本书的出发点. 也感谢他关于需求样式. 可维护性需求的一些提议.

Otto Vinter （Bruel & Kjaer公司）, 感谢他准许我使用噪声源定位系统的部分需求（第14章）, 也感谢他所提供的一些案例以及富有启发性的讨论, 尤其是关于错误源及预防措施的讨论.

Karin Lomborg （现在是Karin Berg）（Deloitte & Touche公司）, 感谢她准许我使用Midland医院系统的部分需求案例（第12章）.

Jan C. Clausen （Katalyse公司）, 感谢他对任务及用例的基本差别所做的解释, 以及许多关于需求. 可用性的富有启发性的讨论.

Klaus Jul Jeppesen （Asea Brown Boveri, 现为IT大学）, 感谢他提供控制. 制造行业的大型项目信息以及与客户的谈判技巧等.

Marianne Mathiassen（硕士研究生）以及West Zealand县的Lotte Riberholt Andersen. Jeanette Andersen和Annemarie Raahauge, 感谢他们在开发“任务及支持” 技术（之前称为“带解决方案的用例”）时的合作.

Lene Funder Anderson. Lene Frydenberg. Jens Wolf Frandsen以及Marc Olivier Collignon（本科生）, 感谢他们率先将“任务及支持”技术应用于实际项目. 他们成功使用这项技术为一家大型电信公司编写了系统需求并用于招标. 他们也帮助该公司从20份建议书中选择了正确的建议书.

Dorte Olesen. Lars Henrik S* fren以及Jette M. Rosb緆 （West Zealand县）, 感谢他们在医院的新项目中使用了“任务及支持”技术.

Erik Simmons （Intel公司）, 感谢他教我Planguage并且如审查需求文档般仔细审阅了本书（同典型的开发人员一样, 我也无法改正所有的不足之处）.



Soren Lauesen



slauesen@itu.dk