软件项目管理中需求分析的研究.doc
软件项目管理中需求分析的研究 1 软件项目需求分析的重要性 当前 ,软件开发往往存在着三大主要问题 :预算超支、进度延误、质量糟糕而且很难控制在预算之内 ——— 尤其是要高质量地实现用户的期望。相关的业界报告与分析对信息系统行业中不能满足客户需求、与用户预期不符合以及资源严重浪费等现象和问题进行了详细描述。 随着信息时代的发展 ,计算机软件的需求愈来愈复杂 ,规模愈来愈大 ,而且随着企业的发展 ,工作过程重组 ,需求变更已愈来愈成为必然。软件危机持续了 30年之久 ,至今仍无法得以很好地解决。究其原因 ,软件本身具有的特点固然有关 ,但长期以来 ,缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关键的原因。 其中软件开发和维护方法的不正确性主要体现在 :忽视软件开发前期的需求分析 ;开发过程缺乏统一的、规范化的方法论的指导 ;文档资料不齐全或不准确 ;忽视与用户之间、开发组员之间的交流。 这样 ,就经常出现用户 对“已完成”系统不满意 ,软件产品的质量经常出现漏洞 ,补丁一大堆。自从 20 世纪 60 年代出现软件危机以来 ,越来越多的人已开始更多地关注于软件 ,思考更好地保证软件开发的质量 ,与软件危机一起诞生的软件工程方法和建模理论已经发展了几十年。 然而事实却是 ,软件项目存在的质量问题仍然很严重。 1969 年 ,北约提交了一份报告 ,列举了软件所面临问题的原因 ,其中的原因在今天仍然存在 :在Rajesh Naik 等人近年来合著的《软件需求与估算》中提到 ,我们经常会看到有头无尾的工程 ,用户不满意的工程 ,难以投入实际使用的工程 ,或者严 重超支和拖延进度的工程。而导致这些现象的重要原因之一 ,往往是由需求问题引起的 ,如客户和开发者对系统的需求缺乏了解 ;搜集和分析需求的非结构化方法 ;没有支持的工具或支持工具价格昂贵。 1994 年《科学美国人》曾经报道 ,尽管经过 50 年的“进步” ,仍然存在着一种慢性危机。这就是缺少能够满足信息时代要求的成熟工程科学的状况已经持续几十年了。以上这些令人惊讶的数字和分析同样包括了对于软件 (信息系统 )产品开发状况的统计与描述。 在软件产业最为发达的欧美国家尚且存在如此严重的需求问题 ,更不用说是近 20 年来刚刚掀起 IT 热潮的中国了。由此可见 ,软件危机自 20 世纪 60 年代起已经持续了近 40 年之久 ,至今在全世界范围内仍无法得以很好地解决。 如何着手解决这个危机 ,首先要从原因入手 ,在明确根源之后 ,再研究制定相应的对策。根据 IDC 的统计 ,80%的失败 IT 项目是由于需求分析做的不好 ,没有真正反映出用户的需求而导致的。同样对于出现这种情况的原因 ,根据 Standish集团公司的分析 ,项目失败最重要的 8 个原因中的 5 个都与需求有关 : ①不完整的需求 ; ②没有用户的介入 ; ③不实际的客户期望 ; ④需求和规范的变更 ; ⑤提供不再需要了的能力。 此外 ,CHAOS 大学工作人员 Sanjiv 指出 :“如果没有搞定需求 ,则项目一定会失败 ;如果搞定需求 ,则项目一定会交付。”在这样的环境下 ,业界人士从长期的实践中逐步意识到以工程化的原则和方法组织信息系统开发工作是解决危机的一条主要出路 ,其中相对而言编码不是“问题” ,问题在于需求阶段 ,需求分析无疑是软件工程中的关键问题。正因如此 ,软件需求的重要性正在不断提高 ,因为它是用户赖以预先知道将获得什么样的系统以及投入多少经费的途径。 因此人们意识到以工程化的原则和方法组织软件开发工作是解 决软件危机的一个主要出路。软件工程中包含需求、设计、编码和测试四个阶段。 需求分析作为软件生命周期的第一个阶段 ,并贯穿于整个软件生命周期 ,其重要性越来越突出 ,到 80 年代中期 ,逐步形成了软件工程的子领域 ——— 需求工程。软件工程的子领域需求工程的出现 ,体现了其在软件质量保证中的重要意义。进入 20 世纪 90 年代后 ,需求工程成为软件界研究的重点之一。 在国内则兴起于 20 世纪 90 年代后期 ,其研究方法和研究方向基本上参照国外的相关方法和理念 ,而研究成果的创新度和实用意义与国外尚有差距。当前对于需求工程的研究已经成 为软件工程中的重要环节 ,但正如 AlanM. Davis所说的那样 :需求工程的进展相当缓慢。 我国已进入 WTO,因此软件开发也要与国际接轨 ,只有这样才能提高我们在项目管理水平 ,最终开发出高质量的软件。 2 需求分析的相关问题及过程 需求分析是软件工程中最复杂和最难处理的过程。归结起来 ,需求分析的问题主要体现在以下 4 个方面 : (1)需求的复杂性。由于用户需求所涉及的因素繁多 ,如运行环境和系统功能等 ,而导致了需求分析的复杂化。积极与用户交流 ,捕捉、分析和修订用户对目标系统的需求 ,并提炼出符合问题解 决领域的用户需求。 (2)分析人员或客户理解有误。系统需求涉及人员较多 ,如软件系统用户、问题领域专家、需求工程师和项目管理员等 ,这些人员往往具有不同的背景知识 ,且处在不同角度 ,扮演不同角色 ,从而不可避免地造成了他们之间相互交流的困难。 例如软件系统分析人员不可能都是全才 ,客户表达的需求 ,不同的分析人员可能有不同的理解 ;客户大多不懂软件 ,他们可能觉得软件是万能的 ,会提出一些无法实现的需求。 (3)不完整性和不一致性。每一项需求都必须将所要实现的功能描述清楚 ,以使开发人员获得设计和实现这些功能所需的 所有必要信息。但由于种种原因 ,用户对问题的陈述往往是不完整的 ,其各方面的需求还不可避免地存在着矛盾。 此外用户需求必须和业务需求一致 ,功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系 ,才可以保证最后开发出来的软件系统不会偏离最初的实现目标。 (4)需求易变性。随着客户对这个项目越来越深刻的理解 ,那么可能他的需求也会随之改变 ,这些变化的可能性越大项目风险就会越大 ,我们在需求分析的时候就要充分考虑到哪些需求是相对固定的需求 ,哪些可能会是产生变动的需求 ,考虑到他的可变性 ,这样设计功能和数据库的 时候不致因为后面的变动而影响整个工程。 需求分析的步骤可归纳为四个 : (1)需求获取。需求获取通常从分析当前系统包含的数据开始 ,建立当前系统的物理模型。 (2)分析建模。分析模型的建立过程是对目标系统的综合要求及数据要求的分析综合的过程。 (3)文档编写。软件需求分析说明书是软件需求分析阶段最主要的文档。 (4)需求验证。软件需求说明需求不一致的问题、二义性问题等 ,这些都必须通过需求分析的验证复审来发送 ,确保需求说明可作为软件设计和最终系统验收的依据。 (1)结构化分析方法 (Struetured Analysis,SA),该方法比较常用 ,不再赘述。 (2)软系统方法 :这只是过度性的方法论他的出现只是证明结构化分析方法的一些不足。因为结构化分析方法采用的相对形式化的模型不仅与社会观格格不入 ,而且在解决“不确定性”时显得十分无力。 (3)面向对象分析方法 (Object Oriented Analysis,OOA):这一方法也较为常用。 (4)面向问题域的分析 (Problem Domain OrientedAnalysis,PDOA):OOA 也存在着很多不足 ,但 PDOA 现在正在研究中所以未被广泛应用。这里需要注意的是 :在软件开发中有很多需求分析方法他们没有好坏之分只要你运用得当照样可以做出一个很好的系统 ,依据个人对某个方法的理解用自己最擅长的方法是最明智的选择。目前 ,软件需求还是企业信息化过程中的一个难点 ,尤其是应用于企业运营、管理及决策活动的管理信息系统 (Management Information System,MIS)拥有复杂多变的业务需求和相当难度的技术要求,这些都使得 MIS 的需求无法被高质量地获取、分析和实现。轻视用户需求和需求分析并给后 期开发带来重大损失的情况在当今 MIS 开发实践中依然比较普遍。传统的 MIS 开发方法主要有两个重大的缺陷 :一是虽然相较于其他软件更加重视系统需求 ,但仍然存在忽略用户需求本体 ,往往没有考虑“为什么”需要这样的系统需求 ;二是过于形式化的需求用例建模常常导致需求的歧义性和不一致性 ,因而难以确认和验证。对于这些问题 ,传统的方法缺乏有效的需求捕获、分析及验证机制和模型 ,因此需要寻求新的需求工程方法。 首先 ,在现有的软件工程理论基础上 ,结合 MIS 开发过程 ,明确其特殊性 ,及其需求分析的特殊性。然后 ,在需求工程理论的研究基 础上 ,找到需求阶段存在的典型问题及其表现形式 ,在研究理论的基础上归纳需求定义度量指标 ,以及需求阶段各时期的划分。 3 结语 项目需求分析是一个项目的开端 ,也是项目建设的基石。在以往建设失败的项目中 ,80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一 ,就是对需求分析的把握程度。