简析软件需求的分析过程

最近正在做新产品的需求分析，对需求分析阶段的很多问题又有了重新的认识，在此结合以前的经验，就软件需求分析阶段的各个任务，做一下总结，与大家分享。

　　众所周知，软件需求分析是软件生命周期的第二阶段，主要对前期软件定义及计划阶段提到的任务及计划进行概要的补充，需求分析的主要任务不是确定将来的系统怎么完成某项工作，这是设计阶段的事情，而是明确系统将要完成什么功能，对目标系统将要完成的功能提出完整、准确的描述等；在我们国内很多软件公司里，需求分析阶段与设计阶段没有明确的界线，需求分析阶段的很多工作，都会放到设计阶段来做或干脆不做，一般很少严格按照软件工程的方法来执行（通过CMM认证的软件公司还好些），大多数人理解下的需求分析阶段的任务主要还是分三部分：需求的收集、需求整理与编写及最终的评审，在此就这几个阶段中经常遇到的问题作一下大体描述。

　　一、需求的收集 

　　无论是老产品的改造还是新产品的开发，都需要收集大量的需求作为改造的重点对象，需求的收集也可笼统的分二大部分：内部需求与外部需求；内部需求一般包括软件在维护过程中客户反馈的未处理的需求、公司内部其它各部门在实施软件过程中反馈的需求及设计或研发人员在工作当中总结的对软件易用性、效率等方面的需求，还包括研究竞争对手的软件而得出的需求等；外部需求一般包括软件实施人员或代理商对产品提出的改造建议、设计人员直接到客户现场调研、通过与客户沟通而得到的需求等。在收集需求的过程中常会遇到以下几方面的问题：

　　1、 误解客户需求，一般情况下需求分析人员与客户在业务术语表达上有所不同，交流过程中可能会理解有误，特别对于有二义性的需求，会导致分析人员误解客户的需求，也可以理解为需求表达比较模糊，不同的人有不同的理解。
　　2、 需求的不确定性，一是分析人员对需求把握不准，有些从各个渠道反馈回来的需求有些失真，不能完全表达客户的意愿；二是客户需求的变动较大，不确定，不到真正实用很难表达清楚要实现的功能。
　　3、 对时间的合理规划，收集过程中经常感觉时间太紧，无法完整的收集到客户的需求，这一点主要还是跟事先没有计划好有关，需求的收集是一个长期的过程，而不是在某一时间段内就能收集完的，好的需求在于平时的积累，是在日常维护工作中逐渐收集形成的。

　　善于主动寻找需求，而不是坐等需求，收集需求的过程中，要通过各种途径来收集，主动跟客户或同事交流，这样才能在沟通过程中得到很多需求，这点主要还是在于分析人员的沟通能力。

　　二、需求的整理与编写 

　　需求收集完成后，此阶段的任务主要对需求进行过虑、分类整理及编写需求规格，需求的整理不权是分分类、写写需求规格，还要对每个需求进行分析，确定这个需求将来做不做，及实现的优先级是什么（是高、中还是低），这一阶段对分析人员的要求比较高，要纵观全局来考虑，充分考虑到每个需求点对整个系统的影响等，最终形成软件需求规格说明书。这一阶段常见的问题有以下几方面：

　　1、 缺乏对需求的深入理解，需求分析这个岗位在很多软件公司都是虚拟的，没有专人负责，一般由设计或开发人员来负责，这样往往会导致对业务的需求不能深入理解，在系统把握能力上略显不足，导致编写出的需求规格不全面。

　　2、 要正确表达所描述的需求，需求规格作为设计阶段的依据，首先要保证其正确性，对每一个需求都应有一种合理正确的解释，不能存在二义性，所以分析人员在表达需求时要认真严谨，不能模棱两可，更不能含糊其词。

　　3、 要完整表达所描述的需求，完整性是需求规格的重要特征之一，一个好的需求规格应该说明什么需求做，什么需求不做，而不需要说明怎么去做，需求规格只是宏观的描述，为设计阶段划定范围，不应该包含不确性因素在里面，要么做，要么不做，不能遗留任何待解决的问题，而且还要保证需求的完整性。

　　4、 对优先级的排列，任何需求在整理过程中都要分优先级，即问题的重要程度，解决时的优先顺序，需求收集过程中会汇总大量的客户需求，在这些需求当中，有些是客户急需解决的，有些是起锦上添花作用的，这时就需要分析人员结合软件的现状，根据问题的急缓，来划分一下将来处理问题的优先顺序，也是为设计和开发阶段的相关人员提供可参照的依据。

　　三、 需求的评审

　　在我们看来需求的评审是软件需求分析的最后一步，将整理好的需求规格进行评审，最终决定下一步如何执行，需求的评审一般由专业人士来完成，主要包括公司的内部专家及外部专家，公司内部一般包括分析设计人员、各部门开发经理、维护经理、项目经理及资深开发人员；外部专家包括典型客户代表、实施人员代表等，评审的目的主要就软件需求规格中定义的各事项做进一步讨论，根据评审过程中各专家提出的问题再作整理、修改，最终确定需求的状态。评审过程中常见的问题有以下几方面：

　　1、 需求的评审流于形式，需求的评审是最后的把关阶段，有时会遇到这种情况：需求规格编写完成后，在评审的过程中只是简单的走一遍，或者评审过程中讨论激烈，评审后该干么干么，没有事后监督与执行，感觉这一点是导致后续软件不急定的主要原因。

　　2、 对评审人员的要求要严格，不是任何人都可以参与评审的，人多了反而效果不好，参与人员应主要是与需求密切相关的，能对需求能提出改进建议的专家，而不是随便找几个人完事。

　　3、 没有典型客户参与，需求的整个过程最好让具有代表性的客户参与进来，哪怕客户不明白自己真正的想要实现的东西是什么，但在整个过程中客户自始至终起到指导作用，软件是个比较抽象的东西，客户不会多过的关注开发的过程，举个例子：如果你跟客户讨论的是在建工程或大型设备的安装，那么客户肯定会重点关注很多细节，提出很多建议，因为客户明白项目完工后再改造带来的影响，但对于软件，作为客户他考虑不到软件开发完成后，后期变更所带来的麻烦，所以在讨论需求时比较马虎，描述不清楚需求，导致开发者开发出的软件与客户的期望存在巨大差异。

　　4、 用户需求不断的增加，这也是最常见的问题之一，在需求评审的过程中，往往评审人员根据讨论的结果会提出新的需求，会导致不断的更改，所以在编写需求规格的时候要把握一个度，不是任何需求都要列入。

　　5、 对需求做全面的检查，从需求的几个特性去综合考虑，如：需求的完整性、正确性、无二义性、可验证性等。

　　作为客户如果得到的最终软件产品不能满足某项功能，就会让开发人员修改，虽然开发人员后期不管费多大力气最终能修改完客户的需求，客户感觉是理所当然的事情，但作为开发人员来讲，如果程序开发完成后再去修改，也是一件很头疼的事，因为要放下手头的工作，优先去处理客户的问题。这一切的问题都是由于在需求的收集或验证的过程的疏忽造成的。

　　需求验证的最终结果是得到一个完整、正确、可执并且无二义性的需求规格，这样才可为后续工作提供保障，在整个软件生命周期中，一个错误发现的越晚，修复错误的费用越高，软件需求分析阶段可以说是发现错误的阶段，可见其重要性，需求分析阶段看似没有明确的目标，实则不然，这期间对任何问题的疏忽，都会导致系统问题呈扇形扩张，估计做过需求分析的同行都能认识其重要性。任何形式的需求规格说明书都不能保证完全没有错误和缺陷，我们在编写的过程中只能尽量按照软件工程的规范去执行，尽量避免问题的发生。