浅谈需求管理.docx
《浅谈需求管理.docx》由会员分享，可在线阅读，更多相关《浅谈需求管理.docx（14页珍藏版）》请在冰豆网上搜索。
浅谈需求管理
目录
一、摘要4
1）内容提要：
4
2）Abstract：
4
二、正文4
1.背景4
1.1需求管理的概念4
1.2需求管理在软件项目管理中的地位5
1.3需求管理的整体过程5
1.4需求管理的要点6
1）控制对需求基线的变动；6
2）保持项目计划与需求一致；6
3）控制单个需求和需求文档的版本情况；6
4）管理单个需求和其他项目可交付品之间的依赖关系；6
5）跟踪基线中需求的状态；6
2.需求管理的现状6
3.需求管理中遇到的一些问题6
3.1需求正确性问题6
3.2需求描述不够详细7
3.3需求描述的完备性7
3.4需求的变更7
4.解决以上问题的一些方法8
4.1制定有效规范的需求管理的步骤8
4.2积极地协作，积极地交流、需求管理专职化8
4.3利用合同的约束力9
4.4充分掌握区分对待的原则9
4.5对需求文档版本的控制9
4.6正确认识需求变更10
4.7管理需求变更10
4.8建立需求管理模型10
4.9与用户充分沟通10
4.10利用需求管理工具11
5.度量需求管理的效果12
6.关于软件需求管理13
三、参考文献13
一、摘要
1）内容提要：
需求管理是整个软件工程的管理的基础，也是项目成功的关键所在，本文就自己在课堂上学到的和自己的一些实际项目经验简述需求管理中主要面临的一些问题，并对部分问题提出相应的解决方法，最后给出度量需求管理的效果的方法。
2）Abstract：
RequirementManagementisnotonlythebasisforthewholemanagementofasoftwareengineering,butalsothekeytothesuccessoftheproject.ThispaperoutlinedthemajorissuesfacinginmyownpracticalprojectexperienceinRequirementManagementaswellaswhatwelearntinclass,andthengivesomesolutionsoftheproblemsrespectively.Finally，IwillgivethemethodtomeasuretheeffectofRequirementManagement.
二、正文
1.背景
1.1需求管理的概念
要理解需求管理，首先要了解需求管理的概念，要知道什么是需求管理，需求管理的核心是什么，为什么要进行需求管理，需求管理在软件项目管理中所处的地位，下面简要地阐述。
由于需求是正在构建的系统必须符合的事务，而这些事务在整个项目的实现过程中，会因为各种各样的原因而发生变更，因而，需求管理实现的是对已有需求及需求变更的管理，即从最初的需求建立开始，需求管理就开始了，首先是对需求进行记录和组织，然后在发生变化的时候对它们进行追踪。
简单地说，需求管理就是一种获取组织并记录系统需求的系统化方案，以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。
需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。
而需求管理的核心就是通过有效的需求管理来控制变更，减少变更的影响，并且尽早标识变更，同时减少来源模糊的变更。
1.2需求管理在软件项目管理中的地位
在软件项目管理过程中，之所以需要需求管理，是因为项目要获得成功，要满足项目需求，就必须有效地对项目的需求进行管理，若无法很好地管理需求，那么就无法较好地达到目标。
根据Carnegie-MellonUniversitySoftwareEngineeringInstitute的调查报告，软件项目失败的十大原因中，Inadequaterequirementsspecification（不充分的需求规范）和Changesinrequirements（需求的改变）排在前两位，成为对软件项目影响最大的两个因素。
1.3需求管理的整体过程
软件需求管理的过程，是从需求的建立就开始的，这里大致介绍需求管理的需求变更管理的过程：
1.规范化需求变更控制的过程：
将需求变更的控制过程确定，该过程确定之后，所有的需求变更都要按照这个过程规范地选择、分析和决策。
2.组建需求变更控制委员会：
由能承担项目风险的项目管理者或需求提出者组成一个项目需求变更控制小组，由他们来进行项目需求变更的选择、分析和决策。
即决定进行哪些需求变更，分析此变更是否在项目范围内，并作出决策，以确定最终选择哪些需求变更，放弃哪些，并确定实现变更的先后顺序。
3.分析需求变更的影响：
对每项确定的需求变更进行评估，来衡量它对于整个项目的计划以及对其他需求的影响。
明确与变更相关的任务，同时分析并预算出完成每个任务所需要的人力、物力和时间成本，并做好计划。
通过这些分析将有助于需求变更小组作出更好的决策。
4.跟踪所有受需求变更影响的工作产品：
当进行某项需求变更时，根据原始的需求找到与之相关的需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。
这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。
5.建立需求基准版本和需求控制版本文档：
确定一个需求基准，这是一致性需求在特定时刻的快照。
之后的需求变更就遵循变更控制过程即可。
每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。
最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。
6.维护需求变更的历史记录：
记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。
版本控制工具能自动完成这些任务。
7.跟踪每项需求的状态：
建立一个数据库，其中每一条记录保存一项功能需求。
保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。
8.衡量需求稳定性：
记录基准需求的数量和每周或每月的变更（添加、修改、删除）数量。
过多的需求变更“是一个报警信号”，意味着问题并未真正弄清楚，项目范围并未很好地确定下来或是政策变化较大。
9.使用需求管理工具：
商业化的需求管理工具能帮助你在数据库中存储不同类型的需求，为每项需求确定属性，可跟踪其状态，并在需求与其它软件开发工作产品间建立跟踪能力联系链。
1.4需求管理的要点
1）控制对需求基线的变动；
2）保持项目计划与需求一致；
3）控制单个需求和需求文档的版本情况；
4）管理单个需求和其他项目可交付品之间的依赖关系；
5）跟踪基线中需求的状态；
2.需求管理的现状
随着信息时代的发展，计算机软件的需求愈来愈复杂，规模愈来愈大，而且随着企业的发展，工作过程重组，需求变更已愈来愈成为必然。
软件危机持续了30年之久，至今仍无法得以很好地解决。
究其原因，软件本身具有的特点固然有关，但长期以来，缺乏软件开发和维护的正确方法以及忽视软件开发过程的质量控制乃是最为关键的原因。
其中软件开发和维护方法的不正确性主要体现在:
忽视软件开发前期的需求分析;开发过程缺乏统一的、规范化的方法论的指导;文档资料不齐全或不准确;忽视与用户之间、开发组员之间的交流;忽视测试的重要性;不重视维护或由于上述原因造成维护工作的困难。
这样，就经常出现用户对“已完成”系统不满意，软件产品的质量经常出现漏洞，补丁一大堆。
因此人们意识到以工程化的原则和方法组织软件开发工作是解决软件危机的一个主要出路。
需求分析作为软件生命周期的第一个阶段，并贯穿于整个软件生命周期，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域—需求工程。
进人20世纪90年代后，需求工程成为软件界研究的重点之一。
从1993年起，每两年举办一次需求工程国际研讨会（ISRE）,1994年起，每两年举办一次需求工程国际会议（ICRE）。
一些关于需求工程的工作小组相继成立。
3.需求管理中遇到的一些问题
3.1需求正确性问题
由于软件的开发专业性很强，一般情况下，原始需求的提出者（用户），是很难理解开发过程和开发人员的开发理念的。
所以在和客户交流时，他们讲述的需求在实际中很多都是利用现有的技术实现不了的，用户只是依据自己当时的工作需求提出的。
但是随着开发人员开发工作的不断进展，用户可能会想到更多的功能，进而提出一些没有的需求或要求对以前的需求进行改动，而导致需求的变更。
还有可能由于用户本身对于需求的描述并不清晰，导致开发人员（需求获取人员）对需求产生了误解，于是就产生了错误的需求，但是在开发过程中，开发人员仍然按照错误的需求来进行工作，这样就导致，当客户看到产品或是产品的雏形时，会发现产品与自己想要的差异很大甚至完全相反，亦即最后开发出来的系统不能满足用户。
如果在软件项目进行到后期的时候才发现，修复费用是非常可怕的，甚至会超出项目本身的费用。
因此必须对需求的正确性进行确认。
3.2需求描述不够详细
需求获取人员和开发人员都希望需求描述越详细越好。
而很多时候都是只要项目的开发方与用户在各种问题上的要求基本上达到一致即可，具体的细节总是推迟到以后再填充，实际上这是一种非常危险的思想。
因为不论前期需求分析做得多么细致，在开发工作逐渐进行过程中，总是会出现各种各样的需求的变更，而前期如果能将需求描述得足够详细，那么在后面需求变更的时候就会更加地简单和方便。
另外一个问题是，在需求分析阶段，开发人员和用户（需求提出者）的心态不同，开发人员为了获取更加详细的需求描述，会愿意花更多的时间在需求分析阶段，但用户却不会这么想，用户不愿意在需求分析阶段花费太多的时间和精力，这样的不一致也使得获取详细的需求描述变得更加困难。
但是，并不是说需求描述越详细越好，详尽的需求描述需要更长的需求分析时间，这使得需求分析阶段的周期过长，反而会影响后面的开发过程，故而，对于需求描述的详细程度，需要凭借经验结合项目实际来定夺。
3.3需求描述的完备性
系统的需求数目庞大，我们几乎不可能把所有的需求都一一地列举出来，而且随着开发工作的进行，用户也会不断地提出新的需求，因此，穷举所有的需求是不可能的，另外，并不是用户提出的所有需求都要满足。
在项目开发的后期，改变一个需求对整个项目的影响或损失很可能会超过需求本身给用户带来的益处，因此，描述的完备性就变得非常重要。
3.4需求的变更
需求的变更是每个项目进行过程中必然会出现的，但是却是最难处理的，若是没有做好需求变更的管理，那么整个需求管理阶段也会受到极大的影响，甚至直接影响到整个项目的管理。
因此，需求的变化问题是每个开发人员、每个项目经理，每个项目管理人员最头痛的问题，一旦发生了需求变化，就不得不来修改原始的设计、重写原始的代码、修改原始的测试用例、调整原始的项目计划等等，需求的变化好比是万恶之源，为项目的正常的进展带来不尽的麻烦。
那么只有管理好它，使它在受控的状态下发生变化，而不是随意变化，需求管理就是要按照规范化的流程来控制需求的变化（但不是减少需求的变化）。
但另一个问题就是，需求中的变化一般不是突发的革命性的变化，而是有一个过程的，慢慢变化的，这种渐变很可能是客户与开发人员都没有意识到的，当开发进行到一定程度，双方才突然意识到很多需求已经发生了巨大的改变。
4.解决以上问题的一些方法
4.1制定有效规范的需求管理的步骤
开发组织应该定义项目组执行管理他们需求的步骤。
文档化编写这些步骤能使组织成员持续有效地进行必要的项目活动。
请考虑选择以下主题：
1.用于控制各种需求文档和单个需求版本的工具、技术和习惯做法；
2.建议、处理、协商、通告新的需求和变更给有关的功能域的方法；
3.如何制定需求基线；
4.将使用的需求状态，并且是谁允许作出的变更；
5.需求状态跟踪和报告过程；
6.分析已建议变动的影响应遵循的步骤；
7.在何种情况下需求变更将会怎样影响项目计划和约定。
你可以在一个文档中包含上面所有的信息。
或者，你可能喜欢专题分述，例如分成变更控制过程，影响分析过程，状态跟踪过程。
这些过程可能在多个项目中都有用，因为他们反映每个项目所应遵循的公共功能。
4.2积极地协作，积极地交流、需求管理专职化
很简单的一个道理，遭到用户抵制的能够成功，因此，与用户的交流非常重要，而在讨论需求的时候，开发人员也应该尽量采取相互理解、相互协作的态度，对能解决的问题尽量解决。
即使用户提出了在开发人员看来"过分"的要求，也应该仔细分析原因，积极提出可行的替代方案。
需求变更管理的过程很大程度上就是用户与开发人员的交流过程。
所以软件开发人员必须学会认真听取用户的要求、考虑和设想，并加以分析和整理。
同时，软件开发人员应该向用户说明，进入设计阶段以后，再提出需求变更会给整个开发工作带来什么样的冲击和不良后果。
另外，最好的方法是安排专职人员负责需求变更的管理，同时负责与用户进行必要的沟通等。
因为有时开发任务较重，开发人员容易陷入开发工作中而忽略了与用户的随时沟通，因此需要一名专职的需求变更管理人员负责与用户及时交流。
4.3利用合同的约束力
需求的变更给软件开发带来的影响有目共睹，所以在与用户签订
合同时，可以增加一些相关条款，如限定用户提出需求变更的时间，规定何种情况的变更可以接受、拒绝接受或部分接受，还可以规定发生需求变更时必须执行变更控制流程。
诸如，需求发布后，变更本着双方友好协商的原则，确定协商流程。
4.4充分掌握区分对待的原则
学会识别目标的变更类型、层次：
1.目标层变更
2.功能层变更
3.操作层变更
随着开发工作的不断进行，有些用户就会慢慢提出一些在项目开发团队看来确实无法实现或者工作量巨大且对项目有重大影响的需求。
遇到这种情况，开发人员可以向用户说明，项目的启动是以最初的基本需求作为开发前提的，如果大量增加新的需求（虽然用户认为是细化需求，但实际上是增加了工作量的新需求），会使项目不能按时完成。
如果用户坚持实施新需求，可以建议用户将新需求按重要和紧迫程度划分档次，作为需求变更评估的一项依据。
同时，还要注意控制新需求提出的频率。
4.5对需求文档版本的控制
客户签收的所有过程文档都要作为基线确定下来，做好相关文档的管理工作。
需求的基线是指是否容许需求变更的分界线，需求分析人员在充分与客户用户进行沟通的基础上形成第一个版本的需求文档，这个需求文档在通过需求评审后即可以建立第一个需求基线。
此后每次需求变更并经过需求评审后，都要重新确定新的需求基线，以免将来用户需求发生变更时，原来的需求无法查找。
为有效进行需求变更控制，必然要做的工作就是保存好各个版本的需求基线，维护需求基线文档，以备不时之需。
4.6正确认识需求变更
在软件开发过程中有这样一条真理:
需求的变化是永恒的，需求不可能是完备的。
软件开发的过程实际上是一个变化的过程，需求的变更不一定是坏事，也有可能是好事。
变更的需求之所以变得难以管理，不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性，而且也因为对某个需求的变更很可能影响到其他需求。
应确保赋予需求一个有弹性的结构，使它能适应变更，并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系。
管理变更包括建立基线，确定需要追踪的重要依赖关系，建立相关项之间的可追踪性，以及变更控制等活动。
需求变更贯穿了软件项目的整个生命周期，通过建立规范的变更控制流程，改进软件分析与设计，把变化纳人计划之中，在应对需求变更时可以更加的从容和有信心。
4.7管理需求变更
变更控制不应该只是软件开发过程应该考虑的事情，随着软件产品的开发和时间的推进，用户会提出越来越多的新需求，甚至在交付软件产品的最后阶段用户还会有不同的需求，因此需求变更的管理应贯穿于整个项目生命周期的全过程。
为了使变更对项目的影响降到最小，就应当采取合适有效的变更控制策略，确定一个选择、分析和决策需求变更的过程，所有的需求变更都需遵循此流程。
对需求的变更的处理应该分以下几个步骤:
提出变更、变更评估、实施变更、监督变更过程。
4.8建立需求管理模型
需求建模是表达需求的一种形式，是对需求的一种描述与阐释，它使用标准的语言，利用类似积木的概念来建模，最大的好处是大家可以直接根据需求，轻易地反复修改需求模型。
并且不会产生歧义，从而可以使大多数人快速地理解。
需求建模的目的是要消除人际沟通随意性很强的弱点，所以需要致力于将沟通标准化、自动化、准确化，而且责任到人负责的具体阶段。
具有可测试、可验证性的特点。
建模的过程就是通过需求的特点和要求进行分析，以建模标准为基础进行准确、完备和有效的阐述，以确保客户和开发方都能够明确无误地、通用的理解。
4.9与用户充分沟通
在需求管理过程中与用户的沟通很重要，因为它直接决定着最终软件产品是否满足客户的要求，即很大程度上决定着项目的成败。
在沟通时，双方对需求的认识要一致，不能模棱两可。
讨论需求及变更需求时，需求人员与客户及用户应该尽量采取协作的态度，良好的工作氛围也会提高工作效率，很难想象双方在“刁难”与“对付”的态度下是多糟糕的工作场景。
确定需求基线的过程也是与客户用户交流的过程，而频繁大量的需求变更在很大程度上也是交流不充分的后果。
所以，有效的充分的交流尤为重要，需求人员认真听取客户用户的要求，进行分析和整理，并最终取得用户的确认。
4.10利用需求管理工具
基于文档存储需求的方法有若干限制。
例如：
1.很难保持文档与现实的一致。
2.通知受变更影响的设计人员是手工过程。
3.不太容易做到为每一个需求保存增补的信息。
4.很难在功能需求与相应的使用实例、设计、代码、测试和项目任务之间建立联系链。
5.很难跟踪每个需求的状态。
需求变更控制委员会可以采取商业化的需求管理工具，以此来在数据库中存储不同类型的需求。
这些工具提供了对每项需求的属性描述、状态跟踪等，并可以在需求与其它的相关工作产品间建立跟踪能力联系链。
需求管理工具使用多用户数据库保存与需求相关的信息，让你不必担心以上的问题。
小一点的项目可以使用电子表格或简单的数据库管理需求，既保存需求文本，又保存它的几个属性。
大项目可以从使用商业需求管理工具中获益，其中包括让用户从源文档中产生需求，定义属性值，操作和显示数据库内容，让需求以各式各样的形式表现出来，定义跟踪能力联系链，让需求同其他软件开发工具相连等功能。
在考虑自行开发工具前先调查一下是否有可用的成熟工具。
即使你善于收集项目的需求，在开发过程中自动化的工具仍能可以帮助你处理这些需求。
随着开发的进行，开发组成员慢慢记不清需求细节，这时商业需求管理工具就变得十分有用。
以下是一些工具可以帮你执行的任务：
1）管理版本和变更项目应定义需求基线，基线是每个版本所包括的需求的集合。
一些需求管理工具提供灵活的设定基线功能。
这些工具可以自动维护每个需求的变动历史，这比手工操作要优越得多。
可以记录变更决定的基本原则并可根据需要返回到以前的需求版本。
通常这些工具包括一个内建的变动建议系统，它可以与变更请求所涉及的需求直接联系。
2）存储需求属性对每一个需求应该保存一些属性，正如16章描述的，有关人员应能看到这些属性，选择合适的人员更新这些属性值。
需求管理工具产生几个系统定义的属性（例如，需求创建日期和版本号），同时允许定义不同数据类型的其它属性。
可以通过排序，过滤，查询数据库来显示满足属性要求的需求子集。
3）帮助影响分析通过定义不同种类的需求，子系统的需求，单个子系统和相关系统部件—例如：
例子、设计、代码和测试—等各个部分之间的联系链，工具可以确保需求跟踪。
联系链可以帮助用来对特定需求所做的变动进行影响分析，即通过确定影响涉及的系统部件来做到这一点。
最好的是这些工具可以查到功能需求的来源。
4）跟踪需求状态利用数据库保存需求可以很容易知道某个产品包含的所有需求。
在开发中跟踪每个需求的状态将可以支持项目的全程跟踪。
当项目管理者知道某个项目的下一版本中的百分之五十五的需求已经验证过了，百分之二十八已经实现但还没有验证，百分之十七还没有实现时，他就对项目状况有了很好的了解。
5）访问控制可以对个人、用户小组确定访问权限。
绝大多数工具允许共享需求信息，对于地域上分散的组可以通过Web网页使用数据库。
数据库在需求这一级别通过锁机制进行多用户管理。
6）与风险承担者进行沟通典型的需求管理工具允许小组成员通过多线索电子对话讨论需求。
当讨论达成一个新的结果时或某个需求修改后，自动电子邮件系统就会通知涉及的人员。
7）重用需求由于在数据库中保存了需求，在其他项目或子项目中重用需求变为可能。
还可以避免信息冗余。
5.度量需求管理的效果
在每个项目的工作分类细目结构中需求管理活动应该表现为分配有资源的任务。
测算当前项目中的需求管理成本，是计划未来需求管理工作或经费的最佳途径。
一个从未度量过工程任何一个方面的组织通常发现很难开始保持一个耗时记录。
测算实际开发和项目管理的工作量要求一个文化上的改变和养成记录日常工作的习惯。
然而，测算并不像人们所担心的那样花费时间，了解成员花费在各个项目任务上的确切工作量会使你获得有价值的资料（Wiegers1996a）。
应该注意到工作量计算与翻过的日历时间不成正比，任务进度可能被打断或因同客户协商造成拖延。
每个单元的工作时数总和表明一个任务的工作量，这个数据没必要随外界因素变化，但总体上却要比原计划长一些。
跟踪实际的需求管理效果能使你了解组员是否采取了措施进行需求管理。
执行需求管理措施不得力，会由于不受约束的变更、范围延伸和遗漏需求等原因而增加项目的风险。
考虑一下需求管理的下列活动的效果：
1.提出需求变更和已建议的新需求。
2.评估已建议的变更，包括影响分析。
3.变更控制委员会活动。
4.更新需求文档或数据库。
5.在涉及人员或团队中交流需求的变更。
6.跟踪和报告需求状态。
7.定义和更新需求跟踪能力信息。
尽管忽视和效率不高会随时发生，管理项目需求能确保你投资到需求的收集、归档和分析的努力没有白费。
有效的需求管理策略能在整个开发过程中使项目参与者获悉需求的当前状态信息，从而减少大家在需求认识上的差距。
6.关于软件需求管理
需求管理是需求分析过程中的一个步骤，是一个持续的不断完善的过程，软件项目开发过程中需求管理的问题有很多，随时都有用户需求变更，需求分析的错误也时常发生，需求质量难以保，针对这些问题，如何采取有效的措施尽可能减少这些问题可能给项目造成的影响也显得尤其重要，因为一旦需求的管理出现问题，将会影响到不只是那部分需求所相关的功能，若是在项目的后期才发现这样或那样的需求偏差或者是需求理解错误，将会给项目造成不可估量的损失，甚至是直接导致项目的失败。
而运用良好的机制和组织来管理需求不仅可以使得需求更加的规范，也会使得整个项目管理起来更加方便，实施起来不会与原始的需求有太大的偏差，或者换句话说，就是最后能够完成一个用户想要的产品。
三、参考文献
1.《软件需求管理用例方法》（第2版）（美）莱芬韦尔等著，蒋慧译中国电力出版社2004-05-01；
2.《软件需求》（美）[K.E.维格斯]著机械工业出版社2000-07-01；
3.《ITProjectManagement》JosephPhillips2004-11；
4.《浅谈
升级会员 