软件开发周期中需求分析.docVIP

软件开发周期中需求分析 　　当用户使用软件的时候，发现软件的功能与自己的需求不一致，往往第一个反应就是：这需求是怎么做的？其实，每个人都知道做软件要做需求分析，然而很多人对需求分析的重视程度却不够。由于前期的需求做得不充分而导致的后果，只有到软件测试和交付的时候才显现出来，而这个时候再纠正，代价就相当惨重了。下面就以笔者做过的一些欧美项目中成功和失败的经验为例，探讨一下软件开发周期中的需求分析。 　　一 什么是需求分析 　　结构化软件开发一般分为分析、设计、开发、测试、验收与运行等阶段。开发前，会进行前期的可行性研究；在运行开始以后，还要进行后期维护。需求分析是结构化开发中的重要阶段。通常情况下，国内软件开发公司在做欧美和日本的项目时，对前期的可行性研究参与得较少，一般都是对方已经做完可行性研究，国内软件开发公司从需求分析开始做起，直到软件开发后的运行和维护。 　　所谓“需求分析”，是指对要解决的问题进行详细的分析，弄清楚客户的需求，包括需要输入什么数据，要得到什么结果，最后应输出什么，等等。可以说，软件工程当中的“需求分析”就是确定要计算机“做什么”。 　　二 需求分析的重要性 　　从需求分析的定义上，就可以看出需求分析在软件开发过程中的重要性了。需求分析做得不对，后面的步骤做得再好，也只能是南辕北辙，无法满足客户的要求。研究表明，改正产品付诸应用后所发现的一个需求方面的缺陷，比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现，在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但若在系统测试时发现则需要5—17个小时来修复。 　　只有通过软件需求分析，才能把软件功能和性能的总体概念描述为具体的软件需求规格说明，从而奠定软件开发的基础。软件需求分析工作也是一个不断认识和逐步细化的过程。该过程将软件设计阶段所确定的软件范围逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决方法。 　　先以笔者之前做的加拿大项目失败的需求分析为例。由于和???户签订了合同，5个月必须交付软件，开发时间紧迫，导致项目计划时做需求分析的时间只给了2周时间（理由是客户的文档已经提供好了，照着做即可）。结果，由于前期对客户文档理解得不是很清楚，导致开发进行到3个月的时候发现需求上有争议。在和客户确认后得出结论：如果要满足客户的要求，则需要对整体架构进行修改。虽然最后按期交付了软件，但是整个项目组最后两个月每天都在加班，包括周末，而且软件质量也没有得到客户的充分认可。 　　再以之前做过的一个美国项目为例。笔者作为需求分析人员在软件开发开始阶段到美国与客户做软件需求分析。在了解客户需求的同时，笔者尽量了解客户为什么要这么做，帮客户一起想需求，以便我们开发的软件能够更好地为客户服务。每天开完会后，笔者把客户的需求整理好，发给国内的同事进行研究分析，建立简单的基础模型并研究技术可行性。需求分析结束回国后，笔者保持每周至少3次电话会议与客户进行沟通，随时了解客户的需求。正因为在前期阶段进行了这种细致的需求分析，项目组在很少加班的情况下，不但按时交付了项目，并且得到客户的充分认可。 　　三 软件需求分析的任务 　　需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制范围和软件同其他系统元素的接口细节，定义软件的其他有效性需求。 　　分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据与功能表示。在软件开发结束后，制定的软件需求规格说明还要为评价软件质量提供依据。这里需提到很重要的一点是，需求分析后的软件需求规格说明书上一定要有客户的确认签字，这是必不可少的环节，关系到以后软件开发的成败。 　　通常，软件开发项目是要实现目标系统的物理模型，即确定待开发软件系统的系统元素，并将功能和数据结构分配到这些系统元素中，它是软件实现的基础。但是，目标系统的具体物理模型是由它的逻辑模型经实例化，即具体到某个业务领域而得到的。与物理模型不同，逻辑模型忽视实现机制与细节，只描述系统要完成的功能和要处理的数据。作为目标系统的参考，需求分析的任务就是借助当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统的“做什么”问题。通常用数据流图、E-R图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。 　　在软件分析过程中，应尽可能地让更多的人参与进来，而不仅仅是软件分析师自己。在之前的美国项目中，在前期分析时软件开发的核心技术人员和测试人员就已经进入项目组，每天技术人员会对分析的结果提出技术实现的难点以及改进的方法，笔者在随后的会议上就会和客户进行讨论，尽量在满足客户需求的同时，使用更简单可行的技术，这样就为以