软件需求管理部分完整版课件

1、需求开发面临的特殊难题需求开发：是针对一个新软件或系统开发项目的情况，这种项目有时也称为零起点项目(green-field project)。大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版本；其他组织也很少是从零开始构建一个新系统，而是对商用现货产品进行集成、定制和扩充，以满足自己的需要。第1页，共59页。1开始捕获信息缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，将此看作是软件考古学(software archaeology)。构建一个包含当前系统部分的需求表示可达到以下3个有用的目标：消除知识鸿沟，使将来的维护人员能更好地理解所做的变

2、更。收集当前系统的一些信息当前系统在以前缺乏良好的书面文档。提供一个指标，表明当前的系统测试集对系统功能的覆盖率。第2页，共59页。定义质量需求软件的质量属性和性能目标是选择解决方案时所要考虑的用户需求的另一个方面。我们至少要研究下面几个属性：性能 易使用性灵活性互操作性完整性第3页，共59页。尽早地而且要经常地设定优先级客户和开发人员协同工作，共同选定功能实现的顺序，这样增量开发才会取得成功。开发团队的目标是，将可用的功能和对质量的改进有规律地交到用户手中，因此，开发人员必须了解每次增量开发计划实现哪些功能。第4页，共59页。设定需求优先级每一个受资源限制的软件项目都必须对要求的产品功能定义

3、相对优先级。设定优先级有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。讨论设定需求优先级的重要性，提出一个简单的优先级划分方案，并介绍更严格的基于价值、成本和风险的优先级分析方案。第5页，共59页。5需求和进度安排注意：不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。 第6页，共59页。需求管理第7页，共59页。需求管理的原则和实践需求管理包括在项目开发过程中维护需求约定的完整性、准确性以及保持需求约定是最新约定的所有活动，如图所示。第8页，共59页。8第9页，共59页。软件需求管理需求管理所要完成的任务 需求管理模型 管理变更 需求风险管理 需求跟踪 需

4、求管理工具 第10页，共59页。需求管理所要完成的任务 需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。 需求模型实际是最终产品的抽象化表现。用户需求的满足程度是衡量设计优劣的标准。优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。需求管理在开发周期中是自始至终存在的。需求管理必须始终保持更新。 需求管理同项目管理是密不可分的。 第11页，共59页。需求管理的任务明确需求并达成共识； 建立关联，根据不同需求设计相应解决办

5、法； 进行系统优化，提出设计方案； 监控和解决可能出现的问题以及需要做出的改变； 控制不同开发任务的开展； 对最终产品做出评测； 监控可能出现的重复开发； 提出项目实施时间表； 确定最终用户界面。 第12页，共59页。里程碑与项目管理 一项需求的满足就意味着一块里程碑的确立。里程碑构造机制的基本方法之一就是进程管理 。需求管理在开发周期中是自始至终存在的。需求管理必须始终保持更新，它构成了技术管理的基础。 需求管理同项目管理是密不可分的 。第13页，共59页。需求管理模型 不同的需求组合起来，构成了一套完整的需求模型。需求管理的一项重要工作就是在整个项目的不同任务之间建立联系。需求管理包括在工

6、程进展过程中维持需求约定集成性和精确性的所有活动。需求管理的关键过程领域。需求管理的步骤。 第14页，共59页。需求管理的主要活动 控制对需求基线的变动。保持项目计划与需求一致。控制单个需求和需求文档的版本情况。管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。跟踪基线中需求的状态。 第15页，共59页。需求开发与需求管理的分界中程在线信息产业培训网第16页，共59页。需求基线管理为何需要：频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件.主要思想：将所有现在的、将来的需求进行优先级评估，然

7、后分解成为不同的组，每次迭代都选择其中优先级最高的部分进行开发，然后在迭代完成之前，开发工作不响应变更，这些划入的需求项就是需求基线的组成部分 第17页，共59页。需求基线管理-操作思路我们应该在分析的基础上，将需求整合成为用例或功能项，然后对其进行优先级、依赖性进行综合性评估优先级判断：业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度”模型依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另外的功能无法开始，这就需要对其进行调整第18页，共59页。需求变更管理需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要避免它，它实际上是希望控制变更 在

8、基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态 专门的需求变更管理来对所有的需求变更进行响应，了解需求变更的关键意图、新产生的工作量，从而良好地进行重新计划，以便能够有效地解决其对整个开发带来的麻烦 第19页，共59页。对待软件项目管理的组织必须确保做到以下几点：在提交提议的需求变更之前要对其进行仔细的评估。请合适的人员就需求变更做出周全合理的业务决策。将已批准的变更传达给受此影响的所有人员。项目以一致的方式将需求变更包含进来。采用一致的变更控制方法，就可以避免相关问题，避免开发工作的返工和浪费时间等情况的发生。第20页，共59页。变更控制委员会变更控制委员会，有时也称为配置控制

9、委员会(configuration control board，CCB)，已被证实是软件开发领域公认的最佳实践(McConnell 1996)。CCB是由人组成的团体，可以由一个小组担任，也可以由多个不同的小组担任，这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现。CCB也决定所报告的缺陷中哪些需要纠正，什么时候纠正。CCB可以评审和批准对项目中任何基线工作产品所做的变更，项目需求文档只是其中的一个样例。第21页，共59页。CCB的组成CCB的成员应该能代表需要参与制定决策的所有小组，当然这些决策制定只能是在CCB的权力范围之内。可考虑从下面这些部门中选择CCB代表：项目或程

10、序管理部门产品管理或需求分析部门开发部门测试或质量保证部门市场或客户代表编写用户文档的部门技术支持或帮助部门配置管理部门第22页，共59页。CCB规章CCB规章描述了CCB的目的、权力范围、成员构成、运作规程和决策的制定过程等(Sorensen 1999)。CCB的权力范围规定了哪些决策由CCB决定，哪些决策则必须上报给高一级CCB或者由管理层来决定。1. 制定决策决策制定过程的描述应该确定：CCB成员或主要角色的人数，这是制定决策的法定人数。所采用的决策规则是投票、少数服从多数、协商决定或其他方法。第23页，共59页。CCB规章CCB主席是否可以否决CCB的集体决策。级别高的CCB或其他人是

11、否必须认可CCB做出的决策。2. 交流状态CCB做出决策之后，应该指派专人对变更数据库中的变更请求状态进行更新。3. 重新协商原先的约定在接受一个重大的需求变更之前，为了适应这一变更，需要同管理部门和客户重新协商原先的约定(Humphrey 1997)。协商的内容可能包括，要求推迟产品交付时间，要求增派人手，或者要求推迟实现尚未实现的优先级较低的需求等。第24页，共59页。变更需要付出代价：影响分析对软件实施大的功能增强，则需要进行影响分析(impact analysis)。但是，即使是小的变更请求，也可能潜伏着难以预料的复杂性。影响分析是需求管理的一个关键方面(Arnold和Bohner 1

12、996)。通过对影响进行分析，可以准确地理解提议的变更所涉及到的问题，有助于项目团队就批准哪些提议做出周全合理的业务决策。影响分析:通过对所提议的变更进行检查，确定可能必须创建、修改或废弃哪些部分，并估计与实现这些变更相关的工作量。第25页，共59页。影响分析的过程影响分析有3个方面：1.理解进行变更可能涉及的问题。变更常常会产生大量的连锁反应，产品包括的功能太多会降低其性能，甚至会到令人难以接受的地步。2.确定如果团队将提议的变更包括到产品中，可能必须对哪些文件、模型和文档进行修改。3.确定实现变更所需执行的任务，并估计完成这些任务所需的工作量。注意:跳过影响分析并不能改变任务的规模，只会使

13、规模令人感到惊奇，而软件方面令人惊奇却很少是好消息。第26页，共59页。影响分析报告模板图是一个推荐的报告模板，表示对每个需求变更造成的潜在影响的分析结果。如果采用标准模板，CCB成员就可以轻松地找到他们所需的信息，作出合理的决策。 第27页，共59页。需求的变化是永恒的。因而，对于需求变更应该正确对待，尽量将其负面影响降低。需求变更可能来自解决方案提供商、客户或产品供应商等外部因素，也可能来源于项目组内部。变更都是有代价的，应该评估一下变更的代价及其对项目的影响。在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。切忌在项目设计之前试图消除需求变更。第28页，共59页。需求

14、变更的原因 因竞争、成本等因素，工期已经确定且极不合理.用户在需求期提不出需求、或用户的需求不明确.项目组对业务不熟悉、或者没有与用户密切结合、需求分析工作不细致.项目组没有很好地实施需求管理.第29页，共59页。需求变更的恶性循环 第30页，共59页。需求变更的因素 第31页，共59页。需求变更的代价 第32页，共59页。减少需求变更 第33页，共59页。需求变更的过程管理 认识到变更不可避免，为变更制订计划。确认需求基线。建立控制变更的唯一渠道。使用变更控制系统来捕获变更。分层次地管理变更。 第34页，共59页。基于配置管理的需求管理避免需求在未授权情况下变更，或在有潜在破坏性的情况下不受

15、限制地随意变更。保护队需求文档的修正。方便对文档以前版本的检索或重建。支持系统以增量的方式改进基线。避免对文档的同时更新和冲突。 第35页，共59页。基线管理 需求基线(requirement baseline)是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。基线：已经通过正式评审和批准的某规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变化控制过程的改变。IEEE基线是一个软件配置管理的概念 。在软件工程的范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。 配置管理组或委员会（CCB）按照需求基线

16、，对整个项目的进程进行控制和把握 。第36页，共59页。需求状态的变化 第37页，共59页。需求管理过程注意如果项目中无人负责执行需求管理活动，那么就不要指望需求管理能够运作。第38页，共59页。需求版本控制版本控制是管理需求规格说明和其他项目文档必不可少的一个方面。需求文档的每一个版本都必须惟一地标识出来。为了尽量减少混乱、冲突和误传，应该指派一个人专门负责更新需求，并确保只要需求有所变更就相应地改变其版本标识号。最简单的版本控制机制是，根据标准约定，对每一个软件需求规格说明版本进行手工标识。还有一种更复杂的技术，可以把需求文档存储在版本控制工具中。版本控制最有用的方法是将需求存储在商业需求

17、管理工具的数据库中 。第39页，共59页。需 求 属 性应该考虑为每个需求指定如下一些属性：需求创建的日期。需求的当前版本号。创建需求的作者。负责确保该需求得到满足的人员。需求的拥有者或一组涉众列表。需求状态。需求的最初来源。创建需求的理由。需求涉及的子系统。需求涉及的产品版本号。使用的验证方法或验收测试的标准。需求实现的优先级。需求的稳定性。 注意如果选择的需求属性太多，那么开发团队会望而生畏，结果是他们绝不可能提供所有需求的全部属性值，也无法有效地使用这些属性信息。第40页，共59页。跟踪需求状态表列出了若干可能的需求状态。有些跟踪人员还添加了另外两个状态： “已设计(Designed)”

18、和“已交付(Delivered)。状 态 定 义 已提议(Proposed) 该需求已被有相应权限的人提出 已批准(Approved) 该需求已经被分析，它对项目的影响已进行了估计，并且已经被分配到某一特定版本的基线中。关键涉众已同意包含这一需求，软件开发团队已承诺实现这一需求 已实现(Implemented) 实现这一需求的代码已完成了设计、编码和单元测试。这一需求已被跟踪到相关的设计元素和编码元素 已验证(Verified) 已在集成产品中确认了这一需求的功能实现是正确的。这一需求已被跟踪到相关的测试用例。这一需求目前可以被认为是已完成了 已删除(Deleted) 已批准的需求又从需求基线

19、中取消了。要解释清楚为什么要删除这一需求，以及是谁决定删除的 已否决(Rejected) 需求已被提议，但并不计划在下一版本中实现它。要解释清楚为什么要否决这一需求，以及是谁决定否决的 第41页，共59页。评估需求管理的工作量如果跟踪在需求管理上投入了多少工作量，我们就可以评估工作量是太少，还是正合适，或者是太多，并且可以对当前过程和未来的计划做出相应的调整。将下面这些活动中所投入的工作量加起来，就可以算出需求管理的工作量：提交需求变更和提议新的需求。评估已提议的变更，包括进行影响分析。变更控制委员会的活动。更新需求文档或数据库。向受影响的小组或个人传达需求变更。跟踪并报告需求状态。收集需求的

20、跟踪信息。第42页，共59页。需求风险管理第43页，共59页。所谓风险就是可能给项目的成功带来某些损失或威胁的情况。由于需求在软件项目中具有十分重要的地位，所以精明的项目管理者应尽早确定与需求相关的风险并积极主动地控制它们。典型的需求风险包括：误解需求。用户的参与不恰当。项目范围和目标不确定或随意进行变更。对需求不断进行变更等。第44页，共59页。44软件风险管理基本原理对外部实体的依赖就是一种常见的风险来源。项目管理一直面临各种风险的挑战：评估不准确、管理人员拒绝开发人员的准确评估、对项目状态不了解以及进行了人员调整等原因所引起的风险。技术风险威胁着高度复杂或很前沿的开发项目。知识的缺乏是风

21、险的另一种来源，另外还有参与者对所用的技术或项目应用领域经验不足。经常变更的或强制执行的一些政府规定可能会使最好的项目规划彻底作废。第45页，共59页。风险管理的要素风险管理(risk management)就是使用某些工具和步骤把项目风险限制在一个可接受的范围内。风险管理提供了一种标准的方法，可以指出风险因素并将其编写成文档，评估这些风险的潜在威胁，并提出减少这些风险因素的战略。第46页，共59页。风险管理包括图所示的这些活动。风险评估(risk assessment)是一个对项目进行检查以确定潜在风险领域的过程。风险避免(riskavoidance)是处理风险的一种方法，也就是尽量不要做冒

22、险的事。第47页，共59页。编写项目风险文档图展示了一个模板，用于对单个风险编写文档。第48页，共59页。制定风险管理计划对于小型项目，可以把控制风险的计划包括在软件项目管理计划内。但对一个大型项目，则应该编写一个单独的风险管理计划，详细说明打算采用哪些方法来识别、评估、编档和跟踪风险。这一计划还应该包括风险管理活动的角色和职责。要建立起周期性进行风险监控的措施。 注意：不要想当然地以为，在识别出了风险并采取了降低风险的相应活动之后，风险就会处于您的控制之下。接下来还要实行风险管理活动。第49页，共59页。与需求有关的风险 无足够用户参与用户需求的不断增加 模棱两可的需求 不必要的特性过于精简

23、的规格说明 忽略了用户分类 不准确的计划 第50页，共59页。风险管理是我们的好帮手即使不能控制项目可能遇到的所有风险，风险管理也能帮助我们看清形势，做出合理的决策。第51页，共59页。风险管理的措施明确你当前项目面临的一些与需求有关的风险，不要把当前的问题当作风险，一定要是那些还未发生的事情。将风险因素编写成文档，为每项风险推荐至少一种可能的降低风险的方法。第52页，共59页。风险管理的措施召集代表开发、市场、客户和管理各方面的涉众召开风险“集体研讨”会议。第53页，共59页。需求跟踪需求跟踪提供了一个表明与合同或说明一致的方法。更进一步，需求跟踪可以改善产品质量，降低维护成本，而且很容易实现重用。需求跟踪链使你能跟踪一个需求使用期限的全过程。通用的跟踪模型显示了我们要在软件开发的不同层面全面地跟踪需求。 第54页，共59页。需求跟踪的定义IEEE，1994 开发过程的两个或多个产品之间能够建立关系的程度，尤其是那些具有前