A001-185-2510-李海鹏

我对需求分析与建模的认识与应有内容建议

作者：李海鹏 班级：18软件5班 学号：1814080902510

				         目录
			我对需求分析与建模的认识与应有内容建议	
一、 摘要/关键字（Abstract and Key words）	
二、 引言（Introduction）	
三、 正文（Text）	
	第1章 需求工程导论（Introduction to Requirements Engineering）	
	第2章 需求基础（Demand basis）	
	第3章 需求工程过程（Requirements engineering process）	
四、 结论（Summary）	
五、 参考文献（References）	

一、摘要/关键字（Abstract and Key words）

【摘要】需求工程是指应用已证实有效的原理和方法,通过合适的工具和记号，系统 地描述待开发系统及其行为特征和相关约束 。需求工程覆盖了体系结构设计之前的各 项开发活动,主要包括分析客户要求、对未来系统的各项功性 及非功能性需求进行规 格说明，并针对不同的对象可分为系统需求工程 (如果是针对由软硬件共同组成的整 个系统 )和软件需求工程(如果仅是专门针对纯软件部分 )。在系统开发中，需求工程 往往与体系结构设计交替进行直到分解的子问题可以单纯地由软件或硬件系统解决。 软件需求工程则是对应用于纯 软件系统开发生命期中系统设计之前的第一阶段。因此, 需求工程的目标相当简单明了:确定客户需求,定义设想中系统的所有外部特征。本次 主要探讨需求工程的绪论部分。
【关键字】需求工程绪论；需求工程导论；需求基础；需求工程过程；需求的定义

二、引言（Introduction）

【为何要重视需求工程】需求工程的作用主要表现在: 增强了项目涉众对复杂产品特征 在细节和相互依赖关系上的理解，增强了项目涉众对需求( 尤其是复杂需求) 的掌握; 增进了项目涉众之间的交流， 减少了可能的误解和交流偏差; 需求管理能够更加有效 地处理需求变更，提高了生产效率; 需求跟踪信息能够更加准确地反映项目的进展情 况，以便进行更好的项目决策 ; 使得项目涉众认识到需求在项目工作中的重要性，使 得需求的作用得到重视和有效发挥。良好的需求分析和管理工作，才能把系统的功能描 述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础 。
【书写目的】随学习软件工程各个课程项目的不断开展，我愈发发现若要完成一个完美 的软件，是离不开需求分析的，加之需求工程对一个软件项目的重要性，所以把这门知 识学好学精是很有必要的。鉴于我上学期的软件工程导论的学习并不是很好，所以此次 对于需求工程与建模这门课我有必要从开始便认真学习，以便弥补自己在这方面的不 足。本次文章主要是对第一部分绪论的总结与认识，以及个人对此的理解。

三、正文（Text）

第1章需求工程导论（Introduction to Requirements Engineering）

1.1软件生产中的需求问题

1.1.1需求问题是当前软件开发面临的主要问题

美国专门从bai事跟踪IT项目成功或失败du的权威机构Standish Group从1994年到1997年的CHAOS Reports证实，导致项目失败的最重要的原因与需求有关。他们对美国和英国500名IT经理作调查后发现，76%的受访者在他们的事业中经历过完全的项目失败.虽然IT项目管理正在变得越来越好，但仍有失败的情况，CHAOS的2004年报告中仍有23%的项目被取消，51%的超期超预算.目前需求问题已经成为软件开发项目失败的主要原因之一，同时也是软件开发项目失败的主要原因。
Standish Group在它每年的CHAOS Report报告中给出了IT项目相关调查数据结果。根据1999年Standish Group对当年美国项目的统计数字表明，只有26%的项目是真正成功的， 28%的项目是彻底失败的（即中途夭折的项目），介于两者之间是完成了的、但“受到质疑的”项目占46%，这些项目被定义为存在费用超支、超出工期的项目。
这些存在问题的或是失败的项目带来的直接损失是970亿美元，占了美国当年全部的IT投资（2550亿美元，17.5万个项目左右）的近40%，而由于这些项目所带来的间接损失是无法估量的。Standish Group 2003年公布的调查数据中，在被调查的1.35万个项目中，绝对成功的项目比例大大低于50%，仅为34%。彻底失败的项目为15%。受到质疑的项目占所有IT项目的51%。通过对Standish Group自1994年以来发布的一系列项目调查数据进行了汇总，可以看到三个现象:

1. 项目的成功率在提高、失败率在下降。这显示出随着时间的推移，被调查企业项目管理能力在上升。例如从1994年和2004年的数据看，取消项目的比例从31%下降到23%; 超期项目从189%下降到45%; 超预算项目从222%下降到63%。
2. 从总体上看，目前项目的成功率仍低至34%。
3. 有疑问项目的比例保持基本不变，而且占据了被调查项目总数的一半左右。
   另外，从历年的Standish Group报告分析看，导致项目失败的最重要原因与需求有关。 Standish Group 的CHAOS 报告进一步证实了与成功项目最密切的因素是良好的需求管 理，也就是项目的范围管理，特别是管理好项目的变更。

1.1.2软件的模拟特性

软件的模拟特性来源于其知识载体的特性：软件在运行中表现出来的特性、行为应该和应用的显示情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件“模拟了现实”。
当然，软件对现实世界的“模拟”并不是机械和被动的。在投入使用之后，它也会通过相应的对外接口对其周围环境产生必要的影响，并进一步帮助人们解决现实世界中遇到的问题。
软件可以分为三类：纯工具型软件、面向普通用户的纯工具型软件和应用型软件
而在实践当中，对应用型软件的“模拟“特性理解不透彻或应用不坚决的问题的确普遍存在。[ Capers 1996 ] 在调查了几百家公司之后发现超过 75% 的企业在需求处理环节存在不足。
2000 年，Nikula等人在对芬兰的中小型公司进行需求处理实践情况评价时发现[ Nikula 2000 ] , 在以 30 分为标准线的情况下，75%的公司竞然在 10 分以下。Hofm ann 等人在欧洲的需求工程实践悯查中发现，仅有约 1/ 3 的项目有明确的需求处理过程[ Hofmann 2001 ].在进行需求分析时，人们对软件自身特性投入很大精力的同时，对本应投入很大精力的问题背景和应用环境却常常关注不足。Jurislo 等入在对欧洲的 150 多名需求工程实践者进行调查后发现，在需求处理的诸多技术中需求获取和冲突协商 的技术没 有得到充分的应用[ Juristo 2002 ] 。研究也发现，当软件生产面临时间、市场等其他压力时，漠视“模拟“特性的情况就更为严重。

1.1.3需求问题具体原因

软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或 应用不坚决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术 原因也会导致需求问题的产生。

1. 非技术性和社会性因素重视不足
2. 传统需求分析方法的缺陷
3. 软件规模的日益扩大
4. 需求问题的高代价性

1.2需求工程

1.2.1需求工程简介

1. 定义
   “需求工程 ”自产生以来，其概念和其领域内的其他名词一样，没有形成较为一致的定义，不同的人从不同的角度出发，根据各自不 同的理解，会得出不同的定义。
   简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反映 软件被应用后与其环境互动形成的期望效应。
   从细节来看，可以定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的现实世界目标、软件系统的功能和软件 系统应 当遵守的约束，同时也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
   通过以上定义可以发现，需求工程有以下 3个主要任务。
   ① 需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这 些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，即要同时说明软件需要“做什么”和“为什么”需要做。
   ② 需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试 、用户手册编写等很多后续软件开发阶段的工作基础。
   ③ 现实世界是不断变化的世界，因此需 求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。

2. 基本活动
   需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需求验证4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在需求开发活动之后，保证所确定的需求能够在后续的项目活动中 有效地发挥作用，保证各种活动的开展都符合需求要求。

1.2.2需求工程与系统工程

系统需求开发的主要目的是获得整个系统的期望目标，包含功能特征和非功能特征（如性能要求等）。为此需要判断系统的涉众，采集他们的目标与要求，研究系统的环境，确定系统的约束，并进行一些整体性的需求分析。系统需求开发阶段的需求分析主要是分析系统的成本效率及系统的组织和行政策略，处理互相依赖、冲突、重叠或不一致的涉众需求，检查并弥补需求缺失，检查技术储备 、外部系统等环境约束。系统需求开发的结果会写入系统需求规格说明。
系统需求开发阶段获得的需求将被分配到软件工程、硬件工程或人力工程部分。其中硬件工程和人力工程的需求一般比较容易落实 ，但软件工程的需求还需要进行更加细致的处理，即进行软件需求开发。软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件行为，产生软件需求规格说明。

1.2.3 需求工程的重要性

由千计算机应用于现实世界的广泛性，所以软件工程师的工作也具有行业上的广泛性。这就要求他们在不同的行业领域里都表现出优秀的工作能力，例如，一个在金融领域软件开发中成绩斐然的工程师也应有能力在医疗领域进行成功的软件开发。这就带来了问题和解决方案的广泛性。但是软件工程师不可能了解所有的领域，所以在软件开发 中他们常常要同时面对新的问题和提出新的解决方案。
因为总要面临新的问题，所以软件工程师常常需要将工作中很大的一部分用来定 义问题，然后再为其设计一个新的解决方案。定义问题就是需求工程的任务，所以除了一些特殊悄况之外，在软件开发中进行需求工程是非常必要的。

1.2.4 需求工程的复杂性

Brooks的论断在表明需求工程重要性的同时，也指出了需求工程的困难性，这来源于需 求处理过程的复杂性 。
[ Lamsweercle 2000 ]认为，需求工程的复杂性体现在以下几个方面。

1. 处理范围广泛
2. 涉及诸多参与方
3. 处理内容多样
4. 处理活动互相交织
5. 处理结果要求苛刻

1.3需求工程师

1. 需求工程师是涉众和开发者之间的桥梁
2. 需求工程师需要具备的技能
3. 需求工程师要重视“软技能”
4. 需求工程师需要创新
5. 需求开发是团队行为

第2章需求基础（Demand basis）

2.1 需求的定义

需求一直是软件工程中较为模糊的词汇之一。提起需求 ( requirement ) , 不同背景的人（用户、开发者）会有不同的看法，因此需求是需求工程中一个非常难以准确定义和解释的概念。
在各种不同的定义中，本书更倾向千使用 IEEE 的需求定义[ IEEE 1990 ] :
① 用户为了解决问题或达到某些目标所需要的条件或能力；
② 系统或系统部件为了满足合同、标准、规范或其 他正式文档所规定的要求而需要具备的条件或能力；
③ 对①或②中的一个条件或一种能力的一种文档化表述。
IEEE的定义中同时包括了用户的观点（第一种条件和能力）和开发者的观点（第二种条件和能力），它强调了＂需求＂的两个不可分割的方面：需求是以用户为中心的，是与问题相联系的；需求要被清晰、明确地写在文档上。

2.2 满足需求就是解决问题

2.2.1 问题与需求

人们开发软件系统的目的就是希望用它作为解决方案来解决问题，使得现实改善到期望的状况。解决问题、改善现实、满足用户期望的条件与能力就是需求。

2.2.2 问题解决的两个方面----问题域与解系统

1. 问题域
   问题在现实世界与软件系统的互动中得到解决。如图 2 - 2 所示，软件系统在应用千现实之后，就成为现实世界的一个部分。当然，软件系统不会也不需要与整个现实世界互动，它只需要与现实世界中的一部分互动即可。这部分就是问题的发生地，也是问题解决的基本范围一一解决问题必须涉及的事件和事物，[ Jackson 1995 b ] 将它们称为问题域( problem domain )。

2. 解系统
   软件系统通过影响问题域帮助人们解决问题，所以[ Jackson 1995b J称之为解系统 ( solution system )。在解系统中软件起着主要的作用 ，它是软件解决方案在通用计算机上的实现。
   解系统是问题的解决手段，并不是问题的产生地，所以解系统并不是问题域的一部分。解系统与问题域之间存在可以互相影响的接口，以实现交互活动。

3. 问题域与需求
   虽然解决问题和满足需求的手段是引入解系统，但问题和需求都来自于用户，用户关注的是问题域，所以需求是用户对问题域中的实体状态或事件的期望描述，例如有需求描述R1、R2如下。
   R1: 一旦书籍被借出，则在归还之前，系统应该不允许它被再次借阅。
   R2: 如果超过30天的归还期限，系统在书籍归还时应该进行超期处罚。
   需求并不针对解系统，它的描述应该尽可能使用问题域的语言，尽最不涉及解系统 的专业名词。例如下述需求描述R3、R4中就含有“数据仓库技术 ”“ 客户关系管理系统”“ 按钮”“界面”等多个计算机词汇是不恰当的。相比之下，R5、R6的描述更能被用户所接受。
   R3: 系统应该使用数据仓库技术建立客户关系管理系统CRM , 以扩大5%的销售额
   R4: 如果用户在销售 列表信息界面选中一个商品，点击“查看”按钮，系统将显示商品的详细信息界面。
   RS: 应用系统 12 个月后，销售额应该扩大 5%。
   R6: 在用户请求查看具体商品时，系统应该显示该商品的详细信息，包括条码、名称、价格和厂家。
   需求开发的最原始出发点就是用户需求，或者需求的源头一一问题。

2.2.3 问题解决的基础----模拟与共享现象

处于问题域之外的解系统之所以能解决问题域中的问题，是因为问题域与解系统之间存在有效的互动 ，并在互动中互相影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域，[ Jackson 1995b J 将这种模拟性称为共享现象( share phe nomenon ) 。
初看上去，问题域与解系统原本是两个相互独立的系统，相互独立性使得它们之间难以互相影响。但是一旦认识到解系统对问题域的模拟性，它们就会变得紧密联系，互相影响也会自然形成。
简单地讲，模拟是指其中一方仿制另一方的信息。解系统对问题域的模拟则更加复杂一些它们之间的模拟性带有交互性：一方面，解系统会在自身中保持一份与间题域现象一致的信息，并随着问题域现象的变化而变化；另一方面，问题域会期待在解系统中看到一致的信息，并据此展开自己的行为。
除了包含共享现象的知识模型之外，解系统也有一些现实世界并非来自于现实模拟的特征，例如数据库管理系统的选择、模型的范式化、索引的建立等，这些因素并不对应于任何问题域知识，却是解系统必不可少的部分。

2.2.4 问题解决的方法----直接与间接

因为模拟后的知识一共享现象，是解系统的一部分，所以解系统可以对其施加操作，适当改变这些知识。知识的改变会通过交互性传递给问题域，问题域在会接受改变的基础上继续规律性的运作，使问题得以解决。
模拟并操纵共享现象是软件系统满足需求最直接的方法，但有些情况下软件系统也会使用间接的方法解决问题：软件系统操纵共享现象影响问题域的一部分，然后利用问题域内在的规律性自动影响另一部分。
考虑问题解决和需求满足的方法时，成本是重要的因素。如果成本能够接受 ，就尽擞使用直接的方式解决，如果成本太高 ，就可以折中使用间接方式解决。
间接解决方式也提醒需求工程师，考虑到问题域内的规律性，在设计解决方案时要防止解系统的引人在问题域中引发未预见的连锁反应，这种反应可能会使解决方案无法达到预期目的，甚至造成不良的负面效应。
防止未预见的连锁反应尤其要关注间接特性。间接特性不会与解系统直接交互，不会受到解系统的直接影响，但是却可能因为连锁反应而受到影响。

2.2.5 问题解决方案----需求规格说明

因为解系统解决问题的方法是改变共享知识 ，影响问题域的运行，进而满足用户的需求。所以需求规格说明主要包括两部分：对共享现象（模型）的描述和对系统对共享现象所施加的操作的描述。这也是软件系统中最为核心的两个部分：数据与功能。

2.2.6 问题解决的困难性

如果拥有描述明确的问题域特性E和定义良好的系统行为S,就可以很容易地发现将系统应用到问题域后会产生的效果。这种效果如果符合预期的需求R , 那么系统就是满足人们需要的系统。所以需求工程的目的就是根据E , 构建S, 使得E 和S 的联合作用效果符合需求。

2.3 需求和问题都有层次性

2.3.1 战略问题与业务需求

业务需求是抽象层次最高的需求，是系统建立的战略出发点，表现为高层次的目标( objective ) , 它描述了组织为什么要开发系统。例如超市管理系统可以有如下业务需 求BR1- BR4 。业务需求通常来自项目的投资人、购买产品的顾客、实际用户的管理者、市场营销部门或产品策划部门。
BR1: 在系统使用6 个月后，商品积压、缺货和报废的现象减少50%。
BR2: 在系统使 用3 个月后，销售人员工作效率提高50% 。
BR3: 在系统使用6 个月后，店铺运营成本降低15%。
•范围：人力成本和库存成本。
•度狱：检查平均每个店铺的员工数撮和平均每 10 000 元销售额的库存成本。
BR4: 在系统使用6 个月后，销售额度提高 20%( 最好情况：40%; 最可能情况： 20%；最坏情况：10%。）
业务需求必须是可验证的，其验证标准可以是一个数值指标，如 BR1-BR4; 也可以是一个直接的有无、是否等判定，例如，下述 BR 5、BR6 验收时就是有与没有的判定。
BR5: 跟踪记录储户的存取款情况。
BR6: 跟踪记录 VIP 顾客信息。
业务需求可验证的数值指标是通过研究问题域的背景资料得出的，例如，若大多数商品从入库到出库的销售周期是6 个月，那么就可以将 BRl 的第一个条件设定为” 系统使用 6 个月后 “; 如果详细列举原来导 致商品积压、缺货和报废 的原因及比率，将软件系统能解决的原因及比率累加后达到50% , 就可以将 BR l 的后一个验证条件写为“商品 积压、缺货和报废的 现象减少50%” 。再如，如果收银员从新手到熟练使用 系统的培训周期为 3 个月，就可以 将 BR2 的第一个条件写为”系统使用 3 个月后” ；如果实例研究中收银员使用与不使用系统的工作时间为 1 : 2, 就可以将 BR2 的第二个条件写为＂销售人员工作效率提高 50%" 。

2.3.2 任何问题与用户需求

高层次的目标是由组织的决策者提出的 ，但普通用户才是组织中任务的实际执行者，只有通过一套具体并且合理的业务流程才能真正实现目标。用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求主要来自系统的使用者一 用户。在有些情况下，系统的直接用户不可知，如通用的软件系统或社会服务领域的软件系统等，所以用户需求也可能来自间接的渠道，如销售人员和售后支待人员等。
需要注意的是：在3个层次中，只有用户需求在表述时在不可验证性上要求较为宽松。因为用户需求具有下面几个特点：
① 模糊、不清晰。用户需求允许适度使用形容词和副词，使得描述常常带有模糊和不清晰的特性。
② 多特性混杂。在用户进行需求描述时常常将功能需求和非功能需求混杂在一起。
③ 多逻辑混杂。用户需求是对用户任务的描述，而任务本身往往含有前后相继的多个逻辑处理过程，即一个任务需要进行多次系统交互才能够完成。
用户需求表达了用户对系统的期望，但是要透彻和全面地了解用户的真正意图，仅仅拥有期 望是不够的，还需要知道期望所来源的背景知识。因此，对所有的用户需求都应该有充分的问题域知识作为背景支待。而在实际工作中，用户表达自己的期望时，通常不会提及需求所涉及的问题域知识，所以需求工程师需要根据用户的需求整理完 整的问题域知识。

2.3.3 系统行为与系统级要求

业务需求描述了系统的目标与效益，适合决策者；用户需求描述了具体任务，适合用户；它们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统的行为，尤其是系统与外界的交互行为 ：在接收到一个外界请求时，软件系统应该给外界提供响应。所以系统级需求的典型形式是“系统可以x x x”或者“在X X 用户提出X X请求时，系统应该x x x ”。
因为系统级需求比用户需求更详细，数量更多，所以为了节省开发时间，在实际开发中有些开发者更愿意使用用户需求而不是系统级需求作为后续开发的基础。这种做法在 一定程度上是可行的，但也有风险 ：用户需求不够准确，给开发人员提供了过大的发挥空间，可能导致开发人员在需求理解上出现偏差 ，因为开发人员未能从用户需求描述中得到足够信息以准确地完成设计与实现工作，就只能以自身的经验进行假设 ，这些假设未必是合理的。如果可能，本书还是建议开发者尽可能使用系统级需求作为后续开发的基础。
一个软件系统的系统级需求集合定义了相应业务需求及用户需求的解决方案 ，构成了需求规格说明的主体部分。解系统及其需求规格说明都是不属于现实的，是人们为了解决问题而构建的，所以系统级需求无法直接从现实中得到。相比之下，业务需求直接或间接地来源于决策者，用户需求直接或间接地来源于用户，而系统级需求就只能通过技术加工获得。技术加工过程被称为需求分析，其源对象是用户需求及相关的问题域知识，处理方式是利用分析方法、技术建立需求分析模型，并基于需求分析模型将用户需求及问题域知识转化为系统级需求。将用户需求转化为系统级需求是一个复杂的活动。

2.3.4 需求开发要遵从层次性

功能需求的3个不同抽象层次之间有紧密的联系，在3个不同层次的功能需求中，业务需求具有明显的目的性和较高的抽象性，比较容易获取和确认。所以需求开发往往从获取业务需求开始。有了业务需求之后，就可以确定系统的最终目标和努力方向，进而指导具体的需求获取活动，发现用户需求。用户需求经过明确和细化的处理，可以转化为系统级需求。
从另一个角度讲，系统开发者理想中的需求是系统级需求，因为开发者可以直接将系统级需求映射为系统行为，进行设计和开发。
但是因为系统级需求是无法直接或间接从现实中获取的，所以开发者只能退而求其次一获取用户需求，并通过分析活动将其转化为系统级需求。
随之而来的另一个问题是，用户需求的获取过程非常复杂，涉及众多参与者和诸多问题， 要成功地获取用户需求，首先要协调参与者的立场和问题的范围，而这只能通过对业务需求的处理进行解决----根据业务需求，协调涉众的立场，限定问题的范围，指导用户需求的获取过程。

2.4 需求的分类与表述

2.4.1 需求的分类

分类的目的是为了区别对待，否则分类就失去了意义。需求分类是为了将需求划分为需要区别对待的不同类型 ，每种类型会被文档化到不同的部分，服务千不同的读者、不同的目的。

1. 广泛意义上的需求谱系
   人们在软件开发中谈论“需求”时，通常是指软件需求，本书中使用“需求“一词时也主要用来指称软件需求。但有时“需求”一词也会被用来指称其他类型的需求。从严格的意义上来说，项目需求与过程需求都不能算是需求，因为它们并不是用户对问题解决的期望，而是用户对软件开发活动本身的要求。硬件需求与其他需求也不属于用户对问题解决的期望 ，而是为了让软件能够成功运营而需要适应的环境与活动。但是在文档化需求的材料中，经常会出现项目需求、过程需求、硬件需求和其他需求，因为它们对需求工程师及开发者正确理解软件需求甚至整个产品具有极其重要和不可缺少的作用，所以它们经常出现在需求文档中。
2. 严格意义上的软件需求分类
   从严格意义上讲，软件需求是直接或间接关系到软件系统功能的期望。根据不同的分类标准，可以将需求分成不同的种类。在各种需求分类中最常见的是[ IEEE 1998 ) 的分类，[IEEE1998] 将需求分成下列几个类别。
   ① 功能需求( functional requirement ) : 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
   ② 性能需求 ( performance requirement ) : 系统整体或其组成部分应该拥有的性能特征，如CPU 使用率和内存使用率等。
   ③ 质抵屈性( quality attribute ) : 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，如可靠性程度和可维护性程度等。
   ④ 对外接口 ( external interface ) : 系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。
   ⑤ 约束( constraint ) : 进行系统构造时需要遵守的约束，如编程语言和硬件设施等。
   除了上述 5 种明确的软件需求类别之外，[ IEEE 1998 ] 还指出项目中也可能会出现逻辑数据需求等其他特殊类型的需求。
   除功能需求之外的其他 4 种类别需求又被统称为非功能需求( non- functional requirement )。在非功能需求中质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指质屈属性。

2.4.2 功能需求

功能需求是软件系统需求中最常见和最重要的需求，同时也是最为复杂的需求。功能需求是一个软件产品得以存在的原因，是软件系统 能够解决用户问题和产生价值的基础，也是整个软件开发工作的基础。所有开发者都需要了解功能需求。在复杂的系统中功能需求数橄太多，所以需要将它组织为多个独立部分，然后按照分工原则由不同的 开发者来处理不同的部分。

2.4.3 性能需求

[ IEEE 1990 ] 对性能的定义是：一个系统或其组成部分在限定的约束下，完成其指定功能的程度，如速度 、精确性和内存使用程度等。性能需求定义了系统必须多好和多 快地完成专门的功能。常见的性能需求包括以下几种：
① 速度( speed ) : 系统完成任务的时间
② 容量( capacity) : 系统所能存储的数据量
③ 吞吐量( throughput ) : 系统在连续的时间内完成的事务数批
④ 负载( load ): 系统可以承载的并发工作量
⑤ 实时性( time- critical ) : 严格的实时要求

2.4.4 质量属性

1. 质量属性的概念
   成功的软件系统必须满足显式的及隐含的各种要求。系统为满足显式的及隐含的要求而需要具备的要素称为质量。
   为了度屈一个系统的质址，人们通常会选用系统的某些质拯要素进行批化处理，建立质屈特征，这些特征称为质量屈性。
   需要注意的是质量属性需求包含性能需求，只是性能需求比较特殊，所以被独立为单独的类型。
   实际工作中，软件体系结构师会比较关心质批需求，因为妥善解决质最问题是软件体系结师的主要工作。

2. 质量模型
   为了更好地根据质质量属性描述和评价系统的整体质量 ，人们从很多质量属性的定义中选择了一些能够相互配合、相互联系的特征集，它们被称为质量模型。

3. 质量属性的重要性
   对于一个巳经完成的设计，如果需要修改其功能，则需要对设计进行一定的调整或拓展。但如果需要修改其质量属性要求，在复杂的情况下就可能会需要重新进行设计方案的选择，受到的影响就是整个设计而不再仅仅局限于其某个部分。所以，在设计开始之初就确定质量属性要求非常重要，而且对越复杂的系统越为重要。

4. 质量属性需求的开发
   [ Chung 2000 ] 认为，在用户的叙述中质量属性大多是和功能需求联系在一起的，因此为了发现用户对质量属性的要求，需求工程师需要对照软件的质县属性检查每一项功能需求，尽力去判断质量属性存在的可能性；对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在遇到特定的实例时意识到它们的存在。[ Cysneiros 2001 ] 通过实践还发现，用户在描述中使用的形容词和副词通常意味着质量属性的存在。

5. 常见的质量属性需求
   （1）可靠性(reliability)
   （2）可用性(availability)
   （3）安全性(security)
   （4）可维护性(maintainability)
   （5）可移植性(portability)
   （6）易用性(usability)

2.4.5 对外接口

对于解系统而言，问题域中的其他软件系统也属于问题域的一部分，且为一个比较特殊的部分。因此用户有权对解系统和其他系统之间的软硬件接口提出要求。解系统的对外接口也是一种重要的需求。用户界面在有些情况下也会被视为系统的对外接口，被作为一种重要的需求。

2.4.6 约束

约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。但是如果解系统不满足约束，那就意味着问题域并不能够提供解系统要求的运行环境，解系统将无法在问题域内成功地部署和运行。

2.5 优秀需求的特性

1. 完备性
   每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。
2. 正确性
   每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因。没有用户参与的需求评审将导致此类说法：“那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。
3. 可行性
   每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（elicitation）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他负责检查技术可行性。
4. 必要性
   每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的资源。
5. 无歧义
   需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有而且只能有一种解释，即需求无歧义 。
6. 可验证
   需求应该是可验证的，也就是说通过分析、检查、模拟或 测试等方法能够判断需求是否被满足。如果需求不可验证，就无法判断完成的系统是否满足了该需求，开发人员也无法去选择一个能够实现该需求的方法。

第3章需求工程过程（Requirements engineering process）

3.1 概述

过程是一组相关活动的集成，通过这些活动的执行，可以完成一项任务或者达到一个目标。需求工程过程是系统开发中需求开发活动的集成，它以用户所面临的业务问题为出发点进行分析和各种转换，最终产生一个能够在用户环境下解决用户业务问题的系统方案，并将其文档化为明确的规格说明。

3.2 需求工程活动

3.2.1 需求获取

1. 收集背景资料
2. 获取问题于目标，定义项目前景与范围
3. 识别涉众，选择信息的来源
4. 选择获取方法，执行获取，获取功能与非功能需求
5. 记录获取结果

3.2.2 需求分析

1. 背景分析
2. 问题分析、目标分析、业务分析、确定系统边界
3. 软件需求建模
4. 细化需求
5. 确定优先级
6. 需求协商

3.2.3 需求规格说明

1. 定制文档模板
2. 编写文档

3.2.4 需求验证

1. 执行验证
2. 问题修正

3.2.5 需求管理

1. 建立和维护需求基线集
2. 建立需求跟踪信息
3. 进行变更控制

3.3需求开发过程是迭代和并发的

需求开发不仅是迭代的，而且它的两个重要活动——需求获取与需求分析——还是交织的。需求获取与需求分析是需求开发中的两个主体活动，它们共同构成一个学习过程。需求开发过程不仅是迭代的，更进一步地说，它的各个活动之间是并发的。

3.4 实践方法的应用

实践方法是人们能够从陌生的知识领域中得到的最早的知识片段和知识形式。在它们逐渐累积和丰富之后，人们就会从它们当中抽象出更加普遍的规律性知识，建立知识 体系。
软件工程是一个“年轻”的工程领域，还没有形成一个完整的知识体系——有些部分完整，有些部分欠缺。在软件工程的各个子活动中，有些领域已经形成了比较完整的 知识体系，如程序的编码和编译方法；也有一些领域还没有形成需要的知识体系，需要依赖大撮的实践方法来指导工作的进行，如设计活动和需求工程活动。

3.5需求开发过程与软件工程过程的互相影响

[ Verner 2005 ]发现，相比于需求方法本身的好坏，需求方法与软件开发方法的适配性更会影响项目的成败。需求开发过程之所以对后续软件开发过程有重要影响，并不仅仅是因为它的结果制品——需求——是后续开发过程的工作基础，如果单纯从产生软件需求规格这个任务来看，这些正性信息都是不必要的，但它们对后续软件开发过程的影响则是明显的。

四、结论与建议（Summary and Suggestion）

这本书的绪论部分可以说给了我很大的启发，让我明白了需求工程的重要性，在学习的同时我也进行了相应的总结。
因为有了“软件危机”的产生，“软件工程”才被提出。而在“软件工程”中，需求分析又是重中之重，它对项目的成败具有至关重要的作用。和软件需求相关的因素为软件项目带来的风险和问题要远远超过所有的其他因素，糟糕的软件生产状况背后隐藏着软件工程的需求问题。
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题，但除此之外，还有一些技术原因也会导致需求问题的产生。一般有非技术性和社会性因素重视不足；传统需求分析方法的缺陷；软件规模的日益扩大；需求问题的高代价性等。
什么是需求工程？需求工程是所有需求处理活动的综合，它收集信息、分析问题、整合挂点、记录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。需求工程是为了在软件开发前需要软件工程师们去了解并去设计出一套解决方案。因为软件工程师并不是了解所有领域。所以更加需要更用户沟通。需求工程十分重要。虽然人们很早就认识到这一点，但是在时间、人力、物力、财力的投入上却并没有那么重要。事后必然会导致需求分析水平低，软件开发质量低，用户抱怨多的问题出现。
然而有时候并不一定是需求分析师的问题，用户有时候并不能明确的描述出自己想要使用什么，而需求分析师又不了解用户所在领域。所以就会出现软件需求出现“不完整、不准确、不清晰、变化不可控”这些现象。所以需求分析师们必须具备以下技能以方便、明确、成功的做出需求分析。
特别地，我对软件工程的学习也有一些建议，我希望能多通过实际的例子来体会需求工程的美与作用，同时这也一定能够让我更好地进行学习，为自己的职业生涯打下更坚实的基础。

五、参考文献（References）

以下排名不分先后：
Wiki百科
百度百科
[ Damian 2003 ] DAM I AN D, CHTS AN J , VALDYANATHASAMY L, etal. An industrial case study of the impact of requirement s engineering on downstream development. Proceeding s of the 2003 International Symposium on Empirical Software Engineering ( JSESE ’ 03), 2003
[ Damian 2005 ] DAMIAN D, CHISANJ , VAJDYANATHASAMYL, etal. Requirements engineering and down stream ware development: findings from a case study. Empirical Software Engineering , 2005, 10 : 255- 283.
[ Damian 2006] DAMIAN D, CHISAN J. An empirical study of the complex relations hips between requirements engineering processes and other processes that lead to payoffs in productivity, quality, and risk management. IEEE Transactions on Software Engineering, 2006, 32 (7) .
[ Hickey 2003 ] HICKEYAM, DAVIS A M . Requirements elicitation and elicitation technique selection:a model for two know ledge-intensive software development processes .In HICSS’03: Proceedings of the 36th Annual Hawaii International Conference on System Sciences ( H ICSS ’ 03) - Track 3, 2003: 96.1 .
[ Robert 2002 ] Glass R L. Facts and fallacies of software engineering. Addison-Wesley , 2002
[ Shaw 1990 ] Shaw M. Prospect s for an Engineering Discipline of Software. IEEE Software , 1 990 , 7 ( 6 ) : 15- 24
[ Siddiqi 199 6 ] STDDlQI J, SHEKARANM C. Requirements engineering: the emerging wisdom . IEEE Software , 1 996,
[ Larnsweerde 2000 ] Lamsweerde V. A Requirements engineering in the year 00: a Research perspective. Invited Paper for l CSE ’ 2000-22nd International Conference on Software Engineering . Limerick: ACM Press, 2000.
[ Lubars 1993 ] LUBARS M, Potts C, Richter C. A review of the state of the practice in requirements modeling. First Int’ ISymp.Requirements Eng. Los Alamitos: IEEE CS Press , I 993: 2-14.
[ Maiden 2007] MAIDEN N, NCUBEL C, ROB ERTSO N S. Can requirements be Creative? Experiences with an Enhanced Air Space Management System.29th International Conference on Software Engineering ()CSE’07), 2007.
[ Minor 2004 ] MJNOR 0 , ARMA GO J. Requirements engineering: a close look at ind us try needs and model curricula. AW RE ’ 04.
[ Nikula 2000 J NIKULA U, SJANIEMI J, Kalviainen H. A state- of- the- practice survey on requirements engineering in small-and medium- sized enterprises.Telecom Business Research Center Lappeenranta. Lappeenranta 2000 .
[ Nuseibeh 2000 ] NUSETBEH B, EASTE RBROOK S. Requirements engineering: a road map. Proceedings. of the 22nd Int’ I Conference.on Software Engineering, Future of Software Engineering Track. New York: ACM Press, 2000
[ Oboler 2003 J OBOLER A, SQUIRE D , KORB, K. Why don’ t we practice what we teach.Engineering Software for Computer Science Research in Academia . International Conference on Software Engineering Research and Applications (SERA 2003), 2003.