A001-186-2629-赖海洲

作业报告
课程名称 软件需求分析与建模 班级 18软件工程6班
作业名称 我对需求分析与建模的认识与应有内容建议 教导教师 董瑞生
姓名 赖海洲 学号 1814080902629

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

自从学习了软件需求分析与建模这门课程之后,我对软件及其开发有了更加浓厚的兴趣,同时我也认识到软件需求分析与建模在软件开发中的重要性。目前国内软件在开发中还没有对软件开发的过程进行明确规定,文档不完整,也不规范,软件项目的成功往往归功于软件开发组的一些杰出个人或小组的努力。这种依赖于个别人员上的成功并不能为全组织的软件生产率和质量的提高奠定有效的基础,只有通过建立全过程的改善,采用严格的软件工程方法和管理,并且坚持不懈地付诸实践,才能取得全组织的软件过程能力的不断提高,使软件开发更规范更合理。

一、需求工程导论

软件需求位于软件工程的起始阶段，是软件系统开发中一个重要的独立工作阶段，为软件工程后续阶段提供了工作基础，对软件项目的成败至关重要。20世纪末，随着软件系统规模的扩大和复杂程度的增长，以需求分析为重心的传统需求处理技术已经不能适应现代软件技术发展的要求，完整的需求工程过程应运而生。本书是关于软件需求工程的专项著述，系统地介绍需求工程中的最新发展，指导了需求工程各个阶段的系统化实践，我希望通过学习本书可以更好的学习需求工程的知识。
学习软件需求分析与建模这门课程我们使用的书是由骆斌主编的 《需求工程——软件需求分析与建模》 第二版。这本书第一章的主要讲的是软件需求工程产生的背景，第一章重点是帮助我们认识到软件需求工程的复杂性和需求工程中非技术因素的重要性。

1.1需求工程的定义

“需求工程”没有一致的定义，从书上来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。
　　需求工程有以下三个主要任务：
1.需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能的基础时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，也即要同时说明软件需要“做什么”和“为什么”需要做。
2.需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明的是需求工程最为重要的成果、是项目规划、设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。
3.现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑处理。

1.2需求工程以及其一系列活动

需求工程为了完成其任务，需要执行一系列的活动。需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的需求特性而存在的，他们是专门用来处理需求的软件技术，包括需求获取，需求分析，需求规格说明和需求验证4个具体的活动。需求管理是因为需求工程的工程特性而存在的，它的目的是在需求开发活动之后，保证所确定的需求能够在后继的项目活动中有效地发挥作用，保证各种活动的开展都符合需求要求。
需求获取的目的是从项目的战略规划开始建立最初的原始需求。为此它需要研究系统将来的应用环境，确定系统的涉众，了解现有的问题，建立新系统的目标，获取为支持研究系统将需要的业务过程细节和具体的用户需求。
需求分析的目的是保证需求的完整性和一致性。它从需求获取阶段输出的原始需求和业务过程细节出发,将目标、功能和约束映射为软件行为,建立系统模型,然后在抽象象后的系统模型中进行分析，标识并修复其中的不一致缺陷，发现并弥补遗漏的需求。
需求规格说明的目的是将完整、十致的需求与能够满足需求的软件行为以文档的方式明确地固定下来。在文档中，可以使用非形式化的文本(如自然语言)描述，也可以使用半形式化的图形语言，如统建模语言描述，还可以使用形式化的语言(如Z语言)描述。描述的结果文档是接下来将被提交进行需求验证的软件需求规格说明。
需求验证是需求开发中的最后一个活动。它的首要目的是保证需求及其文档的正确性，即需求正确地反映了用户的真实意图;它的另一个目标是通过检查和修正，保证需求及其文档的完整性和一致性。需求验证之后的需求及其文档应该是得到所有涉众一致同意的软件需求规格说明，它将作为项目规划、设计测试用户手册编写等多个其他软件开发阶段的工作基础，对帮助项目开发人员建立共同的前景具有重要作用。
需求管理是对需求开发所建立的需求基线的管理，它在需求基线完成之后正式开始，并在需求工程阶段结束之后继续存在,在设计、测试、实现等后续的软件系统开发中保证需求作用的持续、稳定发挥。它的主要工作是跟踪后续阶段中的需求实现与需求变更情况，确保需求得到正确的理解和实现。

1.3需求工程的重要性

我们为什么要将需求工程系统化，因为需求工程老重要了，软件开发是一个工程性的问题,这一点已经被人们广泛接受。软件开发者的任务就是开发一个软件系统，将之应用于现实世界，并通过软件系统和现实世界的交互，影响和改变现实世界。在这个过程中,软件开发者并不是要从物理结构开始针对问题建立一个特定的计算机，而只是描述所需软件系统的特征和行为，然后通过编程在通用计算机上实现、使之表现出之前所描述的特征和行为。因此软件开发是这样一个工程问题：利用通用的计算机结构构建一个有用的软件系统来满足人们的某些目的。
但是，作为一名工程师。软件开发者的工作方式却和其他工程领域的工程师不太一样，领域包括常见的汽车、电子、化学、航空等。最大的区别在于一个汽车工程师在开始工作之前，不需要花费精力去研究等待他解决的问题是什么。他们的问题总是设计某种特殊类别的汽车，而且该种汽车的设计目标和特性要求都是清晰与明确的。家庭轿车的设计师不需要考虑让轿车飞行或载重15t等性能之外的要求,也不需要考虑轿车是否应该有轮子或驾驶员应该坐在轿车的前面还是后面等性能之内的问题。每种类型汽车所要解决的问题都是固定的，或者是解决市内交通，或者是解决长途客运，等等，没有人会用汽车来建造一栋摩天大厦。 因此对于这些工程领域中的工程师而言，一方面因其所从事行业的特殊性给他们施加了很大约束，另一方面也给他们提供了很好的工作基础。
由于计算机应用于现实世界的广泛性，所以软件工程师的工作也具有行业上的广泛性。这就要求他们在不同的行业领域里都表现出优秀的工作能力，例如，一个在金融领域软件开发中成绩斐然的工程师也应有能力在医疗领域进行成功的软件开发。这就带来了问题和解决方案的广泛性。但是软件工程师不可能了解所有的领域，所以在软件开发中他们常常要同时面对新的问题和提出新的解决方案。
因为总要面临新的问题，所以软件工程师常常需要将工作中很大的一部分用来定义问题，然后再为其设计一个新的解决方案。定义问题就是需求工程的任务，所以除了一些特殊情况之外，在软件开发中进行需求工程是非常必要的。
人们很早就认识到需求工程的重要性,正如Frederick Brooks[Brooks 1987]所说:开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写详细技术需求，这包括所有面向用户、面向机器和其他软件系统的接口。同时，这也是一旦有错最终将会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难。

二、需求

2.1需求的定义

第二章主要帮助我们区分软件需求的基本术语，包括问题、问题域、需求、规格说明、解决方案、业务需求等。在区分软件需求的基本术语之前，我们得先了解需求是什么，需求一直是软件工程中较为模糊的词汇之一。提起需求，不同背景的人(用户、开发者)会有不同的看法，因此需求是需求工程中一个非常难以准确定义和解释的概念。IEEE的需求定义是这样的：
①用户为了解决问题或达到某些目标所需要的条件或能力;
②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力:
③对①或②中的-个条件或一种能力的一种文档化表述。
IEEE的定义中同时包括了用户的观点(第一种条件和能力)和开发者的观点(第二种条件和能力)，它强调了“需求”的两个不可分制的方面:需求是以用户为中心的，是与问题相联系的：需求要被清晰、明确地写在文档上。
需求源于问题，要准确理解需求，就必须明确它与问题的关系。[Jackson 195，Jackson1997]认为当现实的状况与人们期望的状况产生差距时，就产生了问题。问题中的差距要么是某些事件、事物的状态不理想，要么是某些事情的发生过程不理想。要解决问题，就需要改变这些事件、事物的状态，或者改变其状一态变化的演进顺序，使其达到期望的状态和理想的演进顺序。人们开发软件系统的目的就是希望用它作为解决方案来解决问题，使得现实改善到期望的状况。解决问题、改善现实、满足用户期望的条件与能力就是需求。

2.2需求的严格分类

需求需要被文档化表述，这要求需求工程师搞清楚需求有哪些类型以及每种类型如何进行表述。
很多公司或项目管理者乃至开发人员，都或多或少的搞混需求的定义，造成用同一种语言和不同角色人进行沟通，就难免出现沟通障碍，造成别人不知道你在说啥，你也不知道别人有无听明白的情况。
实际上需求要分好几个种类，针对不同角色，就有不同角色的需求，比如软件项目中常定义的业务解决方案和技术解决方案。我们把需求进一步细化分类，可以发现这些分类可以大致概况为以下几类：
1.功能需求 2.性能需求 3.质量属性 4.对外接口 5.约束 6.其他需求。
功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求，因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性，是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
性能需求：系统整体或其组成部分应该拥有的性能特征，如CPU使用率和内存使用率等。
质量属性：系统完成工作的质量，即系统需要在一 个“好的程度”上实现功能需求，如可靠性程度和可维护性程度等。
对外接口:系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。
约束:进行系统构造时需要遵守的约束，如编程语言和硬件设施等。

2.3优秀需求的特性

2.3.1完备性
理想情况下，需求应该既是解决用户问题所需要的，又是表述清晰的；既是用户的需要，又是开发者的需要。为此，有人定义了一些优秀需求应该具备的特性。优秀的需求是完备的，它不需要做更多的扩展就可以充分说明用户需要的系统功能。完备性的判断标准是:需求是否描述了开发人员设计和实现这项功能所需的所有信息。只有完备的需求在开发中才可能被独立出来，单独对待。在需求开发过程中,对于不清晰的信息可以标记为TBD，但在需求开发结束之前，所有的TBD都必须被解决。
2.3.2正确性
每一项需求都必须正确措述所需要的系统功能，要真实反映用户的限以需求在传递给又常被称为真实性。需求的正确性只有提出需求的人才能加以判断.所开发人员之前，必须请需求的提出者予以确认。
2.3.3可行性
需求必须能够在系统及其运行环境的已如条件和约束下实现。用户无法判断需求的技术可行性，所以需求的可行性是由开发人员进行检查的。在检查的过程中，开发人员可能需要进行一定的分析和研究.而不是单纯地凭借经验和直觉。对于难以判断的需求，必要时要通过开发原型来加以验证。
2.3.4必要性
每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够以同样的效果解决用户的问题，那么它就不值得在开发的过程中消耗额外的资源。
2.3.5无歧义
需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有而且只能有一种解释，即需求无歧义。为了让需求可理解，一般倾向于以用户的语言描述需求，而用户的语言往往含有大量容易导致歧义的元素，因此在保证需求描述的无规汇表，然后再在其基础上进行需求的描述。
2.3.6可验证
需求应该是可验证的，也就是说通过分析、检查、模拟或测试等方法能够判断需求是否被满足。如果需求不可验证，就无法判断完成的系统是否满足了该需求,开发人员也无法去选择一个能够实现该需求的方法。通常，不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要让需求具体化，小心形容词和副词的使用，避免程度词的使用。
在对需求进行描述之后，我们需要了解需求工程的过程是什么样的一种情况。

三、需求工程过程

3.1需求工程过程概述

过程是一组相关活动的集成，通过这些活动的执行，可以完成一项任务或者达到一个目标。需求工程过程是系统开发中需求开发活动的集成，它以用户所面临的业务问题为出发点进行分析和各种转换，最终产生个能够在用户环境解决用户业务问题的系统方案。并将其文档化明确的规格说明。
经过分析的需求被认为是有效的需求，它必须被记录和文档化，因为只有将需求文档化为正式的规格说明，才可能将它们传递给其他参与系统开发的人员让所有相关人员形成对系统需求的一致和正确的理解。规格说明文档可能被传递给设计人员、测试人员、项目管理人员等众多系统开发者，因此如果传递的规格说明文档中存在一些错误或偏差将造成很大的影响。 为了尽可能减小不利因素，尽最大可能产生完善的规格说明文档，就需要在规格说明文档产生之后和传递给相关人员之前组织进行文档的验证，以尽可能发现文档中的错误和偏差，并进行纠正。
在需求开发活动中会产生各种成果文档，比较常见的有3种：项目前景和范围文档、用户需求文档和需求规格说明文档。项目前景和范围文档定义了系统的业务需求，明确了系统开发的努力方向和工作范围。用户需求文档定义了系统的用户需求，以用户的立场表达了对系统行为的期望，常见的用例文档就是用户需求文档的一种形式。需求规格说明文档定义了系统的系统级需求，指出了开发者应该完成的任务。需求规格说明文档又依文档内所定义的需求范围分为系统规格说明和软件规格说明，其中系统规格说明内定义的是对整个系统的需求，包括软件需求、硬件需求和其他需求;软件规格说明内定义的仅仅是软件需求。
在所有的需求开发活动结束之后定义良好的需求被转入系统开发的后续阶段——设计、实现和测试等,但这时系统开发人员却仍需经常面对一个非常头疼的需求问题——需求变化。 因为遭遇业务问题的现实世界的确处于不断变化之中，所以为了得到有效的系统解决方案，有些变化必须要进行妥善的处理，这就需要在需求开发结束之后，在后续阶段中采取有效的策略统一管理开发的需求和变化的需求进行需求的管理和变化的控制。所以，和前面的4个需求开发活动不同需求管理是项目管理活动。它在需求开发活动结束之后才开始执行。

3.2需求工程活动

需求工程过程包括如下主要活动：
3.2.1需求获取
深入实际，在充分理解用户需求的基础上，获取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合解决领域问题的用户需求。需求获取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等。其中有这些方法获取需求：
3.2.1.1用户面谈
这是一种理解商业功能和商业规则的最有效方法。面谈过程需要认真的计划和准备。其基本要点如下。
(1)面谈之前：确立面谈目的；确定要包括的相关用户；确定参加会议的项目小组成员；建立要讨论的问题和要点列表；复查有关文档和资料；确立时间和地点；通知所有参加者有关会议的目的、时间和地点。
(2)进行面谈时：衣着得体；准时到达、寻找异常和错误情况；深入调查细节；详细记录；指出和记录下未回答条目和未解决问题。
(3)面谈之后：复查笔记的准确性、完整性和可理解性；把所收集的信息转化为适当的模型和文档；确定需要进一步澄清的问题域；适当的时候向参加会议的每一个人发一封感谢信。
3.2.1.2需求专题讨论会
需求专题讨论会也许是需求获取的一种最有力的技术。项目主要风险承担人在短暂而紧凑的时间段内集中在一起，一般为一或两天，与会者可以在应用需求上达成共识、对操作过程尽快取得统一意见。参加会议的人员包括主持人、用户、技术人员、项目组人员。
专题讨论会具有以下优点。
(1)协助建立一支高效的团队，围绕项目成功的目标；
(2)所有的风险承担人都畅所欲言；
(3)促进风险承担人和开发闭队之间达成共识；
(4)揭露和解决那些妨碍项同成功的行政问题；
(5)能够很快地产生初步的系统定义。
3.2.1.3问卷调查
可用于确认假设和收集统计倾向数据，问卷需要快速叫答，允许匿名方式。存在问题的是：相关的问题不能事先决定；问题背后的假设对答案造成偏颇。如“这符合你的期望吗?”难以探索一些新领域：难以继续用户的模糊响应。在完成最初的面谈和分析后，问卷调查可作为一项协作技术收到良好的效果。
3.2.1.4．现场观察
掌握用户如何实际使用一个系统以及到底用户需要哪些信息，最好的办法是亲自观察用户是如何完成实际工作的。 一般方法如下。
(1)对办公室进行快速浏览，了解布局、设备要求和使用、工作流总体情况；
(2)安排几个小时观察用户是如何。实际完成他们的工作的，理解用户实际使用计算机系统和处理事务的细节；
(3)像用户一样接受训练和做实际工作，发现关键问题和瓶颈。
3.2.1.5原型化方法
一个软件原型是所提出的新产品的部分实现，帮助开发人员、用户以及客户更好地理解系统的需求，它比开发人员常用的技术术语更易于理解。建立原型可以解决在产品开发的早期阶段需求不确定的问题，用户、经理和其他非技术项目风险承担者发现在确定和开发产品时，原型可以使他们的想象更具体化，如建立基于Web的应用系统原理，使用HTML进行界而设计。
3.2.1.6基于用例的方法
随着面向对象技术的发展，基于用例的方法任需求获取和建模方面应用越来越广泛。用例建模是以任务和用户为中心的，开发和描述用户需要系统做什么。另外，用例帮助于开发人员理解用户的、业务和应用领域，并可以运用面向对象分析和设计方法将用例转化为对象模型。
用例建模的基本步骤如下。
(1)确定系统的参与者：参与者是与系统交互的外部实体，它既可以是人员也可以是外部系统或硬件设备。
(2)确定场景：场景是对人们利用计算机系统过程做了什么和体验了什么的叙述性描述，它从单个参与者的角度观察系统特性的具体化和非正式的描述。
(3)确定系统用例：用例描述了一个完整的系统事件流程，其重点在于参与者与系统之间的交互而不是内在的系统活动，并对参与者产生存价值的可观测结果。
(4)确定用例之间的关系：在确定出每一个参与者的用例之后，需要将参与者和特定的用例联系起来，最终绘制出系统的用例图。
(5)编写用例描述文档：单纯使用用例图并不能提供用例所具有的全部信息，因此需要使用文字描述那些不能反映在网形上的信息。用例描述是关于角色与系统如何交互的规格说明，要求清晰明确，没有二义性。在描述用例时，应该只注重外部能力，不涉及内部细节。
3.2.2需求分析与建模。
对已获取的需求进行分析和提炼，进行抽象描述，建立目标系统的概念模型，需求概念模型的要求包括实现的独立性:不模拟数据的表示和内部组织等；需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。进一步对所建立的模型（原型）进行分析。需求模型的表现形式有自然语言、半形式化(如图、表、结构化英语等)和形式化表示等三种。
需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。
问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。
分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。
制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。
评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。
需求分析的特点及难点，主要体现在以下几个方面。
(1)确定问题难。主要原因：一是应用领域的复杂性及业务变化，难以具体确定；二是用户需求所涉及的多因素引起的，比如运行环境和系统功能、性能、可靠性和接口等。
(2)需求时常变化。软件的需求在整个软件生存周期，常会随着时间和业务而有所变化。有的用户需求经常变化，一些企业可能正处在体制改革与企业重组的变动期和成长期，其企业需求不成熟、不稳定和不规范，致使需求具有动态性。
(3)交流难以达到共识。需求分析涉及的人事物及相关因素多，与用户、业务专家、需求工程师和项目管理员等进行交流时，不同的背景知识、角色和角度等，使交流共识较难。
(4)获取的需求难以达到完备与一致。由于不同人员对系统的要求认识不尽相同，所以对问题的表述不够准确，各方面的需求还可能存在着矛盾。难以消除矛盾，形成完备和一致的定义。
(5)需求难以进行深入的分析与完善。需求理解对不全面准确的分析，客户环境和业务流程的改变。市场趋势的变化等。也会随着分析、设计和实现而不断深入完善，可能在最后重新修订软件需求。分析人员应认识到需求变化的必然性，并采取措施减少需求变更对软件的影响。对必要的变更需求要经过认真评审、跟踪和比较分析后才能实施。

3.2.3需求规格说明。
对需求模型进行精确的、形式化的描述，为计算机系统的实现提供基础。软件需求规格说明书有以下几个方面的作用： (1)便于用户、开发人员进行理解和交流。 (2)反映出用户问题的结构，可以作为软件开发工作的基础和依据。 (3)作为确认测试和验收的依据。

3.2.4需求验证。
以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性，确保需求说明准确、完整地表达系统的主要特性，就是对需求规格说明与用户达成一致。其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。
需求验证阶段的主要任务包括以下两方面。
(1)执行认证
执行验证的方法有很多，同级评审是其中最常见、最有效的一个。在有些情况下，也需要使用原型或模拟等代价相对较高的验证方法
(2)问题修正
在需求验证的过程中会发现一些问题，这些问题在验证之后必须要及时得到修正。问题修正的过程还应该得到跟踪，以保证修正的落实。
3.2.5需求管理。
在整个需求工程过程中，贯穿了需求管理活动。需求管理主要包括跟踪和管理需求变化，支持系统的需求演进。由于客户的需要总是不断（连续）增长的，但一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件管理的首要问题。对于传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性，并进行关于变化的推理。进化需求是十分必要的。系统开发团队之所以管理需求,是因为他们想让项目获得成功.满足项目需求即为成功打下了基础.若无法管理需求,达到目标的几率就会降低. 以下最近收集的证据很有说服力: Standish Group 从 1994 年到 2001 年的 CHAOS Reports 证实,导致项目失败的最重要的原因与需求有关. 2001年,Standish Group 的CHAOS Reports报导了该公司的一项研究,该公司对多个项目作调查后发现,百分之七十四的项目是失败的,既这些项目不能按时按预算完成.其中提到最多的导致项目失败的原因就是"变更用户需求".
软件需求位于软件工程的初始阶段，是软件系统开发中一个重要的独立工作阶段，为软件工程后续阶段提供了工作基础，对软件项目的成败至关重要。随着软件系统规模的日益扩大和复杂程度的日益增长，以需求分析为中心的的传统需求技术已不能适应现代软件及时的发展的要求，完整的需求工程工程应运而生。需求工程是开发者再进一步升入理解然软件项目需求处理活动之后提出的一阶段性活动。
这本书从开发者角度出发，侧重实践的技术与方法，系统地介绍了需求工程中的最新进展，促进需求工程领域理论、方法和技术的融合应用。大概了解到从软件需求工程的角度出发，以需求开发过程为主线，完整描述了需求获取、需求分析、需求验证、需求规格说明和需求管理等需求工程活动。软件需求位于软件工程的初始阶段，是软件系统开发中一个重要的独立工作阶段，为软件工程后续阶段提供了工作基础，对软件项目的成败至关重要。随着软件系统规模的日益扩大和复杂程度的日益增长，以需求分析为中心的的传统需求技术已不能适应现代软件及时的发展的要求，完整的需求工程工程应运而生。需求工程是开发者再进一步升入理解然软件项目需求处理活动之后提出的一阶段性活动。
心得体会：
《需求工程-软件建模与分析》对我们初学者帮助很大，在书中从需求产生的根源出发，说明了需求工程的内容、目标、作用和意义，并介绍了需求工程的活动框架，概述了需求工程中的主要活动和实践方法，让我对需求工程有了初步的了解。在需求获取部分介绍了需求工程的需求获取活动，包括获取的活动的内容、任务、成果和实践情况，同时说明了如何为需求获取确定项目的前景和范围。讲到了如何选择需求获取的获取源，给出了需求获取的方法，并以需求获取为背景，介绍了需求工程中模型驱动方法的初步知识。书中运用大量的理论知识介绍分析需求工程，让我对需求工程的了解逐步加等，同时书中也引用一些经典的的实例来分析，在分析实例中让我们对理论知识了解更加透彻。通过学习分析能让理论知识运用于实际的开法中。

参考文献：

https://baike.baidu.com/item/%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90/2012709?fr=aladdin