软件需求分析的研究现状.docx

软件需求分析的研究现状.docx

《软件需求分析的研究现状.docx》由会员分享，可在线阅读，更多相关《软件需求分析的研究现状.docx（8页珍藏版）》请在冰豆网上搜索。

软件需求分析的研究现状

软件工程结课论文

题目：

软件需求分析的研究现状

学院：

xxxxxxxxxxxxxxxx学院

专业班级：

xxxxxxxxxxxxx一班

任课教师：

xxxxxxxxx

姓名：

xxxx

学号：

xxxxxxxxx

日期：

2010年01月

软件需求分析的研究现状

摘要

随着信息时代的发展，计算机软件的需求愈来愈复杂，规模愈来愈大，而且随着企业的发展，工作过程重组，需求变更已愈来愈成为必然。

软件危机持续了30年之久，至今仍无法得以很好地解决。

究其原因，软件本身具有的特点固然有关，但长期以来，缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关键的原因。

其中软件开发和维护方法的不正确性主要体现在：

忽视软件开发前期的需求分析;开发过程缺乏统一的、规范化的方法论的指导;文档资料不齐全或不准确;忽视与用户之间、开发组员之间的交流;忽视测试的重要性;不重视维护或由于上述原因造成维护工作的困难。

关键词

需求分析软件工程 数据库 计算机软件 系统 

正文

一、软件需求的概况

软件需求的定义

　　软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。

对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。

客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。

定义的多样性导致了令人迷惑和沮丧的沟通问题。

　　需求必须被记录成文档，这一点很重要。

公凭一堆电子邮件、便条、会议记录，以及对走廊中几次交谈的模糊印象就自称掌握了需求，那纯属自欺欺人。

　　咨询专家BrianLawrence提出，需求是“任何促成设计决策的因素”。

很多信息都属于这一范围。

　　IEEE的软件工作标准术语表（1990）则将需求定义为：

　　用户为解决某个问题或达到某个目标而需具备的条件或能力。

　　系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。

　　上述第一项或第二项中定义的条件和能力的文档表达。

　　这一定义既体现了用户对需求的看法（系统的外部行为），也代表了开发人员的观点（一些深层的特性）。

术语用户隶属于涉众，因为并非所有涉众都是用户。

　　我对需求的理解是：

产品为向涉众提供价值而必须具备的特性。

　　下面这条定义则确认了需求类型的多样性（Sommervill和Sawyer1997）：

　　需求是对应该实现什么功能的说明――可以是对系统运行方式或系统特征与属性的描述；还可能是对系统开发过程的约束。

　　很显然，对于需求是什么没有一个统一的定义。

为便于交流，我们需要协商决定一组限定词来修饰“需求”这个内涵丰富的术语，并认识到用可通用的形式记录需求的重要性。

　　不要一厢情愿地认为项目涉众对需求的理解是一致的。

应该事先给出定义，才能保证大家谈论的是同一个问题。

二、软件需求的发展

需求工程是指应用已验证的有效的技术、工具、方法进行需求分析，确定客户要求，帮助分析人员理解问题，并定义目标系统的所有外部特征的一门学科。

它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

需求工程的概念最初来自于计算机软件系统工程，主要用于解决计算机软件系统开发过程中的需求问题。

随着需求工程的发展，人们认识到需求工程研究的对象不仅局限于计算机软件系统，也适用于一般的系统和组织。

近几年，需求工程与组织管理的联系得到了来自流程再造、组织变更、设计理论等领域研究人员和业内人士的关注，需求工程现在已经发展到了与系统和组织等方面相关的更广阔的视角。

2.1需求工程的国内外发展现状

需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。

后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。

随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。

人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。

80年代中期，形成了软件工程的子领域——需求工程（requirementengineering,RE）。

进入90年代以来，需求工程成为研究的热点之一。

从1993年起每两年举办一次需求工程国际研讨会（ISRE），自1994年起每两年举办一次需求工程国际会议（ICRE），在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。

一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR（RequirementsEngineeringNetworkofInternationalCooperatingResearchGroups），并开始开展工作。

在我国，需求工程的研究始于20世纪80年代末、90年代初，主要有下列科研院所开展这方面的研究，并取得研究成果，如:

中国科学院软件所、南京大学软件所、北京大学计算机系、北京航空航天大学软件工程研究所、武汉大学软件工程研究所、还有华中理工大学、国防科技大学、复旦大学等。

2.2需求工程的内容

需求工程是一个不断反复的需求定义、记录和演进的过程，并在最终达到需求的冻结。

我们可以把需求工程的活动划分为五个阶段：

（1）需求获取：

积极与用户交流，捕捉、分析和修订用户对目标系统的需求，并提炼出符合问题解决领域的用户需求。

用户的需求分为俩类:

功能性需求与非功能性需求。

功能性需求主要说明了系统各功能部件与环境之间的相互作用的本质，即拟开发软件在职能上实际应做到什么。

它是用户最主要的需求，通常包括系统的输入、系统能完成的功能、系统的输出以及其它反应。

非功能性需求有人简单称为“约束”，它主要从各个角度对所考虑的可能的解决方案起约束和限制作用。

在对用户进行需求分析时不只是定义功能性需求，还应定义非功能性需求。

（2）需求建模：

根据需求分析，对已获取的需求进行抽象描述，为目标系统建立一个概念模型。

需求模型的表现形式有自然语言、半形式化（如图、表、结构化英语等）和形式化表示等三种。

自然语言形式具有表达能力强的特点，但它不利于捕获模型的语义，一般只用于需求抽取或代写硕士论文标记模型。

半形式化表示可以捕获结构和一定的语义，也可以实施一定的推理和一致性检查。

形式化表示具有精确的语义和推理能力，但要构造一个完整的形式化模型，需要较长时间和对问题领域的深层次理解。

（3）需求规格说明：

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

软件需求规格说明是开发者和用户之间的一个协约。

SRS是对外部行为和系统环境（软件、硬件、通信端口和人）接口的简洁完整的描述性文档。

SRS基本内容包括行为需求和非行为需求。

行为需求定义系统需要“做什么”，描述系统输入输出的映射及其关联信息，刻画系统功能。

非行为需求定义系统的属性，描述与行为无关的目标系统特性，如性能、可靠性、安全性、易维护性、可用性、顺应性等。

（4）需求验证：

以需求规格说明为基础输入，通过符号执行、模拟或快速原型等方法，分析和验证需求规格说明的正确性和可行性。

IEEE这样定义"验证"：

"它是用来评价某一系统或某一组件的过程，来判断给定阶段的产品是否满足该阶段开始时施加的条件。

换句话说，验证活动在很大程度上是一种普通的测试活动，要求您验证每个开发阶段（例如软件某项需求或多项需求的实现）是否符合先前阶段定义的需求。

（5）需求管理：

跟踪和管理需求变化，支持系统的需求演进。

有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估，对项目风险承担者进行协商，对软件开发各阶段应跟踪每项需求的状态。

2.3需求工程实施中存在的问题

（1）需求不正确：

需求的正确性是分析模型最基本的要求之一，它一般是指在模型中的对于待开发系统的功能、行为、性能的表述必须与用户对目标系统的期望相吻合，即分析模型中所描述的每一项需求都代表了对于待开发系统的真实要求。

然而大多数情况下，需求分析只是将UML作为描述系统的业务流程方法，但并没有将建模图型作为用户与分析人员交流的介质，单向的需求分析造成需求的不准确。

此外，需求也未被作为需求目标分解的依据。

（2）需求不一致：

需求的一致性是指在系统的各子集中不存在显式的或隐含的矛盾。

需求分析往往按照系统利益相关者的不同角色进行划分，但这些需求往往会因为系统资源限制不能完全得到满足，或因认识角度的不同而相互矛盾，因此这样的需求不能直接反映系统的需求。

（3）需求存在二义性：

要求分析模型中所描述的任何事情有且只有一种解释。

如果其中某一部分给不同的人理解，解释超过一种，那么该分析模型就存在二义性。

（4）需求不精确：

现有的系统需求主要通过文本和图形的方式表示，这种需求分析方法只能对需求进行定性分析，而在有些情况下，需求需要更加精确的描述，如定量描述。

（5）需求不完整：

需求的完整性是指分析模型中包含了目标系统所要求做的全部工作的描述。

具体地说，就是要将待开发系统的所有功能、行为、性能约束以及它在所有可能情况下的预期行为，对于所有可能出现的输入数据的定义以及对合法和非法输入值的响应等，都要包含在分析模型中。

（6）需求不灵活：

现有的需求是根据特定的系统环境分析得出的，但当系统环境变化时，需求不能随之快速变化。

对于具有弹性的系统环境，现有的需求分析也不能得出在特定的系统环境变化范围内的系统需求。

三、软件需求的现状

1.需求工程的方法学

　　需求工程的方法学发展很快，对需求工程方法学不同侧面的研究和一些经典论述为需求工程的发展奠定了基础。

其中典型的有：

　　*Lano提出的操作概念规格，于需求产生前由开发人员写成，它既满足精确的规格说明要求，同时易读、易理解，便于用户了解是否真正体现了其要求。

　　*Sutcliffe、Maiden等人提出从领域知识的角度定义在需求工程环境中通用的领域语义模型和组合模型。

　　*Alford提出任务分割的概念，大大减低了需求分析的问题复杂度。

　　*Chou和Eckert讨论了面向对象的需求工程方法学的概念和模型。

　　*Drake提出用于确定系统需求边界的限定过程。

　　*Gotel对需求跟踪性问题进行了研究。

　　还有其他许多人对需求工程方法学的其他方面进行了研究和论述。

　　综合看来，需求工程方法大致分为四类：

面向过程、面向数据、面向控制、面向对象。

　　*面向过程的分析方法主要研究系统输入输出的转化方式，对数据本身及控制方面并不很重视。

传统的结构分析方法SA（structureanalysis）、SADT（structureanalysisanddesigntechnique）和可执行/可操作模型PAISley、Descartes以及形式方法VDM（viennadesignmethod）、Z等都属于这一类。

　　*面向数据的方法强调以数据结构的方式描述和分析系统状态，JSD和关系实体（ER）模型都属此类。

　　*面向控制的方法强调同步、死锁、互斥、并发以及进程激活和挂起，数据流图就是典型的面向控制的方法，SADT是以面向控制的方法为辅的。

　　*面向对象的方法把分析建立在系统对象以及对象间交互的基础上，通过对象的属性、分类结构和集合结构定义和沟通需求。

从对象模型、动态模型和功能模型三个方面对问题进行描述。

面向对象的方法正在成为需求分析中的一个热点，并展现出良好的应用前景。

Yourdan和Coad的OOA方法、Booch的方法、Jacobson的OOSE、Rumbaugh的OMT方法等，都是这一方法的典型流派。

　　2.面向对象的需求工程方法

　　目前，作为解决软件危机的一个最佳对