A001-185-2521-李子泓

实验名称 我对需求分析与建模的认识与应有内容建议 教导教师 董瑞生
姓名 李子泓 学号 1814080902521 日期 2020年10月3号

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

一、需求分析与建模的认识
1、软件生产中所遇到的需求问题**

需求问题是当前软件开发面临的主要问题，无论是实践者的切身体会,还是各种调查数据,都明确指出需求问题是当前软件开发面临的主要问题之一。在所有调查数据中,以美国专门从事跟踪工厂项目成功或失败的权威机构Standish Group的CHAOS系列报告最广为人知。

该项研究分别显示了影响成功项目，问题项目，失败项目的因素通过综合分析表格数据，需求因素对成功项目影响指数为53.9%,对问题项目的影响指数为55.6%,对失败项目的影响指数为60.9%。

除此之外还有许多调查研究，所有这些调查数据表明,和软件需求相关的因素为软件项目所带来的风险和问题已经超过了所有的其他因素,糟糕的软件生产状况背后隐藏着软件工程的需求问题。

2、导致需求问题最为重要的原因

2.1软件的模拟特性

在导致需求问题的原因当中在这些导致需求问题的原因当中,一个最为重要的原因是:末能很好地理解和掌握"应用"型软件的模拟特性以及由此而产生的一系列影响和要求。

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

例如在酒店管理软件中，系统产生一条客人入住的记录，而客人并没有入住，那么这个系统将被认为是存在缺陷的，不正常的，因为系统的记录和现实中的客人入住酒店事件没有保持一致。当系统和现实在保持一致的情况下，客人入住后系统记录下客人的入住信息，通过系统就能查询到客人的房间号，入住时间等信息。

软件的冗余功能问题也从另一个侧面很好地反映了它的模拟特性。在软件开发中,一方面只能完成预期功能的60%~70%[Standish1995],另一方面移交软件中却存在着大量的冗余功能，很少有开发人员能够意识到,这些冗余功能往往也是导致用户不满意和软件不被接受的原因之一。正是因为缺乏这种意识,所以软件开发人员才会在开发中持续不断地超出用户的需求添加"出色功能",进行自我陶醉地为软件"镀金"。

当然,软件对现实世界的"模拟"并不是机械和被动的。在投人使用之后,它也会通过相应的对外接口对其周围环境产生必要的影响，并进一-步帮助人们解决现实世界中遇到的问题。只是它必须以准确的现实理解为基础,在现实的制约之下对外施加影响，进而解决问题。

2.2软件的三种类别

软件可以被分为3种类别:面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和应用型软件。

专业用户通常以软件为中心开展工作,工具软件是他们的主要手段,因此面向专业用户的纯工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。功能的复杂可以让专业用户在执行任务时具有更大的发挥空间和回旋余地。使用的高效可以帮助专业用户更快、更好地完成任务。以上两点的实现都要以先进的技术为必要条件。该类软件以创新性为主要关注点，技术创新是它们的生存之道。

普通用户利用软件的目的通常仅限于解决一些实际问题,软件仅仅是一种辅助性的手段,因此面向普通用户的纯工具型软件以功能的有用性为首要成功标准，一-些过于复杂的功能反而会.因其灵活性而丧失一定的实用性,进而受到用户的抵制。普通用户技术能力有限,所以对操作的要求以使用方便为主,在使用方便的前提下追求使用的高效性。实现功能的有用性和使用的方便性,利用常见的可行技术即可,先进技术并非必要条件。有效性是该类软件的主要关注点,能够有效使用即可占有一-席之地。

应用型软件在"模拟"现实的基础之上接收用户的请求,协助用户完成任务,它正确工作的基础是具有"模拟"性。应用型软件一.般以普通用户为应用对象,因此也要求具有使用的方便性。实现功能的"模拟"性和使用的方便性也仅要求所用技术具有可行性。和工具型软件不同，应用型软件通常不是通用的,它们是为特定的应用环境定制的,对环境的"模拟"性是其主要的关注点。

在实际工作中,开发人员受到的工具型软件相关评判标准、关注点及生产过程的影响过大,就会对应用型软件的"模拟"特性理解不透彻或应用不坚决,进而导致对需求处理阶段重视不足或者在需求阶段轻视领域知识研究,应用型软件的生产就会发生需求问题。

3、需求问题的具体原因

需求分析的具体原因可以分为四点：

（1）非技术性和社会性因素重视不足

在20世纪90年代之前的需求处理往往更专注于技术处理，二对其中的非技术性和社会性因素重视不足

（2）传统需求分析方法的缺陷

传统的需求分析方法,如结构化分析和面向对象分析,都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功,但它们并不非常适合于需求阶段的技术处理需要,因此它们在需求处理中的应用具有一定的先天缺陷。

（3）软件规模的日益扩大

20世纪90年代之后大量出现的以"企业"为中心的软件反映了软件规模日益扩大的发展趋势,这一方面提高了需求处理中非技术性和社会性因素的影响比重,另一方面也进–步放大了传统技术在需求处理阶段的不适应性。

（4）需求问题的高代价性

需求处理是软件工程的起始阶段,设计、实现等后续阶段的正确性都以它的正确性为前提。如果在需求处理过程中有错误未能解决,则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高,需求问题对软件成败的影响较大。统计表明,在需求阶段发生的错误如果到了维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍

4、需求工程简介

4.1需求工程的定义

简单来说，需求工程是所有需求处理活动的总和,它收集信息、分析问题、整合观点、记录需求并验证其正确性,最终反映软件被应用后与其环境互动形成的期望效应。

从细节来看,可以定义如下:需求工程是软件工程的一个分支,它关注软件系统所应实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束,同时也关注以上因素和准确的软件行为规格说明之间的联系,关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。

4.2需求工程的主要任务

通过以上定义可以发现,需求工程有以下3个主要任务：

①需求工程必须说明软件系统将被应用的环境及其目标，说明用来达成这些目标的软件功能，还要说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法所施加的限制和约束,即要同时说明软件需要"做什么"和"为什么"需要做。

②需求工程必须将目标、功能和约束反映到软件系统中,映射为可行的软件行为,并对软件行为进行准确的规格说明。需求规格说明是需求工程最为重要的成果,是项目规划、设计、测试、用户手册编写等很多后续软件开发阶段的工作基础。

③现实世界是不断变化的世界,因此需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。同时,为了节省开支和进行需求规格说明的重用,需求工程还需要对目标、功能和约束在软件产品族中的演化和分布情况进行综合考虑与处理。

4.3需求工程的基本活动

需求工程活动包括需求开发和需求管理两个方面:

需求开发是是专门用来处理需求的软件技术.包括需求获取、需求分析、需求规格说明和需求验证4个具体的活动。

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

4.4需求工程与系统工程

系统需求开发的主要目的是获得整个系统的期望目标,包含功能特征和非功能特征(如性能要求等)。为此需要判断系统的涉众，采集他们的目标与要求,研究系统的环境,确定系统的约束,并进行一些整体性的需求分析。系统需求开发阶段的需求分析主要是分析系统的成本效率.及系统的组织和行政策略,处理互相依赖、冲突、重叠或不一-致的涉众需求,检查并弥补需求缺失,检查技术储备、外部系统等环境约束。系统需求开发的结果会写人系统需求规格说明。

系统需求开发阶段获得的需求将被分配到软件工程、硬件工程或人力工程部分。其中硬件工程和人力工程的需求一般比较容易落实,但软件工程的需求还需要进行更加细致的处理,即进行软件需求开发。软件需求开发用来确定系统需求中应该由软件满足的部分,将其映射为软件行为,产生软件需求规格说明。

5、需求工程的重要性

软件开发是一个工程性的问题,这一点已经被人们广泛接受。软件开发者的任务就是开发一个软件系统,将之应用于现实世界,并通过软件系统和现实世界的交互，影响和改变现实世界。在这个过程中,软件开发者并不是要从物理结构开始针对问题建立–个特定的计算机,而只是描述所需软件系统的特征和行为，然后通过编程在通用计算机上实现,使之表现出之前所描述的特征和行为。因此软件开发是这样一个工程问题:利用通用的计算机结构构建-一个有用的软件系统,来满足人们的某些目的。

由于计算机应用于现实世界的广泛性,所以软件工程师的工作也具有行业上的广泛性。这就要求他们在不同的行业领域里都表现出优秀的工作能力,例如，一个在金融领域软件开发中成绩斐然的工程师也应有能力在医疗领域进行成功的软件开发。这就带来了问题和解决方案的广泛性。但是软件工程师不可能了解所有的领域,所以在软件开发中他们常常要同时面对新的问题和提出新的解决方案。

因为总要面临新的问题,所以软件工程师常常需要将工作中很大的–部分用来定义问题,然后再为其设计一个新的解决方案。定义问题就是需求工程的任务，所以除了一些特殊情况之外,在软件开发中进行需求工程是非常必要的。

6、需求工程的复杂性

1、处理范围广泛

2、涉及诸多参与方

3、处理内容多样

4、处理活动相互交织

5、处理结果要求苛刻

7、需求的定义

什么叫做需求，不同背景的人（用户、开发者）对需求会有不同的看法，因此需求这个词在需求工程中一个非常难以定义和解释的概念，在教材中更倾向于IEEE的需求定义：

①用户为了解决问题或达到某些目标所需要的条件或能力;

②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力;

③对①或②中的一个条件或一种能力的一.种文档化表述。

IEEE的定义中同时包括了用户的观点(第一种条件和能力)和开发者的观点(第二种条件和能力),它强调了"需求"的两个不可分割的方面:需求是以用户为中心的,是与问题相联系的;需求要被清晰、明确地写在文档上。

8、满足需求就是解决问题

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

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

问题解决的基本范围------解决问题必须设计的事件和事务，将它们称之为问题域。问题域特性是既定现实,可以改善但不能忽视，更不能违背的。

解系统是问题的解决手段。

8.2问题域与需求

问题和需求都来自于用户，用户关注的是问题域，所以需求是用户对问题域中的实体状态或事件的期望描述，需求开发的最原始出发点是用户需求，需求的源头是问题。

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

处于问题域之外的解系统之所以能解决问题域中的问题,是因为问题域与解系统之间存在有效的互动,并在互动中互相影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域,将这种模拟性称为共享现象( share phenomenon)。

简单地讲，模拟是指其中一方仿制另一方的信息。解系统对问题域的模拟则更加复杂一些，它们之间的模拟性带有交互性:一方面,解系统会在自身中保持一份与问题域现象一致的信息，并随着问题域现象的变化而变化;另一方面,问题城会期待在解系统中看到一致的信息,并据此展开自己的行为。

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

因为模拟后的知识一共享现象,是解系统的一部分,所以解系统可以对其施加操作,适当改变这些知识。知识的改变会通过交互性传递给问题域,问题域在会接受改变的基础上继续规律性的运作，使问题得以解决。模拟并操纵共享现象是软件系统满足需求最直接的方法

有些情况下软件系统也会使用间接的方法解决问题:软件系统操纵共享现象影响问题域的一部分,然后利用问题域内在的规律性自动影响另一部分。例如,图书管理员希望能够督促那些超期的借书者尽快归还图书,直接的解决方式是软件系统将借书者的联系方式建模为表Contact,并自动使用Contact的数据完成督促告知(如发送邮件)。但是如果软件系统中没有存储借书者的联系方式,即软件系统的共享知识中没有解决问题所需要的信息,就只能通过间接的方式来满足需求了，这时软件系统可以将超期者的名单告知图书管理员,然后由图书管理员逐一打电话督促归还。

9、需求和问题都有层次性

9.1需求的3层抽象层次

需求是问题解决的期望，问题可大可小，期望耶可大可小，问题和期望粒度不同的现象被称为需求的不同抽象层次。需求最为常见的抽象层次有3层:①业务需求(businessrequirement),针对整个业务的期塑,②用户需求( user requirement) ,针对具体任务的期望。③系统级需求( system requirement) ,针对用户与系统一次交互的期望。

业务需求是抽象层次最高的需求,是系统建立的战略出发点，表现为高层次的目标(objective) ,它描述了组织为什么要开发系统。业务需求通常来自项目的投资人、购买产品的顾客、实际用户的管理者、市场营销部门或产品策划部门。业务需求必须是可验证的,其验证标准可以是一个数值指标

为了满足用户的业务需求,需求工程师需要描述系统高层次的解决方案,定义系统应该具备的特性( feature)。高层次的解决方案及系统特性指出了系统建立的方向,参与各方必须就它们达成一致，以建立一个共同的前景( vision),保证涉众朝着同一个方向努力。以支持业务需求的满足为衡量标准,系统特性说明了系统为用户提供的各项功能,它限定了系统的范围( scope),定义良好的系统特性可以帮助用户和开发者确定系统的边界。

高层次的日标是由组织的决策者提出的,但普通用户才是组织中任务的实际执行者,只有通.过一套具体并且合理的业务流程才能真正实现目标。用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望,描述了系统能够帮助用户做些什么。用户需求主要来自系统的使用者一用户。在有些情况下,系统的直接用户不可知,如通用的软件系统或社会服务领域的软件系统等,所以用户需求也可能来自间接的渠道,如销售人员和售后支持人员等。

需要注意的是:在3个层次中,只有用户需求在表述时在不可验证性上要求较为宽松。因为用户需求具有下面几个特点:

①模糊、不清晰。用户需求允许适度使用形容词和副词,使得描述常常带有模糊和不清晰的特性。

②多特性混杂。在用户进行需求描述时,常常将功能需求和非功能需求混杂在–起。

③多逻辑混杂。用户需求是对用户任务的描述,而任务本身往往含有前后相继的多个逻辑处理过程,即一个任务需要进行多次系统交互才能够完成。

用户需求表达了用户对系统的期望,但是要透彻和全面地了解用户的真正意图,仅仅拥有期望是不够的,还需要知道期望所来源的背景知识。因此,对所有的用户需求都应该有充分的问题域知识作为背景支持。而在实际工作中,用户表达自己的期望时,通常不会提及需求所涉及的问题域知识,所以需求工程师需要根据用户的需求整理完整的问题域知识。

适合软件开发者的需求层次是系统级需求,它关注的是软件系统的行为,尤其是系统与外界的交互行为:在接收到一个外界请求时,软件系统应该给外界提供响应。所以系统级需求的典型形式是"系统可以xxx"或者"在xx用户提出xx请求时，系统应该xxx"。系统级需求比用户需求更加详细和准确，包含更多的技术细节。

因为系统级需求比用户需求更详细,数量更多,所以为了节省开发时间,在实际开发中有些开发者更愿意使用用户需求而不是系统级需求作为后续开发的基础。这种做法在一定程度.上是可行的，但也有风险:用户需求不够准确，给开发人员提供了过大的发挥空间,可能导致开发人员在需求理解.上出现偏差,因为开发人员未能从用户需求描述中得到足够信息以准确地完成设计与实现工作，就只能以自身的经验进行假设,这些假设未必是合理的。一个软件系统的系统级需求集合定义了相应业务需求及用户需求的解决方案,构成了需求规格说明的主体部分。

9.2需求开发要遵从层次性

在3个不同层次的功能需求中，业务需求具有明显的目的.性和较高的抽象性,比较容易获取和确认。所以需求开发往往从获取业务需求开始。有了业务需求之后，就可以确定系统的!最终目标和努力方向,进而指导具体的需求获取活动,发现用户需求。用户需求经过明确和细化的处理,可以转化为系统级需求。

从另一个角度讲，系统开发者理想中的需求是系统级需求，因为开发者可以直接将系统级需求映射为系统行为,进行设计和开发。

但是因为系统级需求是无法直接或间接从现实中获取的,所以开发者只能退而求其次一获取用户需求,并通过分析活动将其转化为系统级需求。

随之而来的另一个问题是,用户需求的获取过程非常复杂，涉及众多参与者和诸多问题，要成功地获取用户需求,首先要协调参与者的立场和问题的范围，而这只能通过对业务需求的处理进行解决一根据业务需求，协调涉众的立场，限定问题的范围,指导用户需求的获取过程。

10、需求分析与建模

10.1需求分析的根本任务

(1)建立分析模型,达成开发者和用户对需求信息的共同理解

分析可以将复杂系统分解成简单的部分并明确它们之间的联系,确定本质特征,并抛弃次要特征。这样,分析就可以抽取出信息的本质含义，帮助开发者准确理解用户的意图，和用户达成对信息内容的共同理解。分析的活动主要包括识别、定义和结构化,其目的是获取某个可以转换为知识的事物的信息,这种分析活动被称为建模(modeling)—建立需求分析模型。

(2)依据共同的理解,发挥创造性,创建软件系统解决方案

分析可以将-一个问题分解成独立的、更简单和易于管理的子问题来帮助寻找解决方案。分析可以帮助开发者建立问题的定义,并确定被定义的事物之间的逻辑关系。这些逻辑关系可以形成信息的推理,进而可以被用来验证解决方案的正确性。创建解决方案的过程是创造性的。

10.2建立分析模型

模型是对事物的抽象，帮助人们在创建一个事物之前有更好的理解"[Blaha2005]。

建立模型的过程被称为建模。“它是对系统进行思考和推理的- -种方式。建模的目标是建立系统的一.个表示,这个表示以精确一致的方式描述系统,使系统的使用更加容易”[Fishwick1994]。

[ Satzinger 2004]认为在软件开发中建立软件模型有以下好处:

●通过建模抽象降低应用的复杂性。

●在建模的过程中更深刻地理解信息。

●可以帮助人们更好地记忆细节。

●可以更好地与其他开发人员进行交流。

●可以更好地与用户以及其他涉众进行交流。

●为以后的维护和升级提供文档。

二、应有内容建议

1、需求背景

面对一个错综复杂的场景，产品经理最好的做法是循序渐进，从最粗略的项目背景，业务目标开始，然后分析业务流程，再到界面展示。所以我们首页需要对产品所服务的业务领域有一个概括性的了解。我们可以从行业背景、业务目标、问题痛点等方面进行调研。

现实中，对于项目背景的调研，往往是我们产品人员容易忽略的，忽略的一个最大的风险是：我们不能很清晰准确的把握客户的期望值和建设目标，从而给项目交付带来风险。所以，在开展工作之前，进入项目背景调研是非常重要的环节。

2、全面的需求分类

从严格意义上讲,软件需求是直接或间接关系到软件系统功能的期望。根据不同的分类标准，可以将需求分成不同的种类。在各种需求分类中最常见的是[ IEEE 1998]的分类,[ IEEE1998 ]将需求分成下列几个类别。

①功能需求(functionalrequirement):和系统主要工作相关的需求,即在不考虑物理约束的情况下,用户希望系统所能够执行的活动,这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。

②性能需求(performancerequirement):系统整体或其组成部分应该拥有的性能特征，如CPU使用率和内存使用率等。

③质量属性( quality ttribute): 系统完成工作的质量，即系统需要在一.个" 好的程度"上实现功能需求，如可靠性程度和可维护性程度等。

④对外接口(external interface) :系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口和数据库接口等。

⑤约東(eonstraint):进行系统构造时需要遵守的约束,如编程语言和硬件设施等。

除了，上述5种明确的软件需求类别之外,[IEEE1998]还指出项目中也可能会出现逻辑数据需求等其他特殊类型的需求。在非功能需求中质量属性对系统成败的影响极大,因此在某些情况下,非功能需求又被用来特指质量属性。

2.1功能需求

功能需求是软件系统需求中最常见和最重要的需求,同时也是最为复杂的需求。通常-一个软件系统的绝大部分需求都是功能需求。虽然在类别划分上功能需求只是5种类别之一,但在比例上功能需求有可能占所有需求的90%以上。进行这样不均衡比例的划分,是因为功能需求的处理方式是一致的。

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

2.2性能需求

[IEEE1990]对性能的定义是:一个系统或其组成部分在限定的约束下,完成其指定功能的程度,如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的功能。

常见的性能需求包括以下几种。

①速度(speed):系统完成任务的时间

②容量(capacity):系统所能存储的数据量

③吞吐量(throughput):系统在连续的时间内完成的事务数量

④负载(load):系统可以承载的并发工作量

⑤实时性( time-critical) :严格的实时要求

2.3质量属性

为了度量一个系统的质量,人们通常会选用系统的某些质量要素进行量化处理，建立质量特征,这些特征称为质量属性。

需要注意的是质量属性需求包含性能需求，只是性能需求比较特殊，所以被独立为单独的类型。

质量模型：

为了更好地根据质量属性描述和评价系统的整体质量,人们从很多质量属性的定义中选择了一些能够相互配合、相互联系的特征集,它们被称为质量模型。最为常见的质量模型有[ ISO/IEC 9126- 1]和[ IEEE 1061- 1992,1998]两个。

质量属性应该和功能需求- -样得到足够的重视。真实的现实系统中，在决定系统的成功或失败的因素中,满足非功能属性往往比满足功能需求更为重要。

常见的质量属性：

(1)可靠性( reliability )可靠性是指在规定时间间隔内和规定条件下，系统或部件执行所要求功能的能力

(2)可用性( availability)可用性指软件系统在投入使用时可操作和可访问的程度，或能实现其指定系统功能的慨率.

(3)安全性( security)安全性是指软件阻止对其程序和数据进行未授权访问的能力,未授权的访问可能是有意的，也可能是无意的.

(4)可维护性( maintainability )可维护性指为排除故障、改进质量或适应环境变化而修改软件系统或部件的容易程度,包括可修改性(modifability)和可扩展性(extensibilit),如QR4.

(5)可移植性( portability)可移植性指系统或部件能从一种硬件或软件环境转换至另外–种环境的特性.

(6)易用性( usability )易用性指与用户使用软件所花费的努力及其对使用的评价相关的特性

2.4对外接口

对于解系统而言,问题域中的其他软件系统也属于问题域的一部分,且为一个比较特殊的部分。因此用户有权对解系统和其他系统之间的软硬件接口提出要求。解系统的对外接口也是一种重要的需求。对系统之间的软硬件接口需要说明以下内容

●接口的用途;

●接口的输人输出;

●数据格式;

●命令格式;

●异常处理要求。

用户界面在有些情况下也会被视为系统的对外接口,被作为一种重要的需求。但[ CMU/SEI1991]认为,和其他需求相比,用户的界面更经常发生变化,进而影响需求的稳定性,所以常,对于人机交互复杂的系统使用单独的人机交互设计文档记录用户界面需求,否则可以将其作为需求文档的一部分进行记录

3、约束

约束是不受解系统影响,却会给解系统带来极大影响的问题域特性。因为不受解系统的影响，所以从解决问题的角度来看约束不会要求解系统为其进行专门的设计。但是如果解系统不满足约束,那就意味着问题域并不能够提供解系统要求的运行环境,解系统将无法在问题域内成功地部署和运行。因此,约束是在总体上限制了开发人员设计和构建系统时的选择范围。

这些约束通常会影响后续的体系结构设计、详细设计、实现、测试等软件开发活动。常见的约束主要有以下几种。

①系统开发及运行的环境(如Constraint-1)。包括目标计算机、操作系统.网络环境、编程语言和数据库管理系统等。Constraint-1:系统要能够在Windows和Linux两种操作系统上运行。

②问题域内的相关标准(如Constraint-2)。包括法律法规、行业协定和企业规章等。Constraint-2:系统的保密性能要符合xxx法律第xxx条的要求。

③商业规则。用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围。

④社会性因素。文化、信仰等社会性因素。

进入21世纪以来,随着Internet的发展，软件系统在社会生活中出现得越来越多,影响越来越大,所以约束变得越来越重要,尤其表现在法律规则[ Otto 2007]和社会性因素[ Yu 2010, Mine2011]这两个方面。规则往往是需求文档的一个重要部分。

4、其他需求

1.完备性

优秀的需求是完备( complete)的,它不需要做更多的扩展就可以充分说明用户需要的系统功能。完备性的判断标准是:需求是否描述了开发人员设计和实现这项功能所需的所有信息。

2.正确性

每一项需求都必须正确描述所需要的系统功能，要真实反映用户的意图,所以需求的正确性又常被称为真实性(real)。需求的正确性只有提出需求的人才能加以判断,所以需求在传递给开发人员之前,必须请需求的提出者予以确认。

正确性是一个看上去简单,但实践中很难满足的特性。实践一再表明,不真实的需求是最为常见的需求错误之一，必须得到足够的重视。需求正确性难以达到的主要原因有以下两方面。

①用户在表达自己的需要时,可能会在潜意识下进行一定的加工。常见的情况是:用户的问题是A,但用户认为如果提供了方法B,则问题A自然可以得到解决,为此用户向需求工程师反映的便是B,而不是真实的A。所以为了发现用户的真实需求,需求工程师一定要进行问题分析,尽力发现问题背后的问题。

②在人际交流中,信息会发生自然衰减,甚至扭曲,导致需求工程师理解的并非是用户所表达的。对此情况的解决方法是在需求传递给开发人员之前，请提出需求的用户进行仔细检查和确认。

3.可行性

需求必须能够在系统及其运行环境的已知条件和约束下实现。用户无法判断需求的技术可行性,所以需求的可行性是由开发人员进行检查的。在检查的过程中,开发人员可能需要进行一定的分析和研究,而不是单纯地凭借经验和直觉。对于难以判断的需求,必要时要通过开发原型来加以验证。

4.必要性

每一项需求都应该是必要的，它是满足用户的业务需求所必需的。如果一条需求被忽略之后，系统仍然能够以同样的效果解决用户的问题,那么它就不值得在开发的过程中消耗额外的资源。

不必要的需求也是实践中常见的一个问题,可能因为多种原因而出现:

①用户将之作为和开发人员谈判的筹码，然后通过自己对不必要需求的进退取舍而在和开发人员的谈判中取得真正想要的利益,如金钱。对此问题,唯一需要的就是开发人员代表的谈判技巧。

②用户在交流中总是害怕信息有所遗漏,并因而产生不利后果,因此用户总是倾向于表达各种各样的需要。要解决这个问题，就需要开发人员在进行用户需求的获取之前先定义明确的业务需求,然后根据业务需求进行用户需求的过滤和选择。

③需求开发人员"画蛇添足",添加"用户肯定会喜欢"的功能,该类功能既会造成项目额外的耗费，又不会给用户带来更多的帮助。这就要求需求开发人员要保持以用户为中心。开发人员尤其需要注意该事项。

5.无歧义

需求能够正确传递知识的前提是传递者和受众能够形成共同的理解,因此每一项需求都应该有而且只能有一-种解释,即需求无歧义。为了让需求可理解,- .般倾向于以用户的语言描述需求,而用户的语言往往含有大量容易导致歧义的因素,因此在保证需求描述的无歧义时要格外注意需求描述中的词汇选择,通常在需求开发中要定义–个可以共同理解的词汇表(glossary),然后再在其基础上进行需求的描述。

有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户,这些用户关于需求的目标互相冲突,需求工程师遂采用了模糊化的处理方法。但软件的生产是无法进行模糊化处理的,所以开发者最终仍要面对一个两难局面。对于用户立场冲突的正确解决方法是在项目前景的指导下,促进用户之间的协商解决。

6.可验证

需求应该是可验证的,也就是说通过分析、检查、模拟或测试等方法能够判断需求是否被满足。如果需求不可验证,就无法判断完成的系统是否满足了该需求,开发人员也无法去选择一个能够实现该需求的方法。通常,不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要让需求具体化,小心形容词和副词的使用,避免程度词的使用。

三、小结

需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答"系统必须做什么"这个问题，是需求工程过程中的一个环节。

需求分析的最终目的建立问题的软件解决方案，因此一个好的方法是选择使用软件构成单位作为模型的元组，将软件构件单位之间的关系作为模型组之间的关系，对获取的信息进行建模。

模型就是对事物的抽象，帮助人们在创建一个事物之前有更好的理解，建立模型的的过程被称为建模

在需求工程阶段，考虑的重点是软件系统需要解决的问题，缺乏和软件实现相关的技术细节，因此，需求分析阶段还无法建立一个形式化的计算机模型。需求工程阶段仅仅要求描述软件系统的解决方案，而不是软件系统的构建方式和实现方式。

对于其应有内容的建议，应能完成需求分析的基本任务。

参考资料.

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

2. 骆斌.丁二玉.需求工程------软件建模与分析（第二版）.高等教育出版社

3. [ Ahmed 2013] AHMED F, CAPRETZ L F, BOUKTIF Set. Soft skills and software development: a reflection from soft-ware industry. International Jourmal of Information Processing and Management(JIPM), 2013, 4:3.

4. [ AI- Ani 2006] AL- ANI B, SIM S E. So, you think you are a requirements engineer. 14th IEEE International Require-ments Engineering Conference (RE’06), 2006.

5. [ Boehm 1981] BOEHM B W. Software engineering economics. Englewood Cliffs: Prentice Hall, 1981.

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

7. 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.

8. 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．

9. 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．

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

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

A001-185-2521-李子泓相关推荐

A002-185-2521-李子泓
课程名称软件建模与分析班级 18软工5班专题名称个人的需求分析与建模读书心得与对你组项目的发展建议教导教师董瑞生姓名李子泓学号 1814080902521 日期 2020年12月19 ...
（电商）唯品会双十一促销活动复盘——数据分析
(电商)唯品会双十一促销活动复盘--数据分析项目背景: 唯品会是一个专门做特卖的网站,什么是特卖呢.特卖一般是指在特定的时间段里,以优惠的价格出售指定的商品,一般以商城或者专卖店为多.该模式在线下早 ...
唯品会电商销售复盘分析
什么是特卖: 唯品会是一个专门做特卖的网站,什么是特卖呢.特卖一般是指在特定的时间段里,以优惠的价格出售指定的商品,一般以商城或者专卖店为多.该模式在线下早已存在(比如商场促销.街边的尾货甩卖),在国 ...
数据分析实战——电商复盘分析
此次分析的目标: 评估每次促销活动的结果,并根据情况优化商品结构,以便让自己的商品卖得更好.因此,明确此次分析的一个主要流程,其具体指标如图所示: 1.总体运营指标 2.从价格区间找出表现不好的产品, ...
某品牌电商促销活动运营分析
加粗样式### 分析流程: 1.总体运营指标总体运营部分,主要关注销售额.售卖比.UV.转化率等指标,其他指标作为辅助指标.销售额用来和预期目标做对比,售卖比用来看商品流转情况. 2.从价格区间找出 ...
李子柒爆红：既然做直播能年薪过亿, 为何还要努力高考？
"李家有女,人称子柒." 这是李子柒的简介,若不是看她粉丝达千万,很难让人把她与网红联系到一起. 她既没网红脸也没大长腿,却是网红界的一股清流. 看过李子柒视频的人,无一不对那视频 ...
JGG：微生物组学专刊(赵方庆、白洋、张志刚、王军、郑钜圣、魏泓、沈伟、刘永鑫等）...
Journal of Genetics and Genomics 微生物组学专刊已经在线发表,欢迎大家下载预览. 下载网址: https://www.sciencedirect.com/journal ...
清华姚班“斩获”AAAI 2020最佳学生论文：首届弟子贝小辉携手本科在读李子豪，攻坚算法博弈研究...
本文经AI新媒体量子位(公众号ID:qbitai)授权转载,转载请联系出处本文约1700字,建议阅读5分钟江湖英雄辈出,又是姚班少年郎. 江湖英雄辈出,又是姚班少年郎. 第34届美国人工智能协会年 ...
已解决：Connecting to raw.githubusercontent.com |185.199.109.133|:443... Unable to establish SSL connect
1.问题描述搭建k8s集群时,有一步需要部署flannel网络,首先需要下载一个yml文件,下载方式如下: wget https://raw.githubusercontent.com/coreos ...

A001-185-2521-李子泓

A001-185-2521-李子泓相关推荐

最新文章

热门文章