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

　　有的客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深人挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。

　　对于高层领导，可以提供系统总体框架图;对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员，可以用数据流图、实体关系图或UMI中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。

　　这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特别提出要求的除外。但是，如果把它提前到需求调研时与客户进行讨论，则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化，以笔者的经验，画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面的需求。原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。

　　4详细描述各项业务，以便让所有客户确认

　　尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从近年来开发的软件看，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT(查增删改传)，但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清楚才能设计出适合用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务节点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。

　　对于各项业务的调查可以通过对以下资料的收集整理分析来完成，这些资料来自各种各样的项目用户方干系人:遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。

　　5对项目用户方干系人的愿望进行平衡

　　不同的项目用户方干系人其愿望和追求的目标往往相差甚远，因此对项目用户方干系人的愿望进行平衡可能是非常重要而又相当困难的事情。例如:我曾在参与的某医院计算机管理系统项目中，遇到医院管理层希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，同时为了对信息进行有效控制而增加一些审批流程;而门诊、药房等对外办公的基层窗口则因为客流速度的压力希望减少信息项的输人量;甚至有些不良的基层部门由于害怕建立透明度高的信息系统会影响他们的利益而消极地应付，即所谓反需求;而客户的客户(就诊的病人)则希望相关机构能够简化工作流程，加快办事速度，增加诊断情况和就诊费用的透明度;甚至项目组本身因为技术、资源、进度等原因，需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的，特别是消极的反需求是不能接受的，但他们的需求都是应当考虑全面并进行平衡的。

　　如果不同的用户方干系人有不一致的需求，那么必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于决定哪一个用户类所占份额更大。如果系统分析人员提出的需求与开发者所想要开发的系统发生冲突时，通常由于系统分析人员作为客户的代理人，市场需求具有更重的分量，但是，系统分析人员不能一味地迁就客户需求。

　　不同的用户方干系人可能都要求产品按照他们各自的喜好来设计。运用项目的业务目标来决定哪些是你最关心的客户，非核心客户的需求可以安排在下一个版本中开发。当开发者想像的产品与客户需求冲突时，通常应该由客户作出决策，然而，不要陷人“客户总是对的”的陷阱中去，现实中，客户并不总是对的。

　　6强调实现项目需求的层次递进性

　　了解该系统或者该项目用户所能够提供的最小的工程费用。当预计经费不能支持时，应当考虑将项目分期实施。在系统上、技术上对用户进行引导性建议，使用户了解集成商所要进行的工作，了解集成商是为了帮助用户实现他的需要、达到用户的目的，而不仅仅是为了赚钱，用户更了解集成商，也更了解自己的系统，有利于以后的项目合作、工程实施和系统维护。

　　分析用户曾用系统模式、数据结构和库模式，看是否保持、共用、转换，这涉及保护用户投资的问题。根据现在工作业务流情况确定现有的工作模式，还应兼顾将来可能会发生的变化、扩展、新规定，及与同国际接轨可能的带来的变化。考查工程实施环境是否有保证，尤其是网络工程，必须在需求调查时充分了解用户领域的实施环境，当不具有实施环境时，要求进行配套设计和环境改造。

　　7编写需求文挡和进行需求评审与其他项目小组成员协作完善系统需求

　　文档资料是集成商重要的财富，贯穿于系统集成和项目开发的整个过程，其中包括法律文档、技术文档、资料文挡。文挡要求完整性、一致性、可修改性、可跟踪性。

　　以原来的需求为基础的工作完成后，要修补需求错误需要大量的工作，研究表明:比起在需求开发阶段由客户发现的一个错误，然后更正这一错误需要多花到倍的时间。因此，需要进行需求评审。需求审查结束的标准为:已经明确阐述了审查员提出的所有问题、已经正确修改了文档、修订过的文档已经进行了语法检查、所有TBD问题都已经解决、文档归档。

　　需求文档完成之后，并不是把它扔给后面的设计人员就了事了。作为项目组其他成员，对需求的有效性也起到某种程度的验证作用。虽然软件项目的生命周期按照各种开发模型有不同阶段的划分，但每个阶段的结束不是简单地把阶段工作成果塞给下一阶段的成员就可以了。特别是高科技的软件开发项目，上一阶段的工作成果往往要通过多次的沟通才能更为清晰地被下一阶段成员接受，其有效性、合理性也要被下一阶段的工作所检验，通过检验有时也有必要对上一阶段的工作结果进行相应的调整，需求分析也是如此。因此，无论是同一阶段不同人员之间，或是不同阶段人员之间都应根据需要相互协作，相互配合，共同完成软件开发任务。

　　论文榜（www.zglwb.com），是一个专门从事期刊推广、投稿辅导的网站。
本站提供如何投稿辅导，寻求投稿辅导代理，快速投稿辅导，投稿辅导格式指导等解决方案：省级投稿辅导/国家级投稿辅导/核心期刊投稿辅导//职称投稿辅导。


期刊鉴别	论文检测	免费论文	特惠期刊	学术答疑	发表流程

搜索

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