软件开发中的需求分析在软件开发项目中,需求分析是关乎软件项目开发成败的重要因素。现在的软件项目中返工开销占了总开销很大比例,而导致返工的主要原因是需求分析不明确。针对这一情况,文章阐述了软件开发中需求分析任务、需求分析过程、需求分析方法、需求分析变更问题,以及如何确保需求分析质量的措施。随着全球经济、科技的快速发展和社会信息化进程的加快,计算机被广泛应用于各行业中,各种应用软件应运而生,各行业的管理或生产日趋专一化、数字化、快捷化。从而用户对计算机软件的要求更加复杂和严格。软件需求分析正是解决用户这种需求,软件需求分析是关乎软件项目开发成败的重要因素。有资料表明,现在的软件项目中返工开销几乎占了总开发的一半,而导致返工的主要原因是需求分析不明确,甚至有些人不知道需求分析是什么,从而引发项目开发中的一系列更改。这些更改可能导致浪费大量资源、软件项目无法按时完成等严重问题。所以,需求分析是软件设计和实现的基础,是软件项目迈向成功的第一步!一、软件需求分析的任务一个软件项目的开发主要分为五个阶段:需求分析阶段、设计阶段、编码阶段、测试阶段和维护阶段。而需求分析阶段所得到的结果,是软件项目开发中其他四个阶段的必备条件。从以往的经验来看,需求分析中的一个小的偏差,就可能导致整个项目无法达到预期的效果,或者说最终开发出的产品不是用户所需要的。何谓软件需求分析。先举个例子来说明,对于建造房子这个问题相信大多数人都知道,用户要建一幢房子,建房者一定会与用户详细讨论各种细节,楼层高多少?构架如何?图纸样式等等,每个环节都有详细的过程文档,双方都明白假如完工后修改带来的损失以及变更细节的危害性。同样在软件需求分析中也需要有详细的文档,软件开发者要从用户的业务中提取出软件系统能够帮助用户解决的业务问题,通过对用户业务问题的分析,规划出开发者的软件产品。这个步骤是对用户业务需求的一个升华,是一个把用户业务管理流程优化,转化为软件产品,从而提升管理而实现质的飞跃,这一步是否成功,直接关系到开发出来的软件产品能否得到用户认可,顺利交付给客户,客户能否真正运用开发者的产品帮助他解决业务或管理问题。软件需求分析的任务不是确定系统怎样完成的工作,而是确定系统必须完成那些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。它所做的工作是深入描述软件的功能和性能,确定软件设计的限制和软件同其他系统的接口细节,定义软件的其他有效性要求。转自项目管理者联盟软件需求分析的任务就是借助于当前系统的逻辑模型导出目标系统的逻辑模型,解决目标系统的“做什么”的问题。其实现步骤是:(1)获得当前系统的物理模型;(2)抽象出当前系统的逻辑模型;(3)建立目标系统的逻辑模型。如图1所示:二、软件需求分析的过程软件需求分析的过程具体可分为对问题的识别、分析与综合、制定规格说明和评审。项目管理论坛问题识别是指系统分析人员研究可行性分析报告和软件项目实施计划,确定目标系统的综合要求,并提出这些需求实现条件,以及需求应达到的标准。这些需求分为:功能性需求+非功能性需求,其具体包括:(1)功能需求:列举出所开发软件在职能上应做什么。(2)性能需求:给出所开发软件的技术性能指标,如存储容量限制、运行时间限制、安全保密性等。(3)环境需求:软件系统运行时所处环境的要求,如硬件方面:机型、外部设备、数据通信接口;软件方面:系统软件,包括操作系统、网络软件、数据库管理系统方面;使用方面:使用部门在制度上,操作人员上的技术水平上应具备怎样的条件。(4)可靠性需求:对所开发软件在投入运行后不发生故障的概率,按实际的运行环境提出要求。所以对于重要的软件,或是运行失效会造成严重后果的软件,应提出较高的可靠性要求。(5)安全保密要求:应当在这方面恰当地做出规定,对所开发的软件给予特殊的设计,使其在运行中,其安全保密方面的性能得到必要的保证。(6)用户界面需求:为用户界面细致地规定到达的要求。(7)资源使用需求:开发的软件在运行时和开发时所需要的各种资源。(8)软件成本消耗与开发进度需求:在软件项目立项后,要根据合同规定,对软件开发的进度和各步骤的费用提出要求,作为开发管理的依据。(9)预先估计以后系统可能达到的目标,这样可以比较容易对系统进行必要的补充和修改。除了这些必需的需求,问题识别的另一个工作是建立分析所需要的通信途径,以保证能顺利地对问题进行分析。分析与综合的目标是给出目标系统的详细逻辑模型。在此步骤中,分析和综合工作需反复地进行。对于编制需求分析的文档,我们称描述需求分析文档为软件需求规格说明书,除了编写软件需求规格说明书之外,还要制定数据要求说明书以及编写初步的用户手册。需求分析评审是指在需求分析的最后一步,对系统功能的正确性、完整性和清晰性,以及其他需求给予评价。三、软件需求分析方法软件需求分析方法很多,如传统方法、原型方法、模型驱动方法、面向数据结构的结构化数据系统开发方法等,选择那种方法要根据哪些资源在什么时间对开发人员有效,不能盲目套用。这里着重阐述原型方法。传统的软件工程方法强调自顶向下分阶段开发,要求在进入实际开发期之前必须预先对需求严格定义。但实践表明,在系统建立起来之前很难紧紧依靠分析就确定出一套完整、一致、有效的应用需求,并且这种预先定义的策略更不能适应用户需求不断变化的情况。由此,原型法应运而生,它一反传统的自顶向下的开发模式,是目前较流行的使用开发模式。转自项目管理者联盟(一)原型的概念原型最早使用在制造业和机械产品设计中,先做出产品的基本模型,然后进行完善和改进,最后得到符合要求的产品。在软件工程中,原型是指要开发的软件系统的原始模型,是软件早期一个可运行的版本,它反映最终系统的某些重要特性(如软件界面与布局、功能等)。在获得一组最基本的需求说明后,通过分析构造出一个小型的简约软件系统,满足用户的基本要求,然后不断演化得到较高质量的产品。原型法克服了传统软件生命周期法的一些弊端,具有快速灵活、交互式等特点,方法核心是用交互、快速建立起来的原型取代了不太明确的需求规格说明,用户通过在计算机上实际运行和试用原型系统得到亲身感受并受到启发,通过反应和评价向开发者提供真实的反馈意见。然后开发者根据用户的意见对原型加以改进,通过“原型构造-试用运行-评价反馈-分析修改”的多次反复,从而提高最终产品的质量。(二)原型分类由于建立原型的目的不同,实现原型的途径也有所不同,通常有以下三种类型:(1)探索型。这种原型目的是要弄清除客户对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性。(2)实验性。这种原型用于大规模开发和实现之前,考核方案是否合适,规格说明是否可靠。(3)进化型。这种原型的目的不在于改进规格说明,而是将系统建造得容易处理变化,在改进原型的过程中,逐步将原型进化成最终系统。(三)原型建立技术原型建立技术:(1)可执行规格说明。它是基于需求规格说明的一种自动化技术,使用这种方法,人们可以直接观察用语言规定的任何系统的功能和行为。(2)基于脚本的设计。脚本是用户界面的原型。一个脚本用来模拟在系统运行期间用户经历的事件。它提供了输入——处理——输出的屏幕格式和有关对话的模型。因此,软件开发者能够给用户显示系统的逼真的视图,使用户得以判断是否符合他的意图。(3)自动程序设计在程序自动生成环境的支持下,利用计算机实现软件的开发。它可以自动地或半自动地把用户的非过程式问题规格说明转换为某种高级语言程序。(4)专用语言。专用语言是应用领域的模型化语言。在原型开发中使用专用语言,可方便用户和软件开发者对系统特性进行交流。(5)可复用的软件。利用可复用的模块,通过适当的组合,构造的原型系统。为了快速地构造原型,这些模块首先必须有简单而清晰的界面;其次它们应当尽量不依赖其它的模块或数据结构;最后,它们应具有一些通用的功能。(6)简化假设。简化假设使设计者迅速得到一个简化的系统。尽管这些假设可能实际上并不能成立,但它们可以使开发者的注意力集中在一些主要的方面。在修改一个文件时,可以假设这个文件确实存在。在存取文件时,待存取的记录总是存在。一旦计划中的系统满足用户所有的要求,就可以撤消这些假设,并追加一些细节。项目经理圈子(四)原型分析优点原型分析优点有:(1)增进软件开发者和用户对需求的理解,使比较含糊的具有不确定性的软件需求(主要功能性的需求)明确化。(2)软件原型化方法提供了一种有力的学习手段。(3)使用原型化方法,可以容易地确定系统的性能,确认系统主要服务的可应用性,确认系统设计的可行性,确认系统最终作为产品。(4)软件原型的最终版本,有的可以原封不动地称为产品,有的略加修改就可以成为最终系统的一个组成部分,这样有利于建成最终系统。四、需求变更在开发项目过程中,用户随时会提出一些新的需求,要求开发人员解决,这些需求的提出,有时在开发阶段中有时在开发阶段后。这种在需求分析的两个相邻子阶段中,或者在迭代周期的需求分析中,后一段或周期的需求分析结果与前一次不一致,我们把这种不一致称为需求变更。产生需求变更的原因主要有以下几个方面:(1)在需求分析阶段,开发人员与用户的沟通不够。在需求分析阶段,开发方与用户没有很好的交流,开发方就根据用户提供的大概信息,自己推导出用户的需求。通过这种需求分析得出的需求往往会和用户的实际需求相差甚远,导致用户提出更改需求。(2)项目的实施周期过长。随着时间的推移,用户对整个系统的了解也越来越深入。他们会对模块的界面、功能和性能方面提出更高更多的要求。(3)技术更新过快。由于技术的快速更新,企业可能引进一些新的设备,而这些设备可能就会与我们的目标系统有直接的关系,由于这一变化可能发生在解决用户原先问题之前或者之中,那么开发人员不得不加入这一新的需求。bbs.mypm.net项目经理博客为了尽可能地避免发生需求变更,以及保证需求分析的高稳定性,可以采用以下方法:(1)对开发人员进行专业培训。因为,开发人员对所开发系统的领域不一定了解,为了开发人员能更好理解用户的需求,在做需求分析的初始阶段对开发人员进行该领域相关知识的培训。(2)开发方与用户进行协作和交流。在用户提出需求变更时开发人员应该认真听取用户的要求并加以整理和分析。分析需求变更的原因并提出可行的替代方案;同时向用户说明这些需求变更会对整个项目的开发带来的不良后果。(3)合同约束。由于需求变更可能会对整个项(下接第85页)(上接第77页)目产生影响,所以,开发方和用户在签定项目合同时,可以对需求变更增加一些相关的合同条款。(4)建立需求文档并进行版本控制。需求分析的最终成果是一份客户和开发人员对所开发的产品达成共识的文档。有了这份文档,即使开发人员的角色有所变动,也不会对需求分析的前期工作有所影响。对每次的需求变更都用一个新的版本来标识。(5)需求评审和设立需求基线。为了让开发方详细了解用户的需求,让不同人员从不同的角度对需求进行验证,作为需求的提出者,在需求评审过程中,用户往往能提出许多有价值的意见。同时,也是用户对需求进行最后确认的机会,可以有效减少需求变更的发生。需求在通过正式评审和批准之后,应该确定需求基线,进一步的需求变更将在此基线的基础上,依照项目定义的变更过程进行。设置需求基线可以将变更引起的麻烦减至最小。五、结束语本文通过对软件需求分析的详细阐述,来说明软件需求分析是软件设计及实现的基础,对于整个软件项目来说至关重要。如果能科学地进行需求分析,采用一些技术来避免可能导致需求分析失败的情况,能圆满地完成软件需求分析任务,为后续软件开发打下坚实的基础。项目管理者联盟。