1、摘要根据软件能力成熟度模型（ CMM）的理论和思想，在软件研发过程中包含多个过程域，软件研发过程改进离不开任何一个过程域的改进。软件的需求管理是这众多个过程域中比较早开始的， 是整个软件范围界定的过程， 它的成果是软件执行的依据和基础。软件的需求管理是一项复杂而富有经验性的工作， 需求管理的成功与否直接关系到项目的成败， 需求管理过程的改进在整个软件研发过程改进的作用至关重要。本文从软件研发过程中的需求管理过程去研究软件研发过程改进中的重要的需求管理改进过程。 立足于软件研发过程改进的复杂性七命题， 成功为某企业制定了一套优化的需求管理过程规范。关键词：需求管理 过程改进 软件研发2 Abst
2、ract According to the software Capability Maturity Model (CMM) theory and ideology, in the process of software R & D domain contains more than one process, software process improvement research and development process of any one domain can not be improved. Demand management software, is the relative
3、ly large number of domains as early as the beginning of the process is to define the scope of the entire software process, its results are based on software and infrastructure implementation. Demand management software is a complex and rich empirical work, the success of demand management is directl
4、y related to the success or failure of projects, demand management to improve the process of research and development throughout the software process improvement is crucial. In this paper, the process of software R & D management process needs to study the process of software R & D important to impr
5、ove the demand management to improve the process. Based on the software research and development to improve the complexity of the process of Proposition 7, the success of an enterprise has developed a set of demand management to optimize the process of norms. Key words: Requirement Management Proces
6、s Improvement Software R & D 3 目录1 前言 . 4 2 需求管理复杂性分析 4 3 需求管理策略 . 5 4 某某企业需求管理过程规范 6 4.1 有关的角色及职责 . 6 4.2 软件需求管理过程的概貌 . 7 4.3Discover 阶段 8 4.4Define 阶段 9 4.5 需求维护 . 12 5 软件过程改进七命题 13 4 1 前言在软件项目的开发过程中，需求变更贯穿了软件项目的整个生命周期，从软件的项目立项，研发，维护，用户的经验在增加，对使用软件的感受有变化，以及整个行业的新动态，都为软件带来不断完善功能 ，优化性能，提高用户友好性的要求。在软
7、件项目管理过程中，项目经理经常面对用户的需求变更。如果不能有效处理这些需求变更，项目计划会一再调整，软件交付日期一再拖延，项目研发人员的士气将越来越低落，将直接导致项目成本增加、质量下降及项目交付日期推后。这决定了项目组必须拥有需求管理策略。2 需求管理复杂性分析软件需求是整个软件开发项目的最关键的一个输入，和传统的生产企业相比较，软件的需求具有模糊性、不确定性、变化性和主观性的特点，他不像生产汽车、电脑等硬件的需求，是有形的、客观的、可描述的、可检测的，软件需求是软件项目最难把握的问题，他的复杂性体现在以下方面：1、需求的描述问题。缺少正式的完整的需求文档浪费了大量的人力物力，但是有了需求文
8、档又出现了新的问题。在用户方进行的需求评审会完全是走形式，因为用户根本不去听他读那上百页的需求文档。不同层次的客户 ( 用户 ) 关心的问题是不一样的，想要每个客户都成为需求专家是不现实的。2、需求的完备程度问题。需求如何做到没有遗漏 ?如何准确划定系统的范围 ?这确实是一个两难问题，稍微大一点的系统要想穷举需求几乎是不可能的，每次开需求评审会时，总会冒出新的需求，以至于系统没有一个准确的范围界定。即使是这样，系统还是要开发，没办法，系统的范围还要硬性的划定一个，从而建立一个基线。3、需求开发的工期问题。在需求上花费了大量的时间，客户、软件公司是否能够忍受 ?为了确保需求的正确性，完备性，项目
9、经理往往坚持要在需求阶段花费大量的时间，但是客户与公司的高层领导却会为项目迟迟看不到实际可运行的软件担心不已 ! 他们往往会逼迫项目组尽快往前推进，而项目组的成员往往也会为系统复杂的善变的需求折腾的筋疲力尽，他们也希望尽快结束此阶段。4、需求的细致程度问题。需求到底描述到多细，才算可以结束了 ?仁者见仁，智者见智，并没有定论，如果时间允许，要想细总可以细下去的。但是，需求的周期越长，可能5 的变化越多，对设计的限制越严格，对需求的共性提取要求越高，所以只要大家 (客户、用户、需求分析人员、设计人员、测试人员 ) 认为描述清楚了，就可以进入设计阶段了。5、需求的变化问题。在软件开发过程中如果只有
10、一条真理的话，那一定是：需求的变化是永恒的，需求不可能是完备的。软件开发的过程实际上是同变化做斗争的过程，需求的变更不一定是坏事，也有可能是好事，是商业机会，对市场敏感的人可以从需求的变化中发现市场机会。需求变化的原因很多，如：一开始没有识别全，需要增加需求；业务发生了变化，需求必须变化；需求错误；需求不清楚。需求的变化问题是每个开发人员、每个项目经理都遇到的问题，也是最头痛的问题，一旦发生了需求变化，你不得不来修改你的设计、重写你的代码、修改你的测试用例、调整你的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦，怎么办 ?管理它 ! 使需求在受控的状态下发生变化，而不
11、是随意变化，需求管理就是要按照标准的流程来控制需求的变化。难题随之而来，需求中的变化一般不是突发的革命性的变化，最常见的是项目需求的渐变问题，这种渐变很可能是客户与开发方都没有意识到的，当达到一定层度时，双方才蓦然回首，发现已经物是人非，换了一番天地。3 需求管理策略需求管理需要遵守以下策略：1、需求一定要与投入有必然的联系。需求一定要与投入有必然的联系，否则如果需求变更的成本由开发方来承担，则项目需求的变更就成为必然了。人们常说世上没有免费的午餐，同样也不应该有免费的需求变更。但是，接受需求变更目前却是软件开发商不得不咽下的苦果。所以，在项目的开始无论是开发方还是出资方都要明确这一条：需求变
12、，软件开发的投入也要变。2、需求的变更要经过出资者的认可。需求的变更引起投入的变化，所以要通过出资者的认可，这样才会对需求的变更有成本的概念，能够慎重地对待需求的变更。笔者曾经经历过一个项目，为了避免项目的风6 险，我们请了用户代表全程参与了开发过程，结果此用户代表在开发过程提出了大量“小的需求变更，当开发人员按此需求变更修改了软件时，在项目进入现场实施阶段时，却有大量的这些变更需要改回去，问题就是出在我们的项目组成员视该用户代表的需求为圣旨，却忽略了需求是否经过了客户方真正有决策权的人员的认可。3、小的需求变更也要经过正规的需求管理流程。小的需求变更也要经过正规的需求管理流程，否则会积少成多
13、。在实践中，人们往往不愿意为小的需求变更去执行正规的需求管理过程，认为降低了开发效率，浪费了时间。正式由于这种观念才使需求的渐变不可控，最终导致项目的失败。4、精确的需求与范围定义并不会阻止需求的变更。并非对需求定义的越细，越能避免需求的渐变，这是 2 个层面的问题。太细的需求定义对需求渐变没有任何效果。因为需求的变化是永恒的，并非由于需求写细了，它就不会变化了。注意沟通的技巧。实际情况是用户、开发者都认识了到了上面的几点问题，但是由于需求的变更可能来自客户方、也可能来自开发方，作为客户他们可能不愿意为需求的变更付出更多的投资，开发方有可能是主动的变更了需求，他们的目的可能是使软件做的更精致，
14、于是作为需求管理者、项目经理需要采用各种沟通技巧来使项目的各方各得其所。4 某企业需求管理过程规范4.1 有关的角色及职责角色 职责描述市场人员 负责 discover 阶段所有工作，并帮助开发项目经理和设计师在 define阶段初期很快地了解业务和客户开发项目经理 协调 discover 阶段的所有活动；与设计师共同完成需求文档；维护scope matrix 。设计师 与开发项目经理共同完成需求文档行业专家 提供行业咨询高层团队 指导 discover 和 define 阶段的工作SEPG 负责过程的培训，提供过程支持，负责过程的跟进和改进7 4.2 软件需求管理过程的概貌需求可定义为“（正
15、在构建的）系统必须符合的条件或具备的功能”，也有人定义为“用户解决某一问题或达到某一目标所需的软件功能”。而需求管理是一种获取、组织并记录系统需求的系统化方案，以及 一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。需求管理的目的是在顾客和将处理顾客需求的软件项目组之间建立对顾客需求的共同理解。需求管理的目标是：1) 使软件需求受控，并建立供软件工程和管理使用的基线。2) 使软件计划、产品和活动与软件需求保持一致。4.2.1 过程图4.2.2 注解(1)Discover 阶段本阶段的目的是了解客户的问题，分析并确定公司是否开展此行业的项目。这里的客户不一定针对一个企业，有可能是一个
16、行业。在进行具体的调研时，目标是本行业的一个或几个典型用户。市场人员主要对客户的问题，客户的现状，和客户的业务模式三方面进理解客户的问了解客户的现了解客户的业务分析项目目标和成功识别项目的风险和获取功能需求和技术建立 Scope 需求变更控需求跟踪需求配置管需求说明文档可行性分析报告需求更改单Scope Matrix Scope Matrix Discover阶段 Define阶段 需求维护阶段8 行了解，然后对照公司的业务发展方向和实际现状进行可行性分析，并负责编写可行性分析报告。然后发起可行性分析会议，邀请公司高层，行业专家和利益相关者一起来商议公司是否开展此项目。一旦决定做此项目，下来将
17、寻找有意向的用户。找到合适的用户后，就可以正式开始创建开发团队进行开发系统的定义，设计，编码等工作。(2)Define 阶段目的是得到一套客户认可的详细的需求说明文档，用来指导后期的软件开发工作。开发项目经理和设计师通过与客户沟通交流，分析项目目标和成功因素，识别项目风险和假设，以及系统的功能需求和技术需求，最终整理出一套详细的需求说明文档，包括总体系统的需求信息，每个子系统的需求信息，数据字典，等。为了指导后期的开发和跟踪需求实现的状态和范围，项目经理需要根据需求来建立本项目的 Scope Matrix 。在 Scope Matrix 中随时跟踪每项功能的 In 或 Out，以及现在处于开发
18、的什么阶段。所有需求文档完成之后，由项目经理和设计师发起并组织阶段审核会议，并邀请客户和行业专家参加。审核的内容包括所有需求文档和 Scope Matrix 。一旦审核通过，则开始制定下阶段的计划，准备进入概念阶段。(3) 需求维护阶段目的是管理需求的变更。在软件开发过程中，需求不可避免会有大或小的更改。为了更有效地管理需求的变更，这里规范了需求变更，需求跟踪，和需求配置管理的要求。对每项内容的详细内容，将在后面的章节中介绍。4.3Discover 阶段4.3.1 过程图理解客户的问题了解客户的现状了解客户的业务模式可 行 性 分析报告 可 行 性 问题的决策放弃此项目寻找客户不可行可行9 4
19、.3.2 活动1、理解客户的需求活动：与客户沟通交流，了解他们的原始需求。并分析公司开发此项目的业务机遇，业务目标，客户和市场的需求，以及业务风险等问题。职责：由公司高层负责，市场人员具体执行。2、 了解客户的现状活动：评估客户的现状，如信息化程度，人员的计算机技能水平，业务模式等。职责：由公司高层负责，市场人员具体执行。3、了解客户的业务模式活动：了解客户当前的业务模式，包括业务角色及其关系。职责：由公司高层负责，市场人员具体执行。4、编写可行性分析报告活动：根据前面三项内容，对本项目做评估，分析是否开展此项目职责：由公司高层负责，市场人员具体执行模板：依据提供的“可行性分析报告的模板”整理
20、。根据实际内容，允许对模板进行裁剪。5、可行性问题的决策活动：审核可行性分析报告的内容；决定是否开展此项目参与人：市场人员（发起者和组织者），行业专家，公司高层决策人员。主要沟通内容：可行性分析报告输出：作出结论的可行性分析报告职责：市场人员发起，组织，和主持会议，做会议记录。负责可行性分析报告的修订和决策记录。说明：决定开展此项目后，方可进入 define 阶段。在进入 Define 阶段之前，需要由项目经理和设计师确定项目的整体计划和 define 阶段的详细计划。4.4Define 阶段4.4.1 过程图10 4.4.2 活动1、准备活动：了解 discover 阶段的输出文档，安排交流
21、的客户代表职责：市场人员帮助开发项目经理和设计师了解可行性分析报告中的内容，并共同联系客户代表；开发项目经理和设计师理解可行性报告中的相关内容，为后面工作的开展作好准备。2、分析项目目标和成功因素活动：通过与客户的沟通，定义项目目标和成功的关键因素职责：开发项目经理和设计师共同完成，市场人员可协助。3、 识别项目的风险和假设活动：通过与客户的沟通，识别项目的风险和假定，并分析他们对项目的影响，给出风险的减缓方法。职责：开发项目经理和设计师共同完成，市场人员可协助。4、获取功能需求和技术需求活动：通过与客户的沟通，获取功能需求和技术需求，即明确系统的功能需求和使用什么样的技术职责：开发项目经理和
22、设计师共同完成，市场人员可协助。5、编写需求说明文档活动：根据前面几个步骤的沟通结果，整理项目的需求文档。需求文档不一定是一个，可以是几个文档。但必须包括内容：总体系统的需求信息，每个子系统的需求Define 阶段计划 准备分析项目目标和成功识别项目风险和获取功能需求和技术需 求 说 明文档Scope Matrix 审核进入概念阶段通过未通过11 信息，数据字典。公司建议将总体系统的需求信息与每个子系统的需求信息分开写成文档。在总体系统的需求中，从系统整体出发来阐述，而每个子系统的需求只针对子系统本身来阐述。职责：开发项目经理和设计市共同完成。模板：依据提供的“总体系统的需求说明模板”“子系统
23、的需求说明模板”“数据字典的模板”整理。根据实际内容，允许对模板进行裁剪。高质量的需求说明文档的关键特点：完整：不应该遗漏要求和必需的信息。发现缺少的信息很难，因为根本不存在。如果你知道已缺少一些信息，使用 TBD（ to be determined ）标准标志可以突出这些缺陷，当你在构建产品的相关部分时，就可以从一个给定的需求集中解决所有的缺陷。一致性：一致性需求就是不要于其他的软件需求或高级别的系统 （商业） 需求发生冲突。可修改性：每个需求必须相对于其他需求有其单独的标示和分开的说明，便于清晰的查阅。通过良好的组织可以使需求易于修改，如：将相关的需求分组，建立目录表，索引，以及前后参考（
24、照）。6、 建立 Scope Matrix 活动：根据系统的需求建立 Scope Matrix ，以指导后期的开发。 Scope Matrix 的所有内容必须忠实于整理出来的需求文档。如果需求文档的内容不足以得到完整细致的 Scope Matrix ，可以回过头来完善需求文档；如果实在确定不下来的内容，可以在Scope Matrix 中标注出来，待以后确定。职责：开发项目经理和设计市共同完成。模板：依据提供的“ Scope matrix 的模板”整理。根据实际内容。如何在 Scope matrix 中描述功能域：7、 Define 阶段的审核活动：以会议的形式沟通需求的内容，对需求进行 Qua
25、lity review. 参与人：项目经理（发起者和组织者），设计师，行业专家，和客户审核内容：数据字典，总体系统的需求说明，各子系统的需求说明， Scope matrix 输出： Review notes 。 Review notes 要求填写在公司规定的 Quality review notes的模板中。12 职责：设计师发起，组织，并主持审核会议，做会议记录。会后总结 review notes. 开发项目经理。与设计师共同完成审核工作。说明： Define 阶段审核通过后，方可进入设计阶段。4.5 需求维护需求维护的关键内容是需求变更管理。需求的变更是不可避免的，如何以可控的方式管理软件
26、的需求，对于项目的顺利进行有着重要的意义。对于需求变更的管理，我们主要使用需求变更控制流程，需求跟踪矩阵，和需求配置的管理方式。4.5.1 变更控制1、变更控制流程填写更改单申请提交给项目经理过滤处理需 要 发 起小组会议不是问题，忽略小问题，项目经理可自做决定项目经理发起小组会开会决策如何处修改有 关合同信息将更改内容安排到开发计划客户提出；开发团队提出；接受， 并本次开发考虑 接受，以后版本中再考虑不接受修 改 Scope matrix 修改 Scope matrix 修改 Scope Matrix 修 改计划13 2、变更审核小组成员组成：项目经理，设计师，和客户代表职责：处理每一份需求
27、更改申请单3、 变更申请单变更申请单的模板请参见“需求更改单模板”文件。本模板包含两部分内容，第一部分是更改申请的信息，第二部分是审核小组的分析和决策信息（包括他们的签字）。需求更改的提出者可以是客户，也可以是开发团队的任何人。4.5.2 需求跟踪活动：使用 scope matrix 来跟踪每项需求是否要求实现，以及需求实现的状态职责：由开发项目经理负责维护 scope matrix 。4.5.3 需求配置管理活动：保存需求方面的所有文档的所有版本职责：每个有关需求的文档以及升级文档均要求保存到 CVS。要求：所有资料均放入 CVS。按照规定的目录存放资料。现有两个： Client 和Requ
28、irement 目录。文件的每个修改版本都要求保存。5 软件过程改进七命题1、成熟度命题：需要不断地组织学习以持续地改进全组织的软件支持过程能力。2、效果命题：需要明确地努力和定期地强化其效果。3、领导命题：需要高层领导的发起、参与和支持。4、过程命题：需要仔细地进行过程设计来减轻甚至消除软件支持过程认知障碍并提高群体认知活动的效力和效率。5、文档命题：需要文档（解释和沟通）支持过程活动可视化，使得复杂的智力密集的支持过程活动得到有效地控制。6、团队命题：需要全体人员的协作和努力。7、投资命题：需要计划，配备专职人员以及管理时间和资金投入。14 如果与软件开发过程复杂性五命题相比较可以发现增加
29、了领导、团队和投资三命题。要注意效果命题主要关心软件支持过程改进，而领导、团队和投资特指软件过程改进。其中原来的地图原理由过程命题和文档命题所代替，同时，也说明了软件过程改进复杂性工作程序四个过程的必要性。Watts S. Humphrey 认为软件过程改进的关键在于：（ 1）为改变软件过程，需要有人为此工作（领导命题、团队命题和投资命题）；（ 2）无计划的过程改进只是一相情愿（过程命题和文档命题）；（ 3）自动化差的已定义过程将产生差的已定义结果（能力命题）；（ 4） 改进应该以小的、可测试的步骤进行 （能力命题、效果命题和投资命题） ； （ 4） 培训、培训再培训（能力命题和投资命题）。如
30、上企业的需求管理过程规范模型中， 立足于过程改进， 从软件研发过程改进的复杂性七命题出发，从人员、计划、自动化性、细化和培训等多个方面对需求管理过程进行规范，并制定相应可执行的措施，并且每条措施都描述了严格的活动、职责、要求等详细规范。15 参考文献 1韩万江 . 姜立新，软件开发项目管理 M . 北京：机械工业出版社， 2004 2 何新贵 . 软件能力成熟度模型 M . 北京：清华大学出版社 ,2001:167 169. 3 杨一平 . 软件能力成熟度模型 CMM方法及应用 M . 北京：人民邮电出版社，2001 4 王永贵 . 产品开发与管理 M . 北京：清华大学出版社， 2007-6 5 丁兴良 林俊 黎燕 . 项目流程管理 M. 北京：经济管理出版社， 2008 6舒冠成 . 流程管理（第 3 版） M. 北京： 北京大学出版社， 2008-06 年
