A001-185-2532

计算机科学与工程学院实验报告

课程名称

软件需求分析与建模

班级

 18软5

实验名称

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

教导教师

董瑞生

姓名

蔡浩凯

学号

1814080902532

日期

2020.10.4

 

 

 

 

 

 

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

目录

 

第1章 、 需求工程导论 1

1.1 、 软件工程中的需求问题 1

1.2 、 需求工程 6

1.3 、 需求工程师 7

第2章 、 需求基础 8

2.1需求的定义 8

2.2 、 满足需求就是解决问题 9

2.3 、 优秀需求的特性 11

第3章 、 需求工程过程 12

3.1 、概述 12

3.2 、 需求工程活动 13

3.3、 需求开发过程是迭代和并发的 17

3.4、 需求开发过程与软件工程过程相互影响 17

应有内容建议: 18

 

首先先谈谈需求分析与建模的一些知识,如下:

第1章 、 需求工程导论

1.1 、 软件工程中的需求问题

1.1.1 、 需求问题是当前软件开发面临的主要问题

提到需求工程,我脑海中所浮现的就是软件工程,这两门课都是为软件开发而设计的,需求分析的任务不是分析系统如何实现用户的需要,而是对业务分析,形成一个体系完整,内容清晰的业务框架,以指导后续的设计开发工作。需求分析就是先分解,再提炼,在这个过程中消除矛盾。

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

在 Standish Group 的调查中将软件项目分为 3 种类别 :

①在预计的时间之内,在预算的成本之下完成预期 的所有功能,则项目为成功项目( success ) 。

② 已经完成,软件产品能 够正常工作,但在生产中或者超支,或者超期,或者实现的功能不全,则项目为问题项目( faulty ) 。

③ 因无法进行而被中途撤销,或者最终产品 无法提交使用,则项目为失败项目( fail )。

Standish Group 1995 年发布的调查 报告[ Standish 1995 ] 表明1994年美国 365 家公司的 8 380 个项目当中 ,成功项目仅为 16. 2% , 失败项目为 31. 1% , 问题项目为52.7%。所有项目平均超支 18.9% , 平均超期 222% , 平均只完成了预计功能的 61%。

上述的例子为我们展示了当前软件开发所面临的的严峻问题。

 

1.1.2 、 软件的模拟特性

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

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

例如,在图书管理软件中,如果在张三没有借书的情况下,软件系统产生了一条张三借书的记录,则该软件系统将会被认为是运行不正常和存在缺陷的,原因即在千借书情况的记录和现实中发生的借书事件没有保持一致。在软件 和现实保持一致的情况下,人们不再需要为了查找一本书而 翻遍所 有的书架 ,通过软件系统进行书目查询就可以得到 准确的答案。

软件的冗余 功能问题也从另一个侧面很好地反映了它的模拟特性。在软件开发中,一方面只能完成预期功能的 60 % - 70 % [ Standish 1995 ] , 另一方面移交软件中却存在着大量的冗余功能(接近 50 % [ Young 2002 ,  Standish  2003 ] )  , 这些功能用户从来不会使用。人们在讨论冗余功能为软件开发带来 额外负担时,却 很少有开发人员 能够意识到,这些冗余 功能往往也是导致用户不满意和软件不被接受的原因之一。正是因为缺 乏这种意识,所以软件开发 人员才会在开发中持续 不断地超出用 户的需求添加“ 出色功能” ,进行自我陶醉地为软 件” 锁金” 。 设 想一个购买 汽车的普通用户,如果发现 汽车除了正常的功 能之外,在方向盘边上 还有一些用途不明的其他部件, 虽 然被告知那些部件可能永远不会被用 到而可以置之不理,但作为一名普通的驾 驶者,没有人 会有设计师的那份泰然,不小心触发那些 部件可能产生的未知后果 会一直萦绕心头 ,以至千恨不 能将之消除而后快。

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

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

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

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

应用型软件在“模拟“现实的基础之上接收用户的诮求,协助用户完成任务,它正确工作的基础是具有“模拟“性。“模 拟“性具体是指以下儿点:

①目的性:软件的目标是直接或间接地满足用 户的某些目的或者解决用户的某些问题,软件的功能是据此设立的 。

②正确性:软件具备的功能能够保证目标的正确实现。

③现实可理解性:软件实 现其功能的基础、手段和过程是在用户领域内现实 可理解的,即软件系统是 在理解其 现实环境的基础上 ,通过影响现实的某些环节 ,或者改变现实各部分的通信方式,最终达成某些 目的或者解决某些问题的。

应用型软件一般以普通用户为应用对象,因此也要求具有使用的方便性。实现功能的模拟性和使用 的方便性也仅要求所用技术具 有可行性。和工具型软件不同 ,应用型软件通常不是通用 的,它们是为特定的应用环境定制的,对环境的“模拟“性是其主要的关注点 。

不同的评判标准和关注点决定 了 3 类软件在生产中也会有所不同(如图1- 4 所示),尤其是在分析阶段具有截然不 同的目标:面向专业用户的工具拟软 件通常在具有一定的观念创新或技术创新后执行功能分析,分析阶段的主要目的是为充分利用创新优势而进行巧妙的功能安排;面  向普通用户的 工具型软件进行分析的主要目的是进行方案权衡 ,寻找一套切实有效的功能配置; 应用型软件分 析阶段的主要目的是发现人们利用软件的原因(目的),找出需 要软件解决的问题,理解应用环境中的领域知识 ,保证 功能的“模拟“性。

在实际工作 中,虽然大部分软件开发人员将其主要精力都消耗在应用型软件的生产中,但他们每天接触更多的却是工具型软件。因此,如果开发人员受 到的 工具型软件相关 评判标准、关注点及生产过程的影响过大 ,就会对应用型软件 的“ 模拟“特性理解不透彻或应用不坚决,进而导致对需求处理阶段重视不足或者在需求阶段轻视领域知识研究,应用型软件的生产就会发生需求问题。

 

1.1.3 、 需求问题具体原因分析

软件生产中产生需求问题的最大原因在于对应用型软件的模拟特性理解不透彻或应用不坚决,它会导致软件 开发者产生轻视需求的态度问题。除此之外,还有一些技术原因也会导致需求问题的产生。

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

应用型软件的模拟特性使得需求处理具有很突出的特性。相对于软件开发的其他阶段而言,需求处理阶段涉及更多的非技术性和社会性因素,并且其所受的影响也远远高千其他阶段。

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

需求建模与分析是需 求处理中的核心活动,它用一些形式化或半形式化的语言进行知识的描述。一方面,只有通过建模与分析才能将混乱、模糊的用户需 求变成清晰、明确的软件需求,所以 它是获取需求处理活动的必然后继,它建立的分析模型是需求处理中最为重要的成果; 另一方面 ,建模与分析的理论可以 帮助人们系统 化地看待问 题,它可以根据理论或分析中出现的各种现象指导其他需求处理活动更 好地进行。因此,建模与分析活动在需 求处理中具有非 常重要的地位,以至于人们理所 当然地把需 求处理工作的重心部署在建模与分析活动中,放在对建模技术的理解和运用上,甚至在传统的软件开发生命周期中用“需求分析”一词指代整个需 求处理阶段。

但在需求处理阶段除了需求建模与分析活动之外,还有其他的活动也应得到重视,理解需求处理中涉及的非技术性和社会性因素与理解建模分析技术一样必要,否则同样会导致软件的失败,这些因素包 括组织机构文化、社会背景、商业目标、利益协商等。它们的必要性具体如下。

(l)从需求处理的任务来看 ,需要重视非技术性和社会性因素

需求处理的主要任务是发现问题并解决问题。现实是问题的发生地,软件系统是人们应对问题的手段。但是单纯的软件系统是不能解决问题的,它只有和现实之间形成一种有效  的互动才能解决问 题。因此,相对于软件系统的构造问题,人们更应该 关注软件系统和现实 之间的互动效应。也就是说,需求处理不应该以新系统的功能性 和内在特征为主要处理目标,而是更应该集中精力于分析环境 的构成、现状和它们将来能与软件达成的期望互动效应。因此,作为软件系统环境的组织机构文化、社会背景和系统涉众( stake holder , 是指将会受到软件系统的影响,并能够直接或间接影响系统需求的个人 、团体或组织)的目标与利益 比软件内部的数据流与状态更应该得到重视。

(2)从需求处理的手段来看,需要重视非技术性和社会性因素

建模与分析技术是进行需求处理的主要手段,这些技术本身都是概念性的,不依赖于某些特殊的应用环境条件,可以被广泛应用于各种应用场景。但是利用 这些技术构建的解决方案一定是和具体应用环境相关的,不存在不依赖千具体应用环境的解决方案。因此,在利用建模与分析技术进行需求处理时,不能忽视具体应用环境中的相关因素,例如组织机构的文化、行业规范和社会背景等,都会约束解决方案的构建空间。

(3)从需求处理的过程来看,需要重视非技术性和社会性因素

在需求处理的过程中 ,试图单纯通过技术 的运用来建立一个一致、完整的需求模型是不太可能的。因为在现实中,因涉众的不同立场而产生利益冲突的情景非常常见,这些冲突 是根本性的,是无法单纯通过技术手段 所能解决的。因此,在需 求处理的过程中,要重视非技术性和社会性因素所导致的问题的解决,面对冲突要能够分析社会原因和组织机构方面的原因,引导涉众进行利益协商,进而建立一个一致、完整的需求模型。

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

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

传统的结构化方法和面向对象方法都是最先在编程领域取得成功的,它们所用的概念和组   织机制都是从编程领域抽象出来的。其后 ,它们又都 相继被用来进行软件设计,因为设 计和编程都有构建高质证(健壮性、可维护性、适应性等)软件的共同目标,而且使用相同的概念和组织机制保证了从设计到编程的平 滑过渡,所以它们在设 计领域的应用也取得了成功。而后它们又被进一步应用到分析领域,但是需求分析除了 拥有构 建高质矗软件的目标 之外 ,还有一个更加重要的目标是理解现实 ,而这是传统分析方法所拥有的概念和组织 机制所无法实现的,所以说传统分析方法在需求分析领域的应用具有 先天缺陷。

3、软件规模的日益扩大

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

在软件以单一任务或几个 相关任务为应用 领域时 ,软件应用的上下文环境相对局限在某个部门或者某个 角色,甚至某个个人的任务范围之内,涉众非常有限。所以 ,它所涉及 的组织机构文化、社会背景 、商业目标和利益协商 等非技术性 因素自然也 相对较少。而且该类软件的需求来源往往很有限 ,所以每条需求相对较为 完整和一致 ,可理解性 相对较好 ,进行技术分析时对“为什么做" ( why ) 进行描述的要求不是非常必要。

但是,当软件以企业为中心时,它的应用范闱会包括企业的各个主要职能部门,包括各部门 的主要任务和它们之间 任务的协同。这样,该组织的部门划分、传统与惯例 、规章和约束 、行业特性和行业约定、社会地位和社 会价值等组织结 构文化和社会背景方面的因素就会对需求分析的正确进行产生一定的影响。而且随着应用范围的扩大,涉众会更加广泛,相互之间的利益冲突也会加剧 ,因此对商业目标和利益协商的处理要求也变得很有必要 ,忽视这些非技术性因素会导 致整个项 目的失败。

在软件以企业为中心时 ,很少有用户能够单独给出对全局的理解,进而 出需求。相反,每个用户往往仅能给出与其相关的片段,需要分析人员将所有用户的片段连接起来,构成全局理解,导出需求。因此,该类软件要求分析人员 能够在拥有相对有限的用户描述片段或者用户描述片段间有冲突时进行相 对正确的解读 ,即需求分析对规格说 明可理解性的要求加强,这样对“为什么做“进行描述就显得非常重要 ,因此传统分 析方法的缺陷也就更加明显。

4、需求问题的高代价性

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

 

 

1.2 、 需求工程

1.2.1 、需求工程简介

1、定义

“需求工程 ” 自产生以来,其概念和其领域内的其他名词一样,没有形成较为一致的定义,不同的人从不同的角度出发 ,根据各自不 同的理解 ,会得出不同的定义。简单来说,需求工程是所有需求处理活动的总和,它收集信息、分析问题、整合观点、记录需求并验证其正确性 ,最终反映软件被应用后与其环境互动形成的期望效应。

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

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

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

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

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

2、基本活动

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

需求分析的目的是保证需求的完整性 和一致性。它从需求获取阶段输出的原始需求和业务过程细节出发,将目标 、功能和约束 映射为软件行 为,建立系统模型 ,然后在抽象后的系统模型中进行分析,标识并修复其中的不一致缺陷,发现并弥补遗漏的需求。

需求规格说明的目的是将完整 、一致的需 与能够满足需 求的软件行为以文档的方式明确地固定下 来。在文档中 ,可以使用非形式化的文本(如自然 语言)描述,也可以使用半形式化的图形语言,如统一建模语言描述 ,还可以使用形式化的语言(如Z 语言)描述。描述的结 果文档是接下来将被提交进行需求验证的软件需求规格说明。

需求验证是需求开发中的最后一个活动。它的首要目的是保证需求及其文档的正确性,即  需求正确地反映了用户的真实意图 ; 它的另一个目标是通过检查和修正,保证需求及其文档的完整性和一致性。需求验证之后的需求及其文档 应该是得到所有涉众一致同意的软件需求规格说明,它将作为项目规划、设计、测试、用户手册编写 等多个其他软件开发阶段的工作基础,对帮助项目开发人员建立共同的前景具有重要作用。

需求管理是对需求开发所建立的需求基线的管理,它在需求基线完成之后正式开始,并在需  求工程阶段结束之后继续存在,在设计、测试、实现等后 续的软件系统开发 中保证需求作用的持续、稳定发挥。它的主要工作是跟踪后续 阶段中的需 求实现与需求变更 情况,确保需求得到正础的理解和实现。

 

1.3 、 需求工程师

1、需求工程师是涉众和开发者之间的桥梁

在软件开发的各项活动中,需求工程的任务是连接现实世界与计算机世界 ,将现实世界的知识内容转化为计算机世界的工作基础,让软件设计、实现、测试等后续的软件开发活动将精力集中在计算机世界中来。需求工程师是负责完成需求工程主要任务的专门人员,所以他负责衔接 现实世界和计算 机世界 ,简单说就是涉众与开发 者之间的桥梁。

2顿号需求工程师需 要具备的技能

因为需求工程比较复杂,又关乎项目的成败,所以合格的需求工程师需要具备多方面的知识与技能。

因为要代表开发者为涉众提供软件解决方案,所以需求工程师必须熟练掌 握软件开发方法与技术,保证设计 出来的软件解决方 案既是可行的又是成本效益比有效的。

需求工程师还要代表涉众把他们的想法准确地告知开发者,所以需求工程师必须要有非常精确的表达能力,尤其是文档化能力。

当然,最关键的是需求工程师要从涉众那里得 到他们的想法并转化为开发者需要的知识 ,所以需求工程师必须有非常好的交流沟通能力以了解涉众的想法,必须要有抽象建模与分析的能力以准确定义涉众的想法。

3、需求工程师要重视“ 软技能”

在需求工程师需要具备的能力中,软件开发技术能力是需  求工程师最为基础的能力,因为他首先是一个软件开发技术人员。但是需求工程具有连接现实 世界的特殊性,所以与其他软件开发角色相比,需求工程 师对非技术能力的要求并不弱于(甚至强 于)对技术能力的要求。这些非技术能力又常被称为软技能 ( soft kill ) , 是指依赖于需求工程师个人素质而非技术方法掌握情况的能力 ,通常会涉及认知心理学、社会学、语言学和人类学等 文学科知识。

4、需求工程师需要创新

在表面上看,需求工程师的工作只是捕获涉众的想法并忠实地转述给开发 者,这使得需 求工程师似乎不需 要创新能力,甚至于应该抵制创新以与涉众保持一致。但事实上,是否具备创新能力往往是判断 一个需求工程师是否出色的必要条件。

5、需求开发是团队行为

需求工程的复杂性使 得一个人很难单独完成复杂系统的需求开发工作,所以实践中需求开发往往是团队行为。团队定义为: 为了一致的目的、绩效目标、方法而共担责任并且技能互补的少数人。

 

  1. 、 需求基础

2.1需求的定义

需求一直是软件工程中较为模糊的词汇之一。提起需求 ( requirement ) , 不同背景的人(用户、开发者)会有不同的看法,因此需求是需求工程中一个非常难以准确定义和解释的概念。

在各种不同的定义中,本书更倾向千使用 IEEE 的需求定义[ IEEE 1990 ] :

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

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

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

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

 

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

2.2.1 、 问题与需求

 

需求源于问题,要准确理解需求,就必须明确它与问题的关系。[ Jackson 19 95a , Jackson 1997 ] 认为当现实的状况与人 们期望的状况产生差距时,就产生了问题(如图2- 1 所示)。问 题中的差距要么是某些事件、事物的状态不理想 ,要么是某些事情的发生过程不理想。解决问题,就需要改变这些事件、事物的状态,或者改变其状态变化的演进顺序,使其达到期望的状态和理想的演进顺序。

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

 

 

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

 

1、问题域

问题在现实世界与软件系统的互 动中得到 解决。如图 2 - 2 所示 ,软件系统在应用千现实之后,就成为现实世界的一个部分。当然,软件系统不会需要与整个现实世界互动,它只需要与现实世界中的一部分互动即可 。这部分就是问题的发生地,也是问题解决的基本范围一一解决问题必须涉及的事件和事物,[ Jackson 1995 b ] 将它们称为问题域( problem domain ) 。问题域是需求的背景,要理解需 求就必须先理解问题域。例如,要准确理解需求将利润率提高到5%就需要弄明白利润由哪些部分组成,各自的比例是多少,工作是如何完成的再如,要准确理解需用户可以查询商品详细信息,就需要了解哪些用户在哪些

任务中需 要查看哪些商品的详细信息,总之,虽然表达期望的需求看起来比较简单,但是只有明白问题域的复杂背景 信息才能真正理解需求的含义。

问题域的背景信息又被称为问题域特性( problem domain feature ) 。 与需求相区别的是,问题域是自治的 ,它有自己 的运行规律,而且这些 规律不会因解系统的引入而发生改变。需求是一种对未来的期望,是可以打折 、部分满足甚 至不予满足的;高到 5%"可以部分满足,只提升到3% 。但是如果用户的销售市场遍布全国(问题域特性),就不能仅考虑一个地点的销售工作状况。

2、解系统

软件系统通过影响问题域帮助人们解决问题,所以[Jackson 1995b] 称之为解系统 ( solution system ) 。 在解系统中软件起着主要的作用 ,它是软件解决方案在通用计算机上的实现。

解系统是问题的解决手段 ,并不是问题的产生地,所以解系统并不是问题域的一部分。解系统与问题域之间存在可以互相影响的接口 ,以实现交互活动 。

需求工程师要注意区分用户与软件开发人员在关注点上的不同用户关注于问题域,软件开发人员更关注解系统。需求工程师扮演着桥梁的作用,一方面使用户不需要了解和关注解系统(因为用户大多不懂软件开发的专业知识),另一方面使软件开发者不需要关注问 题域让软件开发者将精力集中到软件构造工作中。尤其需要注意的是虽然需求工程师通常是技术人员,来自于解  系统领域,但是他们也必须要懂得如何站在用户的立场,与用户进行基于问题域的交流。

 

2.2.3 、 问题解决的基础一模拟与共享现象

 

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

初看上去,问题域与解系统原本是两个相互独立的系统,相互独立性使得它们之间难以互相影响。但是一旦认识到解系统对问题域的模拟性,它们就会 变得紧密联系,互相影响也会自然形成。

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

例如,一个图书馆中有图书、借书人  、借书规则等现实信息,图书馆管理系统中就会建立相应的数据表( Table-Book 、Table- Borrower 、Table-Rule ) , 这个是简单的仿制。如果图书馆中有一本书《软件需求工程》因为磨损而报废了 ,那么 Book 表中就需要删除" Name =《软件需求工程》"的数据行。如果在表Borrower 中有一个数据行是" Name = 张三,BorrowedNum = 5 " , 那么管理员就会认为张三巳经借走5 本书。如果张三实际上只借走了 3 本书,那么管理员就会认为管 理系统出了错误,不能正常工作。这种带有交互性的模拟就是解系统与问题域能够互相影响的原因和途径。

解系统与问题域模拟的交互性其实是由人在意识 中强制建立的。如果用户并未将现实发生的情况实时地输入到软件系统中,或者用户在工作时完全忽视 软件系统提供的输出,那么软件系统就会失去影响和改变现实的能力 ,就不可能 解决现实问题或者满足现实需求。这充分说明软件系统必须得到用户的认可,否则就会失去价值。

2.3 、 优秀需求的特性

1、 完备性

优秀的需求是完备 ( complete ) 的,它不需要做更多的扩展就可以充分说明用户需要的系统功能。完备性的判断标准是:需 求是否描述了开发人员设计和实现这项功能所需 的所有信息。只有完备的需求在开发中才可能被 独立出来 ,单独对待。在需求开发 过程中,对于不清晰的信息可以标记为 TBD (To  Be Determined , 待确定),但在需 求开发结束之前,所有的 TBD 都必须被解决。

  1. 正确性

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

正确性是一个看上去简单 ,但实践中很难满足的 特性。实践一再表明,不真实的需求是最为常见的需求错误之一,必须得到足够的重视 。

3、可行性

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

4、必要性

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

5、无歧义

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

 

 

  1. 、 需求工程过程

3.1 、概述

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

为了有效地理解用户问题,分析各种可能 的系统解决方案 ,最终产生 一个适宜 的规格说明文档,需 要将需求开发活动组织成一个系统化和严格的需求工程过程 ,这是人们随着系统 开发的进展而逐渐认识到。在初期,系统开发的唯一焦点就是编码 ,此时不论系统大小 , 开发都是一个单独的活动一一-编码。这个时期人们还不认为存 在独立的需求开发活动。其后, 随着生命周期模型的引入,对系统开发活动的认知取得重大进展,人们认识到需求开发是系统开发中的一个独立的阶段,即软件开发 生命周期 模型的第一个阶段。在此后 的进一步发展中,人们逐渐认识和接受了系统的演化式开发思想,认识到系统的实现往 往是开始千一个并非完备的需求体系,发现需求开发也是一个递进的过程,包含一系列的独立活动。今天,大多数软件专业人士已经意识到需求工程也有屈千它自己的生命周期模型,即存在针对需求开发的需求工程过程,这个过 程又作为系统 工程和软件工程的一个子过程部署在系统开发的初期阶段。

目前看来 ,如果所开发系统的类型不同开发公 司的规模和文化不同,或者系统 开发资源获取的途径不同 ,需求工程过程都会表现出极大的差异。例如,对一个大规模的军用或航空系统而言,通常存在一个正式、严格的需求工程过程 ,它详细定 义了过程的各个阶段 ,要求产生能 够详细描述系统需 求和软件需 求的规 格说明 文档。而对开发创新型软件的小公司而言,需求工 程过程可能仅仅包含一些头脑风暴会议 ,它产生 的文档也可能仅仅是对系统期望的一段简短描述。但不管实际上执行的需求工程过程为何 ,它们都拥有一些共同的需求工程活动:需求获取、需求分析、需求规格说明 、需求验证和需求管理。其中,需求获取、需求分析、需求规格说明、需求验证为需求开发活动 ,需求管理为项目管理活动。

在需求工程的开始必须要获取用户期望系统 表现出来的各种行为,这些期望并不是外在和

直接得到的 ,系统分析师需要利用一些方法和技术才能得到正确的结果。

为了取得对需求的正确和深入理解,系统分析师还需要对获取的结果进行综合与整理,通过分析保证需求的正确性、完整性和可行性。

 

3.2 、 需求工程活动

3.2.1 、 需求获取

需求获取是从文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需求从文档或环境中直接转移到获取的结果文档上 ,需求工程师必须要利用各种方法和技术来“发现“需求。

需求开发的过程包含有学习和认知的过程,而学习和认知的过程是递进的,即学习一点,增加一些认知,然后在新的认知的基础上继续学习。因此需求获取和需求分析是交织在一起的,需求工程师需要获取一些信息,随即进行分析和整理,理解、认知到一定程度后再确定要进一步获取的内容。

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

  1. 背景资料
  2.  获取问题与目标,定义项目 前景与范围
  3. 识别涉众,选择信息的来源
  4. 选择获取方法,执行获 取,获取功能与 非功能需 求
  5. 记录获取结果

3.2.2 、 需求分析

 

需求分析的主要工作是通过建模来整合各种信息,以使人们更好地理解问题。同时,需求分析工作还会为问题定义一个需求集合,这个集合能够为问题界定一个有效的解决方案。需求分析还需要检查需求中存在的错误、遗湍和不一致等各种缺陷,并加以修正。

需求分析活动最后会产生一个需求的基线集,它指定了系统(或当前 版本的系统)开发需 要完成的任务。在资源受限的 情况 下,这个基线集往往只是用 户所要求功能的一个子集,而且需求工程师和用户必须就该子集的取舍达成一致 。需求基线集中的需求要具有优秀需求的特性,尤其是一些不一致和冲突的现象必须得到妥善的解决 。

在需求分析阶段 ,需求工程师 主要的任务包括以下几方面。

  1. 背景
  2. 问题分析、目标分析 、业务分析 ,确定 系统边界
  3. 软件需求建模
  4. 细化需求
  5. 确定优先级
  6. 需求协商

 

3.2.3 、 需求规格说明

获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档,用 户需求被写入用户需求文档(或用例文档),系统 级需求被写入需求规格说明。

编写文档的主要目的是在系统涉众之间交流需求信息,因此编写的文档应该具有一定的质掀。这些质撮特性有 些来自于文档内所有独立需求的质量之和,有些来自于 编写者的写作技巧, 最重要的质拭要求是简洁、精确、一致和易于理解。

 

3.2.4 、 需求验证

为了尽可能地不给设计、实现、测试等后续开发活动带来不必要的影响,需求规格说明文档至少要满足下面儿个标准:

-文档内每条需求都正确、准确地反映了用户的 意图。

-文档记录的需求集在整体上具有完整性和一致性。

-文档的组织方式和需求的书写方式具有可读性和可修改性。

 

3.2.5 、 需求管理

 

在需求开发活动之后,设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工作。需求的影响力贯穿于整个软件的产品生命周期,而不是单纯的需 求开发阶段。所以,在需求开发结束之后,还需要有一种力批保证需求作用的持续、稳定和有效发挥,需求管理就是这样的一个管理活动。

需求管理阶段的主要任务包括以下两方面。

  1. 建立和维护需求基线集
  2. 进行变更控制

 

 

3.3、 需求开发过程是迭代和并发的

从需求工程各项活动的内容来看,需求开发 活动似乎可以遵 循"需求获取一需求分析一需求规格说明一需求验证” 的路线顺序执行,并 成功地产生有效的成果文档。但正如软件开发 过程的瀑布模型一样,实践者们很快就发现这个线性顺序的过程可以用 于解释需求开发中的活动内容, 却无法用于组织成功的需求开发。

究其根本,作为软件开发的一个阶段,需求 开发与软件开发一样存在着大盘的不确定性 ,甚至是软件开发中不确定性最多的一个阶段 ,所以需求开发与软件开发一样都应该是迭代的。

需求开发不仅是迭代的,而且它的两个重要活动-----需求获取与需求分析,还是交织的。需求获取与需求分析是需求开发中的两个主体活动 ,它们共同构成一个学习过程。

 

3.4、 需求开发过程与软件工程过程相互影响

“需求的好坏对后续软件开发有着极其重要的影响” 这一观念已经是开发者的共识了,近些年的实践研究进一步发现:不仅仅是最终制品需求,整个需求开发过程都会对其后续的软件开发过程产生重要影响。

研究发现 ,相比于需求方法本身的好坏,需求方法与软件开发方法的适配性更会影响项目的成败。这也就是说,需求开发方法与软件开发方法是否适配,比结果需求的好坏更能影响项目的成败。

需求开发过程之所以对后续软件开发过程有重要影响,并不仅仅是因为它的结果制品一需求一是后续开发过程的工作基础,更要认识到需求开发过程中还会产生很多正性信息(如前景与范围定义、涉众描述、分析模型、需求特征描述等)。如果单纯从产生软件需求规格这个任务来看 ,这些正性信息都是不必要的,但它们对后续软件开发过程的影响则是明显的。也就是说,为了让整个软件开发团队的工作能够更加顺利 ,需求工程师需要完成很多看上去似乎不属于其本职工作的任务,这就是“团队”的含义。

 

应有内容建议:

一个软件项目的开发主要分为五个阶段:需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段。而需求分析阶段所得到的结果,是软件项目开发中其他四个阶段的必备条件。从以往的经验来看,需求分析中的一个小的偏差,就可能导致整个项目无法达到预期的效果,或者说最终开发出的产品不是用户所需要的。何谓软件需求分析。先举个例子来说明,对于建造房子这个问题相信大多数人都知道,用户要建一幢房子,建房者一定会与用户详细讨论各种细节,楼层高多少?构架如何?图纸样式等等,每个环节都有详细的过程文档,双方都明白假如完工后修改带来的损失以及变更细节的危害性。同样在软件需求分析中也需要有详细的文档,软件开发者要从用户的业务中提取出软件系统能够帮助用户解决的业务问题,通过对用户业务问题的分析,规划出开发者的软件产品。这个步骤是对用户业务需求的一个升华,是一个把用户业务管理流程优化,转化为软件产品,从而提升管理而实现质的飞跃,这一步是否成功,直接关系到开发出来的软件产品能否得到用户认可,顺利交付给客户,客户能否真正运用开发者的产品帮助他解决业务或管理问题。

需求分析的任务不是确定系统怎样完成的工作,而是确定系统必须完成那些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。它所做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统的接口细节,定义软件的其他有效性要求。

需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的问题。其实现步骤是:(1)获得当前系统的物理模型;(2)抽象出当前系统的逻辑模型;(3)建立目标系统的逻辑模型。

所以教材内容必须要有简单易懂,让人快速读懂,弄懂该如何去获得当前系统的物理模型,如何抽象出系统的逻辑模型,还有如何建立系统的逻辑模型等这些内容,以便于让需求分析更好,更优的进行,减少后边的修改代价,开发出更好的软件。

 

 

文献引用

 

[ Robert 2002 ] Glass R L. Facts and fallacies of software engineering. Addison-Wesley , 2002

[ Shaw 1990 ] Shaw M. Prospect s for an Engineering Discip line of Software. IEEE Software , 1 990 , 7 ( 6 ) : 15- 24

[ Siddiqi 199 6 ] STDDlQI J, SHEKARANM C. Requirements engineering: the emerging wisdom . IEEE Software , 1 996,  

 

[ Larnsweerde 2000 ] Lamsweerde V. A Requirements  engineering in the year 00: a  Research perspective. Invited Paper for l CSE ' 2000-22nd International Conference on Software Engineering . Limerick: ACM Press, 2000.

[ Lubars 1993 ] LUBARS M, Potts C, Richter C. A review of the state of the practice in   requirements modeling. FirstInt' ISymp.Requirements Eng. LosAlamitos: IEEE CS Press , I 993: 2-14.

[ Maiden  2007]  MAIDEN  N,  NCUBEL  C,  ROB ERTSO N  S.  Can  requirements  be  Crea tive?  Exper ie nce s   with  an   En­ han ced Ai r Space Manageme nt System . 29th Inte rna tional Con ferenc e on Software Engin ee ring ()CSE'07), 2007.

[ Minor 2004 ] MJNOR 0 , ARMA GO J. Requirements engineering: a close look at ind us try needs and model curricu­la. AW RE ' 04.

[ Nikula 2000 J NIKULA U, SJANIEMI J, Kalviainen H. A state- of- the- practice survey on requirements engineering in small- and medium - sized enterprises.Telecom Business Rese arch Center Lappeenranta. Lappeenranta 2000 .

[ Nuseibeh 2000 ] NUSETBEH B, EASTE RBROOK S. Requirements engineering: a road map.  Proceedings. of the 22nd Int' I Conference.on Software Engineering, Future of Software Engineering Track. New York: ACM Press, 2000

[ Oboler 2003 J OBOLER A, SQUIRE D , KORB, K. Why don' t we practice what we teach.Engineering Software forComputer Science Research in Academia . International Conference on Software Engineering Research and Applications (SERA 2003), 2003.

 

 

©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页