A001-185-2530-吴伟滨

课程名称 软件建模与分析 班级 18软工5班
实验名称 我对需求分析与建模的认识与应有内容建议 教导教师 董瑞生
姓名 吴伟滨 学号 1814080902530 日期 2020年10月3号

---

《需求工程–软件分析与建模》这本书第1章介绍需求工程产生的背景，说明它在整个软件工程中的地位，并简要描述需求工程。第2章从需求产生的根源出发，说明需求工程的内容、目标、作用和意义。第3章介绍需求工程的活动框架，概述需求工程中的主要活动和实践方法。

需求工程这本书的第一部分（第一到第三章），主要是帮助读者建立对软件需求工程的整体认识，理解软件需求工程的定位、关注点、基本术语、过程框架等知识。

1. 需求工程导论

这一章介绍了需求工程产生的背景，说明它在整个软件工程中的地位当前软件开发面临的主要问题是需求问题。无论是实践者的切身体会，还是各种调查数据，都明确指出需求问题是当前软件开发面临的主要问题之一。在所有调查数据中，以美国专门从事跟踪工厂项目成功或失败的权威机构Standish Group 的CHAOS系列报告最广为人知。这些调查数据表都明了和软件需求相关的因素为软件项目所带来的风险和问题已经超过了所有的其他因素，糟糕的软件生产状况背后隐藏着软件工程的需求问题。而软件生产中产生需求问题的最大原因在于对应用软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。另外，还有一些技术原因也会导致需求问题的产生，如：1.非技术性和社会性因素重视不足；2.传统需求分析方法的缺陷；3.软件规模的日益扩大；4.需求问题的高代价性。

软件的模拟特性是一种来源于其知识载体的特性：软件在运行中表现出来的特性、行为应该和应用的现实情况保持一致。这一模拟特性使人们可以通过对软件的表现就可以得出相应现实问题的答案。

另外，软件对现实世界的"模拟"并不是机械和被动的。在投入使用之后，它会通过相应的对外接口对其周围环境产生必要的影响，进一步帮助人们解决现实问题中遇到的问题。不同类型软件的模拟特性决定了它的关注点和评判标准。一般软件分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和应用型软件。然而，不同的评判标准和关注点决定了3类软件在生产中也会有所不同，尤其是在分析阶段具有截然不同的目标。因为在实际工作中，虽然大部分软件开发人员将其主要精力消耗在应用型软件的生产中，但他们每天接触更多的却是工具型软件。如果开发人员受到的工具型软件相关评判标准、关注点及生产过的影响过大，就会对应用型软件在"模拟"特性理解不透彻或应用不坚决，进而导致对需求处理阶段重视不足或者在需求阶段轻视领域知识研究，应用型软件的生产就会发生需求问题。

产生需求问题也有一些其他原因：其一，非技术性和社会性因素重视不足；需求处理的任务是发现问题并解决问题。现实是问题的发生地，软件系统是人们应对问题的手段。但是单纯的软件系统是不能解决问题的，它只有和现实之间形成一种有效的互动才能解决问题。因此，相对于软件系统的构造问题，人们更应该关注软件系统和现实之间的互动效应。另外，建模与分析技术是进行需求处理的主要手段，这些技术本身都是概念性的，不依赖于某些特殊的的应用环境条件，可以被广泛应用于各种应用场景。但是利用这些技术构建的解决方案一定是和具体应用环境相关的，不存在不依赖于具体应用环境的解决方案。因此很多先相关因素约束了解决方案的构建空间。其二，传统需求分析方法的缺陷：传统的结构化方法和面向对象方法都是最先在编程领域取得成功的，它们所用的概念和组织机制都是从编程领域抽象出来的。需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实，而这是传统方法所拥有的概念和组织机制所无法实现的；另外软件规模的日益扩大和需求问题的高代价性也是产生问题的重要原因。

经过对软件工程的需求问题进行了大量调查和分析之后，人们认识到了需求处理除了核心的建模与分析活动之外，还有其他的活动也需要慎重对待，"需求工程"的说法也提出来了。需求工程即利用工程化的手段进行需求处理，以保证需求处理的正确进行。

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

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程 ,并最终在验证的基础上完成需求规范。为了提高目标软件需求规格的质量 ,需求工程提出了以下几种方法。 [2]

1)结构化需求抽取方法:需求工程支持结构化的需求抽取过程 ,为需求的抽取过程提供构型未来系统的理念 ,提供需求抽取的线索、需求描述的框架和需求抽取方法论,明确指出需求抽取过程中所涉及的有关问题及其正确的处理方法,从而保证抽取过程的质量 ,并提供系统化、工程化的指南和有效的支持工具 ,使得需求信息的无二义性、完整性和一致性[3]。

2)系统化的需求建模方法需求工程支持系统化的需求建模过程和途径 ,为软件需求模型提供预定义的语义解释和预定义的语义约束 ,支持需求提供者和系统开发者从语义上正确地理解所获得需求信息的含义 ,使得需求提供者可以正确地判断当前已提供的需求信息是否真正表达了他们自己的意图 ,也使得系统开发者可以了解自己对需求提供者所提供需求信息的理解程度。 软件项目成功的关键是开发者真正理解并在软件中正确地表达用户的意图。

3)形式化的需求验证技术形式化的验证技术是在形式化需求模型基础之上进一步保证需求信息正确性的手段。它采用精确的数学语言来表达需求模型 ,并借助于数学推导的手段,使得需求模型中含糊的、不完整的、矛盾的以及无法实现的表述能够被准确地发现 ,从而尽早得到纠正。形式化需求验证技术一般分为 3类 ,分别是代数方法、基于模型的方法和基于进程代数的方法,它们分别适用于描述和分析不同类型的软件系统。形式化需求验证技术的作用分为两个方面: 一方面是验证需求提供者的意图可满足性 (即需求模型的有效性 ) ;另一方面是验证需求模型的可实现性 (即需求模型的正确性 ) ,这一点使得形式化需求验证技术和一般的形式化方法得以区别开来。形式化需求验证的意义在于: 如果方法被正确使用的话 ,对于特定的语义是有充分定义的。

综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：

1)需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

2)需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

3)形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

4)需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性，包含有效性检查，一致性检查，可行性检查和确认可验证性；

5)需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。

需求工程的作用主要表现在: 增强了项目涉众对复杂产品特征在细节和相互依赖关系上的理解，增强了项目涉众对需求(尤其是复杂需求) 的掌握[4]; 增进了项目涉众之间的交流， 减少了可能的误解和交流偏差; 需求管理能够更加有效地处理需求变更，提高了生产效率; 需求跟踪信息能够更加准确地反映项目的进展情况，以便进行更好的项目决策 [5] ; 使得项目涉众认识到需求在项目工作中的重要性， 使得需求的作用得到重视和有效发挥。良好的需求分析和管理工作， 才能把系统的功能描述和性能指标转化为具体的软件需求规格说明书，成为系统建设的依据和基础[6]。

为了完成需求工程的各项任务，也就有了需求工程师。需求工程师是沟通用户与开发人员的桥梁，做好需求分析是一个产品是否能够适应用户要求的关键所在。需求工程师们在了解用户又了解技术的基础上掌控着项目发展的风向标。需求工程师的工作，可以概括为四个方面：需求获取、需求分析、编写需求规格说明书和需求评审。

1. 需求获取的目的是确定对目标系统的各方面需求。涉及到的主要任务是建立获取用户需求的方法框架，并支持和监控需求获取的过程。

2. 需求分析是对获取的需求进行分析和综合，最终给出系统的解决方案和目标系统的逻辑模型。

3. 编写需求规格说明书作为需求分析的阶段成果，可以为用户、分析人员和设计人员之间的交流提供方便，可以直接支持目标软件系统的确认，又可以作为控制软件开发进程的依据。

4. 需求评审是对需求分析阶段的工作进行复审，验证需求文档的一致性、可行性、完整性和有效性。对客户进行需求调研，整理客户需求，负责编写用户需求说明书；负责将完成的项目模块给客户做演示，并收集完成模块的意见；协助系统架构师、系统分析师对需求进行理解。

2. 需求基础

需求一直是软件工程中较为模糊的词汇之一。提起需求，不同背景的人（用户、开发者）会有不同的看法。IEEE对需求的定义中:1、用户为了解决问题或达到某些目的所需的条件或能力；2、系统为了满足合同、标准、规范或其他正式文档所规定要求所要具备的条件或能力； 3、对1或2中的一个条件或一种能力的一种文档化表述。

满足了需求就是解决了问题。需求源于问题，要准确理解需求，就必须明确它与问题的关系。要解决问题有几个方面。1）问题域：要解决问题，就需要改变现实中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。这些实体和状态构成了问题解决的基本范围，称为该问题的问题域。2）解系统：软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。3）共享现象：软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模型、处理模型等。 问题域中的某些信息能够和模型中的信息建立映射关系，这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象。4）需求规格说明：解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征。5）约束：问题域中有些特性完全不受共享现象（解系统）的影响，同时却可能很大程度上影响共享现象、解系统，甚至关乎解系统的成败。这些特性被认为是解系统对环境的依赖特性。特性非常明确时，称为约束；特性不明确时，称为假设。

需求和问题都是有层次性的。我们的软件产品或者项目，其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次软件需求包括3个不同的层次：1)业务需求、用户需求和功能需求。 业务需求表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求文档。2)功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求，因为习惯上总是用"应该"对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性，是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。 3)系统需求用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。 业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。 功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。

在软件系统的开发和使用中，人们很自然地关注系统的功能，它是系统能够为用户提供帮助的第一要素。为了度量一个系统的质量，人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征即为质量特性。包括了以下质量特性：

安全性：指软件系统同时兼顾向合法用户提供服务，以及阻止非授权使用的能力。

易用性：指软件系统易于被使用的程度。

可靠性：软件系统在一定的时间内无故障运行的能力。

持续可用性：指系统长时间无故障运行的能力。

互操作性：指本软件系统与其他系统交换数据和相互调用服务的难易程度。

开发期质量属性

易理解性：指设计被开发人员理解的难易程度。

可扩展性：软件因适应新需求或需求变化而增加新功能的能力。也称为灵活性。

可重用性：指重用软件系统或某一部分的难易程度。

可测试性：对软件测试以证明其满足需求规范的难易程度。

可维护性：当需要修改缺陷、增加功能、提高质量属性时，定位修改点并实施修改的难易程度；

可移植性：将软件系统从一个运行环境转移到另一个不同的运行环境的难易程度。

满足这些质量属性是十分重要的，真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往比满足功能需求更为重要。而要做出一份优秀的需求，要满足几个重要的质量属性：1）完备性；2）正确性；3）可行性；4）必要性；5)无歧义；6）可验证。理想情况下，需求应该即是解决用户问题所需要的，又是表达清晰的：既是用户的需要，又是开发者的需要。只有需求满足了应该具有的特性，才能开发出合格的软件或系统。

第三章 需求工程过程

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

需求工程过程包括如下主要活动：

⑴获取需求。深入实际，在充分理解用zhi户需求的基础上，获dao取足够多的问题领域的知识，积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合解决领域问题的用户需求。需求获取的方法一般有问卷法、面谈法、数据采集法、用例法、情景实例法以及基于目标的方法等。

⑵ 需求分析与建模。对已获取的需求进行分析和提炼，进行抽象描述，建立目标系统的概念模型，需求概念模型的要求包括实现的独立性:不模拟数据的表示和内部组织等；需求模拟技术又分为企业模拟、功能需求模拟和非功能需求模拟等。进一步对所建立的模型（原型）进行分析。需求模型的表现形式有自然语言、半形式化(如图、表、结构化英语等)和形式化表示等三种。

⑶ 需求规格说明。对需求模型进行精确的、形式化的描述，为计算机系统的实现提供基础。

⑷ 确认需求。以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性，确保需求说明准确、完整地表达系统的主要特性，就是对需求规格说明与用户达成一致。其主要任务是冲突求解，包括定义冲突和冲突求解两方面。常用的冲突求解方法有：协商、竞争、仲裁、强制、教育等，其中有些只能用人的因素去控制。

⑸ 需求管理。在整个需求工程过程中，贯穿了需求管理活动。需求管理主要包括跟踪和管理需求变化，支持系统的需求演进。由于客户的需要总是不断（连续）增长的，但一般的软件开发又总是落后于客户需求的增长，如何管理需求的进化(变化)就成为软件管理的首要问题。对于传统的变化管理过程来说，其基本成分包括软件配置、软件基线和变化审查小组。当前的发展是软件家族法，即产品线方法。多视点方法也是管理需求变化的一种新方法，它可以用于管理不一致性，并进行关于变化的推理。进化需求是十分必要的。

从需求工程各项活动的内容来看，需求开发活动似乎可以遵循"需求获取-需求分析-需求规格说明-需求验证"的路线顺序执行，并成功地产生有效的成果文档。但正如软件开发过程的瀑布模型一样，实践者们很快就发现这个线性顺序的过程可以用于解释需求开发中的活动内容，却无法用于组织成功的需求开发。需求开发不仅是迭代的，而且它的两个重要活动------需求获取与需求分析------还是交织的。需求获取与需求分析是需求开发中的两个主体活动，它们共同构成一个学习过程。由各种现象说明，实际的需求开发过程应该是"获取、分析------重构------再获取、分析------再重构------···"这样一个获取与分析交织并迭代的过程。

在RUP中定义了需求工作流程的工作目的：

1，客户和其他涉众*在系统的工作内容方面达成并保持一致。

2，使系统开发人员能够更清楚地了解系统需求。

3，定义系统边界（限定）。

4，为计划迭代的技术内容提供基础。

5，为估算开发系统所需成本和时间提供基础。

6，定义系统的用户界面，重点是用户的需要和目标。

涉众：涉众是所有会受到项目结果重大影响的人。如客户（或客户代表）用户（或用户代表）、投资者 、股东 、生产经理 、买方 、设计员、测试员 、文档编写员等

很多人认为需求管理的目的是为了控制需求过程，这是没有错，但是在RUP的思想中，更重要的思想是迭代。迭代的目的是为了发展，为了进化，为了完善。所以RUP中的软件生命周期是分为多个迭代周期的（软件生命周期将会在下文讨论）。

迭代：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。

是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目，很多时候，用一些非正规的方法来生成原型：如果你要开发一个WEB系统，让你的美工做几个页面给用户看看，如果你做一个C/S系统，做一个界面给用户，都已经足够用了，甚至你完全可以在黑板上画一画你将来的软件的面貌都可以。用户大都是比较友善的，不要把问题想的过于复杂。

需求的标准

讨论软件需求的文章有很多，对于需求的标准也不尽相同，但是在思想上是相同，都是为了保证项目的顺利进行。这里我总结一些比较通用的标准，可能并不完善，但你只要能保证做到这几点，你的项目就不容易失败：明确(Clear)、完整(Complete)、一致(Consistent)、可测试(Testable)，此外还有其他的概念，如可跟踪、可修改等等。

煮鸡蛋的启示，有个英国人学煮鸡蛋，开始，他把鸡蛋放到开水里煮时总会炸裂。他为此想了各种方法，并找到了一个解决方案：在鸡蛋上打个孔。但在鸡蛋上打孔带来了另一个问题:孔打小了，鸡蛋还会裂；孔打大了，蛋清会在它凝固以前流出来。于是，这个英国人给一批鸡蛋分别打了各种不同孔径的洞，并记录下每个鸡蛋孔径的大小。通过这一方法，他找到了一个最合适的大小──既避免了炸裂，又保证蛋清不会流出来。这时，虽然煮鸡蛋炸裂的问题解决了，但这个英国人仍然不知道煮多长时间才能把鸡蛋煮熟。为了解决这个问题，他又开始尝试煮不同时间的结果，并从中找出最佳的时间长度。最后，他终于找到了一个放之四海而皆准的煮鸡蛋的方法。这个案例对很多中国人来说是个可笑的例子。因为聪明的中国人早就知道把鸡蛋放在水中与之一起加热至鸡蛋浮起来就可以了。

从煮鸡蛋这样一个小小的事件上，中国人和英国人体现了两种完全不同的思维习惯──中国人凭借他的聪明直奔结果，而英国人却仔细地把每一个过程细化到最简单，然后按部就班地执行。

典型的几种生命周期模型包括瀑布模型、快速原型模型、迭代模型。

瀑布模型（Waterfall Model），首先由Royce提出。该模型由于酷似瀑布闻名。在该模型中，首先确定需求，并接受客户和SQA小组的验证。然后拟定规格说明，同样通过验证后，进入计划阶段…可以看出，瀑布模型中至关重要的一点是只有当一个阶段的文档已经编制好并获得SQA小组的认可才可以进入下一个阶段。这样，瀑布模型通过强制性的要求提供规约文档来确保每个阶段都能很好的完成任务。但是实际上往往难以办到，因为整个的模型几乎都是以文档驱动的，这对于非专业的用户来说是难以阅读和理解的。想象一下，你去买衣服的时候，售货员给你出示的是一本厚厚的服装规格说明，你会有什么样的感触。虽然瀑布模型有很多很好的思想可以借鉴，但是在过程能力上有天生的缺陷。

迭代式模型 ，迭代式模型是RUP推荐的周期模型，也是我们在这个系列文章讨论的基础。在RUP中，迭代被定义为：迭代包括产生产品发布（稳定、可执行的产品版本）的全部开发活动和要使用该发布必需的所有其他外围元素。所以，在某种程度上，开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，它类似小型的瀑布式项目。RUP认为，所有的阶段（需求及其它）都可以细分为迭代。每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。迭代的思想如上图所示。

迭代和瀑布的最大的差别就在于风险的暴露时间上。“任何项目都会涉及到一定的风险。如果能在生命周期中尽早确保避免了风险，那么您的计划自然会更趋精确。有许多风险直到已准备集成系统时才被发现。不管开发团队经验如何，都绝不可能预知所有的风险。”（RUP）二者的区别如下图所示：

由于瀑布模型的特点（文档是主体），很多的问题在最后才会暴露出来，为了解决这些问题的风险是巨大的。“在迭代式生命周期中，您需要根据主要风险列表选择要在迭代中开发的新的增量内容。每次迭代完成时都会生成一个经过测试的可执行文件，这样就可以核实是否已经降低了目标风险。”（RUP）

快速原型（Rapid Prototype）模型

快速原型模型在功能上等价于产品的一个子集。注意，这里说的是功能上。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。这个产品只是实现部分的功能（最重要的）。它最重要的目的是为了确定用户的真正需求。在我的经验中，这种方法非常的有效，原先对计算机没有丝毫概念的用户在你的原型面前往往口若悬河，有些观点让你都觉得非常的吃惊。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。至于保留原型方面，也是有一种叫做增量模型是这么做的，但这种模型并不为大家所接受，不在我们的讨论之内。

上述的模型中都有自己独特的思想，其实现在的软件组织中很少说标准的采用那一种模型的。模型和实用还是有很大的区别的。

软件生命周期模型的发展实际上是体现了软件工程理论的发展。在最早的时候，软件的生命周期处于无序、混乱的情况。一些人为了能够控制软件的开发过程，就把软件开发严格的区分为多个不同的阶段，并在阶段间加上严格的审查。这就是瀑布模型产生的起因。瀑布模型体现了人们对软件过程的一个希望：严格控制、确保质量。可惜的是，现实往往是残酷的。瀑布模型根本达不到这个过高的要求，因为软件的过程往往难于预测。反而导致了其它的负面影响，例如大量的文档、繁琐的审批。因此人们就开始尝试着用其它的方法来改进或替代瀑布方法。例如把过程细分来增加过程的可预测性。这个方面的讨论我们会在第5小节中继续

RUP和XP

RUP是瑞理（Rational）公司经过不断的实践和理论总结发展出来的一套软件开发统一过程（Unified Process）的思想集和方法集。还记得我们在第一章的那张图吗，那就是RUP的核心图。RUP把软件开发过程分成4个阶段（Phases）和9个核心工作流程（Core Workflows），通过一次次的迭代（Iterations），完成整个的软件生命周期。RUP可以把软件开发过程分到非常细小的单位，每个角色（Workers）都参与活动（Activities），产生出工件（Artifacts）。由于精密的控制，所以RUP可以胜任于超大型的项目开发。虽然RUP定义了很多微小的活动，但是由于CASE工具的使用，它并不会像传统瀑布模型那样陷入文档的海洋中。RUP通过适当的剪裁，同样可以试用于较小型的项目。

XP（Extreme Programming），极端编程。不过好像并没有这样翻译的（听上去像是计算机领域的极右组织）。它是由Kent Beck大师提出的。大师在经历传统软件开发的痛苦之后，希望能够找到一种优秀的软件开发方法。大师总结了大量的软件的成功和失败的因素之后，提出了改进软件开发方法的四个要素：沟通（communication）、简单化（simplicity）、反馈（feedback）、勇气（courage）。这形成了XP的核心价值观。在经历了数年的发展，XP在软件开发的各方面都发展出了众多的方法来支持软件开发。[6]

另外，相比于需求方法本身的好坏，需求方法与软件开发方法的适配性更会影响项目的成败，也就是会所需求开发方法与软件开发方法是否适配，比结果需求的好坏更能影响项目的成败。需求开发过程之所以对后续软件开发过程有重要影响，并不仅仅是因为它的结果制品------需求------是后续开发过程的工作基础，更要认识到需求开发过程中还会产生很多正性影响。

以上是对前三章的认识与记录，通过前三章的学习，对需求分析与建模这门课程有了大致的了解。软件需求是开发者和用户交互的一个过程，任何一方的不投入都会导致项目的失败。当然，由于用户不是专业人士，开发者有权利告诉用户应该采用何种态度来对待项目的需求。所有最成功的项目都有一个重要的特性：用户非常的支持。

评判一个软件项目成功的标准是看它是否解决了用户的问题，而用户的问题就是体现为用户的需求，需求也就顺理成章的成为项目的成功标准。而需求阶段的一个不慎都有可能导致软件实现阶段的大量返工，而需求的不慎不是说你小心就可以的，因为很多需求是隐性的，连用户都不清楚自己的需求。这时候就需要一种科学的方法来帮助软件组织实施需求过程。

大师说：“没有不变的需求，世上的软件都改动过3次以上，唯一一个只改动过两次的软件的拥有者已经死了，死在去修改需求的路上。”

需求是不稳定的，那么需求之中是不是没有稳定的东西呢？有的，就是对象。世界都是由对象组成的，而对象都是持久的，例如动物、植物已经有相当长的时间。虽然对象也在变化，动物，植物也在不断的进化。但对象在一个相当长的时期内都存在，动植物的存在时间肯定比任何一家企业长久。面向对象的开发方法的精髓就是从企业的不稳定需求中分析出企业的稳定对象，以企业对象为基础来组织需求、构架系统。这样得出的系统就会比传统的系统要稳定得多，因为企业的模式一旦变化，只需要将稳定的企业对象重新组织就行了。这种开发的方法就被称为OOAD（Object Orient Analysis & Design 面向对象的分析和设计），而分析出的企业对象就被称为Common Business Object[7]。

《需求工程------软件建模与分析》作为教材，浅显易懂，很容易入门。虽然上个学期已经学了一些这方面的知识，但是并不是很系统，可以通过这本书再稍微了整理一下。

软件需求分析首先明确了软件需求包含的三个不同层次，业务需求即组织机构或客户的需求目标，用户需求即用户使用产品必须要完成的任务，功能需求即开发人员需要实现的软件功能。从需求的定义上我们可以知道需求关注的是究竟想开发什么与设计细节实现细节项目规划信息或者测试信息无关，不重视需求过程会给项目带来极大风险，所以在需求过程中我们要注意避免以下几种情况，无足够用户参与，用户需求不断扩展，用户需求不明确或者说模棱两可，不必要的特性即为软件画蛇添足，过于精简的规格说明，忽略了用户分类，不准确的计划，而高质量的需求过程要求产品开发过程中的通力合作同时充分了解其市场，因此要想完成一份优秀的需求就必须具备完整性，正确性，可行性，必要性，划分优先级，无二义性，可验证性等特性。同时需求规格说明也需具备完整性，一致性，可修改性，可跟踪性。

需求的获取方法之原型：原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看，考察某一方面的可行性。如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确定性。其中主要有两种类别：1 水平原型也叫做"行为原型" ，这是我们和业务人员经常谈到的原型 。探索预期系统的一些特定行为，并达到细化需求的目的。当用户在考虑原型中所提出的功能可否使他们完成各自的业务任务时，原型使用户所探讨的问题更加具体化。它更多从业务需求着手，应用在需求阶段。2 垂直原型 也叫做结构化原型或概念的证明，实现了一部分应用功能。当预期实现阶段可能存在技术风险时，可以开发一个垂直原型。比起在软件的需求开发阶段，垂直原型更常用于软件的设计阶段以减少风险。从原型存在生命时机考虑分为抛弃型原型和进行型原型，抛弃型原型不作为最终产品的一部分，只是作为探索性的回答一些需求问题，细化需求并提高需求质量。由于在开发阶段最终将抛弃这些原型，因此不需要花太大力气去建立该原型。进化型原型是在已经清楚地定义了需求的情况下，为开发渐进式产品提供了坚实的开发基础，作为产品的部分实现。与抛弃型原型的快速、粗略的特点相比，进化式模型一开始就必须具有健壮性和产品质量级的代码。因此，对于描述相同的功能，建立进化型原型比建立抛弃型原型所花的时间要多。一个进化型原型必须设计为易于升级和优化的，因此，你必须重视软件系统性和完整性的设计原则。要达到进化型原型的质量要求并没有捷径。进化型原型一般在处理架构时会采用。

总之需求获取是从人、文档或者环境中获取需求的过程。 需求分析需求分析主要工作是通过建模来整合各种信息，从而使人们更好地理解问题。

参考资料.

1.田忠，钱乐秋.需求工程综述.[J].上海.复旦大学计算机科学系

2. 刘忠宝，赵文娟.需求工程现状和发展研究.[J].山西.电脑开发与应用.第 24卷 第 11期.1003-5850( 2011) 11-0001-04

3. Ba lzer R, Go ldman N. Principles of Goo d Softw are Specificatio n and Th eir Implications for Specification Languag e [ C ] / /Proc Spec Reliable Softw are Conf,1979 : 58-67.

4. Tu Yan，Yang Zijiang，Benslimane Y． Towards an optimal classification model against imbalanced data for customer relationship management[ C] / /2011 Seventh International Conference on Natural Computation．[ s． l．]: [ s． n． ]，2011: 2401－2045．

5. Crone S F， Lessmann S， Stahlbock R． Empirical comparison and evaluation of classifier performance for data mining in customer relationship management neural networks[ C] / /Proceedings of 2004 IEEE International Joint Conference．[ s．l．]: [ s．n．]，2004．

6. https://www.cnblogs.com/SGSoft/articles/79871.html

7. https://docs.oracle.com/en/cloud/saas/sales/18b/oesws/Custom-Common-Business-Object-CrmCommonReferenceService-svc-10.html