A001-185-2531

计算机科学与工程学院实验报告
课程名称 软件建模与分析 班级加粗样式 18软工5班
实验名称 我对需求分析与建模的认识与应有内容建议
教导教师 董瑞生
姓名 郑佳铨 学号 1814080902531 日期 2020年10月3号

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

摘要
需求问题是当前软件开发面临的主要问题，同时，导致需求问题的原因当中，一个最为重要的原因是：未能很好地理解和掌握“应用” 型软件的模拟特性以及由此而产生的一系列影响和要求。还有软件生产中产生需求问题的原因在于对应用型软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求问题的产生。对于如何发现和解决需求求分析过程的问题，需要我们进行进一步探讨。
目录

1、 需求问题
2、 软件的模拟特性
3、需求问题具体原因分析
4、传统需求分析方法的缺陷
5、软件规模的日益扩大
6、需求问题的高代价性
7、需求工程
8、需求工程与系统工程
9、需求工程的重要性
10、需求和问题都有层次性
11、优秀需求的特性
12、 过程

1、需求问题
无论是实践者的切身体会，还是各种调查数据，都明确指出需求问题是当前软件开发面临的 主要问题之一。在所有调査数据中，以美国专门从事跟踪工厂项目成功或失败的权威机构 Standish Group的CHAOS系列报告最广为人知。软件项目可以分为3种类别：
①在预计的时间之内，在预算的成本之下完成预期的所有功能，则项目为成功项目(success )o
②已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不 全，则项目为问题项目(challenged or faulty)。
③因无法进行而被中途撤销，或者最终产品无法提交使用，则项目为失败项目(failed or impaired )o

2、软件的模拟特性
在这些导致需求问题的原因当中，一个最为重要的原因是：未能很好地理解和掌握“应用” 型软件的模拟特性以及由此而产生的一系列影响和要求。
软件的模拟特性来源于其知识载体的特性：软件在运行中表现岀来的特性、行为应该和应用 的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件 “模拟”了现实。
例如，在图书管理软件中，如果在张三没有借书的情况下，软件系统产生了一条张三借书的 记录，则该软件系统将会被认为是运行不正常和存在缺陷的，原因即在于借书情况的记录和现实 中发生的借书事件没有保持一致。在软件和现实保持一致的情况下，人们不再需要为了查找一 本书而翻遍所有的书架，通过软件系统进行书目査询就可以得到准确的答案。
软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。在软件开发中，一方面 只能完成预期功能的60%-70% [Standish 1995],另一方面移交软件中却存在着大量的冗余功能 (接近50% [Young 2002, Standish 2003]),这些功能用户从来不会使用。人们在讨论冗余功能为 软件开发带来额外负担时，却很少有开发人员能够意识到，这些冗余功能往往也是导致用户不满 意和软件不被接受的原因之一。正是因为缺乏这种意识，所以软件开发人员才会在开发中持续 不断地超出用户的需求添加“出色功能”，进行自我陶醉地为软件“镀金”。设想一个购买汽车 的普通用户，如果发现汽车除了正常的功能之外，在方向盘边上还有一些用途不明的其他部件， 虽然被告知那些部件可能永远不会被用到而可以置之不理，但作为一名普通的驾驶者，没有人会 有设计师的那份泰然，不小心触发那些部件可能产生的未知后果会一直萦绕心头，以至于恨不能 将之消除而后快。
当然，软件对现实世界的“模拟”并不是机械和被动的。在投入使用之后，它也会通过相应 的对外接口对其周围环境产生必要的影响，并进一步帮助人们解决现实世界中遇到的问题。只 是它必须以准确的现实理解为基础，在现实的制约之下对外施加影响，进而解决问题。
软件可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。
专业用户通常以软件为中心开展工作，工具软件是他们的主要手段，因此面向专业用户的纯 工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。功能的复杂可以让专业用 户在执行任务时具有更大的发挥空间和回旋余地。使用的高效可以帮助专业用户更快、更好地 完成任务。以上两点的实现都要以先进的技术为必要条件。该类软件以创新性为主要关注点， 技术创新是它们的生存之道。
普通用户利用软件的目的通常仅限于解决一些实际问题，软件仅仅是一种辅助性的手段，因 此面向普通用户的纯工具型软件以功能的有用性为首要成功标准，一些过于复杂的功能反而会 因其灵活性而丧失一定的实用性，进而受到用户的抵制。普通用户技术能力有限，所以对操作的 要求以使用方便为主，在使用方便的前提下追求使用的高效性。实现功能的有用性和使用的方 便性，利用常见的可行技术即可，先进技术并非必要条件。有效性是该类软件的主要关注点，能 够有效使用即可占有一席之地。
应用型软件在“模拟”现实的基础之上接收用户的请求，协助用户完成任务，它正确工作的 基础是具有“模拟”性。“模拟”性具体是指以下几点：
①目的性。软件的目标是直接或间接地满足用户的某些目的或者解决用户的某些问题，软件的功能是据此设立的。 .
②正确性。软件具备的功能能够保证目标的正确实现。
③现实可理解性。软件实现其功能的基础、手段和过程是在用户领域内现实可理解的，即 软件系统是在理解其现实环境的基础上，通过影响现实的某些环节，或者改变现实各部分的通信 方式，最终达成某些目的或者解决某些问题的。
应用型软件一般以普通用户为应用对象，因此也要求具有使用的方便性。实现功能的“模拟”性和使用的方便性也仅要求所用技术具有可行性。和工具型软件不同，应用型软件通常不是 通用的，它们是为特定的应用环境定制的，对环境的“模拟”性是其主要的关注点。
不同的评判标准和关注点决定了 3类软件在生产中也会有所不同（如图1-4所示），尤其是 在分析阶段具有截然不同的目标：面向专业用户的工具型软件通常在具有一定的观念创新或技 术创新后执行功能分析，分析阶段的主要目的是为充分利用创新优势而进行巧妙的功能安排；面 向普通用户的工具型软件进行分析的主要目的是进行方案权衡，寻找一套切实有效的功能配置； 应用型软件分析阶段的主要目的是发现人们利用软件的原因（目的），找出需要软件解决的问 题，理解应用环境中的领域知识，保证功能的“模拟”性。
3、需求问题具体原因分析
软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚 决，它会导致软件开发者产生轻视需求的态度问题。除此之外，还有一些技术原因也会导致需求 问题的产生。
应用型软件的模拟特性使得需求处理具有很突岀的特性。相对于软件开发的其他阶段而言，需求处理阶段涉及更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。 20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和社会性因素重 视不足。
需求建模与分析是需求处理中的核心活动，它用一些形式化或半形式化的语言进行知识 的描述。一方面，只有通过建模与分析才能将混乱、模糊的用户需求变成清晰、明确的软件需 求，所以它是获取需求处理活动的必然后继，它建立的分析模型是需求处理中最为重要的成 果；另一方面，建模与分析的理论可以帮助人们系统化地看待问题，它可以根据理论或分析中 出现的各种现象指导其他需求处理活动更好地进行。因此，建模与分析活动在需求处理中具 有非常重要的地位，以至于人们理所当然地把需求处理工作的重心部署在建模与分析活动 中，放在对建模技术的理解和运用上，甚至在传统的软件开发生命周期中用“需求分析”一词 指代整个需求处理阶段。
但在需求处理阶段除了需求建模与分析活动之外，还有其他的活动也应得到重视，理解需 求处理中涉及的非技术性和社会性因素与理解建模分析技术一样必要，否则同样会导致软件 的失败，这些因素包括组织机构文化、社会背景、商业目标、利益协商等。它们的必要性具体 如下。
(1)从需求处理的任务来看，需要重视非技术性和社会性因素
(2)从需求处理的手段来看，需要重视非技术性和社会性因素
(3)从需求处理的过程来看，需要重视非技术性和社会性因素
4、传统需求分析方法的缺陷
传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功，但它们并不非常适合于需求阶段的技术处理需要，因此它 们在需求处理中的应用具有一定的先天缺陷。
传统的结构化方法和面向对象方法都是最先在编程领域取得成功的，它们所用的概念和组 织机制都是从编程领域抽象出来的。其后，它们又都相继被用来进行软件设计，因为设计和编程 都有构建高质量(健壮性、可维护性、适应性等)软件的共同目标，而且使用相同的概念和组织机 制保证了从设计到编程的平滑过渡，所以它们在设计领域的应用也取得了成功。而后它们又被 进一步应用到分析领域，但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要 的目标是理解现实，而这是传统分析方法所拥有的概念和组织机制所无法实现的，所以说传统分 析方法在需求分析领域的应用具有先天缺陷。
5、软件规模的日益扩大
20世纪90年代之后大量出现的以“企业”为中心的软件反映了软件规模日益扩大的发展趋 势，这一方面提高了需求处理中非技术性和社会性因素的影响比重，另一方面也进一步放大了传 统技术在需求处理阶段的不适应性。
在软件以单一任务或几个相关任务为应用领域时，软件应用的上下文环境相对局限在某个 部门或者某个角色，甚至某个个人的任务范围之内，涉众非常有限。所以，它所涉及的组织机构 文化、社会背景、商业目标和利益协商等非技术性因素自然也相对较少。而且该类软件的需求来 源往往很有限，所以每条需求相对较为完整和一致，可理解性相对较好，进行技术分析时对“为什 么做”(why)进行描述的要求不是非常必要。
但是，当软件以企业为中心时，它的应用范围会包括企业的各个主要职能部门，包括各部门 的主要任务和它们之间任务的协同。这样，该组织的部门划分、传统与惯例、规章和约束、行业特 性和行业约定、社会地位和社会价值等组织结构文化和社会背景方面的因素就会对需求分析的正确进行产生一定的影响。而且随着应用范围的扩大，涉众会更加广泛，相互之间的利益冲突也 会加剧，因此对商业目标和利益协商的处理要求也变得很有必要，忽视这些非技术性因素会导致 整个项目的失败。
在软件以企业为中心时，很少有用户能够单独给出对全局的理解，进而得出需求。相反，每 个用户往往仅能给出与其相关的片段，需要分析人员将所有用户的片段连接起来，构成全局理 解，导出需求。因此，该类软件要求分析人员能够在拥有相对有限的用户描述片段或者用户描述 片段间有冲突时进行相对正确的解读，即需求分析对规格说明可理解性的要求加强，这样对“为 什么做”进行描述就显得非常重要，因此传统分析方法的缺陷也就更加明显。
6、需求问题的高代价性
需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。 如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错 误修复代价较高，需求问题对软件成败的影响较大。统计表明，在需求阶段发生的错误如果到了 维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍 [Boehm 1981, Boehm 2001 ]（如图1-5所示）。这种递增效应也说明了需求问题的高代价性。
7、需求工程
“需求工程”自产生以来，其概念和其领域内的其他名词一样，没有形成较为一致的定义，不同的人从不同的角度出发，根据各自不同的理解，会得岀不同的定义。
简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需 求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。
从细节来看，可以定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的 现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时也关注以上因素和准确的软件 行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的 联系。
需求工程有以下3个主要任务。
①需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功 能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制 和约束，即要同时说明软件需要“做什么”和“为什么”需要做。
②需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件 行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试、 用户手册编写等很多后续软件开发阶段的工作基础。
现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间 的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和 约束在软件产品族中的演化和分布情况进行综合考虑与处理。
需求工程为了完成其任务，需要执行一系列的任务。需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特 性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需 求验证4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在需求开发活动之后，保证所确定的需求能够在后续的项目活动中有效地发挥作用，保证各种活动的开 展都符合需求要求。需求获取的目的是从项目的战略规划开始建立最初的原始需求.为此，它需要研究系统将 来的应用环境，确定系统的涉众，了解现有的问题，建立新系统的目标，获取为支持新系统目标而 需要的业务过程细节和具体的用户需求。需求分析的目的是保证需求的完整性和一致性。它从需求获取阶段输出的原始需求和业务 过程细节出发，将目标、功能和约束映射为软件行为，建立系统模型，然后在抽象后的系统模型中 进行分析，标识并修复其中的不一致缺陷，发现并弥补遗漏的需求。需求规格说明的目的是将完整、一致的需求与能够满足需求的软件行为以文档的方式明确 地固定下来。在文档中，可以使用非形式化的文本(如自然语言)描述，也可以使用半形式化的 图形语言，如统一建模语言(Unified Modeling Language,UML)描述，还可以使用形式化的语言(如 Z语言)描述。描述的结果文档是接下来将被提交进行需求验证的软件需求规格说明。需求验证是需求开发中的最后一个活动。它的首要目的是保证需求及其文档的正确性，即 需求正确地反映了用户的真实意图；它的另一个目标是通过检査和修正，保证需求及其文档的完 整性和一致性。需求验证之后的需求及其文档应该是得到所有涉众一致同意的软件需求规格说 明，它将作为项目规划、设计、测试、用户手册编写等多个其他软件开发阶段的工作基础，对帮助 项目开发人员建立共同的前景具有重要作用。需求管理是对需求开发所建立的需求基线的管理，它在需求基线完成之后正式开始，并在需 求工程阶段结束之后继续存在，在设计、测试、实现等后续的软件系统开发中保证需求作用的持 续、稳定发挥。它的主要工作是跟踪后续阶段中的需求实现与需求变更情况，确保需求得到正确 的理解和实现。
8、需求工程与系统工程
在系统化的需求工程出现之后，需求处理在整个系统开发中所处的位置也出现了变化。
计算系统工程通常是指将计算机引入某一现实系统，并用它来改变现实系统的运作方式，达 到一个理想效果的过程。在计算系统工程中，软件通常具有重要的作用，但系统工程中除了含有 处理软件的软件工程之外，还包括硬件工程和人力工程。硬件工程为计算机在某一现实系统中 的应用提供硬件支持，如网络布局和处理机配置等。人力工程为计算机在某一现实系统中的应 用提供人力资源支持，如维护人员培训、系统管理人员培训和用户培训等。因此，在系统工程中 虽然应该重点关注软件工程部分的内容，但并不能完全以软件为中心来看待和处理整个系统。
正确的方式应该是在处理软件所关注的内容之前就先综合考虑和处理所有的系统因素，包括软 件、硬件和人力资源。为此，在实现具体的软件工程、硬件工程和人力工程之前，系统工程需要先 进行系统需求开发，以获得对系统整体的综合理解。
系统需求开发的主要目的是获得整个系统的期望目标，包含功能特征和非功能特征（如性能 要求等）。为此需要判断系统的涉众，釆集他们的目标与要求，研究系统的环境，确定系统的约 束，并进行一些整体性的需求分析。系统需求开发阶段的需求分析主要是分析系统的成本效率 及系统的组织和行政策略，处理互相依赖、冲突、重叠或不一致的涉众需求，检査并弥补需求缺 失，检查技术储备、外部系统等环境约束。系统需求开发的结果会写入系统需求规格说明。
系统需求开发阶段获得的需求将被分配到软件工程、硬件工程或人力工程部分。其中硬件 工程和人力工程的需求一般比较容易落实，但软件工程的需求还需要进行更加细致的处理，即进 行软件需求开发。软件需求开发用来确定系统需求中应该由软件满足的部分，将其映射为软件 行为，产生软件需求规格说明。
9、需求工程的重要性
软件开发是一个工程性的问题，这一点已经被人们广泛接受。软件开发者的任务就是开发 一个软件系统，将之应用于现实世界，并通过软件系统和现实世界的交互，影响和改变现实世界。 在这个过程中，软件开发者并不是要从物理结构开始针对问题建立一个特定的计算机，而只是描 述所需软件系统的特征和行为，然后通过编程在通用计算机上实现，使之表现出之前所描述的特 征和行为。因此软件开发是这样一个工程问题：利用通用的计算机结构构建一个有用的软件系 统，来满足人们的某些目的。
但是，作为一名工程师，软件开发者的工作方式却和其他工程领域的工程师不太一样，这些 领域包括常见的汽车、电子、化学、航空等。最大的区别在于，一个汽车工程师在开始工作之前， 不需要花费精力去研究等待他解决的问题是什么。他们的问题总是设计某种特殊类别的汽车， 而且该种汽车的设计目标和特性要求都是清晰与明确的。家庭轿车的设计师不需要考虑让轿车 飞行或载重15 t等性能之外的要求，也不需要考虑轿车是否应该有轮子或驾驶员应该坐在轿车 的前面还是后面等性能之内的问题。每种类型汽车所要解决的问题都是固定的，或者是解决市 内交通，或者是解决长途客运，等等，没有人会用汽车来建造一栋摩天大厦。因此对于这些工程 领域中的工程师而言，一方面因其所从事行业的特殊性给他们施加了很大约束，另一方面也给他 们提供了很好的工作基础。
由于计算机应用于现实世界的广泛性，所以软件工程师的工作也具有行业上的广泛性。这 就要求他们在不同的行业领域里都表现出优秀的工作能力，例如，一个在金融领域软件开发中成 绩斐然的工程师也应有能力在医疗领域进行成功的软件开发。这就带来了问题和解决方案的广 泛性。但是软件工程师不可能了解所有的领域，所以在软件开发中他们常常要同时面对新的问 题和提出新的解决方案。
因为总要面临新的问题，所以软件工程师常常需要将工作中很大的一部分用来定义问题，然 后再为其设计一个新的解决方案。定义问题就是需求工程的任务，所以除了一些特殊情况之外， 在软件开发中进行需求工程是非常必要的。
人们很早就认识到需求T程的重要性，正如Frederick Brooks： Brooks 1987］所说：开发软件系 统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写详细技术需求，这 包括所有面向用户、面向机器和其他软件系统的接口。同时，这也是一旦有错最终将会给系统带 来极大损害的部分，并且以后再对它进行修改也极为困难。
虽然需求工程的重要性早就被人们所认识，而且实践也一次又一次地证实了这种认识，但在 很多情况下人们还是会忽略需求工程的重要性，这种忽略在学生的校园实践项目中体现得尤为 明显。
究其原因，是因为有些特定问题的具体特性掩盖了需求工程的重要性。常见的情况有两类：
①问题广为人知。像电梯调度、图书管理等问题就属于此类。面对此类问题时，即使不采 用需求工程的方法，开发人员也可以得到对问题的准确和全面理解，进而开发出符合要求的 系统。
问题小而简单。它们开发的代价较小，因此修复的代价也较小，即使全部推倒重来也不 会有太大的影响，因此该类问题可以不釆用需求工程的方法。
也在调查中发现，学校的实践和科研项目存在不注重工程化方法（当然也包 括需求工程方法）的现象，并总结了两个原因：第一，项目的结果往往仅要求提交一个可运行的原型系统，而不是完善的产品；第二，一旦项目结束，很少存在后续的完善和维护需要。
这些特定的问题会在一定的场合掩盖需求工程的重要性，但该类情况只是软件开发中的极 少数，需求工程的重要性仍然需要得到足够的重视。
10、需求和问题都有层次性
需求是问题解决的期望，问题是可大可小的，期望自然也是可大可小的。例如，一个超市收 银员的问题可以是“工作效率太低（大）”，也可以是“商品销售过程太繁琐（中）”，还可以是“销 售时计算总价不方便（小）”。
11、优秀需求的特性
理想情况下，需求应该既是解决用户问题所需要的，又是表述清晰的；既是用户的需要，又是开发者的需要。为此，人们定义了一些优秀需求应该具备的特性，下面是其中比较重要的 部分。
1.完备性
优秀的需求是完备(complete)的，它不需要做更多的扩展就可以充分说明用户需要的系统 功能。完备性的判断标准是：需求是否描述了开发人员设计和实现这项功能所需的所有信息。 只有完备的需求在开发中才可能被独立出来，单独对待。在需求开发过程中，对于不清晰的信息 可以标记为TBD ( To Be Determined,待确定)，但在需求开发结束之前，所有的TBD都必须被 解决。
例如，R20就是不完备的，仅仅根据需求描述，开发人员并不能明确到底如何输入商品信息， 以及显示哪些商品信息。相对而言，SR1、SR3更加完备。
R20：在收银员输入商品时，系统显示商品信息。
[Firesmith 2005]建议对不同类型的需求可以从不同的方面来保障需求描述的完备性。
(1)对功能需求要确保下列方面都得到了描述
①行为的触发者(trigger),它使系统执行功能需求的行为，常见的触发者包括数据输入、接 收的请求、要处理的异常等。
②行为的前置条件(precondition),它是系统成功满足功能需求的前提，常见的前置条件包 括系统的模式或状态，其他外部系统的状态、任何系统数据的值等。
③行为(action)，在前置条件下接受到触发者时，系统必须执行的行为。
④后置条件(postcondition),-旦系统成功执行行为后所处的状态，常见的后置条件包括系 统的模式或状态、其他外部系统的状态、任何系统数据的值等。
⑤不满足前置条件(failed preconditions)的情况，以及相应情况下的结果(resulting failure postconditions) o
(2)对数据需求(或者功能需求描述中的数据内容)要注意下列内容
①类型；
②语义(如在数据字典或项目术语表中描述数据的含义)；
③组成成分(如属性和子部分等)；
@初始值或默认值；
①可能的取值范围；
②度量单位；
③数据量；
④更新频率；
⑤可以对其施加的合理操作；
⑥对外关系，如关联、聚集和泛化等。
(3)对对外接口的描述要注意下列内容
①接口的名字；
②接口的定义，简短的描述；
③接口的方向声明（In. Out或者双向）；
④服务请求，包括：
-语法，如名称、参数和返回值；
•语义、含义、协议，如前置条件、后置条件与不变量或者状态模型等；
•异常，语法与语义；
・接口定义的特殊数据类型；
-质量属性要求（如性能、可靠性、安全性、保密性等）。
（4） 对质量属性（含性能）的描述要注意下列内容
①针对系统或其部件的质量标准；
②明确需要满足质量标准的情况与条件；
③衡量质量标准所使用的单位；
④质量度量的阈值。
（5） 要注意与需求源头和相关事项的专家确认
2.正确性
每一项需求都必须正确描述所需要的系统功能，要真实反映用户的意图，所以需求的正确性 又常被称为真实性（real）。需求的正确性只有提出需求的人才能加以判断，所以需求在传递给 开发人员之前，必须请需求的提出者予以确认。
正确性是一个看上去简单,但实践中很难满足的特性。实践一再表明，不真实的需求是最为 常见的需求错误之一，必须得到足够的重视。
需求正确性难以达到的主要原因有以下两方面。
①用户在表达自己的需要时，可能会在潜意识下进行一定的加工。常见的情况是：用户的 问题是A,但用户认为如果提供了方法B,则问题A自然可以得到解决，为此用户向需求工程师 反映的便是B,而不是真实的Ao所以为了发现用户的真实需求，需求工程师一定要进行问题分 析，尽力发现问题背后的问题。
②在人际交流中，信息会发生自然衰减，甚至扭曲，导致需求工程师理解的并非是用户所表 达的。对此情况的解决方法是在需求传递给开发人员之前，请提出需求的用户进行仔细检査和 确认。
12、过程
过程是一组相关活动的集成，通过这些活动的执行，可以完成一项任务或者达到一个目标。 需求工程过程是系统开发中需求开发活动的集成，它以用户所面临的业务问题为出发点进行分 析和各种转换，最终产生一个能够在用户环境下解决用户业务问题的系统方案，并将其文档化为 明确的规格说明。
为了有效地理解用户问题，分析各种可能的系统解决方案，最终产生一个适宜的规格说明文 档，需要将需求开发活动组织成一个系统化和严格的需求工程过程，这是人们随着系统开发的进 展而逐渐认识到的［Siddiqi 1996］。在初期，系统开发的唯一焦点就是编码，此时不论系统大小， 开发都是一个单独的活动——编码。这个时期人们还不认为存在独立的需求开发活动。其后， 随着生命周期模型的引入，对系统开发活动的认知取得重大进展，人们认识到需求开发是系统开 发中的一个独立的阶段，即软件开发生命周期模型的第一个阶段。在此后的进一步发展中，人们 逐渐认识和接受了系统的演化式开发思想，认识到系统的实现往往是开始于一个并非完备的需 求体系，发现需求开发也是一个递进的过程，包含一系列的独立活动。今天，大多数软件专业人 士已经意识到需求工程也有属于它自己的生命周期模型，即存在针对需求开发的需求工程过程， 这个过程又作为系统工程和软件工程的一个子过程部署在系统开发的初期阶段。
目前看来，如果所开发系统的类型不同、开发公司的规模和文化不同，或者系统开发资源获 取的途径不同，需求工程过程都会表现出极大的差异。例如，对一个大规模的军用或航空系统而 言，通常存在一个正式、严格的需求工程过程，它详细定义了过程的各个阶段，要求产生能够详细 描述系统需求和软件需求的规格说明文档。而对开发创新型软件的小公司而言，需求工程过程 可能仅仅包含一些头脑风暴会议，它产生的文档也可能仅仅是对系统期望的一段简短描述。但 不管实际上执行的需求工程过程为何，它们都拥有一些共同的需求工程活动：需求获取、需求分 析、需求规格说明、需求验证和需求管理。其中，需求获取、需求分析、需求规格说明、需求验证为 需求开发活动，需求管理为项目管理活动。
在需求工程的开始必须要获取用户期望系统表现出来的各种行为，这些期望并不是外在和 可以直接得到的，系统分析师需要利用一些方法和技术才能得到正确的结果。
为了取得对需求的正确和深入理解，系统分析师还需要对获取的结果进行综合与整理，通过 分析保证需求的正确性、完整性和可行性。
经过分析的需求被认为是有效的需求，它必须被记录和文档化，因为只有将需求文档化为正 式的规格说明，才可能将它们传递给其他参与系统开发的人员，让所有相关人员形成对系统需求 的一致和正确的理解。
规格说明文档可能被传递给设计人员、测试人员、项目管理人员等众多系统开发者，因此如 果传递的规格说明文档中存在一些错误或偏差将造成很大的影响。为了尽可能减小不利因素， 尽最大可能产生完善的规格说明文档，就需要在规格说明文档产生之后和传递给相关人员之前 组织进行文档的验证，以尽可能发现文档中的错误和偏差，并进行纠正。
获取、分析、规格说明和验证这些需求开发活动并不是看上去的那样以线性、顺序的方式执行。实 际上,这些活动之间是互相交织的，整个开发活动也是不断迭代和递增的。
在需求开发活动中会产生各种成果文档，比较常见的有3种：项目前景和范围文档、用户需 求文档和需求规格说明文档。项目前景和范围文档定义了系统的业务需求，明确了系统开发的 努力方向和工作范围。用户需求文档定义了系统的用户需求，以用户的立场表达了对系统行为 的期望，常见的用例文档就是用户需求文档的一种形式。需求规格说明文档定义了系统的系统 级需求，指出了开发者应该完成的任务。需求规格说明文档又依文档内所定义的需求范围分为 系统规格说明和软件规格说明，其中系统规格说明内定义的是对整个系统的需求，包括软件需 求、硬件需求和其他需求；软件规格说明内定义的仅仅是软件需求。在所有的需求开发活动结束之后，定义良好的需求被转入系统开发的后续阶段——设计实现和测试等，但这时系统开发人员却仍需经常面对一个非常头疼的需求问题——需求变化。因 为遭遇业务问题的现实世界的确处于不断变化之中，所以为了得到有效的系统解决方案，有些变 化必须要进行妥善的处理，这就需要在需求开发结束之后，在后续阶段中釆取有效的策略统一管 理开发的需求和变化的需求，进行需求的管理和变化的控制。所以，和前面的4个需求开发活动 不同，需求管理是项目管理活动，它在需求开发活动结束之后才开始执行。

关键词
【过程】是一组相关活动的集成，通过这些活动的执行，可以完成一项任务或者达到一个目标。
【需求】应该既是解决用户问题所需要的，又是表述清晰的；既是用户的需要，又是开发者的需要。
【软件开发】是一个工程性的问题，这一点已经被人们广泛接受。软件开发者的任务就是开发 一个软件系统，将之应用于现实世界，并通过软件系统和现实世界的交互，影响和改变现实世界。
【软件】可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。

引用文献
[Hofmann 2001 ] HOFMANN H F, LEHNER F. Requirements engineering as a success factor in software projects. IEEE Software, 2001,18(4): 58- 66.
[REGPG] SOMMERVILLE I, SAWYER P. Requirements engineering: good practice guide. Chichester: John Wiley & Sons, 1997.
[Young 2002] YOUNG R R. Effective requirements practices. Boston: Addison Wesley, 2002.
[Wiegers 2003] WIEGERS K. Software requirements. 2nd ed. Redmond: Microsoft Press, 2003.