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