浅析计算机软件项目管理中的需求分析

    关键词:需求分析　用户方干系人　项目经理　需求分析员
　　论文摘要:机软件项目管理中的需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。本文介绍了在需求分析研究中探索出的一些有效措施。
　　众观国内计算机软件业的，除远不如欧美等西方发达国家外，与人均GDP不及我国的印度相比也相距甚远，软件业的劣势正严重制约着我国IT业的发展。我国软件业的劣势表现在自主开发的成熟软件不多，而开发的大量软件工程项目(如ERP等)存在缺陷或完全开发失败。目前，国家正在加大对软件工程的研究和对软件工程人才的培养。根据资料显示，属于需求分析造成软件设计的错误和缺陷约占软件失败的6400，而属于程序代码的错误仅占软件失败的360a，数据表明需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。通过对软件项目管理知识的系统学习并结合近年来自己参与部分软件项目实施的经验，介绍在需求分析研究中探索出的一些有效措施。
　　1尽快熟悉项目用户方干系人全貌
    项目用户方干系人，指所有可能受到项目结果重大影响的人，即项目的风险承担者，他可能是项目的受益者，也可能是项目的受害者。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目用户方干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。
    有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，“从头再来”的部分比例很高，大大超过进度要求时间。因此，熟悉项目用户方干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目用户方干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构;还应当在相关单位组织结构图基础上画出全体项目用户方干系人结构图，以便更好更全面地进行需求调研分析;用责任矩阵确定各部分的调研对象;建立调研对象通讯录以保证调研及分析期间及时的沟通。
　　2采取正确的需求获取方法
    软件开发项目的目的就是要实现项目用户方的需求，项目用户方的需求包含明确的和隐含的，也可以分为NEED, WANT, WISH等不同的层次。如果对项目所有用户方干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则会出现客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极，或者是多个用户代表各说各话、昨是今非，项目后期需求变化随意等现象，这就会造成项目范围的蔓延，进度的拖延，成本的扩大，甚至项目的完全失败。
    各种用户对系统具有不同的要求，如一个没有经验的用户关心系统是否简单易用，对于高级用户则关心产品的易用性和高效性。因而需要对用户进行分类，每一个用户类将有自己的一系列功能和非功能要求。在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同的需求。
    项目需求具有双面性(用户与开发商)和多面性(项目中各干系人)，因此，项目经理和系统集成者应了解用户干系人需求，用户干系人也应了解技术方面的需求，两者缺一不可。正确的需求获取需要了解需求的来源、用户的分类、用户的代表性、用户需求谁说了算数等因素。开发人员和项目经理要有足够的耐心聆听用户的讲述，要足够详细地了解每一个细节。项目管理者要善于将需求分类、归类，善于将需求文档化，并有所查询标记。
　　3可视化需求调研，引导各种客户挖掘他们的需求
    有的客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深人挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。
    对于高层领导，可以提供系统总体框架图;对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员，可以用数据流图、实体关系图或UMI中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。
    这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特别提出要求的除外。但是，如果把它提前到需求调研时与客户进行讨论，则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化，以笔者的经验，画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面的需求。原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。
　　4详细描述各项业务，以便让所有客户确认
    尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从近年来开发的软件看，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT(查增删改传)，但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清楚才能设计出适合用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务节点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。
    对于各项业务的调查可以通过对以下资料的收集整理分析来完成，这些资料来自各种各样的项目用户方干系人:遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。 　　5对项目用户方干系人的愿望进行平衡
    不同的项目用户方干系人其愿望和追求的目标往往相差甚远，因此对项目用户方干系人的愿望进行平衡可能是非常重要而又相当困难的事情。例如:我曾在参与的某机管理系统项目中，遇到医院管理层希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，同时为了对信息进行有效控制而增加一些审批流程;而门诊、药房等对外办公的基层窗口则因为客流速度的压力希望减少信息项的输人量;甚至有些不良的基层部门由于害怕建立透明度高的信息系统会影响他们的利益而消极地应付，即所谓反需求;而客户的客户(就诊的病人)则希望相关机构能够简化工作流程，加快办事速度，增加诊断情况和就诊费用的透明度;甚至项目组本身因为技术、资源、进度等原因，需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的，特别是消极的反需求是不能接受的，但他们的需求都是应当考虑全面并进行平衡的。
    如果不同的用户方干系人有不一致的需求，那么必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于决定哪一个用户类所占份额更大。如果系统分析人员提出的需求与开发者所想要开发的系统发生冲突时，通常由于系统分析人员作为客户的代理人，市场需求具有更重的分量，但是，系统分析人员不能一味地迁就客户需求。
    不同的用户方干系人可能都要求产品按照他们各自的喜好来设计。运用项目的业务目标来决定哪些是你最关心的客户，非核心客户的需求可以安排在下一个版本中开发。当开发者想像的产品与客户需求冲突时，通常应该由客户作出决策，然而，不要陷人“客户总是对的”的陷阱中去，现实中，客户并不总是对的。
　　6强调实现项目需求的层次递进性
    了解该系统或者该项目用户所能够提供的最小的工程费用。当预计经费不能支持时，应当考虑将项目分期实施。在系统上、技术上对用户进行引导性建议，使用户了解集成商所要进行的工作，了解集成商是为了帮助用户实现他的需要、达到用户的目的，而不仅仅是为了赚钱，用户更了解集成商，也更了解自己的系统，有利于以后的项目合作、工程实施和系统维护。
    分析用户曾用系统模式、数据结构和库模式，看是否保持、共用、转换，这涉及保护用户投资的问题。根据现在工作业务流情况确定现有的工作模式，还应兼顾将来可能会发生的变化、扩展、新规定，及与同国际接轨可能的带来的变化。考查工程实施环境是否有保证，尤其是工程，必须在需求调查时充分了解用户领域的实施环境，当不具有实施环境时，要求进行配套设计和环境改造。
　　7编写需求文挡和进行需求评审与其他项目小组成员协作完善系统需求
    文档资料是集成商重要的财富，贯穿于系统集成和项目开发的整个过程，其中包括文档、技术文档、资料文挡。文挡要求完整性、一致性、可修改性、可跟踪性。
    以原来的需求为基础的工作完成后，要修补需求错误需要大量的工作，研究表明:比起在需求开发阶段由客户发现的一个错误，然后更正这一错误需要多花到倍的时间。因此，需要进行需求评审。需求审查结束的标准为:已经明确阐述了审查员提出的所有问题、已经正确修改了文档、修订过的文档已经进行了语法检查、所有TBD问题都已经解决、文档归档。
    需求文档完成之后，并不是把它扔给后面的设计人员就了事了。作为项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求分析也是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务。