软件需求管理部分完整版.ppt

软件需求管理部分完整版.ppt

《软件需求管理部分完整版.ppt》由会员分享，可在线阅读，更多相关《软件需求管理部分完整版.ppt（59页珍藏版）》请在冰豆网上搜索。

需求开发面临的特殊难题需求开发：

是针对一个新软件或系统开发项目的情况，这种项目有时也称为零起点项目（green-fieldproject）。

大多数组织的主要精力集中于维护现存的遗留系统，或者为已有的商业产品构建新的版本；其他组织也很少是从零开始构建一个新系统，而是对商用现货产品进行集成、定制和扩充，以满足自己的需要。

1开始捕获信息缺少精确的需求文档，那么维护人员就必须进行逆向工程，通过代码来理解系统，将此看作是软件考古学（softwarearchaeology）。

构建一个包含当前系统部分的需求表示可达到以下3个有用的目标：

消除知识鸿沟，使将来的维护人员能更好地理解所做的变更。

收集当前系统的一些信息当前系统在以前缺乏良好的书面文档。

提供一个指标，表明当前的系统测试集对系统功能的覆盖率。

定义质量需求软件的质量属性和性能目标是选择解决方案时所要考虑的用户需求的另一个方面。

我们至少要研究下面几个属性：

性能易使用性灵活性互操作性完整性尽早地而且要经常地设定优先级客户和开发人员协同工作，共同选定功能实现的顺序，这样增量开发才会取得成功。

开发团队的目标是，将可用的功能和对质量的改进有规律地交到用户手中，因此，开发人员必须了解每次增量开发计划实现哪些功能。

设定需求优先级每一个受资源限制的软件项目都必须对要求的产品功能定义相对优先级。

设定优先级有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。

讨论设定需求优先级的重要性，提出一个简单的优先级划分方案，并介绍更严格的基于价值、成本和风险的优先级分析方案。

5需求和进度安排注意：

不要迫于压力而许下自己明知道不可能做到的诺言，这是避免最后两败俱伤的秘诀。

需求管理需求管理的原则和实践需求管理包括在项目开发过程中维护需求约定的完整性、准确性以及保持需求约定是最新约定的所有活动，如图所示。

8软件需求管理软件需求管理需求管理所要完成的任务需求管理模型管理变更需求风险管理需求跟踪需求管理工具需求管理所要完成的任务需求管理的首要任务在于使开发人员和用户双方对于需求都有一个明确的认识。

需求模型实际是最终产品的抽象化表现。

用户需求的满足程度是衡量设计优劣的标准。

优秀的需求分析应当非常精确细致地对用户需求作出描述，同时也应该最大程度地给予方案设计者充分发挥的余地。

对开发项目进行任务划分，将整体开发任务细化为多个子模块，从而使这些子模块能够平行开发而无需太多的干预。

需求管理在开发周期中是自始至终存在的。

需求管理必须始终保持更新。

需求管理同项目管理是密不可分的。

需求管理的任务明确需求并达成共识；建立关联，根据不同需求设计相应解决办法；进行系统优化，提出设计方案；监控和解决可能出现的问题以及需要做出的改变；控制不同开发任务的开展；对最终产品做出评测；监控可能出现的重复开发；提出项目实施时间表；确定最终用户界面。

里程碑与项目管理一项需求的满足就意味着一块里程碑的确立。

里程碑构造机制的基本方法之一就是进程管理。

需求管理在开发周期中是自始至终存在的。

需求管理必须始终保持更新，它构成了技术管理的基础。

需求管理同项目管理是密不可分的。

需求管理模型不同的需求组合起来，构成了一套完整的需求模型。

需求管理的一项重要工作就是在整个项目的不同任务之间建立联系。

需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动。

需求管理的关键过程领域。

需求管理的步骤。

需求管理的主要活动控制对需求基线的变动。

保持项目计划与需求一致。

控制单个需求和需求文档的版本情况。

管理需求和联系链之间的联系或管理单个需求和其它项目可交付品之间的依赖关系。

跟踪基线中需求的状态。

需求开发与需求管理的分界中程在线信息产业培训网中程在线信息产业培训网需求基线管理为何需要：

频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件.主要思想：

将所有现在的、将来的需求进行优先级评估，然后分解成为不同的组，每次迭代都选择其中优先级最高的部分进行开发，然后在迭代完成之前，开发工作不响应变更，这些划入的需求项就是需求基线的组成部分需求基线管理-操作思路我们应该在分析的基础上，将需求整合成为用例或功能项，然后对其进行优先级、依赖性进行综合性评估优先级判断：

业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度”模型依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另外的功能无法开始，这就需要对其进行调整需求变更管理需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要避免它，它实际上是希望控制变更在基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态专门的需求变更管理来对所有的需求变更进行响应，了解需求变更的关键意图、新产生的工作量，从而良好地进行重新计划，以便能够有效地解决其对整个开发带来的麻烦对待软件项目管理的组织必须确保做到以下几点：

在提交提议的需求变更之前要对其进行仔细的评估。

请合适的人员就需求变更做出周全合理的业务决策。

将已批准的变更传达给受此影响的所有人员。

项目以一致的方式将需求变更包含进来。

采用一致的变更控制方法，就可以避免相关问题，避免开发工作的返工和浪费时间等情况的发生。

变更控制委员会变更控制委员会，有时也称为配置控制委员会（configurationcontrolboard，CCB），已被证实是软件开发领域公认的最佳实践（McConnell1996）。

CCB是由人组成的团体，可以由一个小组担任，也可以由多个不同的小组担任，这些人共同决定将哪些已提议的需求变更和新提议的特性在产品中付诸实现。

CCB也决定所报告的缺陷中哪些需要纠正，什么时候纠正。

CCB可以评审和批准对项目中任何基线工作产品所做的变更，项目需求文档只是其中的一个样例。

CCB的组成CCB的成员应该能代表需要参与制定决策的所有小组，当然这些决策制定只能是在CCB的权力范围之内。

可考虑从下面这些部门中选择CCB代表：

项目或程序管理部门产品管理或需求分析部门开发部门测试或质量保证部门市场或客户代表编写用户文档的部门技术支持或帮助部门配置管理部门CCB规章CCB规章描述了CCB的目的、权力范围、成员构成、运作规程和决策的制定过程等（Sorensen1999）。

CCB的权力范围规定了哪些决策由CCB决定，哪些决策则必须上报给高一级CCB或者由管理层来决定。

1.制定决策决策制定过程的描述应该确定：

CCB成员或主要角色的人数，这是制定决策的法定人数。

所采用的决策规则是投票、少数服从多数、协商决定或其他方法。

CCB规章CCB主席是否可以否决CCB的集体决策。

级别高的CCB或其他人是否必须认可CCB做出的决策。

2.交流状态CCB做出决策之后，应该指派专人对变更数据库中的变更请求状态进行更新。

3.重新协商原先的约定在接受一个重大的需求变更之前，为了适应这一变更，需要同管理部门和客户重新协商原先的约定（Humphrey1997）。

协商的内容可能包括，要求推迟产品交付时间，要求增派人手，或者要求推迟实现尚未实现的优先级较低的需求等。

变更需要付出代价：

影响分析对软件实施大的功能增强，则需要进行影响分析（impactanalysis）。

但是，即使是小的变更请求，也可能潜伏着难以预料的复杂性。

影响分析是需求管理的一个关键方面（Arnold和Bohner1996）。

通过对影响进行分析，可以准确地理解提议的变更所涉及到的问题，有助于项目团队就批准哪些提议做出周全合理的业务决策。

影响分析:

通过对所提议的变更进行检查，确定可能必须创建、修改或废弃哪些部分，并估计与实现这些变更相关的工作量。

影响分析的过程影响分析有3个方面：

1.理解进行变更可能涉及的问题。

变更常常会产生大量的连锁反应，产品包括的功能太多会降低其性能，甚至会到令人难以接受的地步。

2.确定如果团队将提议的变更包括到产品中，可能必须对哪些文件、模型和文档进行修改。

3.确定实现变更所需执行的任务，并估计完成这些任务所需的工作量。

注意:

跳过影响分析并不能改变任务的规模，只会使规模令人感到惊奇，而软件方面令人惊奇却很少是好消息。

影响分析报告模板图是一个推荐的报告模板，表示对每个需求变更造成的潜在影响的分析结果。

如果采用标准模板，CCB成员就可以轻松地找到他们所需的信息，作出合理的决策。

需求的变化是永恒的。

因而，对于需求变更应该正确对待，尽量将其负面影响降低。

需求变更可能来自解决方案提供商、客户或产品供应商等外部因素，也可能来源于项目组内部。

变更都是有代价的，应该评估一下变更的代价及其对项目的影响。

在需求变更发生之前尽量减少需求变更，以将需求变更带来的风险降低到最低。

切忌在项目设计之前试图消除需求变更。

需求变更的原因因竞争、成本等因素，工期已经确定且极不合理.用户在需求期提不出需求、或用户的需求不明确.项目组对业务不熟悉、或者没有与用户密切结合、需求分析工作不细致.项目组没有很好地实施需求管理.需求变更的恶性循环需求变更的因素需求变更的代价减少需求变更需求变更的过程管理认识到变更不可避免，为变更制订计划。

确认需求基线。

建立控制变更的唯一渠道。

使用变更控制系统来捕获变更。

分层次地管理变更。

基于配置管理的需求管理基于配置管理的需求管理避免需求在未授权情况下变更，或在有潜在破坏性的情况下不受限制地随意变更。

保护队需求文档的修正。

方便对文档以前版本的检索或重建。

支持系统以增量的方式改进基线。

避免对文档的同时更新和冲突。

基线管理需求基线（requirementbaseline）是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。

基线：

已经通过正式评审和批准的某规约或产品，它可以作为进一步开发的基础，并且只能通过正式的变化控制过程的改变。

IEEE基线是一个软件配置管理的概念。

在软件工程的范围内，基线是软件开发中的里程碑，其标志是有一个或多个软件配置项的交付，且已经经过正式技术评审而获得认可。

配置管理组或委员会（CCB）按照需求基线，对整个项目的进程进行控制和把握。

需求状态的变化需求管理过程注意如果项目中无人负责执行需求管理活动，那么就不要指望需求管理能够运作。

需求版本控制版本控制是管理需求规格说明和其他项目文档必不可少的一个方面。

需求文档的每一个版本都必须惟一地标识出来。

为了尽量减少混乱、冲突和误传，应该指派一个人专门负责更新需求，并确保只要需求有所变更就相应地改变其版本标识号。

最简单的版本控制机制是，根据标准约定，对每一个软件需求规格说明版本进行手工标识。

还有一种更复杂的技术，可以把需求文档存储在版本控制工具中。

版本控制最有用的方法是将需求存储在商业需求管理工具的数据库中。

需求属性应该考虑为每个需求指定如下一些属性：

需求创建的日期。

需求的当前版本号。

创建需求的作者。

负责确保该需求得到满足的人员。

需求的拥有者或一组涉众列表。

需求状态。

需求的最初来源。

创建需求的理由。

需求涉及的子系统。

需求涉及的产品版本号。

使用的验证方法或验收测试的标准。

需求实现的优先级。

需求的稳定性。

注意如果选择的需求属性太多，那么开发团队会望而生畏，结果是他们绝不可能提供所有需求的全部属性值，也无法有效地使用这些属性信息。

跟踪需求状态表列出了若干可能的需求状态。

有些跟踪人员还添加了另外两个状态：

“已设计（Designed）”和“已交付（Delivered）。

状状态态定定义义已提议已提议（Proposed）（Proposed）该需求已被有相应权限的人提出该需求已被有相应权限的人提出已批准已批准（Approved）（Approved）该需求已经被分析，它对项目的影响已进行了估计，并且已经被分配到某该需求已经被分析，它对项目的影响已进行了估计，并且已经被分配到某一特定版本的基线中。

关键涉众已同意包含这一需求，软件开发团队已承一特定版本的基线中。

关键涉众已同意包含这一需求，软件开发团队已承诺实现这一需求诺实现这一需求已实现已实现（Implemented）（Implemented）实现这一需求的代