时间：2022-05-31 06:13:56
开篇：写作不仅是一种记录，更是一种创造，它让我们能够捕捉那些稍纵即逝的灵感，将它们永久地定格在纸上。下面是小编精心整理的12篇项目需求分析，希望这些内容能成为您创作过程中的良师益友，陪伴您不断探索和进步。
2 什么是需求分析
结构化软件开发一般分为分析、设计、开发、测试、验收与运行等阶段。开发前，会进行前期的可行性研究；在运行开始以后，还要进行后期维护。需求分析是结构化开发中的重要阶段。通常情况下，国内软件开发公司在做欧美和日本的项目时，对前期的可行性研究参与得较少，一般都是对方已经做完可行性研究，国内软件开发公司从需求分析开始做起，直到软件开发后的运行和维护。所谓需求分析，是指对要解决的问题进行详细的分析，弄清楚客户的需求，包括需要输入什么数据，要得到什么结果，最后应输出什么，等等。可以说，软件工程当中的需求分析就是确定要计算机做什么。
3 需求分析的重要性
从需求分析的定义上，就可以看出需求分析在软件开发过程中的重要性了。需求分析做得不对，后面的步骤做得再好，也只能是南辕北辙，无法满足客户的要求。研究表明，改正产品付诸应用后所发现的一个需求方面的缺陷，比在需求阶段改正这个错误要多付出大约100倍的成本。而另一项研究发现，在需求开发阶段发现的一个错误，平均仅需要花30分钟修复，但若在系统测试时发现则需要5-17个小时来修复。
需求工程的成功与否直接关系到系统给的命运，需求工程绝对不是软件开发的前期任务，而应该在整个系统的生命周期里都扮演着重要角色。在需求工程阶段解决和根除需求引起的问题可以大大降低生产和维护的成本，提高用户的满意度。在软件开发的过程中，需求工程阶段是了解用户需求的最佳时期，但很大一部分用户不知道、不了解需求工程，以至于在和他们交流的时候，他们都不能准确完整的说出自己的需求，因而对于从事需求工程的人员来说，能够正确的理解用户的需求观点，利用一些方法和技巧来启发用户阐述清楚自己的需求是很重要的。需求工程作为了解并实现软件开发者的目标的重要手段，有着不可替代的作用。
比如一个失败的案例：由于和客户签订了合同，5个月必须交付软件，开发时间紧迫，导致项目计划时做需求分析的时间只给了2周时间（理由是客户的文档已经提供好了，照着做即可）。结果，由于前期对客户文档理解得不是很清楚，导致开发进行到3个月的时候发现需求上有争议。在和客户确认后得出结论：如果要满足客户的要求，则需要对整体架构进行修改。虽然最后按期交付了软件，但是整个项目组最后两个月每天都在加班，包括周末，而且软件质量也没有得到客户的充分认可。
再如我們在了解客户需求的同时，应该尽量了解客户为什么要这么做，帮客户一起想需求，以便我们开发的软件能够更好地为客户服务。每天开完会后，我们应该把客户的需求整理好，发给同事进行研究分析，建立简单的基础模型并研究技术可行性。需求分析结束后，保持每周至少3次电话会议与客户进行沟通，随时了解客户的需求。最后正因为在前期阶段进行了这种细致的需求分析，项目组在很少加班的情况下，不但按时交付了项目，并且得到客户的充分认可。
4 软件需求分析的任务
软件工程的发展来源于信息需求对它的推动，现在互联网技术和应用越来越成熟，信息的获取也逐渐变得简单和完整，但是由于资源的开放性、系统与系统的相互渗透性、用户的变动性让需求变得多目的、多变化，增加了软件制作的难度，但同样带来了巨大的用户市场。需求的获取同样也是困扰软件工程的绊脚石。需求与资源的搭配不合理，就会影响软件工程的发展。未来适应变化多端的用户需求，必须让软件也随之变化。要满足多样化的信息需求，提取合适的信息需求建立模式，就要有相应的系统对需求信息进行分析和总结，通过程序化的模式来制定切实可行的软件方案。
国项目中，在前期分析时软件开发的核心技术人员和测试人员就已经进入项目组，每天技术人员会对分析的结果提出技术实现的难点以及改进的方法，笔者在随后的会议上就会和客户进行讨论，尽量在满足客户需求的同时，使用更简单可行的技术，这样就为以后的开发奠定了基础，使开发时的工作量大大减少。测试人员也在需求时提出从测试角度看到的问题，同样在需求分析阶段得到解决，节省了大量的开发时间。
需求工程在未来发展中会有如下几个方面的着重考虑：（1）缩小需求工程在理论研究阶段取得的成果同实际应用中得到的效果的差距，通过得到的结论来更好的设计软件；（2）规范需求工程的各种机制，可以有需求工程规格数据的搜集、整理、制作、实现以及维护，也可以有需求工程的问题的解决办法；（3）保证需求工程有较高的质量。这一点是需求工程最为关键的要求，质量的高低直接影响了未来实现效果的好坏。需求工程就是对未知问题进行探索、处理的过程。未来必然会朝着对象具体化、分析自动化的方向发展。
5 进行需求分析的注意事项
5.1 需求分析是分析人员与用户共同的责任
用户必须对软件功能和性能提出初步要求，并澄清一些模糊概念。而需求分析人员则要认真了解用户的要求，细致地进行调查分析，把用户做什么的要求最终转换成一个完全的、精细的软件逻辑模型，并写出软件的需求规格说明，准确地表达用户的要求。在一些项目中，由于时间紧迫，一些模糊问题没有及时澄清，导致最后返工，影响了项目进度。
5.2 需求分析阶段研究的对象是软件项目的用户要求
需要注意的是，必须理解用户的各项要求，但又不能全盘接受所有的要求。在一些项目中，针对客户提出的需求，了解客户的意图后，发现技术上实现有很大难度。我们了解到这个需求对客户来说不是十分重要，于是和客户商量出一个折中的解决方案，绕过技术难点，并且没有降低客户满意度。
5.3 主动积极了解客户业务和相关知识
求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语教给分析人员，而客户不一定要懂得计算机行业的术语。由于通常情况下客户对计算机术语了解不多，需求分析人员应该尽量将计算机术语转化成通俗易懂的语言，这样便于和客户沟通。而对于客户方面的术语，一方面不懂的时候一定要问；另一方面也要多学习。
论文摘要:计算机软件项目管理中的需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。本文介绍了在需求分析研究中探索出的一些有效措施。
众观国内计算机软件业的发展，除远不如欧美等西方发达国家外，与人均GDP不及我国的印度相比也相距甚远，软件业的劣势正严重制约着我国IT业的发展。我国软件业的劣势表现在自主开发的成熟软件不多，而开发的大量软件工程项目(如ERP等)存在缺陷或完全开发失败。目前，国家正在加大对软件工程的研究和对软件工程人才的培养。根据资料显示，属于需求分析造成软件设计的错误和缺陷约占软件失败的6400，而属于程序代码的错误仅占软件失败的360a，数据表明需求分析是提高软件质量的基础也是决定一个软件项目成败的关键。通过对软件项目管理知识的系统学习并结合近年来自己参与部分软件项目实施的经验，介绍在需求分析研究中探索出的一些有效措施。
1尽快熟悉项目用户方干系人全貌
项目用户方干系人，指所有可能受到项目结果重大影响的人，即项目的风险承担者，他可能是项目的受益者，也可能是项目的受害者。因此，应当从项目的启动开始，需求分析员及其项目成员就要分清项目用户方干系人包含哪些人和组织，通过沟通协调对他们施加影响，驱动他们对项目的支持，调查并明确他们的需求和愿望，减小其对项目的阻力，以确保项目获得成功。
有些项目在做需求调查时，由于受进度要求等客观因素影响，需求分析员与建设单位的技术部门交流较多，向业务管理部门和实际使用者调查不够深入，造成软件试用后不得不再对需求做较大调整，“从头再来”的部分比例很高，大大超过进度要求时间。因此，熟悉项目用户方干系人全貌是进行需求调查的第一步，也是需求调查的基础。在定制开发项目的项目用户方干系人中，最重要的是建设单位中的人事组织、业务关系。最好是能够用组织结构图画出相关单位的组织结构;还应当在相关单位组织结构图基础上画出全体项目用户方干系人结构图，以便更好更全面地进行需求调研分析;用责任矩阵确定各部分的调研对象;建立调研对象通讯录以保证调研及分析期间及时的沟通。
2采取正确的需求获取方法
软件开发项目的目的就是要实现项目用户方的需求，项目用户方的需求包含明确的和隐含的，也可以分为NEED， WANT， WISH等不同的层次。如果对项目所有用户方干系人没有进行足够的沟通和影响，使其尽可能地参与项目，则会出现客户方相关责任人不明确或对范围和需求责任心不强，提出的需求具有随意性，项目前期对需求的确认不够积极，或者是多个用户代表各说各话、昨是今非，项目后期需求变化随意等现象，这就会造成项目范围的蔓延，进度的拖延，成本的扩大，甚至项目的完全失败。
各种用户对系统具有不同的要求，如一个没有经验的用户关心系统是否简单易用，对于高级用户则关心产品的易用性和高效性。因而需要对用户进行分类，每一个用户类将有自己的一系列功能和非功能要求。在项目中，要尽早为产品确定并描述不同的用户类，这样就能从每一个重要的用户类代表中获取不同的需求。
项目需求具有双面性(用户与开发商)和多面性(项目中各干系人)，因此，项目经理和系统集成者应了解用户干系人需求，用户干系人也应了解技术方面的需求，两者缺一不可。正确的需求获取需要了解需求的来源、用户的分类、用户的代表性、用户需求谁说了算数等因素。开发人员和项目经理要有足够的耐心聆听用户的讲述，要足够详细地了解每一个细节。项目管理者要善于将需求分类、归类，善于将需求文档化，并有所查询标记。
3可视化需求调研，引导各种客户挖掘他们的需求
有的客户因为自己缺乏计算机知识，无法提出完整准确、隐含的或潜在的需求。若这些需求不能满足将导致用户的不满。因此需求调研分析人员应善于想用户所想，不但要确定明确的需求，还要善于用启发的方式与用户探讨隐含的或潜在的需求，并结合各种调研分析技术挖掘超出客户期望的令人兴奋的需求。这就要求需求调研分析员要尽快完整地熟悉相关业务，从而能够站在用户的立场看待软件需求，想用户所想，做好业务与计算机之间的桥梁。利用可视化需求调研的方法可以很好地启发用户深人挖掘潜在的需求。可视化需求调研就是使用图表等工具来启发引导用户清楚地叙述需求，并且使需求更加全面完善。
对于高层领导，可以提供系统总体框架图;对于业务管理人员，可以用业务流程图来描述新旧系统的业务流程;对于客户中的技术人员，可以用数据流图、实体关系图或UMI中的各种图形对系统进行各种角度的描述;而对于业务管理人员、客户中的技术人员、以及各层次各流程中的用户，画出用户界面图来进行需求挖掘，是个比较有效的沟通方式。
这里特别说明一下用户界面的重要性。用户界面的设计按理来说是软件设计的责任，当然客户自己对界面有特别提出要求的除外。但是，如果把它提前到需求调研时与客户进行讨论，则可以大大改善需求调研的效果。因为这时客户对于将来的系统还没有一个形象上的概念，或者有一个模糊的预想的概念需要表述、验证、明晰化、完善化，以笔者的经验，画出用户界面草图与客户进行讨论，可以大大激发他们提供更为准确全面的需求。原来收集资料，描述业务，说明系统模型到了山穷水尽的时候，这种方法可以达到柳暗花明又一村的效果。
4详细描述各项业务，以便让所有客户确认
尽可能全面详细地调查并且描述原有系统和用户希望将来系统具有的各项业务的流程，并将这些业务流程文档化后与客户进行讨论，对描述错误或不准确不精确的进行修改，最终让客户进行确认。从近年来开发的软件看，对业务处理过程了解的完整性和准确性非常重要。虽然对数据来说都是SIDUT(查增删改传)，但具体业务都是分为若干步骤，每个步骤都有其业务名称，同一步骤可能对多个数据集进行不同操作，需要调查了解清楚才能设计出适合用户业务特点和习惯的软件，使开发出来的软件更受欢迎。当然在进行软件概要设计时，要尽量排除业务流程的制约，即把流程中的各项业务节点工作作为独立的对象，充分考虑他们与其他各种业务对象的接口，在流程之间通过业务对象的相互调用实现其业务流程，这样，在业务流程发生有限的变化时，就能够比较方便地修改系统程序而实现新的需求。
对于各项业务的调查可以通过对以下资料的收集整理分析来完成，这些资料来自各种各样的项目用户方干系人:遵循的标准、组织发放的工作手册、作业流程、有关业务的上级通知、有关业务的办事指南、办理业务时需要填写的登记表、各种相关的统计报表及通过其他途径收集的类似系统的介绍、技术资料等等。
5对项目用户方干系人的愿望进行平衡
不同的项目用户方干系人其愿望和追求的目标往往相差甚远，因此对项目用户方干系人的愿望进行平衡可能是非常重要而又相当困难的事情。例如:我曾在参与的某医院计算机管理系统项目中，遇到医院管理层希望能够采集尽可能多的信息项以便对数据进行多种多样的统计分析，同时为了对信息进行有效控制而增加一些审批流程;而门诊、药房等对外办公的基层窗口则因为客流速度的压力希望减少信息项的输人量;甚至有些不良的基层部门由于害怕建立透明度高的信息系统会影响他们的利益而消极地应付，即所谓反需求;而客户的客户(就诊的病人)则希望相关机构能够简化工作流程，加快办事速度，增加诊断情况和就诊费用的透明度;甚至项目组本身因为技术、资源、进度等原因，需要对一些功能进行优先级排序和取舍。虽然不是所有人的需求都是可以满足的，特别是消极的反需求是不能接受的，但他们的需求都是应当考虑全面并进行平衡的。
如果不同的用户方干系人有不一致的需求，那么必须决策出满足哪一类用户方干系人的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于决定哪一个用户类所占份额更大。如果系统分析人员提出的需求与开发者所想要开发的系统发生冲突时，通常由于系统分析人员作为客户的人，市场需求具有更重的分量，但是，系统分析人员不能一味地迁就客户需求。
不同的用户方干系人可能都要求产品按照他们各自的喜好来设计。运用项目的业务目标来决定哪些是你最关心的客户，非核心客户的需求可以安排在下一个版本中开发。当开发者想像的产品与客户需求冲突时，通常应该由客户作出决策，然而，不要陷人“客户总是对的”的陷阱中去，现实中，客户并不总是对的。
6强调实现项目需求的层次递进性
了解该系统或者该项目用户所能够提供的最小的工程费用。当预计经费不能支持时，应当考虑将项目分期实施。在系统上、技术上对用户进行引导性建议，使用户了解集成商所要进行的工作，了解集成商是为了帮助用户实现他的需要、达到用户的目的，而不仅仅是为了赚钱，用户更了解集成商，也更了解自己的系统，有利于以后的项目合作、工程实施和系统维护。
分析用户曾用系统模式、数据结构和库模式，看是否保持、共用、转换，这涉及保护用户投资的问题。根据现在工作业务流情况确定现有的工作模式，还应兼顾将来可能会发生的变化、扩展、新规定，及与同国际接轨可能的带来的变化。考查工程实施环境是否有保证，尤其是网络工程，必须在需求调查时充分了解用户领域的实施环境，当不具有实施环境时，要求进行配套设计和环境改造。
7编写需求文挡和进行需求评审与其他项目小组成员协作完善系统需求
文档资料是集成商重要的财富，贯穿于系统集成和项目开发的整个过程，其中包括法律文档、技术文档、资料文挡。文挡要求完整性、一致性、可修改性、可跟踪性。
关键词：软件工程；需求分析与管理
中图分类号：TP311文献标识码：A文章编号：1007-9599 (2010) 15-0000-01
The Requirements Analysis and Management of Software
Huang Degui
(Communications Information Branch,Zhanjiang Port(Group)Co.,Ltd.,Zhanjiang524019,China)
Abstract:In the process of software development requirements analysis and management,there are some problems.This paper analyzes the problems and issues reference for these recommendations and solutions.
Keywords:Software engineering;Requirements analysis and management
在软件项目开发过程中，需求分析与管理十分重要。但在实际的软件项目开发的需求分析与管理过程中存在一些问题，如果不重视这些问题，往往导致项目开发进度延期、超出项目预算甚至项目开发失败。
在软件工程理论中，需求分析是指构建一个新的系统或者完善现有系统时，确定系统的目标、范围、功能需求和非功能性需求等方面所涉及的工作。
需求分析是软件工程的一个关键过程，也是软件项目开发的一个关键阶段。软件需求分析人员需要准确、清晰和形象的表达和描述用户的真实需求。需求分析阶段的工作是否准确和充分、提交的软件需求说明书是否完善和规范、需求管理的方法是否正确将直接影响和决定整个项目开发是否能够按照时间进度和在项目预算范围内完成。
在项目开发过程中，经常出现如下情况：软件需求分析人员描述的用户需求不完整、用户需求经常发生变化、软件需求分析人员与系统设计人员的沟通障碍、开发人员边做需求分析边做开发、用户需求管理混乱、缺少专业的需求分析与管理工具等。这些情况的出现使整个项目管理风险加大、系统代码返工率高、项目团队士气日益低下和用户对项目开发进度的抱怨越来越多，最终可能导致整个项目开发失败。
软件需求分析人员描述的用户需求不完整主要原因：一种情况是没有专职的软件需求分析人员，兼职的软件需求分析人员同时担当该模块的设计及开发，导致需求分析没有真正从业务的角度来考虑，而是从技术实现的角度考虑。有的即使有专职的软件需求分析人员，该软件需求分析人员也不具备该行业的业务知识和经验，对行业术语不了解，有的甚至聘用刚刚毕业的学生去做需求分析，导致整个需求分析不准确甚至出现偏差。另外一种情况是专职的软件需求分析人员没有系统的学习和掌握软件需求分析的基本方法、原则和技巧，了解的业务需求不能准确直观的表达和描述，编制的软件需求说明书过于简单和形式化，导致项目开发的其他人员不能很好的理解用户需求，有的甚至要重新做软件需求分析。
为详细和准确的描述用户需求，需要注意以下几个方面：
首先需要由专职的人员担任需求分析工作，而且软件需求分析人员需要系统的学习和掌握需求分析的基本方法、原则和技巧。例如获取业务需求常用的方法有用户访谈、速记、谈话录音、会议纪要等；其中用户访谈的要点包括确定访谈的时间、访谈的对象、设计用户访谈计划并提前发送给用户等；速记要求软件需求分析人员能够快速准确的记录用户描述的业务需求和业务流程。谈话录音和会议纪要是为了更准确记录用户描述的业务需求，便于分析和理解用户需求；软件需求分析人员最好具备该行业的业务经验和知识或者聘请该行业的业务专家指导，这样有助于软件需求分析人员准确分析和理解行业术语、行业业务需求和行业业务流程。
其次，描述的软件需求说明书内容应该包括系统的目标、范围、功能需求、非功能性需求和系统界面原型等方面。非功能性需求主要包括系统界面的可用性、易用性、操作便捷、时间效率高、出错率低和操作系统需要的专业领域知识少等方面；系统界面原形是指使用专业界面原形工具（Axure等）或者直接使用开发工具（Visual Studio等）编制系统的初始用户界面，便于软件需求分析人员、系统设计人员和开发人员更直观和形象的与用户沟通和明确需求。非功能性需求和系统界面原形在需求分析阶段非常重要，我们在项目开发过程中应该注重非功能性需求和系统界面原形。
最后，对于软件需求分析人员编制的软件需求说明书要做好需求验证工作，参加需求验证工作的成员应该包括项目组所有成员、该行业的业务专家和最终用户。在需求验证会议上提供的需求验证材料应该简单、清晰、直观和明确，不能笼统的提供一些复杂的业务流程及繁琐的文字说明。在需求验证会议上可以通过情景模拟和系统界面原形的方式演示。情景模拟是根据不同业务角色模拟整个业务办理的情况。系统界面原形能让用户切身感受到系统的界面效果，便于直观、形象的沟通和交流业务细节和业务流程。
在项目开发过程中，用户需求发生变化的情况经常出现。我们不能避免和逃避用户需求变化情况的出现，但应该控制和管理用户需求变化，应该有需求变更的流程、需求变更的团队、需求变更的平台、需求变更的影响分析以及固定的需求变更周期。对于用户提出的需求变更，我们首先应该做好详细的记录，然后将需求变更的记录通过需求变更的流程提交给需求变更团队评估和确认，最终在需求变更的平台中反映出来，同时要做好需求变更的影响分析报告并及时反馈给用户。需要注意的是对于需求变更我们要有固定的需求变更周期，不能用户有需求变更马上要求项目团队及时更改系统，这样会加大项目管理的风险和影响项目团队的士气。
[关键词] 需求分析 需求变更 需求控制
一、问题的提出
什么是需求分析?
要知道需求变更是什么,首先要知道什么是需求分析。
需求分析是指理解客户需求,就软件功能与客户达成一致,估计软件风险和评估项目成本代价,最终形成开发计划的一个复杂过程。需求分析的成果形成需求说明书。
什么是需求变更?
根据软件工程思想定义,需求说明书一般要经过论证,如果在需求说明书经过论证以后,需要在原有需求基础上追加和补充新的需求,或对原有需求进行修改和削减,均属于需求变更。
二、需求变更的原因及影响
1.需求变更原因
一方面是用户:他们是项目需求的提出者。一个十分常见的现象是用户提出需求以后,在软件开发过程中用户改变了需求,这只能迫使开发工作返工,丢弃一些无法修正的部分。无疑这会造成一定的损失,但又无法完全避免。要求用户一次性把需求讲清楚,并且不允许此后需求有任何变更,这是不现实的。只能尽量减少需求变更,降低它所造成的影响。
二是系统因素:在系统内部,如计算机硬件、系统软件或数据的变更要求与其相适应。
三是外部环境因素:与软件运行相关的工作制度或法规、政策的变更,或是业务要求变更导致的需求变更。
四是需求分析阶段工作缺陷:需求调研、分析、定义和评审工作不够充分,致使需求规格说明中隐含着问题,在开发过程中才有所发现。或者需求开发中开发人员与用户沟通不够充分,如未能如实获得用户的潜在需求等。
软件需求一旦出现变更,它可能要涉及到一些相关的代码和文档的修改,为此要把这一变更通知到所有相关人员。提出需求变更有可能在开发的任何阶段,并且随着项目的进展,越晚的需求变更引起的损失越大。
2.需求变更给软件的开发工作带来的影响
需求变更对软件开发的影响是多方面的,概括的看,包括以下三个方面:
(1)增加项目的人员、费用开支,影响开发进度。需求变意味着原先的需求调研、分析的结果与预期的软件实现存在偏差,需要进行需求变更。这无疑要增加项目的人员、费用的开支,并对开发进度造成影响。更有甚者,如果变更频繁,可能对项目造成较大影响,严重时可能直接导致项目的失败。
(2)影响软件质量。在一个复杂的软件系统中,需求之间具有一定的联系,相关需求可构成需求链。如果由于需求变更导致需求链的某些环节脱节,就可能引起一些难以察觉的错误。当需求变更没能及时修改项目的设计、开发文档时,这些错误一般难以被测试人员发现,将直接影响系统质量,严重时可导致系统崩溃。
(3)影响开发者与用户之间的合作关系。需求变更的实施是用户和开发者相互协作的过程。开发者和用户在是否采用变更问题上常常产生分歧,如果没有恰当处理,影响双方的互信,从而影响项目开发进程。同时需求变更也会在项目开发人员之间产生分歧,影响合作关系。
三、采取的对策
1.首先是预防
尽量做好需求分析工作,以期减少需求变更的频次,为此在需求分析阶段着重处理好以下问题,力图使需求分析的结果更接近目标。
(1)培养正确的需求意识。优秀软件产品建立在优秀的需求基础之上,而高质量的需求又来源于客户与开发人员之间有效的交流与合作。因此,双方的参与者都需要认识到:要想获得成功,自己需要什么,合作方又需要什么。只有这样,才能建立融洽的合作关系。因此,培养正确的需求意识是双方都需要努力的,而开发人员在这个阶段应该发挥更加积极主动的作用。
首先,需求分析人员应该接受一定的正规培训,以提高与人沟通的能力、缓解矛盾的能力、善于倾听和询问的技巧,以及收集整理资料的能力等。在参与具体项目时,分析人员也应主动学习一些项目所涉及的具体应用领域的基本知识,以更好地理解用户的需求。
其次,开发单位应该对那些不想花时间在需求分析上的用户明确指出:如果用户不能充分地支持并参与,项目很可能会失败;开发单位还可以通过学习一些前车之鉴的真实案例警告用户:低质量的需求分析可能导致严重的后果。通过对用户代表和管理人员的培训,使他们真正理解需求分析的重要性和忽略需求带来的风险,并对计算机系统有一个大体的了解,这样用户才能够主动地参与需求分析。
同时,正因为不可能一次就完全了解用户的需求,而且在系统开发过程中还需要不断地请用户参与,因此与用户的沟通是需要贯穿始终的。需求分析中所采取的一些策略可能会让用户觉得意外和难以接受。因此,需求分析人员需要对用户解释一些做法的必要性和合理性,以得到用户最大的支持与合作。
(2)从业务需求入手。用户认识到了需求分析的重要性,但可能仍然不知道从何处入手表达自己的需求。这时可以从业务需求入手,任何企业对自己的经营运作目标应该是比较清楚的,这样的经营背景让用户不仅有话说,也让开发者有章可循。需求分析不可以完全与它所处的背景相脱离,只有当系统真正置身于它的社会和组织环境中,它的需求才能清晰地反映出来。
(3)充分利用需求来源。有了以上需求背景,就比较容易做到有的放矢了。需求分析人员可以直接与系统未来的操作者探讨他们希望有什么样的软件;观察系统的潜在用户当前的日常工作以获取有价值的信息;系统的使用者可能有很多,可以将他们分类以简化需求;最后一定要与真正的决定者达成协议:对于有冲突的需求如何权衡,对于直接用户的众多需求如何取舍等。
同时,用户往往对计算机期望过高,认为计算机可以解决当前存在的所有问题,因此会提出很多的功能需求,并且希望在很短的时间内看到成效。但是,由于技术、人力等资源的限制,并不一定能够在设定的时间期限内满足用户所有的期望,这时就应该尽早确定出交付的产品应具备的最重要功能,即设定需求的优先级。
在这个阶段,可以采用UML中的用例图帮助用户和需求分析人员之间的交流。一个用例图描述用户可以用软件产品执行的一个任务。它不是从软件的性能和系统的行为方面出发,而是从用户到底能够用这个软件产品干什么入手。这样的方式用户比较熟悉,容易沟通;而且不会在需求分析的一开始就陷入过于细节化的设计,也有助于避免分析人员添加一些与所需任务无关的自认为很好的功能。
(4)提供选择方案。由于用户对软件系统缺乏经验,或者由于用户的运作机制还未完善,或者由于其他种种原因,用户可能仍然不能对一些需求做出明确的说明,收集整理的需求中可能仍然存在一些不确定因素。这时可提出几份比较详细的方案。附带不同做法的优点,供用户选择或者启发用户确定需求。
如果需求分析做得好,文档清晰且又有客户签字,那么后期客户提出的变更就超出了合同范围,需要另外收费。这个时候,开发方一定要据理力争,此时这并非要刻意赚取客户的钱财,而是不能让客户养成经常变更的习惯,否则后患无穷。
2.分级管理客户需求
软件开发项目中,“客户永远是对的”和“客户是上帝”并不完全的正确,因为在已经签定的项目合同中,任何新需求的变更和增加除了影响项目的正常进行以外,还影响到了客户的投入收益,所以有的时候项目经理反倒应该为客户着想。
对于项目中的需求变更,可以实行分级管理,以达到对需求变更的控制。
一级需求变更是关键性的需求,这种需求如果不满足,意味着整个项目不能正常交付使用,前期工作也会被全部否定。这个级别的需求是必须满足的,否则就意味着否定自已的项目成员和成员的所有努力,所以定为“Urgent”。
二级需求变更是后续关键性需求,它不影响前面工作内容的交付,但不加以满足,新的项目内容无法提交或继续,所以是“Necessary”。一般新模块关键性的基础组件,属于这个级别。
三级需求是后续重要的需求,如果不被满足会令整体项目工作的价值下降,为了体现项目价值,也是开发人员自已的技术价值的证明,所以定为“Needed”。一般性的重大的有价值的全新模块开发,属于这个级别。
以上三个等级是应该实施的,但时间性上可以作优先级的排列。
四级需求是改良性需求,没有满足这类需求并不影响已有功能的使用,但如果实现了则会更好,定级为“Better”。界面和使用方式的需求,一般在这个档次。
五级需求是可选性需求,更多的是一种设想,以及一种可能,通常只是客户的的一种个人喜好而已,定级为“Maybe”。
对于四级需求,如果时间和资源条件都允许的话,不妨做下去。对于五级需求,正如对它的描述一样做与不做是“Maybe”。
3.加强需求变更的控制
在需求分析阶段工作完成后,需求变更仍可以会发生,因此就要加强对需求变更的控制,主要有以下原则:
(1)建立需求基线。需求基线是需求变更的依据。在开发过程中,需求确定并经过评审后(用户参与评审),可以建立第一个需求基线。此后每次变更并经过评审后,都要重新确定新的需求基线。
(2)制订简单、有效的变更控制流程,并形成文档。在建立了需求基线后提出的所有变更都必须遵循这个控制流程进行控制。同时,这个流程具有一定的普遍性,对以后的项目开发和其他项目都有借鉴作用。
(3)成立项目变更控制委员会(CCB)或相关职能的类似组织,负责裁定接受哪些变更。CCB由项目所涉及的多方人员共同组成,应该包括用户方和开发方的决策人员在内。
(4)需求变更一定要先申请然后再评估,最后经过与变更大小相当级别的评审确认。
(5)需求变更后,受影响的软件计划、产品、活动都要进行相应的变更,以保持和更新的需求一致。
(6)妥善保存变更产生的相关文档。
这六大原则看起来简单,但真正实施起来有难度,还需要依据理论知识配合开发项目组的实际工作情况,在实践中不断摸索总结。
四、总结
软件项目的需求变更是对软件产品的质量、成本、工期带来巨大的影响。通过预防性措施和加强需求变更的控制与管理,将需求变更的频次大幅度降低,从而为软件项目的顺利实施打下坚实基础。
参考文献:
[1]王 莉 吴洁明:软件项目中的需求变更管理的研究[J].计算机技术与发展,2007,17(1):120～121
[2]王 强:软件开发项目中的需求变更管理[J].电脑知识与技术(学术交流),2007,(11)
随着计算机技术的发展，我国逐渐在软件工程理论中取得了很大的成就。对于软件需求分析取得的结果也是软件项目开发的重点，软件开发项目的成本其实取决于软件需求的分析。由此可见，提高软件需求分析质量不仅能够促进软件项目的发展，更是提高计算机软件技术的重要手段。本文就软件需求分析的任务与要点进行分析，并针对存在的问题提出具体措施。
【关键词】计算机技术 软件技术 软件需求分析 存在的问题
计算机技术与信息技术的飞速发展，不仅给人们的工作生活带来了方便，更促进了经济的发展，使得其被广泛运用到各个行业中。计算机技术的发展带来的不仅是硬件方面的技术提升，各种软件也逐渐趋于多元化。随着人们对于计算机软件的需求越来越高，软件产品的需求分析质量直接关系到软件成品的质量。下文就软件需求分析的任务和基本特点进行分析，就怎样提高软件需求分析质量展开讨论。
1 软件需求分析任务分析。
1.1 软件工程概述
IEEE将软件工程定义为能够系统的、规范的、可度量化的工程方法运用到软件开发、运行以及维护等全过程中去的方法。软件工程由方法、工具以及过程三部分组成，所谓方法就是指完成软件工程项目的一种技术手段，是支持整个软件生命周期的手段。而软件开发的方法必须遵循一定的方法和步骤，软件开发模型是软件开发过程的一种概括。现代软件开发模型可以分为以软件需求确定为基本条件的瀑布模型、处于软件开发初期，却只能提供基本去修采用的迭代式、渐进式开发模型以及以形式化开发方法为前提的变换模型三种类型。
1.2 软件需求分析的任务
所谓软件需求分析就是指客户对目标软件产品在功能、行为、性能以及设计约束上的期望，软件需求分析就是对这些问题或者涉及到的信息、功能建立模型，将客户的需求进一步精确化、完全化。软件需求分析的主要任务就是借助当前系统的逻辑模型对目标系统进行逻辑模型建立，并解决需求的具体问题。
1.3 软件需求分析的重要性
总的来说，软件需求分析对软件产品起着决定性的作用，软件的开发必须满足客户的要求，客户的要求必须由软件分析来挖掘，并根据客户的需求来完善软件的性能、功能以及设计。此外，软件需求分析更是对软件的后期开发具有一定的引导作用，可以让软件项目人员明确好开发的方向并加以实施，通过合理的软件需求分析，才能更好的将软件的功能、性能总体概括出来成为具体的规格说明，为软件开发指明方向。
2 提高软件需求分析质量的控制要点分析
2.1 软件开发成本的控制
软件开发也是决定软件开发质量的重要因素，包括管理成本、人力成本、设备成本以及环境等成本内容。在软件开发的时间过程中，软件开发项目的风险是产生需求变化最主要的原因。对于软件需求者来说，软件开发和需求分析是一个漫长的过程，如果超过了预期的时间，很可能带来开发成本的上升。因此，为了控制软件开发的成本，提高软件成品的质量，则需要在软件需求确定、人员正确分配的基础上探索新的方法，创造新的标准化流程。
2.2 软件需求分析的流程改造
尽管人们对软件需求分析工作的重要性有所认识，但在这方面的研究还少。事实上，软件需求分析可以分为软件开发和软件管理两大环节，且都是为人服务的。所以软件需求分析有三大重点要素，分别是界面、说明和函数关系。改变传统的软件工程理论生产顺序，将验收标准与操作使用手册提前制定，这样一来，既彻底明确了用户和开发者之间的责任，使得软件开发的目标更加明确，又能将需求分析与后续的开发阶段进行分离，以减少用户在开发过程中投入的人力、降低软件开发对专业人员的依赖。更是为后期的外包创造了条件，且降低了对需求分析人员的高要求。
2.3 人员分配策略分析
实际上，人员分配策略对于软件开发成本的影响非常明显，高质量的人才对于成本的要求就越高，而合适的人员才能发挥最佳的作用后，有效降低开发成本，两者是互相作用的。针对人员分配中存在的问题，加以改进，以确定更适应的需求方法，从需求分析阶段起就应针对性的进行人员分配策略改造，在保证软件开发质量的基础下，降低总体开发成本。与此同时，按照现有的软件需求来确定软件工程理论进行软件生产，最终交付合格的产品，不仅减少了需求分析的人力成本，更提高了软件生产的效率。
3 结语
总的来说，软件需求分析是软件开发整个过程中非常重要的环节，完善的软件需求分析不仅是降低软件开发成本的重要措施，更是促进软件产品获得更大经济收益的手段。显然，提高软件需求分析质量是顺利进行软件开发工作的必要策略。
参考文献
[1]杨毅，杨杰.一种提高软件需求分析质量的方法[J].计算机系统应用，2014（05）：16-20.
[2]王兰. 提高软件需求分析质量的探讨[J]. 电脑知识与技术，2013，23：5270-5272.
[3]邓蓉蓉.基于敏捷建模方法的软件需求分析研究[D].武汉理工大学，2009.
[4]徐赛华. 软件需求分析研究[J].吉林师范大学学报（自然科学版），2006（01）：104-105+110.
作者单位
在进行培训需求分析预测以后，对培训需求分析预测的情况进行整理和汇总，形成书面报告。
培训需求分析报告不但作为某一培训项目开发前的培训需求分析预测工作的总结材料，而且还是企业总体培训计划制定前的调研报告。
一、培训需求分析报告的基本内容
1、标题：
2、分析预测工作概况。此次培训需求分析预测的组织领导、工作目的、起止时间、接触的组织和人员（包含数量）、采用的方法、工具等等。
3、分析预测的主要内容：
（1）企业的情况分析。企业面临的外部背景、市场竞争的形势、本行业的发展状况；企业内部面临的问题和改革情况，做出较为全面细致的分析。分析尽量与培训需求分析预测的相关性强一些。
（2）企业员工基本素质状况分析。对于企业员工素质的分析，应根据岗位任职资格和能力要求，结合企业生产、经营的实际需要，从员工队伍的年龄、文化结构、管理人员与操作人员比例、技术登记结构、岗位能力胜任程度等方面入手，重点分析出问题和差距。
（4）对培训的认知程度分析。领导对培训的重视程度、各部门的配合程度、员工的认可和需求的程度。
（5）培训资源条件分析。包括企业内外可利用的教师、教材、设施、工具和企业培训经费支持情况等。
4、分析预测的具体成果：
通过对以上几个方面内容的分析，应当主要回答以下问题：
（1）在制约企业发展的诸多因素中，哪些是因员工素质和能力方面的差距所致？其中哪些是通过培训能够解决的差距。
（2）解决以上差距需要开发哪些培训项目？其中哪些培训项目是最紧迫的？
（3）每一培训项目又要具体说明以下问题：
①为什么进行培训？（培训目的）
②谁需要培训（培训对象及其目标人群）
③培训的深度和广度（培训的目标）
④培训什么（培训内容）
⑤怎样培训好（培训方式、时间、考核方式）
（4）企业，特别是企业领导对培训的态度。
（5）企业具有的培训资源
（6）可利用的外部资源
（7）项目运行可能出现的障碍和问题
5、其他相关建议和说明。
6、报告撰写时间及执笔人、负责人等。
二、撰写培训需求分析报告应注意哪些问题
1、报告中各项情况的分析和说明，必须有出处、有依据，不能主观臆造。
2、报告内容要全面，基本上涵盖以上6项内容。
【关键词】软件工程 软件需求 需求工程 需求开发 需求管理
【中图分类号】TP311.5 【文献标识码】A 【文章编号】2095-3089（2015）06-0181-02
软件工程师所需解决的问题往往十分复杂，了解问题的性质可能是非常困难的，尤其当系统是全新的时候。
1.综述
软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，这个阶段的任务仍然不是具体地解决问题，而是准确地确定“为了解决这个问题，目标系统必须做什么”，主要是确定目标系统必须具备哪些功能。本文以企业人事信息管理系统为例详细介绍了需求工程的构成和进行方法。
2.需求的标准
定义需求标准有所不同，但在思想上是相同的，都是为了保证项目的顺利进行。一般的标准为：明确（Clear）、完整（Complete）、一致（Consistent）、可测试（Testable），还有可跟踪、可修改等等。
明确：目前大多数的需求分析采用的仍然是自然语言，自然语言对需求分析最大的弊病就是它的二义性。所以对需求分析中采用的语言应该做某些限制尽量采用主语+动作的简单表达方式。还有，不要使用计算机术语。需求分析最重要的是和用户沟通，可是用户多半不是计算机的专业人士，如果在需求分析中使用了行话，就会造成用户理解上的困难。
完整：需求的完整性是非常非常重要的，要做到需求的完整性是很艰难的一件事情，它涉及到需求分析过程的各方各面，贯穿了整个过程，从最初的计划制定到最后的需求评审。
一致：用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。
可测试：需求的几项标准都是为了保证需求的可测试性，只有系统的所有需求是可以被测试的，才能够保证软件始终围绕着用户的需要，保证软件系统是成功的。
需求工程分为了需求开发和需求管理两个阶段：下面就以这两个阶段说明：
3.需求开发
需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。以下列出和讲解分析常规的步骤，当然应按照项目的大小和特点等实际情况我们应该自己确定合适的步骤。
3.1需求获取：
这是该阶段的一个最重要的任务。以下为获取用户需求需要执行的活动。
了解客户方的所有用户类型以及潜在的类型。然后，根据他们的要求来确定系统的整体目标和系统的工作范围。
对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，对于交流的结果还可以进行分类，便于后续的分析活动。例如，可以将需求细分为功能需求、非功能需求（如响应时间、平均无故障工作时间、自动恢复时间等）、环境限制、设计约束等类型。
需求分析人员对收集到的用户需求做进一步的分析和整理。
需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。
3.2需求分析
需求分析是软件定义时期中很重要的一个阶段，它的基本任务是准确地回答“系统必须做什么？”这个问题。在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。用户需求的分析与获取用户需求有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取用户更明确的需求。
用于需求建模的方法有很多种，最常用的包括数据流图（DFD）、实体关系图（ERD）和用例图（Use Case）三种方式。DFD作为结构化系统分析与设计的主要方法，已经得到了广泛的应用，DFD尤其适用于MIS系统的表述。DFD使用四种基本元素来描述系统的行为，过程、实体、数据流和数据存储。DFD方法直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从DFD图中无法判断活动的时序关系。
ERD方法用于描述系统实体间的对应关系，需求分析阶段使用ERD描述系统中实体的逻辑关系，在设计阶段则使用ERD描述物理表之间的关系。需求分析阶段使用ERD来描述现实世界中的对象。ERD只关注系统中数据间的关系，而缺乏对系统功能的描述。如果将ERD与DFD两种方法相结合，则可以更准确地描述系统的需求。
3.3编写规格说明书
项目视图和范围文档包含了业务需求，而使用实例文档则包含了用户需求。你必须编写从使用实例派生出的功能需求文档，还要编写产品的非功能需求文档，包括质量属性和外部接口需求。软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。
采用软件需求规格说明模版：采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。
3.4需求验证
需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中15%的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，要按以下步骤进行需求验证：
1）审查需求文档；2）依据需求编写测试用例；3）编写用户手册；4）确定合格的标准。
4.需求管理
需求开发的结果应该有项目视图和范围文档、使用实例文档、软件需求规格说明及相关分析模型。经评审批准，这些文档就定义了开发工作的需求基线。这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定。需求约定是需求开发和需求管理之间的桥梁，需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。
5.企业人事管理系统
5.1企业人事管理系统概述
企业人事管理系统是针对企业人事方面的大量业务处理工作而开发的管理软件。根据用户的要求，实现人员基本情况管理、工资管理、和考勤管理等几个方面的功能。用户通过输入工资、考勤、职工履历等基本信息，由系统自行生成相应的统计数据及各类统计报表以供用户查询、打印。
5.2系统功能分析
系统开发的总体任务是实现企业人事信息关系的系统化、规范化和自动化。
系统功能分析是在系统开发的总体任务的基础上完成的。经过按照以上分析过程进行分析，分析出企业人事信息管理需要完成功能。
6.总结
以上详细介绍了软件需求分析过程。软件工程中包含需求、设计、编码和测试四个阶段，其中需求工程是软件工程第一个也是很重要的一个阶段，要想做好一个项目，必须先做好需求分析，需求工程分为了需求开发和需求管理两个阶段：需求开发又分为需求获取、需求分析、编写规格说明书和需求验证。需求管理就是对需求变更控制的过程。通过介绍企业人事信息管理系统的需求分析阶段，更好地说明了需求分析过程。
关键词：软件项目；需求管理；意识；沟通
随着计算机和信息技术的发展，软件的需求越来越复杂，规模越来越大，而且随着软件企业的日益壮大，软件需求管理已成为日常软件开发中不可或缺的组成部分。在软件项目的开发过程中，需求管理贯穿了软件项目的整个生命周期，是软件项目管理中一项十分重要的工作，据调查显示在许多失败的软件项目中，由于需求原因而导致的约占到四至六成，因此，需求管理做得好坏直接影响到软件质量的高低，甚至软件项目的成功与否。
需求管理是每个软件项目开发的基础，是一种用于查找、记录、组织和跟踪系统需求变更的系统化方法，可用于获取、组织和记录系统需求并使客户和项目团队在系统需求变更上保持一致。目前，软件工程仍然是一种新兴的工程领域，它远远没有其他传统工程领域那么规范，其开发过程缺乏成熟的理论和统一的标准。因此，软件需求管理具有相当的复杂性和特殊性，当然仍存在着各种问题，下面将针对需求管理的相关问题进行探讨。
1.意识问题
在许多软件企业中，从事需求管理的人员大多是技术骨干，在需求管理方面的培训较少或不够系统，未能掌握需求管理的常用工具及方法，在实际的需求分析中主要依靠个人现有知识经验，需求管理随意性和盲目性较大。其中部分需求管理人员都没有意识到自己是从事需求管理的角色，而是局限于软件技术的分析，造成需求管理计划不周、任务不均、安排不明、资源浪费。
目前软件企业中，很少有专门从事需求管理的专业人员，被任命为需求管理的人员往往都是具体负责软件开发的技术人员，而这些技术人员在沟通、技能以及专业知识方面与专业软件需求管理人员仍有很大的差距，因此造成在软件开发时并不清楚究竟该做什么，但却在一直忙碌不停地开发。这个现象，已经成为国内软件业的顽疾。
需求的复杂性以及不确定因素的存在，加之意识上的不重视，使需求管理人员对需求分析认识不足，认为需求分析做得再好也不如实际变化快，导致做需求分析走过场而留于形式，造成需求分析与实际情况脱节，无法获知真实有效的需求。因此，加强需求管理人员意识的培养，提高需求分析的技能是更好地做好需求管理工作的基础。
2.沟通问题
在软件需求调研过程中，很多客户都不能正确表达自身的需求，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为只要简单的说说自己意图就是把需求说明白了，而对业务的规则、工作流程却谈及甚少，也讲不清楚。更有甚者，在调研过程中参与度不高，对需求的确认不够积极，提出的要求也较随意；或者多个用户代表各说各话，昨是今非但又要求项目尽早交付。这些情况往往会增加需求调研的工作难度，分析人员需要花费更多的时间和精力与用户尽心沟通，帮助他们梳理思路，搞清用户的真实需求。
客户沟通是需求管理中的剂，在需求管理过程中与客户的沟通很重要，因为它直接决定着最终软件产品是否满足客户的要求，在很大程度上决定着项目的成败。在沟通时，双方对需求的认识要一致，不能模棱两可。
建立良好的沟通环境和氛围。需求管理人员与用客户沟通的程度关系到需求分析的质量，因此建立一个良好的沟通氛围、处理好需求管理人员与客户之间的关系显得尤其重要。通常情况下，客户作为投资方会有一些心理优势，希望他们的意见得到足够的重视，分析人员应该充分的认识到这一点，做好心理准备，尽量避免与他们发生争执，因为我们的目的是帮助用户说出他们的最终需要。
在沟通时需求管理人员应注意以下几个方面：
（1）和具体业务执行者的沟通。要尽量深入他们的实际工作，了解软件项目需要解决的实际问题的关键点。做一个优秀的倾听者，以最快的速度适应客户的语言风格，理解他们要表达的意思。以及使用不同的沟通手段和沟通工具来和客户沟通，比如片界面或者文档规格说明书等等，争权把软件开发语言和客户语言能够很好的在表述上达到一致，切忌自以为是，答非所问。
（2）和决策者的沟通。项目产品基本定型和相对完整的产品需求，需要经过客户决策者的认可，以确认项目建设思路和方向没有偏离，利于投入更多的资源来细化和付诸开发实现。和客户决策者要定期汇报沟通项目进展，及时修正项目目标偏离，争权客户更大力度的协调配合，裁定项目范围需求便捷，贯穿始终。
3.管理问题
需求管理工作应该是需求全生命周期的管理，从用户原始需求的提出，到最终形成软件产品后客户对需求实现情况的验证以形成闭环流程。因此我们需要跟踪和了解到需求状态的演变过程。大型的项目软件生命周期模型较为复杂，一个需求的实现会经过用户需求，软件需求，总体设计，详细设计，开发和单元测试，集成测试，系统测试和验收测试多个环节，在这个过程中需要建立需求追踪以确认需求和中间阶段产生的工作产品的一致性。
变更管理是需求管理的另外一个重点，对于软件项目来的需求而言，客户会经常性地提出需求变更要求，主要原因有：客户对系统功能理解的分歧。在前期需求调研时，需求分析人员的知识、业务水平与客户的沟通交流情况等因素会造出双方在功能理解上的分歧，随着软件项目开发的进行，这种分歧会导致需求的变更；客户业务逻辑发生改变。客户在竞争激烈的市场环境中随着市场发展情况的变化而调整自己的业务逻辑，从而对软件项目需求提出新的变更要求。各种原因导致需求的不断变更，使其始终困扰着软件需求管理人员。
为此就要引进规范而又专业的管理机制，使得需求管理更加规范。需求管理的重要性则体现在项目计划的严肃性和可执行性，以保证项目目标的实现。通过引入了需求变更管理后，使软件项目需求文档成为大家都共同承诺和作为依据参考的文档，这个文档需要在设计，开发，测试等多种角色之间充分传递和共享。另外通过需求管理工作，使每个人意识到变更对项目的影响和变更的代价，从而促进需求开发质量的提高。
对软件需求管理中存在的常见问题进行了浅显的分析，软件需求管理涵盖了意识、技术和管理等多方面的知识，对软件项目开发的成败有着 非常重要的意义，它是一个软件项目成功与否的关键因素之一。在软件开发过程中，要树立既要注重技术，又要注重管理的意识，努力提高需求管理的水平。
参考文献：
[1]吴艳艳，周长伦﹒软件项目管理中的需求管理[J]﹒信息技术与信息化研究与探讨，2008.
[2]陈俊霞，王卫东﹒软件项目管理的若干问题探讨[J]﹒现代计算机，1999.
【关键词】电子政务软件 信息系统 软件项目
1 电子政务信息系统的特殊性
受到广泛认可的联合国经济社会理事会的对电子政务进行定义，即政府为了提高公共服务效率、增强政府的透明度、改善公共管理的质量，利用信息通信技术（ICTs）手段应用组织公共管理的方式，建立良好的政府之间、政府与社会、社区以及政府与公民之间的关系，提高公共服务的质量，赢得广泛的社会参与度。这在一定程度上说明电子政务系统涉及的用户角色多，情况复杂。需要处理政府、社会、公民三者之间关系，不用用户立场不同对系统的要求不同，这就要求对所用用户的需求进行收集汇总，然后进行整理确定最终的需求。
2 软件需求分析的过程
软件需求分析过程包括四个环节。可以分为系统可行性研究，需求导出和分析，需求描述，需求有效性验证。软件系统的需求通常分为功能需求和非功能需求。
（1）功能需求包括对系统应该提供的服务、如何对特殊收入做出反应，以及系统在特定条件下的行为的描述。在某些情况下，功能需求可能还需明确声明系统不应该做什么。
（2）非功能需求对系统提供的服务或功能给出的约束。包括时间约束、开发过程的约束和所受到的标准的约束。非功能需求经常适用于整个系统而不是个别的系统功能或服务。
3 电子政务软件需求分析方法
软件需求的方法很多，通常包括：面谈、问卷调查、小组讨论、情景串联、参与观察业务流程、用例等。选择那种方法需要根据具体应用实际情况而定，综合考虑选择哪些方法对系统开发最为有效，但不能盲目套用。下面将重点阐述在电子政务软件需求中用例分析的方法和快速原型分析方法。
3.1 用例分析方法
用例是一种需求发现技术，这种技术起先是在面向对象方法中被引入的。现在已经成为统一建模语言的一个基本特征。一个最简单的形式是，一个用例识别在一个交互中所参与的所有角色并命名该交互类型。然后还会附加一些描述系统交互的额外信息。这些信息可能是文本描述或是一个或多个图形化模型，例如UML序列图或状态图。
用例通过一个高层用例图记录下来。用例的集合代表所有将会在系统需求中出现的交互。过程中的角色可能是人，也可能是其他系统，用人形图标来表示。每一个交互类用一个命名的椭圆来表示。用例和交互类之间用线相连。也可以选择把箭头添加在连线一端，代表交互的开始方向。
在电子政务软件的需求收集过程中，传统的面谈、问卷调查过程，由于客户的计算机水平、对需求的理解、表达程度都参差不齐，有些客户只有朦胧的感觉，当然说不清楚具体的需求，有些客户心里非常清楚想要什么但却说不明白等多种原因，引起分析人员理解错误。特别是因为分析人员对于政府最初运作流程不熟悉，在与具体使用客户交流时就会引起某些误解，语言上表达一样但实际并不是一致。采用用例的图形表达方式，就能够在一定程度上解决对文字描述的理解歧义。用例图采用图形的方式描述系统的交互，比较直观，能够让用户与分析人员交流更明确更顺畅。
3.2 快速原型分析方法
在传统的软件工程方法学中，一贯强调的是自上而下的分阶段开发方式，在各个阶段具体开发之前必须对所开发项目需求进行严格意义上的定义。具体实践表明，在系统未建立起来之前很难仅仅依靠分析就确定出一套完整、有效的需求应用，并且这样预先定义的需求也无法适应用户需求的不断变化。因此，快速原型分析方法应运而生，其自顶而下的开发模式是目前应用十分广泛的开发模式。
快速原型模型在功能上等价于最终系统的一个子集。瀑布模型的缺点就在于不够直观，快速原型法就解决了这个问题。一般来说，根据客户的需要在很短的时间内解决用户最迫切需要，完成一个可以演示的产品。在得到用户的需求之后，原型将被抛弃。因为原型开发的速度很快，设计方面是几乎没有考虑的，如果保留原型的话，在随后的开发中会为此付出极大的代价。在快速原型模型中，原型最重要的目的是为了确定用户的真正需求。从某种程度上，可以将快速原型理解为需求分析的一种更直观的方式，也是业界比较认可和取得良好效果的一种方式。
快速原型分析的显著特点是增进软件分析人员与客户对需求的理解，将比较模糊的且具有不确定性的软件需求明确化，同时快速原型分析方法有利于更好发掘客户的潜在需求，将尽量降低需求变更频率，有效地控制软件的开发成本，保证软件项目最终取得成功。
4 结束语
电子政务信息系统需要处理的数据越来越复杂，对其进行的需求分析也变得越来越重要。在电子政务信息系统的开发过程中，如何使软件系统需求过程更加合理有效，是提高电子政务信息系统质量的关键。本文通过对电子政务信息系统中软件需求分析的详细阐述，来说明软件需求分析是软件设计实现的基础，直接关系整个软件项目成败。如果能科学地进行需求分析，采用合适的技术及方法避免可能引起需求分析缺陷的问题，获取用户完整的需求规格说明书，能够为后面的设计阶段打下良好的基础。
参考文献
[1]阮俊杰.软件开发方法与管理教程[M].北京：海洋出版社，2003.
关键词：系统集成；项目管理；问题；对策
中图分类号： N945 文献标识码： A 文章编号：
一、大型信息系统集成项目管理问题
（一）项目范围管理欠缺。缺少正确的项目定义和范围核实是导致项目失败的主要因素。因此，项目管理最重要也是最难做的一项工作就是确定项目的范围。
范围是指项目的任务是什么，包含两方面的含义：一是产品范围，即产品或服务所包含的特征或功能；二是项目范围，即为交付具有规定特征和功能的产品或服务所必须完成的工作。简单地说，就是产品范围决定项目范围。目前，在大型信息系统集成项目范围管理中主要存在两方面的问题：
1、项目范围界定不清。引起这个问题的主要根源是项目需求分析不完整。造成需求分析不完整的具体原因如下：
（1）项目初期客户对自身需求不清晰。在这个阶段，客户一般会要求项目承包方替他们设想需求。这种情况下的需求分析存在一定的主观性，并不能完全表达用户真正的需要，可能为项目未来实施埋下隐患。
（2）项目实施过程中客户需求自身发生变动。随着项目进展深入，客户方人员对信息系统的认识会逐步加深，以及自身业务水平的提高，他们会在项目实施的不同阶段对项目的需求提出新的要求和需求变更。
（3）需求分析人员和客户对需求的理解有误。由于双方人员各自的专业背景和行业背景不同，对事物的认识角度不同，往往会发生对同一个问题的理解产生一定程度的偏差。
（4）缺少客户业务部门参与。一般来说，系统集成项目是由客户的业务部门提出具体需求，由信息技术管理部门组织实施，最终供业务部门使用。业务部门参与不足，就可能产生需求分析偏差；业务部门不理解、不认可等问题。
2、项目范围变更失控。在项目范围管理过程中，出现变更失控的原因有以下几个：
（1）项目团队成员对项目变更管理不够重视，直接导致当范围变化发生的时候不能及时地反馈给项目经理。
（2）项目范围蔓延的问题。是指一个项目接受了很多小的变化，当这些小的变化都聚合到一起的时候，项目团队才意识到项目范围已发生重大变更。
（3）项目的变更控制缺少统一的流程和标准。这个问题会直接导致项目变更管理自身的失控，无法起到有效控制项目实施的作用。
（二）项目团队疏于管理。一般来说，参与大型系统集成项目的人员中并不缺少精通技术和业务的人才，但能够有效调动、合理使用这些人员，共同实现项目目标并不是一件容易的事情。实际上不良的项目团队管理直接导致了项目的最终失败。究其根源在于“重视技术，疏于管理”，这主要体现在沟通不良、合作意识差、分工不够细致和项目成员流动等方面。
（三）项目风险管理落后。目前，虽然风险管理已经在国内大型信息系统集成项目的管理中开始采用，但是因为在具体实践中还存在的一些问题，阻碍了项目风险管理在大型信息系统集成项目中的合理应用。
1、缺乏风险意识。缺乏项目风险意识，对项目风险管理的必要性和重要性缺乏足够的认识，这正是影响风险管理合理运用的主要问题。
2、风险识别的偏差。进行有效的项目风险管理，必然要从风险识别开始，如果这个阶段的工作不到位，势必会影响到后续的风险分析评估，进而造成应对措施失误等问题。
3、风险评估客观性差。风险评估也可称为风险量化，是指确定风险发生的概率与后果。目前国内项目风险评估的方法大部分采用专家预测法。这种专家主观性判断得到的数据可能存在不真实、不可靠的问题，这就可能给后面的决策埋下隐患。
二、大型信息系统集成项目管理策略
（一）项目范围管理
1、真实需求的获取。最终用户真实需求的获取就是需求分析的过程，它是一个项目的基石。一般来说，需求分析的过程分为四个阶段：挖掘需求、引导需求、证实需求和确认需求。
（1）挖掘需求。在收集用户零散的信息后，在了解用户业务流程以及结合专业知识的基础上，找出这些信息之间的逻辑关系并且用常识性的语言表述出来。
（2）引导需求。挖掘需求阶段后，需要与用户沟通，引导用户，使双方对需求的理解达到一致。
（3）证实需求。在双方对需求理解一致的基础上，形成一份完整、可操作的、真实表达用户需要的需求分析说明书。
（4）确认需求。这一阶段的目的就是通过证实需求阶段收集的信息，确认用户的真实需要，审核完成需求分析说明书。
2、利用 WBS 分解项目。工作分解结构（WBS）是指把主要可交付成果分成较小的、便于管理的组成部分，直到可交付成果定义明晰到足以支持各项项目活动（计划、实施、控制和收尾）的制定。
使用WBS的最大优点是可以监控以及预测成本、进度等不同的项目信息，并且给所有的项目参与者提供了一个均可与之做对比的一致基准。WBS有以下四个原则：
（1）“四十小时原则”。四十小时原则是指处于WBS 层次最末端的工作可以在七个工作日内完成，这样可以把任务执行检查的周期控制在一个星期内，从而大幅度地提高了任务分解的可靠性和任务执行的及时性。
（2）最末端的工作可以由某个具体的人或者某个团队完成。最末端的工作需要明确责任人或者资源。如果某个任务虽然可以在一周内完成，但是执行该任务的资源却大于一个人，则应该按照每个人的任务再进行分解，直到明确每个人或者每个团队具体的任务和职责。
（3）最末端的工作不应有较高的风险。例如，解决某个技术难题的任务，或许这项任务可以在一周内完成，但是在执行该任务过程中存在较大的风险，能否解决不确定因素过多，因此需要将该任务按照解决问题的步骤进一步分解，通过进一步的细化，很大程度上降低了该任务的风险。
3、范围的验证。项目范围验证不应该仅仅发生在项目结项的时候，这样做往往会流于形式。比较理想的做法是在项目各个阶段，至少是里程碑的阶段，由项目需求分析小组的成员（特别是用户方代表）、项目经理、该阶段可交付成果的负责人组成评估小组，由阶段工作成果的负责人进行宣讲，评估小组一起进行评审和验证。
（二）项目团队管理
1、项目经理的选择。对于大型项目的项目经理要具备以下能力：有管理经验，是一个精明而且讲究实际的管理者；拥有成熟的个性，具有个人魅力；具备良好的人际关系，尤其是能够处理好与项目各干系方的关系；有一定的技术背景。
2、项目小组的构成。一个大型信息系统集成项目团队可以分为需求分析组、设计组、开发组、商务组、实施组等若干个项目组，每个项目组还可以细分成若干个子项目小组。
根据大型信息系统集成项目的特点，在构建每个项目小组时，应考虑以下两点因素：（1）适度地安排不同的人员去做不同的工作，做到人尽其能；（2）加强项目人才梯队培养，在人员发生变动时可以“无缝”交接。
3、项目团队的成长。借用著名心理学家 B.W.塔克曼的团队管理理论，项目团队的成长一般需要经过四个阶段，即形成阶段：促使个体成员转变成项目团队成员；震荡阶段：团队成员之间的相互磨合；正规阶段：形成团队，形成合力；表现阶段：积极工作，向目标冲刺。根据项目实际进展情况，其他阶段的激励方式也可以同时被很好地采用。当然，足够的物质激励是不可缺少的最有效的激励方式。实质上，“以人为本”的理念要贯穿于从项目团队组建开始的全部工作中，以项目团队成员为本，从项目团队成员的角度上去思考问题，可以很快地增强团队凝聚力和团队效率。
（三）持续改进的项目风险管理方法。持续改进思想主要针对：一是对可能会出现风险的部分持续评估；二是决定哪类风险最主要，并且进行重要程度描述；三是实施处理风险的策略。持续改进的风险管理具有以下优点：能够在问题发生前预防、改进产品质量，使得资源更好地被利用、增进团队合作，为投资决策设立预期目标，并且提供解决方案。
参考文献：
[1] 左美云. 信息系统项目管理. 北京：清华大学出版社，2008.
[2]刘晓红，徐玖平. 项目风险管理. 北京：经济管理出版社，2008.
金融业的发展与计算机软件工程之间存在着高度融合，作为金融业的重要组成，邮政银行与市场上的工商企业存在一定的差别，是一个特殊企业，因此，在软件工程项目的要求及开发原则上具有独特的要求。邮政银行信息工程项目建设要注重质量管理、成本管理及风险管理，保障邮政银行借助软件工程项目，达到预期的经营目标。
1邮政储蓄银行软工工程项目的基本目标及原则
邮政银行的信息系统要采用科学先进的项目设计思路和项目架构，集中处理邮政银行的资金储蓄及现金汇兑业务，信息系统要具备可操作性、高性能、伸缩性强的特点。此外，除了能够有效处理银行业务需求外，在系统的扩展性及维保的便捷性上，也要具备相当大的弹性空间，以促进邮政银行发展目标的达成。邮政银行软件信息系统项目要遵循先进性、安全性、前瞻性、可扩展性、可维护性及经济适用性等原则，强化信息系统项目的质量。
2邮政储蓄银行软工工程项目的开发管理过程
（1）需求分析。根据用户准确要求，找准市场定位，是进行需求分析的基础。需求分析的目的，在于保证软件开发的准确到位，以节约时间和成本，提高系统利用率。需求分析的主要内容为需求的符合程度、项目系统的安全性、稳定性、可扩展性及容错性等，在此基础上形成完整一致、可控性强的文档，以满足邮政银行的各项业务需求。由于软件用户在软件的功能性上有着一个较为清晰化的框架，对软件要处理哪些数据有着明确的需求，因此，在对软件投入研发前，要和用户及时交流沟通，以便软件在使用中达到高效完美的最佳效果[1]。（2）概要设计需求分析阶段，只是根据用户需求大体划分出目标系统的类型，并没有设计到具体设计思路，如使用何种编程语言，运用哪个操作平台等，而概要设计阶段，就是着重对这些要素进行甄选[2]。要实现概要设计与需求分析的有效衔接，根据具体情况选择合适的开发方式，需求变化幅度较小的，选择采用瀑布式开发模型，以形成较完整的分析文档，需求变化幅度较大的，采用更稳妥的设计方式，以便及时返回上一级进行修缮。邮政银行信息系统项目设计，要依据设计文档整体要求，对整体系统项目及各个子系统项目加以编码，形成开发文档。（3）细致设计。细致设计阶段可以采用成熟度模型（CMM），这一模型涵盖了软件工程，硬件工程和系统工程三个环节，并细分了各自环节的等级，各等级中又有对应的过程域。细致设计环节着重对分析模型进行详细校验修改，因为编程环境的改变，或为了细致定义软件界面，需要对相关类结构进行修改。详细设计的过程主要是根据概要设计的脉络，对软件体系结构作细化处理，设计各软件单元外部接口、输入输出、算法、流程逻辑、占用资源比、性能表现、单元调试与测试等方面，从而完成对整体数据库的详细设计。通过对这些环节的细致设计，对软件的系统性能，逻辑集中系统是否健壮、安全进行分析验证，以满足邮政业务开展需求。（4）编码单元测试和联合测试。软件开发人员以特定软件开发工具为基础，通过操作每个软件单元及数据库定义的形式，在相应语言开发工具的配合下，正确研发，调测系统，从而更贴合软件用户需求。邮政银行信息系统项目要借助工具模拟运营后的业务最高峰值时的系统承压能力、稳定能力及性能表现能力，以便有效处理邮政银行的各类业务。测试的内容有稳定性测试、容灾测试、异常测试及双机切换测试等。测试中要注意软件单元的集中性，做到将模块、硬件及网络其他资源有机结合，测试结果与需求不符时，要适时地返回修改[3]。此外，对系统的功能、性能，也需进行测试，以保证软件的运行需求得以满足，最后形成测试报告。（5）试运行和后期维护。挑选试用范围，开发人员与试用用户对系统运行情况进行记录，以便分析总结试运行中出现的问题。试用人员要接受开发人员的相关培训。后期维护涉及到软件系统的升级变更，此时就要进行性能回归测试，验证业务更新后系统的逻辑性能能否及时跟进，避免因性能不佳致使银行业务的滞后及瘫痪。此外，在银行业务增加时，要选取邮政银行典型业务开展绿灯测试，确保业务在软件系统上的兼容性、可操作性。
3结语
信息化时代，计算机软件工程与邮政银行的业务发展结合得越来越紧密，同时，软件工程项目的安全可靠也是邮政银行系统稳定安全的技术保障。邮政银行要着力提高软件工程项目的应用管理，通过设计检验的规范化、科学化，不断提高软件运行的精准度，从而在金融市场竞争中占得先机。
作者：张倩 单位：中国邮政储蓄银行
论文关键词：软件项目；软件过程；CMM；KPA
1．引言
项目管理(PM，projectmanagement)是指利用现有的知识、方法和技术手段，有效地计划、调度、控制和跟踪项目的开始、执行、直止终止的过程，是项目顺利实现的有效手段。软件项目管理则是在项目管理的基础上，结合软件产品的实际，利用工程的概念和方法来开发与维护软件，对成本、风险、时间、质量、过程、配置等进行分析、管理、控制，最终目的是为了让软件项目的整个生命周期都在管理者的控制范围内，以预定成本按期、按质完成软件的开发并交付用户使用。目前，软件产品已广泛应用于各个领域，但是很多软件项目的成功率并不高．虽然有些公司根据软件工程理论建立了一些软件开发管理规范．但并没有从根本上提高软件项目管理问题，这就导致软件产品质量不稳定甚至是项目的失败，同时也损害了用户的利益。本文结合我国软件项目管理的特点并经实践应用．以提高软件质量、降低成本、加强软件项目的可控性为目标，通过对CMM的研究和改进，给出了一个基于CMM加强软件项目管理的实践模式，在这个模式中对目前CMM中的KPA做适当的裁减，定义了6个关键过程域和3个工作组。
2．软件项目管理中目前存在的问题
影响软件项目成功率的因素主要是软件质量问题，而在整个软件项目的实施过程中需求不明确、跟踪和监督不力、缺乏客观的软件评审和软件配置以及风险管理意识不足等都阻碍着软件质量的提高。
2．1需求不明确
需求管理是软件项目管理中非常关键的一个步骤．需求分析的完整与否可以降低软件质量、延长项目周期、加大成本。由于用户对计算机系统认识的不足，对于系统的需求往往比较模糊，遗漏甚至是错误的问题经常出现(包括管理流程、业务流程、数据或报表的分析处理等)，但这些问题往往没有暴露给开发人员，而是随着项目的进展才逐渐明确。对于开发人员来说，需求的变更意味着软件产品的部分内容必须重新开发，而对于整个软件项目管理而言，势必要重新分配资源、调整计划、估算成本等等，导致软件产品质量下降。
2.2跟踪和监督不力
跟踪和监督主要针对过程而言，也是项目管理中最容易被忽视的环节。软件项目过程由多个任务构成，大部分任务都有前置任务和后置任务，这就要求项目管理者要严格跟踪和监督每一个任务。任务的完成主要从时间进度和质量两方面来衡量，还要充分考虑因客户方引起的一些客观因素(更改需求分析等)。项目管理者虽然制定了具体的项目进度内容，但如果缺乏有效的跟踪和监督机制，对于每一个阶段所要完成的任务疏于评价，就会影响下阶段软件产品的质量，有时甚至是软件产品的重新开发，最终影响整个软件项目。
2．3缺乏客观的软件评审
客观的软件评审是软件产品质量的直接保障，软件评审一直贯穿于整个软件项目的过程中，对软件产品的评审应有客户使用人员和软件业中的同行来进行。客户使用人员对软件产品做阶段性的评审可以及时发现软件产品功能方面的不足，同行评审可以从软件业的规范及标准去发现问题．软件评审可以降低软件开发的成本提高软件产品的质量。大多情况下项目管理者没有做任何阶段性的评审，通常只是在软件产品开发基本完成之后来组织评审，果发现了很多问题，但要修改已经非常困难．要花费很长的时间甚至从头再来。
2．4软件配置混乱
软件配置是指软件产品在各个阶段各种版本的文档、程序及数据的集合，贯穿于整个软件项目的始终。随着软件产品开发的进行，由于各种客观原因，其中的预算、设计方案、进度等内容都有可能需要大大小小的更改(这些改动可能是合理的)，整个改变的过程对软件项目的参与人员来说必须是可视的，以便提高软件的可靠性和质量，而这一切都应该有正确的软件配置来控制如果失去正确的软件配置管理，那么针对软件产品发生的任何更改或者是维护都会给软件项目带来混乱甚至是失败。
2．5风险管理意识不足
风险管理是软件项目中防止失败的一种重要手段，软件项目不同的阶段存在着不同的风险，并且风险会随着项目的进展而变化，目前国内的软件企业大都不注意软件项目的风险管理。除了社会环境风险、商业风险等这些客观风险之外．可控的软件项目风险主要指技术风险。技术风险主要是指与软件项目本身相关的的技术因素变化带来的风险，如果在一定的条件下达不到技术条件能够实现的目标，不但延缓项目的进度而且会增加项目的成本．继而使整个项目受到影响。
3．通过过程管理加强软件项目管理的实践模式
利用cMM fCapabilityMaturityModeforSoftware)的核心思想把软件项目管理看作一个软件过程，并根据这一原则对整个软件项目的开发和管理进行过程监控，监督发现过程中影响项目的关键问题并予以解决。软件过程是指软件开发人员开发和维护软件及相关产品的一套行为、方法、实践及变换过程，包括软件开发过程和软件管理过程。CMM把软件开发机构按照不同开发水平划分为5个级别。每个等级被分解为几个KPA(关键过程域)，KPA是指在某个成熟度等级应重点关注的区域，也是达到此成熟度等级必须解决的关键点。①初始级，无过程意义。软件过程是无序的、随机的、缺乏总计划，无预见性，大多数活动是应付危机，经常超期超支，成功取决于个人。②可重复级，具备基本的项目管理。KPA分别是：需求管理、软件项目计划、软件跟踪与监督、软件子合同管理、软件质量保证、软件配置管理；③已定义级，已定义软件过程。已将软件管理和软件工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。KPA分别是：组织过程焦点、组织过程定义、培训大纲、集成软件管理、软件产品工程、组间协调、同行评审；④可管理级，过程可度量。已收集了软件过程和产品质量的详细度量方法，软件过程和产品均可被定量地理解和控制。KPA分别是：定量过程管理、软件质量管理；⑤优化级，过程控制。通过过程的量化反馈以及新技术、新方法促使过程不断改进。KPA分别是：缺陷预防、技术更新预防、过程更改管理。
CMM只是一个过程改进的框架．并没有给出具体实施的办法。在该模式中对目前CMM中的KPA做适当裁减．定义了6个关键过程域：软件项目计划(SPP)、需求管理(RM)、软件项目跟踪和监督(SPTO)、软件质量保证(SQA)、软件配置(SCM)、同行评审(PR)，设置了三个工作组：软件项目过程组(SPPG)、软件工程组(SEG)、软件质量保证组(SQAG)。通过工作组对关键过程域的操作来加强软件项目的管理。
3．1定义KPA
3.1.1软件项目计划(SPP)
软件项目计划是为要实施的软件项目编制软件过程活动的安排，包括进度控制、成本控制、质量控制、风险控制等，也是实施CMM2的核心此阶段在安排过程活动的同时开展项目设计的前期工作，设计和界定在整个项目中各阶段所需的开发、质量、跟踪、评审、风险、成本等工作。项目计划是指导项目过程的具体措施，要在有软件项目实施经验的人员领导下投人大量的时间和人力资源来完成。制定项目计划应注意7个问题。①在科学论证的基础上制定过程，充分调动人员积极性合理地确定项目组的参加人员；②对软件项目各程中的任务进行分解，明确项目的里程碑和检查点；③正确估计软件项目中的软件资源、硬件资源、人力资源及其它费用；④正确估计各方面因素带来的风险并制定应对措施；⑤制定项目实施过程中的跟踪和监督措施；⑥确定软件的评审和测试方法；⑦详细的文档资料。
3．1．2需求管理(RM)
需求分析主要包括面向用户的用户需求和面向开发人员的系统需求．是整个软件工程的第一步．也是非常关键的一个环节。需求分析主要针对用户的业务流程、系统功能、性能、数据分析进行严格的定义．是设计一个软件应用系统的起点与基本依据，通过它来评判软件产品是否能够解决用户问题，也是项目成功与否的标准。就目前国内现状来讲，一般签定软件项目合同的用户是主管信息技术的负责人，它所关心的可能是整个系统的目标需求，用户方中层管理人员关心的是业务流程需求．终端操作人员则注重软件本身的易操作性和功能特性，因此．面向用户的需求一定要和用户多方人员多沟通、交流．最终通过双方有关部门人员的论证以文档资料的形式确定下来。任何一个需求分析因客观原因可能存在着需求更改的现象，对于这种情况一定要注意需求更改的可控性．要建立需求的基准版本和更改版本控制文档资料．使受需求变化影响的产品与需求变更一致。但要注意在更改需求的同时要衡量需求的稳定性，如果一个需求的变更比较频繁，意味着本项目并没有真正了解用户想要解决的实际问题。可以说需求分析的完整性和变更可控性直接影响到软件过程的改进，它可以降低软件质量、加大软件开发的成本、甚至是导致项目的失败。软件工程组(SEG)中要明确定义一个需求管理员。
3．1．3软件项目跟踪和监督(SPTO)
软件项目的跟踪和监督始终贯穿于整个软件项目的过程中，是项目得以控制的前提和条件、是软件质量的根本保障，其目的是增加软件过程中进度、成本、工作量、质量、风险等内容的可视性，也是实施CMM2的核心。除去市场、法律等不可控制因素外，根据项目计划对项目进展的有关情况及影响项目实施的相关因素进行及时、客观、准确的信息采集，将采集到的需求、成本、进度、风险等内容形成文档并建立一个项目跟踪信息平台。项目负责人定期召集软件过程人员、开发人员、质量保证人员、用户方有关人员召开开放式的例会，例会的主要内容是检查项目进展、数据的分析、认识的偏差、资源的搭配、相关的风险等问题并讨论确切的解决办法，通过跟踪和监督使项目始终处于可视化的受控状态。
3.1.4软件质量保证(SQA)
软件质量保证是与软件产品满足规定的和隐含的需要能力有关的特征或特性的组合。对用户来讲主要体现在软件产品的有效性、一致性、完整性、可靠性和可操作性等方面，对于软件产品本身来讲体现在软件产品的可移植性、易维护性、健壮性、可重用性等方面。具体实践中．软件质量保证应在软件项目计划、需求分析、跟踪和监督、软件配置和软件评审的相互配合下完成．软件质量保证要做到以事先预防和跟踪为主，事后纠偏为辅。
3．1．5软件配置(SCM)
软件配置是针对软件产品的跟踪和控制活动．贯穿于整个软件项目的过程中．目的是建立和维护在整个生命周期内软件产品的完整性和一致性，使整个软件产品的演进过程处于可控的状态，继而提高软件的可靠性和质量。在实践应用中主要做到五个子项的配置①配置项的标识。标识做到唯一性。便于跟踪和管理。②版本管理。对整个软件过程中的文件和目录提供有效的跟踪手段。③变更控制。保持并传递修改信息。④配置审计。确定整个项目生产周期中产品在技术和管理上的完整性。⑤系统整合。把系统的不同部分集成后完成一组特定的功能。
3．1．6同行评审(PR)
同行评审是根据预定的规范和标准对软件产品进行评审。评审的结果是衡量软件产品质量的依据。在整个软件过程中对详细设计和软件综合测试作为两个关键评审点来进行评审，评审的过程中注意要结合本软件项目的具体要求和标准。
3．2组的定义
在具体的实践应用中设置了三个组，在降低了人员成本的同时提高了软件过程改进能力和软件质量。
软件项目过程组(SPPG)组织具体的项目实施活动，管理并协调整个软件项目的过程，主要完成SPP和SPTO。
软件工程组(SEG)负责软件工程的需求分析、概要设计、详细设计、编码、测试、维护工作。
软件质量保证组(SQAG)主要完成SPTO、SCM、PR、SQA等工作。
4．实践模式效率评估
4．1开发时间
软件开发由需求分析、概要设计、详细设计、编码、软件测试、项目维护和软件集成几部分内容组成，在需求分析和设计阶段采用CMM框架实施过程管理所花费的时间要多于没有实施过程管理花费的时间。首先对项目做大量分析，论证项目的可行性。然后在和用户做良好沟通、反复论证的基础上做需求分析，形成文档资料。这种模式下花费在需求分析和设计上的时间大约占项目总开发时间的40％，但这两个阶段完成了数据流程、算法描述、详细的规格说明等内容，为代码编写、软件测试、软件维护等后续内容的工作节省了时间，软件项目的开发周期大大缩短。经过评估，采用该实践模式实施软件过程管理的软件项目开发周期比没有实施软件过程管理的软件项目开发周期缩短20％。
4．2开发质量
采用CMM标准通过软件过程管理加强软件项目管理的实践模式使软件质量明显提高、需求分析周密、代码错误率明显降低、软件产品完整性好、功能齐全、维护量下降，软件项目最终得以顺利实现。
