浅析检察业务信息化项目开发中需求分析.docVIP

浅析检察业务信息化项目开发中需求分析 　　一、加强对需求分析内涵和外延的认识 　　 　　“大多数软件灾难的种子通常都是在软件项目开始的头三个月种下的。”这是软件开发届的名言。作为软件开发起始的需求开发与管理是软件项目中一项十分重要的工作,据调查显示在众多失败的软件项目中,由于需求原因导致的约占到45%,因此,需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此,在项目开发工作中,很多人对需求的认识还远远不够,从本人参与或接触到的一些项目来看,软件项目的需求都多多少的存在问题,有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因,以上种种原因都表明做好软件需求开发是一项系统工作,而不是简单的技术工作,只有系统地了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识,并在实践中加以应用,才能真正做好需求的开发和管理工作。 　　从软件工程的角度来说,需求就是用户的需要,它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件,它是一个程序或系统开发工作的说明,表现形式一般为文档形式。需求分析的过程,也叫做需求工程和需求阶段,它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动,分为四个阶段:情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的,他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动,它包括:变更控制、版本控制、需求跟踪、需求状态跟踪等工作。 　　如何判断需求规格说明的好坏,按照比较常见的NASA SEL推荐方法,它是由美国国家航空和航天局软件工程实验室开发的五大常用国际软件工程规范之一,它对软件需求过程的评价标准是:清晰、完整、一致、可测试。 　　(1)清晰:目前大多数的需求分析采用的仍然是自然语言,自然语言对需求分析最大的弊病就是它的二义性,所以开发人员需要对需求分析中采用的语言做某些限制。例如尽量采用主语+动作的简单表达方式。需求分析中的描述一定要简单,千万不要采用疑问句、修饰这些复杂的表达方式。除了语言的二义性之外,注意不要使用行话,就是计算机术语。需求分析最重要的是和用户沟通,可是用户多半不是计算机的专业人士,如果在需求分析中使用了行话,就会造成用户理解上的困难。 　　(2)完整:需求的完整性是非常重要的,如果有遗漏需求,则不得不返工,在软件开发过程中,最糟糕的事情莫过于在软件开发接近完成时发现遗漏了一项需求。但实际情况是,需求的遗漏是常发生的事情,这不仅仅是开发人员的问题,更多发生在用户那里。要做到需求的完整性是很艰难的一件事情,它涉及到需求分析过程的各个方面,贯穿整个过程,从最初的需求计划制定到最后的需求评审。 　　(3)一致:一致性是指用户需求必须和业务需求一致,功能需求必须和用户需求一致。在需求过程中,开发人员需要把一致性关系进行细化,比如用户需求不能超出预前指定的范围。严格的遵守不同层次间的一致性关系,就可以保证最后开发出来的软件系统不会偏离最初的实现目标。 　　(4)可测试:一个项目的测试从什么时候开始呢?有人说是从编码完成后开始,有人说是编码的时候同时进行单元测试,编码完成后进行系统测试,这些结论都不完全正确。实际上,测试是从需求分析过程就开始了,因为需求是测试计划的输入和参照。这就要求需求分析是可测试的,只有系统的所有需求都是可以被测试的,才能够保证软件始终围绕着用户的需要,保证软件系统是成功的。 　　 　　二、当前需求分析工作中存在的问题 　　 　　 由于项目在做需求分析时受人员、时间、投资等客观因素的影响和需求本身具有主观性和可描述性差的特点,往往面临着一些风险,体现在: 　　1) 用户不能正确表达自已需要什么。许多用户认为计算机无所不能,对工作流程和规则讲的不透,也讲不清楚。 　　2) 业务部门配合力度不够。有的用户日常工作繁忙,不愿意花更多的时间和精力来参与,只是应付一下。 　　3) 用户的需求不断变更。由于业务变化或需求不清楚,需求在整个系统生命周期都可能发生变化,这种需求的变化会严重影响项目的进展,也会造成系统的不稳定。 　　4) 需求的完整程度。一个系统很难确定明确的需求范围并把所有需求一次性提出来,这会造成在后继的开发中不断增加新的需求,容易引起整个系统的返工。 　　5) 需求的细化程度。需求做得越细,所花的时间越多,对设计的限制越严格,但做得过粗,开发人员在技术设计时不清楚的地方就越多,也会影响系统的开发。 　　6) 忽略了用户的特点分析。做需求分析时容易忽略系统用户的特点,哪些用户用的多,哪些用户的信息化水平比较高,这些都是要考虑的问题。 　　7) 做需求分析时间的保障