《需求分析论文》由会员分享,可在线阅读,更多相关《需求分析论文(7页珍藏版)》请在金锄头文库上搜索。
1、姓名:李浩 学号:12136155需求分析对软件项目开发成败影响探讨摘要:需求分析是软件工程过程中计划阶段的一个决定性步骤,在这一步将把含糊的软件概念转变成具体的规格说明,从而奠定了软件开发的基础。本文通过对需求的定义、需求的类型、需求分析的任务、需求分析的方法、需求的变更以及应用实例等几个方面的介绍,对于在软件开发中做好需求分析有一定的借鉴作用。关键词:软件;开发;需求;分析1 引言软件项目的开发主要分为五个阶段:需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段,需求分析是软件开发的第一个阶段。完善的软件需求说明是软件开发项目得以成功的基础。不管设计如何精心或者编码如何巧妙,如果对软件需
2、求不加以明确规定,将使用户感到失望,并给软件开发者带来严重后果。据权威部门统计,目前软件的成功率约为25%,75%的软件是失败的。在这75%的失败中,约有50%以上的软件是由于需求的原因造成的。另有资料表明,软件开发项目中返工开销几乎占开发总费用的一半,而导致返工的主要原因是需求分析错误或不明确,从而引发项目开发中的一系列更改。成功的软件需求分析不仅能提高软件的成功率,而且能节省大量的资源,因此需求分析是软件开发的关键阶段。2 需求的定义和类型 2.1 需求的定义软件产业存在的一个普遍问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的“需求”对开发者似乎是一个较高层次的产品概念,而开
3、发人员所说的“需求”对用户来说又像是详细设计了。实际上,软件需求包含着多个层次,不同层次的需求从不同角度与不同程度反映着细节问题。IEEE软件工程标准词汇表(1997年)将需求定义为:1) 用户解决问题或达到目标所需的条件或能力。2) 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 3) 一种反映上面1)或2)所描述的条件或能力的文档说明。IEEE的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求,其关键的问题是一定要编写需求文档。另外,还有其他几种关于“需求”的定义:需求是用户所需要的并能触发一个程序或系统开发工作的说明;需求是从
4、系统外部能发现系统所具有的满足于用户的特点、功能及属性等;需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性,是在开发过程中对系统的约束。从以上的定义中,我们依然无法得到有关“需求”的清晰概念,真正的“需求”实际上存在人们的脑海中,任何文档形式的需求(例如:需求规格说明)仅是一个模型或一种叙述,但是编写出高质量的需求规格说明书在需求分析阶段还是关键。需求分析奠定了软件工程和项目管理的基础。我们在建造软件系统这座大厦的时候,如果需求分析的基础不够坚实和牢固,那么往往会导致软件系统问题百出,甚至被马上丢弃。在建造软件系统的过程中,如果我们经常习惯地沿用一些不规范的方法,其后果便是产生
5、一条鸿沟开发者开发的与用户所想得到的软件存在着巨大的“期望差异”。 因此“需求”这个名词的定义不仅仅是从用户角度对系统外部行为的描述,以及从开发人员角度对系统内部特性的描述,其关键的一点是“需求”必须文档化。2.2 需求的类型软件需求包括三个不同的层次业务需求、用户需求和功能需求。除此之外,每个系统还有各种非功能需求。业务需求(BusinessRequirement)表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统,即组织希望达到的目标。使用前景和范围(vision and scope)
6、文档来记录业务需求,这份文档有时也被称作项目轮廓图或市场需求(project charter 或 market requirement)文档。用户需求(UserRequirement)描述的是用户的目标,或用户要求系统必须能完成的任务。用例、场景描述和事件响应表都是表达用户需求的有效途径。也就是说用户需求描述了用户能使用系统来做些什么。功能需求(Functional Requirement)规定开发人员必须在产品中实现的软件功能,用户利用这些功能来完成任务,满足业务需求。功能需求有时也被称作行为需求(behavioral requirement),因为习惯上总是用“应该”对其进行描述:“系统应
7、该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。非功能需求(Non-functional Requirement) 定义了软件产品为满足用户业务需求而必须具有的除功能需求以外的特性。包括系统的完整性(联机帮助、 数据管理、用户管理、软件发布管理、在线升级等)、性能、可靠性、可维护性、可扩充性、对技术和业务的适应性等。3 需求分析的任务 3.1 解决的问题1) 齐全、准确地找出目标系统全部的功能、性能、限制;2) 找出全部的输入流、输出流;3) 找出所有的加工;4) 产生完整的分层的DFD、数据字典、加工的描述;5) 补充的意见。3.2 综合要求确定对系统的综合要求,
8、系统功能要求,系统性能要求,运行要求,将来可能提出的要求。3.3 任务 需求分析任务图,需求分析阶段要完成的具体明确的最终任务就是形成一份经开发方和用户认可或达成共识的软件需求分析文档(需求规格说明书、修改后的项目开发计划、初步的用户手册、确认测试计划、数据要求说明书)。这个文档能清晰准确地说明系统将要开发什么,能够规定出详细的技术需求,包括所有面向用户、面向机器和其它软件系统的接口。可以说需求文档在开发过程中一直起指导作用。为了更好地完成软件开发第一阶段的需求分析任务,提高质量,需求管理是必不可少的。需求管理的目的是在客户与开发方之间建立对需求的共同理解,维护需求与其他工作成果的一致性,并控
9、制需求的变更,主要体现在跟踪和控制需求变更管理。需求管理是开发工作有效进行的保证,是一种很高层次的系统行为,涉及整个开发过程和产品本身。4 需求分析的方法需求分析方法由对软件问题的信息域和功能域的系统分析过程及其表示方法组成,大多数的需求分析方法是由信息驱动的。信息域具有三种属性: 信息流、信息内容和信息结构。常用的需求分析方法有:面向数据流的结构化分析方法(SA),面向数据结构的Jackson方法(JSD),面向数据结构的结构化数据系统开发方法(DSSD),面向对象的分析方法(OOA)等。选择那种方法要根据哪些资源在什么时间对开发人员有效,不能盲目套用。这里着重阐述面向数据流的结构化分析方法
10、(SA)。2 4.1 面向数据流的结构化分析方法 面向数据流的结构化分析方法(Structured Analysis,简称SA),是面向数据流进行需求分析的方法,是需求分析使用最多的方法之一。 SA也是一种建模活动,该方法使用简单易读符号,根据软件内部数据传递、变换的关系,自顶向下逐层分解,描绘出满足功能要求的软件模型。适用于数据处理类型软件的需求分析,这一方法除了简单,容易掌握之外,还能和设计阶段的结构化设计(SD)衔接,从而取得良好的设计结果。4.2 自顶向下逐层分解的分析策略 SA方法的基本手段:“分解”和“抽象”。这是系统开发技术中控制复杂性的两种手段。它先将系统“抽象”成一个模型,此
11、模型是有输入和输出并有系统名称的盒子,然后打开这个盒子,对它进行逐层分解,直到能被理解,可以实现为止。因此分析的策略是自顶向下,逐层加细,由抽象到具体的过程。如图2。4.3 结构化分析方法使用工具 SA方法利用图形等半形式化的描述方式表达需求,简明易懂,用它们形成需求规格说明书中的主要部分。描述工具是1) 数据流图:描述系统由哪几部分组成,各部分之间有什么联系等等。2) 数据字典:定义了数据流图中每一个图形元素。3) 描述加工逻辑的结构化语言、判定表、判定树:详细描述数据流图中不能被再分解的每一个加工。由于分析中的主要依据是数据传递及数据变换所形成的数据流,所以结构化分析一般采用的方法是使用数
12、据流图的分析方法,最终结果是产生需求规格说明书,该文档包括一套数据流图,对数据流图中的成分进行定义的一本数据字典及对加工逻辑的描述。4.4 结构化分析步骤 用结构化分析方法进行系统需求分析的具体步骤是: 1) 了解当前系统的工作流程,获得当前系统的物理模型。通过对当前系统的详细调查,了解当前系统的工作过程,同时收集资料、文件、数据、报表等,将看到的、听到的、收集到的信息和情况用图形描述出来。也就是用一个模型来反映自己对当前系统的理解,如画系统流程图。 2) 抽象出当前系统的逻辑模型。物理模型反映了系统“怎么做”的具体实现,去掉物理模型中非本质的因素,抽取出本质的因素,构造出当前系统的逻辑模型,
13、反映了当前系统“做什么”的功能。 3) 建立目标系统的逻辑模型。分析、比较目标系统与当前系统逻辑上的差别,明确目标系统到底要“做什么”,从而从当前系统的逻辑模型导出目标系统的逻辑模型。 4) 作进一步补充和优化。为了对目标系统做完整的描述,还需要对得到的逻辑模型做一些补充。 说明目标系统的人机界面。 说明至今尚未详细考虑的细节(包括出错处理、系统的启动与结束、系统的输入/输出和系统性能方面的需求等)。 其他(系统特有的其他必须满足的性能和限制,也需要用适当的形式做出书面记录。 分析阶段结束时,系统分析员必须和用户再次认真地审查系统文件,争取在系统开始设计之前,尽可能地发现其中存在的一些错误并及
14、时纠正,直至用户确认这个模型表达了他们的要求后,系统文件(软件需求规格说明书等)才作为用户和软件开发人员之间的“合同”而最后得到确定。 4.5 结构化分析方法的优缺点 1) 优点: 结构化分析方法是软件需求分析中公认的、有成效的、技术成熟的、使用广泛的一种方法,它较适合于开发数据处理类型软件的需求分析,该方法利用图形等半形式化工具表达需求,简明易读,也易于使用,为后一阶段的设计、测试、评价提供了有利条件。 2) 缺点: 传统的SA方法主要用于数据处理方面的问题,主要工具DFD体现了系统“做什么”的功能,但它仅是一个静态模型,没有反映处理的顺序,即控制流程。因此,不适合描述实时控制系统。 上世纪
15、60年代末出现的数据库技术,使许多大型数据处理系统中的数据都组织成数据库的形式,SA方法使用DFD在分析与描述“数据要求”方面是有局限的,DFD应与数据库技术中的实体联系图(ER图)结合起来(如同IDEF0功能模型与IDEF1信息模型相结合一样)。ER图能增加对数据存储的细节以及数据与数据之间,数据与处理过程之间关系的理解,还解决了在DD中所包含的数据内容表示问题,这样才能较完整的描述用户对系统的需求。 对于一些频繁的人机交互的软件系统,如飞机订票、银行管理等系统,用户最关系的是如何使用它,输入命令、操作方式、系统响应方式、输出格式等都是用户需求的重要方面,DFD不适合描述人机界面系统的需求,SA方法往往对这一部分用自然语言作补充。 描述软件需求的精确性有待提高。5 需求的变更 在开发项目过程中,用户随时会提出一些新的需求,要求开发方解决,这些需求的提出,有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中,或者在迭代周期的需求分析中,后一段或周期的需求分析结果与前一次不一致,我们把这种不一致称为需求变更。产生需求变更的原因主要有以下几个方面:1) 在需求分析阶段,开发方与用户的沟通不够。在需求分析阶段,开发方与用户没有很好的交流,开发方就根据用户提供的大概信息,自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需