A001-185-2539-陈丹

作业A001-185-2539-陈丹
课程名称 软件需求分析与建模
班级 18软件工程5班
教导教师 董瑞生
陈丹 1814080902539
日期 2020.10.4

---

目录

---

---

# 第一章 需求工程导论 第一章主要介绍软件需求工程产生的背景，软件需求工程和软件需求工程师的定位和主要关注内容。本章的重点是帮助读者认识到软件需求工程的复杂性和需求工程中非技术因素的重要性。 ## 生产中的需求问题 需求问题是当今软件开发面临的主要问题。 ## 需求因素 •用户参与（用户输入） • 高层管理支持 • 清晰的需求说明 • 切合实际的期望 • 清晰的目标和前景 • 需求变化 • 额外的无用功能 ## 软件的模拟性 软件的模拟性： 软件的模拟特性来源于其知识载体的特性：软件在运行中表现岀来的特性、行为应该和应用的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件“模拟”了现实。 软件对现实世界的“模拟”并不是机械和被动的。在投入使用之后，它也会通过相应 的对外接口对其周围环境产生必要的影响，并进一步帮助人们解决现实世界中遇到的问题。只是它必须以准确的现实理解为基础，在现实的制约之下对外施加影响，进而解决问题。 应用型软件在“模拟”现实的基础之上接收用户的请求，协助用户完成任务，它正确工作的 基础是具有“模拟”性。“模拟”性具体是指以下几点： ①目的性。软件的目标是直接或间接地满足用户的某些目的或者解决用户的某些问题，软件的功能是据此设立的。 ②正确性。软件具备的功能能够保证目标的正确实现。 ③现实可理解性。软件实现其功能的基础、手段和过程是在用户领域内现实可理解的，即软件系统是在理解其现实环境的基础上，通过影响现实的某些环节，或者改变现实各部分的通信方式，最终达成某些目的或者解决某些问题的。 ## 需求问题的具体原因分析 软件生产中产生需求问题的最大原因在于对应用软件的模拟特性理解不透彻或应用不坚决，它会导致软件开发者产生轻视需求的态度问题。另外，还有一些技术原因也会导致需求问题的产生。 1.非技术性和社会性因素重视不足 应用型软件的模拟特性使得需求处理具有很突岀的特性。相对于软件开发的其他阶段而言，需求处理阶段涉及更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。 20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和社会性因素重 视不足。 但在需求处理阶段除了需求建模与分析活动之外，还有其他的活动也应得到重视，理解需求处理中涉及的非技术性和社会性因素与理解建模分析技术一样必要。 2.传统需求分析方法的缺陷 传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功，但它们并不非常适合于需求阶段的技术处理需要，因此它们在需求处理中的应用具有一定的先天缺陷。 传统的结构化方法和面向对象方法都是最先在编程领域取得成功的，它们所用的概念和组织机制都是从编程领域抽象出来的。其后，它们又都相继被用来进行软件设计，因为设计和编程都有构建高质量(健壮性、可维护性、适应性等)软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡，所以它们在设计领域的应用也取得了成功。而后它们又被进一步应用到分析领域，但是需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要 的目标是理解现实，而这是传统分析方法所拥有的概念和组织机制所无法实现的，所以说传统分析方法在需求分析领域的应用具有先天缺陷。 3.软件规模的日益扩大 20世纪90年代之后大量出现的以“企业”为中心的软件反映了软件规模日益扩大的发展趋势，这一方面提高了需求处理中非技术性和社会性因素的影响比重，另一方面也进一步放大了传统技术在需求处理阶段的不适应性。 当软件以企业为中心时，它的应用范围会包括企业的各个主要职能部门，包括各部门的主要任务和它们之间任务的协同。这样，该组织的部门划分、传统与惯例、规章和约束、行业特性和行业约定、社会地位和社会价值等组织结构文化和社会背景方面的因素就会对需求分析的正确进行产生一定的影响。而且随着应用范围的扩大，涉众会更加广泛，相互之间的利益冲突也会加剧，因此对商业目标和利益协商的处理要求也变得很有必要，忽视这些非技术性因素会导致整个项目的失败。 4.需求问题的高代价性 需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。 如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。所以在需求处理的过程中的正确性，能极大地节省后期修复所需要付出的代价。 ## 需求工程的定义 定义1：简单来说，需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。 定义2：从细节来说，需求工程是软件工程的一个分支，它关注于软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时它也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。 ## 需求工程的三个主要任务 ①需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束，即要同时说明软件需要“做什么”和“为什么”需要做。 ②需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果，是项目规划、设计、测试、 用户手册编写等很多后续软件开发阶段的工作基础。 ③现实世界是不断变化的世界，因此需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时，为了节省开支和进行需求规格说明的重用，需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。 ## 需求工程的基本活动  需求开发: 需求开发是因为需求工程的“需求”特 性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需求验证4个具体的活动。

需求管理: 需求管理是因为需求工程的“工程”特性而存在的，它的目的是在需求 开发活动之后，保证所确定的需求能够在后续的项目活动中有效地发挥作用，保证各种活动的开展都符合需求要求。

需求获取: 需求获取的目的是从项目的战略规划开始建立最初的原始需求.为此，它需要研究系统将来的应用环境，确定系统的涉众，了解现有的问题，建立新系统的目标，获取为支持新系统目标而需要的业务过程细节和具体的用户需求。

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

需求工程在系统工程中的位置

需求工程的复杂性

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

需求工程师

1.需求工程师是涉众和开发者之间的桥梁，要重视“软技能”，需要创新，需求开发是团队行为。
2.需求工程师需要具备的技能：
（1）熟练掌握软件开发方法 与技术，保证设计出来的软件解决方案既是可行的又是成本效益比有效的。
（2）必须要有非常 精确的表达能力，尤其是文档化能力。
（3）有非常好的交流沟通能力以了解涉众的想法，必须要有抽象建模与分析的能 力以准确定义涉众的想法。
3.需求工程师要重视“软技能”
需求工程师需要掌握的重要软技能包括以下几方面。
(1)交流技能
(2)观察技能
(3)抽象分析与问题解决技能
(4)写作技能
(5)关系协调和团队工作技能
4.需求工程师需要创新
5. 需求开发是团队行为

第二章 需求基础

需求的定义

① 用户为了解决问题或达到某些目标所需要的条件或能力；
② 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；
③ 对①或②中的一个条件或一种能力的一种文档化表述。

满足需求就是解决问题

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

1. 问题域
   问题在现实世界与软件系统的互动中得到解决。软件系统在应用于现实之后，就成为现实世界的一个部分。当然，软件系统不会也不需要与整个现实世界互动，它只需要与现实世界中的一部分互动即可。这部分就是问题的发生地，也是问题解决的基本范围——解决问题必须涉及的事件和事物，［Jackson 1995b］ 将它们称为问题域(problem domain )。
   问题域是需求的背景，要理解需求就必须先理解问题域。
   问题域的背景信息又被称为问题域特性(problem domain feature) o与需求相区别的是，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的引入而发生改变。需求是一种对未来的期望，是可以打折、部分满足甚至不予满足的；而问题域特性是既定现实，可以改善但不能忽视，更不能违背的。
   2.解系统
   软件系统通过影响问题域帮助人们解决问题，所以［Jackson 1995b］称之为解系统(solution system)。在解系统中软件起着主要的作用，它是软件解决方案在通用计算机上的实现。
   解系统是问题的解决手段，并不是问题的产生地，所以解系统并不是问题域的一部分。解系统与问题域之间存在可以互相影响的接口，以实现交互活动。
   3.问题域与需求
   虽然解决问题和满足需求的手段是引入解系统，但问题和需求都来自于用户，用户关注的是问题域，所以需求是用户对问题域中的实体状态或事件的期望描述。需求开发的最原始出发点就是用户需求，或者需求的源头——问题。
2. 解系统与需求规格说明
   解系统的核心是软件解决方案和解决方案在通用计算机上的实现。虽然解决方案及其实现都关注于软件系统本身，但相互间也有所不同。解决方案描述的是软件系统与问题域交互的过程，侧重于软件系统中与外界交互的部分。实现部分则主要是软件内部的组成元素、结构关系、 物理实现等软件系统的构造要素。需求工程所关心的仅仅是解决方案，不涉及软件的实现细节。
   [IEEE 1990]将规格说明定义为：以一种完全的、精确的、可验证的方法规定系统或部件的需求、设计、行为或者其他特性的文件，并经常指明判定这个规定是否满足的过程。
   [IEEE1990]将需求规格说明定义为：规定系统或部件的需求的文档，典型地包括功能需求、 性能需求、接口需求、设计需求和开发标准。

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

问题解决的方法——直接与间接

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

需求开发要遵从层次性

需求的分类

严格意义上的软件需求分类
从严格意义上讲，软件需求是直接或间接关系到软件系统功能的期望。根据不同的分类标准，可以将需求分成不同的种类。在各种需求分类中最常见的是［IEEE 1998］的分类,［IEEE 1998］将需求分成下列几个类别。
① 功能需求(functional requirement):和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。
② 性能需求(performance requirement):系统整体或其组成部分应该拥有的性能特征，如 CPU使用率和内存使用率等。
③ 质量属性(quality attribute)：系统完成工作的质量,即系统需要在一个“好的程度”上实现 功能需求，如可靠性程度和可维护性程度等。
④ 对外接口 (external interface):系统和环境中其他系统之间需要建立的接口，包括硬件接 口、软件接口和数据库接口等。
⑤ 约束(constraint):进行系统构造时需要遵守的约束，如编程语言和硬件设施等。
除了上述5种明确的软件需求类别之外,［IEEE 1998］还指出项目中也可能会出现逻辑数据 需求等其他特殊类型的需求。
除功能需求之外的其他4种类别需求又被统称为非功能需求(non-functional requirement)。 在非功能需求中质量属性对系统成败的影响极大，因此在某些情况下，非功能需求又被用来特指 质量属性。
功能需求
功能需求是软件系统需求中最常见和最重要的需求，同时也是最为复杂的需求。
通常一个软件系统的绝大部分需求都是功能需求。虽然在类别划分上功能需求只是5种类别之一，但在比例上功能需求有可能占所有需求的90%以上。进行这样不均衡比例的划分，是因 为功能需求的处理方式是一致的。
功能需求是一个软件产品得以存在的原因，是软件系统能够解决用户问题和产生价值的基础，也是整个软件开发工作的基础。所有开发者都需要了解功能需求。在复杂的系统中功能需求数量太多，所以需要将它组织为多个独立部分，然后按照分工原则由不同的开发者来处理不同 的部分。
在大规模软件系统中，因为其功能需求比较复杂，所以它是最需要按照3个抽象层次进行展开的需求类别，也就是说功能需求的开发要围绕“目标-任务-交互”的路线进行，对“目标”“任务”和“交互”3个概念的关注是功能需求开发的重中之重。
性能需求
[IEEE 1990]对性能的定义是：一个系统或其组成部分在限定的约束下，完成其指定功能的程度，如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的功能。
常见的性能需求包括以下几种。
① 速度(speed)：系统完成任务的时间，如PR1O
PR1 :所有的用户査询都必须在10 s内完成。
② 容量(capacity):系统所能存储的数据量，如PR2。
PR2：系统应该能够存储至少10万条销售记录。
③ 吞吐量(throughput)；系统在连续的时间内完成的事务数量，如PR3。
PR3：解释器每分钟应该至少解析5 000条没有错误的语句。
④ 负载(load):系统可以承载的并发工作量，如PR4。
PR4：系统应该允许200个用户同时进行正常的工作。
⑤ 实时性(time-critical):严格的实时要求，如PR5。
PR5：监测到病人异常后，监控器必须在0.5 s内发岀警报。
性能需求的定义要适合于运行环境。过于宽松的性能要求会带来用户的不满，过于苛刻的性能要求会给系统的设计造成不必要的负担，所以给出一个合适的量化目标是非常关键的，但同 时也是非常困难的。更加常见的方法是在限定性能目标的同时给出一定的灵活性(如PR6)或 者给出多个不同层次的目标要求(如PR7)。
PR6：98%的査询不能超过10 s。
PR7：(最低标准)在200个用户并发时，系统不能崩溃；
(一般标准)在200个用户并发时，系统应该在80%的时间内能正常工作；
(理想标准)在200个用户并发时，系统应该能保持正常的工作状态。
将性能需求划分为独立的类别，文档化为独立的部分，是因为它有其他类别需求都不具备的动态性一理论上说，只有开发完成并实际运行系统，才能确定软件系统的性能。实际工作中，软件体系结构师、系统工程师等人员需要特别关注性能需求，必要时需要专门进行模拟。
质量属性

1. 质量属性的概念
   在软件系统的开发和使用过程中，人们很自然地关注系统的功能，它是系统能够为用户提供帮助的第一要素。但成功的软件系统除了满足功能需求之外，还需要满足更多的要求，如易于使用和少出错等。
   功能需求是用户对软件系统的显式要求，用户在软件系统创建之前就可以清晰地向开发者表达这种要求。而非功能需求属于隐式要求，用户在软件系统创建之前无法清晰地告诉开发者他们希望该系统具备什么样的非功能性特征。但是在软件系统投入使用之后，他们却可以快速判断出软件系统的哪一部分非功能需求不满足他们的条件。例如，在市场买一双鞋子时，对于鞋子功能（休闲、跑步还是踢足球）的要求是显式的，但是对鞋底是否会脱胶、鞋面坚韧度等特性的要求就是隐式的，虽然不会有明文规定鞋底不能脱胶，但是一旦脱胶就会被认为是鞋子质量不合格。一般认为，具备职业素质的人员能够在用户不提及的情况下认识到用户的隐式要求，否则该人员就是不合格的。
   成功的软件系统必须满足显式的及隐含的各种要求。系统为满足显式的及隐含的要求而需要具备的要素称为质量。
   为了度量一个系统的质量，人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征称为质量属性。
   需要注意的是质量属性需求包含性能需求，只是性能需求比较特殊，所以被独立为单独的类型。
   实际工作中，软件体系结构师会比较关心质量需求，因为妥善解决质量问题是软件体系结构师的主要工作。

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

3. 质量属性的重要性
   质量属性应该和功能需求一样得到足够的重视。真实的现实系统中，在决定系统的成功或 失败的因素中，满足非功能属性往往比满足功能需求更为重要°
   质量属性对设计的影响很大。在软件设计中对任何指定的功能都会有多种可选的方案，不同的方案选择产生不同的设计结果。设计方案的质量因素往往包含很多不同的质量属性，而且不同的质量属性之间互有折中(如提高可移植性往往会导致效率降低，很难会岀现某一个设计方案的质量属性完全优于其他方案的情况。因此，软件设计必须根据需求的质量属性在多种方案中选择一个最优的方案。如果不存在事先定义好的质量属性需求，设计方案的选择将完全没有依据，结果就很有可能导致软件不被用户接受。
   对于一个已经完成的设计，如果需要修改其功能，则需要对设计进行一定的调整或拓展。但如果需要修改其质量属性要求，在复杂的情况下就可能会需要重新进行设计方案的选择，受到的影响就是整个设计而不再仅仅局限于其某个部分。所以，在设计开始之初就确定质量属性要求非常重要，而且对越复杂的系统越为重要。

4. 质量属性需求的开发
   虽然用户会在和需求工程师交流的过程中表达一些和质量属性相关的想法，但因为他们并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组可量化的质量属性，所以一般来说，他们并不能明确地提出对产品质量的期望。
   ［Chung 2000］认为，在用户的叙述中质量属性大多是和功能需求联系在一起的，因此为了发现用户对质量属性的要求，需求工程师需要对照软件的质量属性检査每一项功能需求，尽力去判断质量属性存在的可能性；对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要 在遇到特定的实例时意识到它们的存在。［Cysneiros 2001］通过实践还发现，用户在描述中使用的形容词和副词通常意味着质量属性的存在。
   在发现质量属性后，要想了解用户的真正想法，需求工程师还需要和用户以及开发人员一起 从多个角度进行质量的定义。进行质量属性的定义时，应当将其与相联系的功能需求关联起来。不能和功能需求建立联系的全局性质量属性应该统一进行处理。

5. 常见的质量属性需求
   (1) 可靠性(reliability)
   可靠性是指在规定时间间隔内和规定条件下，系统或部件执行所要求功能的能力。
   (2)可用性(availability)
   可用性指软件系统在投入使用时可操作和可访问的程度，或能实现其指定系统功能的概率。
   (3) 安全性(security)
   安全性是指软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意的，也可能是无意的。
   (4) 可维护性(maintainability)
   可维护性指为排除故障、改进质量或适应环境变化而修改软件系统或部件的容易程度，包括可修改性(modifiability)和可扩展性(extensibility)。
   (5 )可移植性(portability)
   可移植性指系统或部件能从一种硬件或软件环境转换至另外一种环境的特性。
   (6)易用性(usability)
   易用性指与用户使用软件所花费的努力及其对使用的评价相关的特性。
   [Vara 2011]在调査中让调査者分别列举出最为常见的5个质量属性需求以及最为重要的 质量属性，最为常见的质量属性是：易用性、可维护性、性能、 可靠性和灵活性。
   对外接口
   对系统之间的软硬件接口需要说明以下内容：
   •接口的用途；
   •接口的输入输出；
   •数据格式；
   •命令格式；
   ・异常处理要求。

约束
常见的约束主要有以下几种。
① 系统开发及运行的环境，包括目标计算机、操作系统、网络环境、编程语言和数据库管理系统等。
② 问题域内的相关标准，包括法律法规、行业协定和企业规章等。
③ 商业规则。用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围。
④ 社会性因素。文化、信仰等社会性因素。

优秀需求的特性

1.完备性
2.正确性
3.可行性
4.必要性
5.无歧义
6.可验证

第三章 需求工程过程

需求工程的基本活动

需求获取：在需求获取中，需求工程师通常需要执行的任务包括以下几方面。

1. 收集背景资料
2. 获取问题与目标，定义项目前景与范围
3. 识别涉众，选择信息的来源
4. 选择获取方法，执行获取，获取功能与非功能需求
5. 记录获取结果
   需求分析：
   需求分析的主要工作是通过建模来整合各种信息，以使人们更好地理解问题。同时，需求分析工作还会为问题定义一个需求集合，这个集合能够为问题界定一个有效的解决方案。需求分析还需要检査需求中存在的错误、遗漏和不一致等各种缺陷，并加以修正。
   需求分析活动最后会产生一个需求的基线集，它指定了系统（或当前版本的系统）开发需要完成的任务。在资源受限的情况下，这个基线集往往只是用户所要求功能的一个子集，而且需求工程师和用户必须就该子集的取舍达成一致。需求基线集中的需求要具有优秀需求的特性，尤其是一些不一致和冲突的现象必须得到妥善的解决。
   在需求分析阶段，需求工程师主要的任务包括以下几方面。
   背景分析
   问题分析、目标分析、业务分析，确定系统边界
   软件需求建模
   细化需求
   确定优先级
   需求协商
   需求规格说明：
   获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档（或用例文档），系统级需求被写入需求规格说明。
   需求验证：
   需求验证阶段的主要任务包括以下两方面。
6. 执行验证
   执行验证的方法有很多，同级评审是其中最常见、最有效的一个。在有些情况下，也需要使用原型或模拟等代价相对较高的验证方法。
7. 问题修正
   在需求验证的过程中会发现一些问题，这些问题在验证之后必须要及时得到修正。问题修正的过程还应该得到跟踪，以保证修正的落实。
   需求管理：
   在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工作“需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。所以，在需求开发结束之后，还需要有一种力量保证需求作用的持续、稳定和有效发挥，需求管理就是这样的 一个管理活动。

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

课本编写的很准确很好，目录的标识也很清晰。但觉得理论的叙述会偏多一些，如果可以适当地添加一些例子或者图示，更生动些会更好。

附录：引用文献

《需求工程——软件建模与分析》
[Jackson 1995b] JACKSON M. The world and the machine, a keynote address at ICSE- 17. Proceedings of ICSE- 17. ACM Press, 1995.
1 IEEE 1990] IEEE Std 610.12- 1990. IEEE Standard Glossary of Software Engineering Terminology. Institute of Electrical and Electronics Engineering, Inc., 1990.
[IEEE 1998] IEEE Std 830- 1998. IEEE Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineering, Inc., 1998.
[Chung 2000 ] CHUNG L, NIXON B A, YU E, et al. Non - functional requirements in software engineering. Kluwer, 2000.
[Cysneiros 2001 ] CYSNEIROS L M, LEITE J C S P, NETO J S M. A framework for integrating non- functional requirements into conceptual models. Requirements Engineering Journal, 2001, 6(2).
[Vara 2011] VARA J L, WNUK K, SVENSSON R B,et al. An empirical study on the importance of quality requirements in industry. 23rd International Conference on Software Engineering and Knowledge Engineering (SEKE 2011), 2011111111111111111