软件需求与分析教程（第十八章）.ppt

第18章 需求管理的原则和实践 需求开发包括对一个软件项目需求的获取、分析、规格说明及确认。 一般的需求开发的成果应包括前景和范围文档、用例文档、软件需求规格说明、数据字典和相关的分析模型。 需求管理包括在项目开发过程中维护需求约定的完整性、准确性以及保持需求约定是必威体育精装版约定的所有活动，如图18.1所示。 第18章 需求管理的原则和实践 需求管理包括： 控制对需求基线的变更。 保持项目规划与需求之间的一致。 控制单项需求和需求文档的版本情况。 跟踪基线中需求的状态。 管理单个需求和其他项目工作产品之间的逻辑联系链。 对提出的新需求或对已变更的需求，项目的响应方式有多种： 推迟实现优先级低的需求。 增派人手。 短时间的突击加班，最好是有偿加班。 为了满足新功能，推迟产品的交付日期。 保持产品交付日期不变，但在质量上打些折扣。 本章描述了需求管理的基本原则。 18.1 需 求 基 线 需求基线(requirement baseline)是团队成员已经承诺将在某一特定产品版本中实现的功能性和非功能性需求的一组集合。 定义了一个需求基线之后，项目的涉众各方就可以对发布的产品中希望具有的功能和属性有一个一致的理解。 确定需求基线时——一般是在通过正式的评审和批准之后，就应该对它们进行配置管理。后续的变更也必须遵守项目预先定义好的变更控制过程。 18.2 需求管理过程 开发组织应该为项目团队规定他们应该通过哪些活动来管理需求。将这些活动编写成文档，并培训其执行者，这样开发组织内的成员就可以一致而有效地完成这些活动。 考虑描述下面这些主题： 用于控制各种需求文档和单个需求版本的工具、技术和约定。 如何将需求纳入基线。 将要使用的需求状态，以及哪些人可能会对它们变更。 18.2 需求管理过程 需求状态跟踪过程。 采用什么方法提出新的需求或对原有需求的变更、对其进行处理和协商并将其传达给受此影响的所有涉众。 如何分析提议的变更所产生的影响。 需求发生变更之后，如何相应地调整项目规划和对客户的承诺。 18.3 需求版本控制 版本控制是管理需求规格说明和其他项目文档必不可少的一个方面。 需求文档的每一个版本都必须惟一地标识出来，使得每个团队成员都能够访问必威体育精装版版本的需求；对所做的变更也必须明确地写入文档中，并传达给受此影响的每一个人。 为了尽量减少混乱、冲突和误传，应该指派一个人专门负责更新需求，并确保只要需求有所变更就相应地改变其版本标识号。 最简单的版本控制机制是，根据标准约定，对每一个软件需求规格说明版本进行手工标识。 还有一种更复杂的技术，可以把需求文档存储在版本控制工具中。 版本控制最有用的方法是将需求存储在商业需求管理工具的数据库中 。 18.4 需 求 属 性 将每一个需求想像成一个对象，它具有一些能将自身与其他需求区分开来的属性。 除了文本描述之外，每个功能性需求都应该有若干条与之相关联的支持信息或属性，这些属性为每一个需求建立了一个上下文和背景，这已超越了所需的功能描述。 我们可以将属性值保存在电子数据表或数据库中，最好是保存在需求管理工具中，定义一些其他属性。 可以用这些工具对数据库进行筛选、排序或查询，以查看根据需求的属性值所选择的需求子集。 18.4 需 求 属 性 应该考虑为每个需求指定如下一些属性： 需求创建的日期。 需求的当前版本号。 创建需求的作者。 负责确保该需求得到满足的人员。 需求的拥有者或一组涉众列表。 需求状态。 需求的最初来源。 创建需求的理由。 需求涉及的子系统。 需求涉及的产品版本号。 使用的验证方法或验收测试的标准。 需求实现的优先级。 需求的稳定性。 18.5 跟踪需求状态 表18.1列出了若干可能的需求状态(还有另一种方案，请参见Caputo 1998)。有些跟踪人员还添加了另外两个状态： “已设计(Designed)”和“已交付(Delivered)。 18.6 评估需求管理的工作量 如果跟踪在需求管理上投入了多少工作量，我们就可以评估工作量是太少，还是正合适，或者是太多，并且可以对当前过程和未来的计划做出相应的调整。 将下面这些活动中所投入的工作量加起来，就可以算出需求管理的工作量： 提交需求变更和提议新的需求。 评估已提议的变更，包括进行影响分析。 变更控制委员会的活动。 更新需求文档或数据库。 向受影响的小组或个人传达需求变更。 跟踪并报告需求状态。 收集需求的跟踪信息。 定义一个用于识别需求文档的版本控制方案，将这一方案作为需求管理过程的一部分而编写为文档。 选择描述功能性需求生命周期所要使用的状态，绘制一幅状态转换图，展示从一个状态转换到另一个状态的触发条件。 定义基线中每个功能性需求的当前状态，在开发过程中要不断更新这