本书全面系统地阐述了一个组织应该如何改进需求工程过程。全书内容涵盖了需求工程过程改进的概念、方法和具体实现，主要提出了一些改进需求工程过程的实践性建议，并把这些建议表示成一组代表需求工程最佳方法的实践指南的形式。基于作者在研究、软件和系统开发中的经验，这些指南以一种标准的、易于理解的方式具体说明了如何改进一个组织的需求工程过程。它们适用于任何类型的应用，但通常适用于系统或软件工程。
　　本书结构合理，内容丰富，适合于所有与软件或系统需求工程相关的人员阅读，也可作为高等学校计算机专业及相关专业的本科生、研究生的参考读物。

“一本绝妙好书……职业软件工程师独一无二的行动指南。”
　　——Watts Humphrey，SEI(软件工程研究所)
　　本书提供了许多反映需求工程中最佳实践的指南。这些指南基于作者在研究中以及在软件和系统开发中积累的经验，以一种易于理解的方式阐述了改进需求工程过程的方法。一般来说，这些指南适用于各类应用，更适用于系统工程和软件工程。　　
　　这些指南既包括简单的“常识”，也包括引入复杂新方法的建议。可以将它们和过程改进计划结合起来，根据问题、　目标和预算的情况加以选择。由于指南之间的相互依赖性很小，可以把它们按任意顺序引入到组织中。
　　与IS09000，CMM一致根据成本／效益分析划分等级给出了实施建议可以组合起来应用以适合组织需要
配套网站http：／／www．comp．lancs．ac,uk／computing／resources／re-gpg／除为本书提供支持外，还包含了许多面向需求工程工具和资源的链接作者简介：
　　lan Sommerville英国著名软件工程专家，兰开斯特大学软件工程学教授。lan Sommerville教授在软件工程的教学和科研方面有20多年的经验。目前他的研究领域包括计算机系统工程、需求工程．系统可靠性以及软件进化。
　　Pete Sawyer英国兰开斯特大学计算机系高级讲师。
　　需求工程是发现、记录和管理计算机系统需求的过程。需求工程的目标是尽可能产生一组完整的、一致的、相关的能够反映出客户真实需要的系统需求。尽管这个理想可能难以完全实现，但是使用一套基于工程理论的系统化方法比使用现今广泛采用的非形式化方法能得到更好的需求。

欧洲最近的一份调查表明：软件开发和生产的主要问题在于需求规格说明和对客户需求的管理方面。毫无疑问，对于其他领域而言，这一点也是同样重要的。发现需求、记录需求、管理需求，这些过程的改进对于将来的业务成功是至关重要的。
　　本书的目的在于给你提一些建议，以帮助你改进需求工程过程。通过对该过程的改进，你将创建一份易于理解、很少有错误的系统需求描述。你也将了解更多有效的过程来管理需求变更，并估计这些变更的影响和代价。
　　本书适于那些涉及软件或系统需求工程的人以及那些深受糟糕的系统需求之害的人。本书也和系统工程师、他们的经理以及涉及组织软件改进过程的每一个人密切相关。本书并不针对任何特殊的应用领域，但是对关键系统的需求工程问题给予了特别的关注。就像系统分析一样，需求工程是一个相对新的名词。如果你是一名系统分析员，则将在本书中找到一些有用的建议。本书中的“工程师”是指所有涉及需求工程的人，而不论他们的技术背景和工作头衔如何。
　　在本书中，我们将假定你负责质量改进并有一些适当有效的质量管理措施。因此，我们的过程改进建议的基点是通过引入新的或改进了的实践方法来改变你的过程。对于如何改进需求表述，发现需求、理解需求、分析需求的过程，以及需求管理系统，本书给出了一些实用的建议。
　　我们编写这本书的初衷在于，我们知道很多组织在系统开发过程中在需求发现、分析和协商上存在问题。已经出现了各种各样处理这些问题的方法，但是据我们所知，还没有任何一本书能够集这些实践性的方法于一体。现有的关于需求工程的书大部分是为学生编写的，目的在于让他们了解系统需求和需求工程的过程，对于需求工程中出现的种种问题的实际解决方案并没有太多的介绍。我们相信，这里提供的实践性建议对负责系统和软件需求工程的实践者会有更大的帮助。
　　类似IS09000之类的标准已经强调了过程定义和标准化的重要性。然而令人吃惊的是，在过程定义和标准化的过程中，需求工程在很大程度上会被忽视。ISO 9000对建立系统需求的过程只字不提。另一个关于软件过程改进的主要标准是SEI的能力成熟度模型(CMM)，这个标准简单地提到你应该管理自己的需求，但只是就所涉及的内容给出了一些简要的原则。本书的所有内容都是与ISO 9000和CMM两者相符合的。
　　本书由三个部分组成：
　　1)　介绍部分。讨论需求工程中的问题、需求工程的过程，并提出一些过程改进的策略(见第1—2章)。
　　2)　指南部分。提出一些可行的改进需求工程过程的建议，这些建议都是基于成功的需求工程实践的。我们尽量用通俗的语言，而不用太多的术语或深奥的用词来表达这些原则(见第3—10章)。
　　3)　深入提高部分。这里将提供更多的信息来补充系统建模的原则、形式化方法和面向视点的方法(见第11—13章)。
　　我们建议任何人都应该阅读介绍部分，然后浏览指南部分以获取一个大致的了解。你应该考虑自己的过程改进策略，然后回到最切合自己需要的那些指南进行仔细阅读。第三部分的材料有助于实施上述一些指南，也有助于判断哪些指南可能对你有用。可以在打算实施相关指南时阅读相关内容。
　　更多的信息
　　为了补充本书内容，我们已经建立了一个网站，里面包含了一些我们觉得不适合写在本书中的详细信息，包括那些迅速变更的内容和一些吸引人的但是我们所知不多的系统的信息。在站点上，可以找到以下内容：
　　1)　　万维网上其他有关需求工程网页的链接。
　　2)　关于本书涉及话题的更多信息，比如可跟踪性和过程依赖性分析。
　　3)　一些支持需求工程的CASE工具的信息。
　　4)　部分顾问人员的联系方式，他们会提供关于需求工程、过程改进和关键系统方面的建议。
　　本书的网址为：http：／／www．comp.lancs．sc．uk/computing／resources／re-gpg／。
REAIMS项目
　　本书所列的指南是欧洲合作项目REALMS(项目编号8649)的一部分，REAIMS项目的目的在于为需求工程的过程改进开发新的技术和策略，尤其是为安全关键系统开发新的技术和策略。除了本书所列指南外，REAIMS项目还有如下成果：
　　1)与本书互为补充的另一本书，主题是过程改进的普遍策略，名为《Process Improve—ment：A Good Practice Guide》。
　　2)　PREview：这是一种适于需求工程和过程分析的面向视点的方法。第13章大致地描述了这种方法。
　　3)　MERE：这是一种在需求工程中重用关于以前问题和事件知识的方法。
　　4)　PERE：这是一种过程分析的方法，其目的是在系统需求中可能引入错误的地方突出显示出潜在的过程缺陷。
　　5)　FRERE：这是一种有关形式化说明和安全关键软件系统证明的方法。
　　关于REALMS项目的信息，包括合作伙伴的联系方式、项目成果的总结和《Plaocess lmprovement：A Good Practice Cuide》可以查阅本书的网页或者REAIMS的网页：http：／／www．comp．
　　lancs.ac.uk/computing/research/cseg/projects/reaims/。

Ian Sommerville, Pete Sawyer：Ian Sommerville: 英国著名软件工程专家，曾任教于兰卡斯特大学，现为圣安德鲁斯大学软件工程学教授。他在软件工程的教学和科研方面有20多年的经验，是IEEE CS组织编撰“软件工程知识体系” (SWEBOK) 的专家委员会成员之一。他的研究领域包括计算机系统工程、需求工程、系统可靠性以及软件进化。

赵文耘 叶恩：暂无简介

自从20世纪60年代以来，各种问题一直困扰着计算机系统的开发。系统可能推迟交付，超过预算，没有达到用户的真正要求，没有发挥它的全部作用等。造成上述问题的一个主要原因是系统或软件需求方面的问题。减少上述问题的最好方法是在一段时期内逐步改进用于发现、理解、协商、描述、确认和管理系统或软件需求的过程。
　　本书有助于改进组织的需求工程过程。本书首先介绍了需求工程和需求工程过程改进的概念。接着讨论了如何改进组织的需求工程过程，引入了需求工程过程成熟度的概念，并建议评估组织成熟度等级的方式。随后详细介绍了需求工程过程改进的各个实践指南，这些指南基于好的需求工程实践，既包括简单的“常识”，也包括引入复杂新方法的建议。它们根据成本和效益等分为初级、中级和高级指南。组织可以根据自身的问题、目标和可用预算选择合适的指南，对它的需求工程过程进行改进。最后本书介绍了一些需求工程技术，包括结
构化方法系统建模、形式化说明方法和面向视点的方法。
　　本书并不针对任何特殊的应用领域，但是特别提到了关键系统的需求工程问题。如果你存在软件或系统需求方面的问题，可以从本书中找到与你的问题相关的实践性建议，即指南。如果你还不熟悉需求工程改进过程，也可以通过阅读本书来了解相关知识。作者用浅显的语言来书写本书，使全书读起来轻松、亲切。从本书的内容和结构安排可以看出，作者对软件开发的认识是十分深刻的，论述也是十分严谨的，相信读者必定能够从中得到不少的收益。
　　本书共分为13章。参加翻译的人员有赵文耘、叶恩、沈铖、杨滨、刘燕秋、张志等。
叶恩负责统稿，赵文耘对全书进行了审校。此外，彭鑫等人对本书的译稿提出了许多宝贵的意见，在此表示衷心的感谢。由于译者的知识水平有限以及时间仓促，难免有翻译不当之处，欢迎读者批评指正。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 译　者
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　2002年10月于上海

第1章　引言
1．1　本书将如何帮助我
1．2　需求是什么
1．3　需求工程是什么
1．4　需求文档是什么
1．5　需求文档的最好表示方式是什么
1．6　需求应该达到怎么样的详细程度
1．7　功能需求和非功能需求的区别是什么
1．8　系统的项目相关人员是指谁
1．9　系统规模的差别
1．10　需求工程过程是什么
1．11　如何发现需求工程过程中的问题
1．12　能推荐一个良好的需求工程过程吗
1．13　ISO 9000适用于什么地方
1．14　在哪里能找到关于需求工程的更多信息

第2章　实际过程改进
2．1　过程成熟度
2．2　过程评估
2．3　过程改进
2．3．1　改进的成本
2．3．2　CASE工具的使用
2．4　十大指南
2．5　指南校验表
2．5．1　初级指南
2．5．2　中级指南
2．5．3　高级指南

第3章　需求文档
3．1　定义标准的文档结构
3．2　说明如何使用文档
3．3　包含一个需求概要
3．4　构造系统的业务案例
3．5　定义专业术语
3．6　安排好文档的版面使文档易读
3．7　帮助读者查找信息
3．8　使文档易于变更

第4章　需求抽取
4．1　评估系统可行性
4．2　注意组织和行政方面的因素
4．3　识别和咨询系统的项目相关人员
4．4　记录需求源
4．5　定义系统的操作环境
4．6　使用业务关系来驱动需求抽取
4．7　寻找领域约束
4．8　记录需求理由
4．9　从多视点收集需求
4．10　原型化难以理解的需求
4．11　使用场景来抽取需求
4．12　定义操作过程
4．13　复用需求

第5章　需求分析和需求协商
5．1　定义系统边界
5．2　使用校验表进行需求分析
5．3　使用软件支持协商
5．4　对冲突和冲突解决方案做好计划
5．5　需求分级
5．6　使用多维方法进行需求分类
5．7　使用交互矩阵发现冲突与重叠
5．8　评估需求风险

第6章　需求描述
6．1　定义描述需求的标准模板
6．2　使用浅显、一致、简明的语言
6．3　适当地使用图解
6．4　用其他需求描述辅助自然语言
6．5定量说明需求

第7章　系统建模
7．1　开发互补的系统模型
7．2　系统环境建模
7．3　系统体系结构建模
7．4　用结构化方法进行系统建模
7．5　使用数据字典
7．6　记录项目相关人员需求和系统模型之间的联系

第8章　需求确认
8．1　检查需求文档是否符合你的标准
8．2　组织正式的需求审查
8．3　使用多学科小组评审需求
8．4　定义确认校验表
8．5　使用原型化来使需求生动化
8．6　编写用户手册草案
8．7　设计需求测试案例
8．8　解释系统模型

第9章　需求管理
9．1　惟一地标识每一个需求
9．2　定义需求管理的策略
9．3　定义可跟踪性策略
9．4　维护可跟踪性手册
9．5　使用数据库来管理需求
9．6　定义变更管理策略
9．7　标识全局系统需求
9．8　标识易变的需求
9．9　记录丢弃的需求

第10章　关键系统的需求工程
10．1　创建安全性需求校验表
10．2　在确认过程中引入外部评审者
10．3　标识和分析风险
10．4　从风险分析中获得安全性需求
10．5　根据安全性需求交叉核对操作需求和功能需求
10．6　使用形式化规格说明来说明系统
10．7　收集事件经验
10．8　从事件经验中学习
10．9　建立组织的安全文化

第11章　结构化方法系统建模
11．1　背景和动力
11．2　选择模型和方法
11．3　模型
11．3．1　行为模型
11．3．2　结构模型
11．3．3　数据字典和其他建模技术
11．4　方法
11．4．1　方法附加值
11．4．2　模型和方法
11．5　更多信息

第12章　形式化规格说明
12．1　为什么进行形式化
12．2　定义和生命期问题
12．3　形式化规格说明方法
12．4　动机和潜在效益
12．5　问题、缺陷和经验教训
12．6　成本
12．7　对规格说明进行推理
12．8　更多信息

第13章　视点
13．1　为什么需要视点
13．2　PREview：一个实用的视点方法
13．2．1　PREview中的需求抽取
13．2．2　PREview中的需求分析
13．2．3　需求协商
13．2．4　需求定义
13．2．5　工具问题
13．3　更多信息