18需求管理的原则与实践

2020 4 17 1 29 软件需求工程SoftwareRequirementsEngineering SRE 第三部分软件需求管理第十八章需求管理的原则与实践 龚永罡 2 20 第二部分软件需求开发回顾 通过业务需求确定项目视图与范围 通过客户需求获取使用实例 从客户需求到SRS 从客户需求到分析模型软件的质量属性关系原型法 优先级 需求验证需求开发向设计的转化 3 20 学习目标 在学完本章内容之后 你应该能够 1 分析需求管理的主要活动 2 理解需求管理的目标与作用 3 掌握需求管理的主要步骤 4 掌握SRS版本控制的方法和技术 5 学会确定和控制需求文档的属性的方法 6 分析需求管理的效果 4 20 18 0需求管理的主要活动 需求工程分为需求开发和需求管理 需求开发包括对一个软件项目需求的获取 分析 规格说明及验证 典型需求开发的结果应该有项目视图和范围文档 use case文档 SRS及相关分析模型 经评审批准 这些文档就定义了开发工作的需求基线 baseline 这个基线在客户和开发人员之间就构筑了计划产品功能需求和非功能需求的一个约定 P221 5 20 18 0需求管理的主要活动 在需求管理工作中应该强调 控制对需求基线的变动 保持项目规划与需求之间的一致 控制单个需求和需求文档的版本情况 跟踪基线中需求的状态 管理单个需求和其它项目工作产品之间的逻辑联系链 P221 6 20 18 0需求管理的主要活动 需求约定是需求开发和需求管理之间的桥梁 需求管理包括在工程进展过程中维持需求约定集成性和精确性的所有活动 如图所示 图18 1需求管理的主要活动 P221 7 20 18 1需求基线 需求基线 Requirementsbaseline 是团队成员已经承诺将在某特定产品版本中实现的功能性和非功能性需求的一组集合 定义了需求基线后 项目涉及的各个方面就可以对发布产品希望具有的功能和属性有一致的理解 确定需求基线后 就应该进行配置管理 后续的变更也必须遵守项目预先定义的变更控制过程 P222 8 20 18 2需求管理过程 开发组织应该定义管理需求的步骤 并实现文档化和制度化 管理需求的步骤应该考虑选择以下主题 用于控制需求文档和版本的工具 技术和约定 如何将需求纳入基线 将要使用的需求状态 以及哪些人可能会对其变更 需求状态跟踪和报告过程 用什么方法提出新的需求或对原有需求的变更 对其进行处理和协商并将其转达给受此影响的所有涉众 如何分析提议的变更所产生的影响 需求变更后 如何调整项目规划黄蓉对客户的承诺 P222 9 20 18 3需求版本控制 版本控制是管理需求的一个必要方面 需求文档的每个版本必须被统一确定 组内每个成员必须得到需求的当前版本 必须清楚地将变更写成文档 并及时通知到项目开发所涉及的人员 为了尽量减少困惑 冲突 误传 应该明确规定只允许指定的人来更新需求 这些策略适用于所有关键项目文档 P223 10 20 18 3需求版本控制 每个公布的需求文档的版本应该包括一个修正版本的历史情况 包括已做变更的内容 变更日期 变更人的姓名以及变更的原因 版本控制的最简单方法是根据标准约定 手工标记SRS的每一次修改 在文档被采纳为基线前 草案数可以随着改进逐次增加 而当文档被确认为基线后被标记为 1 0正式版 若只有较小的修改 可认为是 1 1版 若有较大的修改时 可认为是 2 0版 P224 11 20 18 3需求版本控制 一个具有更高级别的版本控制包括用版本控制工具来存储需求文档 例如用登录和检出程序来管理源代码 这方面有很多商业配置管理工具 版本控制的最有力方法是用商业需求管理工具 这些工具能跟踪和报告每个需求的变动历史 当需要恢复早期的需求时这很有价值 在添加 变动 删除 拒绝一个需求后 附加一些评语描述变更的原因在对将来需要讨论时很有帮助 P224 12 20 18 4需求属性 除了文本 每个功能需求应该有一些相关信息或称之为属性与之相联系 这些属性为每个需求建立了一个上下文和背景资料 对大型复杂项目来说 丰富的属性类别显得重要 定义和更新这些属性值是需求管理成本的一部分 精心挑选属性的最小子集对有效的管理项目很有帮助 P225 13 20 18 4需求属性 在需求文档中应考虑明确如下的属性 创建需求的时间需求的版本号创建需求的作者负责认可该需求的人员需求状态需求的原因或根据 或信息的出处 需求涉及的子系统需求涉及的产品版本号使用的验证方法或接受的测试标准产品的优先级或重要程度需求的稳定性 已提议已批准已实现已验证已删除已否决 P225 14 20 18 5跟踪需求状态 过高地估计工作进度 会导致一种普遍得情况 即宣布软件项目或主要任务完成一定百分比之后 这个状态会延续很长一段时间 在整个开发期间跟踪每一个功能需求得状态 是一种更精确地测量项目进度的方法 跟踪状态的依据是 对本次产品迭代所期望的 完成 的含义 将需求状态分成若干状态类别 比起努力监视每个需求完成的百分比或者整个基线完成的百分比更有意义 P226 15 20 18 6评估需求管理的工作量 在每个项目的工作分解结构 WBS 中 需求管理活动应该表现为分配有资源的任务 测算已完成项目的需求管理成本 是计划未来需求管理工作或经费的最佳途径 P228 16 20 18 6评估需求管理的工作量 一个从未度量过工程任何一个方面的组织 通常发现很难开始保持一个耗时记录 测算实际开发和项目管理的工作量 要求一个文化上的改变和养成记录日常工作的习惯 然而 测算并不像人们所担心的那样花费时间 了解成员花费在各个项目任务上的确切工作量 对项目管理是非常有价值的资料 P228 17 20 18 6评估需求管理的工作量 执行需求管理措施不得力将导致需求变更不受约束 范围不断延伸和需求经常遗漏 从而增加项目风险 将下列活动所投入的工作加起来 就可以知道需求管理的工作量 提交需求变更和提议新的需求 评估已提议的变更 包括进行影响分析 变更控制委员会的活动 更新需求文档或数据库 向受影响的小组或个人传达需求变更 跟踪并报告需求状态 收集需求的跟踪信息 P228 18 20 18 6评估需求管理的工作量 因为在软件开发过程中忽视需求和开发效率不高的问题会随时发生 所以通过管理项目需求来确保需求的实现是非常必要的和有效的 有效的需求管理策略能在整个开发过程中使项目参与者获悉需求的当前状态信息 从而减少大家在需求认识上的差距 P228 19 20 本章小结 需求基线在客户和开发人员之间建立了计划产品的功能需求和非功能需求的一个约定 这个需求约定是需求开发和需求管理之间的桥梁 需求管理