第二十七章 需求管理实践
软件需求工程领域分为需求开发和需求管理。
需求管理流程
需求管理包括项目过程中所有保持需求协议的完整性、准确性和流通性的活动。图显示了需求管理的四大核心活动：版本控制、变更控制、需求状态跟踪和需求跟踪。
组织要定义项目团队需要执行的需求管理活动。可以考虑如下主题：
>用于区分单个需求和需求集合版本的工具、技术和惯例
>需求集合的核准与基线化方式（参见第2章）
>新需求和现有需求变更的提出、评估、协商和沟通方式
>如何评估提议变更的影响
>需求属性和需求状态跟踪过程，包括使用的需求状态和哪些人可以修改这些状态
>谁负责何时更新需求跟踪信息
>如何跟踪和解决需求问题
>项目计划和承诺如何反映需求变更
>如何有效使用需求管理（RM）工具
过程适用于整个组织。
项目的业务分析师自常对需求管理负有领导责任。
图：主要的需求管理活动
需求基线
需求开发活动包括获取、分析、描述和验证软件项目需求。需求开发的交付物包括业务需求、用户需求、功能/非功能需求、数据字典和各种分析模型。
确立一个需求集合的基线之后——通常是经过评审和核准之后——需求就会置于配置管理（或变更管理）之下。接下来的变更只能通过项目定义好的变更控制流程进行。
如果发布范围变更，一定要更新相应的需求基线。
项目可以通过以下几种方式适应新需求或需求变更：
>将低优先级需求延迟到以后的迭代或彻底砍掉
>额外增加人力或将部分工作外包
>延长交付时间或在敏捷项目中增加迭代
>牺牲质量来确保按最初的日期交付
需求版本控制
版本控制——唯一性标识别一个条目的不同版本——既适用于单一需求也适用于需求集合，而这些需求通常都表现为文档形式。
需求的每个版本必须有唯一性的标识。
为了减少混乱和误解，只允许指定的人才能更新需求，而且每当更新之后要确保版本号更新。
版本控制最稳健的方式是将需求存在需求管理工具中。
需求属性
将每个需求当作一个带有属性的对象，使其有别于其他需求。
可以考虑以下这个需求属性列表：
>需求创建日期
>需求的当前版本号
>写需求的人
>优先级
>状态
>需求来源
>需求的理由
>发布版本号或需求分配的迭代信息
>干系人（有问题可以联系或对提议变更做出决策的人）
>使用的验证方法或验收条件
跟踪需求状态
跟踪状态意味着将某一特定时间点的情况与整个开发周期所期望的完成情况进行比较。
把需求分为几个状态类别远比试图监控每个需求或整个发布基线的完成比例更有意义。
表：建议的需求状态
| 状态 | 定义 |
| 已提议 | 需求已由授权来源提出 |
| 进行中 | 需求分析师正在积极打磨需求 |
| 起草完成 | 需求的初始版本已经完成 |
| 已核准 | 需求已通过分析，项目影响已通过评估，该需求已被分配到某一具体发布版本的基线。关键干系人同意处理该需求且软件开发团队已承诺实现它。 |
| 已实现 | 实现需求的代码已经设计好，写好并完成单元测试，该需求已追溯到相关设计和代码元素。实现该需求的软件已准备进行测试、评审和其他验证 |
| 已验证 | 需求已满足验收标准，意味着实现需求的正确功能已确认。该需求可以追溯到相关的测试。现在可以认为该需求已完成 |
| 已推迟 | 一个核准的需求现在计划在稍后的版本中实现 |
| 已删除 | 一个核准的需求从基线中移除。需要包含相关的解释，说明原因以及决策者 |
| 已驳回 | 需求提出后但从未被核准，也没有计划在将来的发布版本中实现。需要包含原因及其决策者 |
解决需求问题
表：需求问题的常见类型
| 问题类型 | 描述 |
| 疑问需求 | 需求的有些内容无法理解或尚未决定 |
| 需求遗漏 | 开发人员在设计或实现过程中发现有遗漏的需求 |
| 错误需求 | 需求是错误的，应当修正或删除 |
| 实现问题 | 开发人员在实现需求时，对某些部分的工作机制或设计方案有疑问 |
| 重复需求 | 发现有两个或更多一模一样的需求。只保留其中一个，删除其他 |
| 不必要的需求 | 一个不再需要的需求 |
度量需求投入
在需求开发时，项目计划中应当包含本章介绍的需求管理活动的任务和资源。
请记录花在需求开发活动上的工时数，如下所示:
>计划项目中的需求相关活动
>召开研讨会和评审会，分析文档和进行其他需求获取活动
>写需求规格说明，建立分析模型和需求优先级排序
>创建和评估旨在协助需求开发的原型
>评审需求和进行其他需求验证活动
将如下活动的投入计入需求管理投入：
>配置项目的需求管理工具
>提交需求变更和提出新需求
>评估提交的变更，包括进行影响分析和进行决策
>更新需求信息库
>与受到影响的干系人的沟通需求变化
>跟踪并报告需求状态
>创建需求跟踪信息
请注意，花在需求相关活动上的时间也是项目成功的投资，并非只是成本。
第二十八章 需求变更
为什么要管理变更
软件变更并非坏事，实际上，变更反而是必要的。一个能够认真管理软件项目的组织肯定可以确保做到以下几点。
>提出的需求变更在做出完成承诺之前经过深思熟虑的评估。
>有合适的个人针对提出的变更做出明智的业务决策。
>变更管理活动对受到影响的干系人可见。
>核准的变更会被通知到所有受到影响的项目参与者。
>项目以一致且有效的方式处理需求变更。
管理范围的蔓延
需求增长包括新功能和重大修改在确定基线它们是需求集合之后提出的。
项目持续越久，经历的需求增长越多。
有些需求演化是合理的、不可避免甚至是有利的。
变更控制政策
如下变更控制政策是有用的。
>所有变更必须遵循流程。
>对于未批准的变更，除了可行性探索外不进行设计和实现工作。
>项目的变更控制委员会（CCB）决定实现哪个变更。
>变更数据库的内容必须对所有项目干系人可见。
>每个变更必须进行影响分析。
>每个变更必须可以追溯到一个通过批准的变更请求。
>变更请求的批准或否决都需要记录其背后的理由。
影响多人的变更不得绕过流程。加入快速通道以加速低风险低投资变更请求，可以缩短决策周期。
变更控制流程的基本概念
合理的变更控制流程可以使项目负责人做出明智的决策，在控制产品生命周期成本和项目排期的同时提供最大的客户价值和业务价值。
变更控制流程并不是阻止进行必要变更和障碍。它是一个漏斗和过滤机制。
变更流程要有良好的文档。
变更控制流程说明
在一个流程中包含如下四个组件是很有帮助的:
>准入标准，在流程执行可以开始之前必须满足的条件
>流程涉及的各种任务，负责各个任务的项目角色和其他参与者
>用来验证任务已经正确完成的步骤
>退出标准，用来指明流程已经成功完成的条件
1:目的和范围
描述该流程的目的及其适用的组织范围。指明是否有具体种类的变更是可以豁免的。定义必要的术语以方便其他人理解整个文档。
图：变更控制流程描述示例模板
2：角色和职责
列出参与变更控制活动的项目团队角色及其职责。
表：变更管理活动中可能的项目角色
| 角色 | 描述和职责 |
| 变更控制委员会主席 | 变更控制委员会主席，如果变更控制委员会未能达成一致，主席通常有最终决定权；针对每个变更请求确定评估人和修改人 |
| 变更控制委员会 | 变更控制委员会针对某一具体项目决定是批准还是驳回提出的变更 |
| 评估者 | 受CCB主席要求负责完成变更影响分析的人 |
| 修改者 | 针对批准的变更请求，负责完成产品修改的人 |
| 提交者 | 提交新变更请求的人 |
| 请求接收者 | 最初接收新提交变更请求的人 |
| 验证者 | 验证变更是否已正确实现的人 |
3：变更请求状态
一个变更请求会经历一系列已定义好的状态生命周期。
4：准入标注
变更控制流程最基本的准入标准是一个带有所有必要信息的变更请求通过审批渠道提交。
5：任务
5.1评估变更请求
开始评估此变更请求的技术可行性、成本并将其与项目业务需求和资源约束对齐。
5.2决定变更
由CCB授意的决策者来决定是否该批准还是驳回该变更。
5.3实现变更
修改人（或者修改人团队）更新受影响的工作产品以完整实现该变更。
5.4验证变更
验证完成以后，修改人根据项目文档和代码管理约定将工作产品更新到适当的位置。
6：退出标准
>请求的状态是已驳回、已完成或已取消。
>所有修改的工作产品都已经更新且存储在正确的位置。
>变更的详细信息及变更请求的状态已经通知相关的干系人。
7:变更控制状态报告
附录：为每个请求保存的属性
表：建议的变更请求属性
| 角色 | 描述和职责 |
| 变更来源 | 要求变更的功能区域，可能的团队包括市场、管理、客户、开发和测试 |
| 变更请求ID | 每个请求分配的唯一标号 |
| 变更类型 | 变更请求的类型，例如需求变更、提出的改进或者缺陷 |
| 提交日期 | 提交人提交变更请求的日期 |
| 更新日期 | 变更请求最近被修改的日期 |
| 描述 | 变更请求的无格式文本描述 |
| 实现优先级 | 由CCB决定的实现变更的相对重要程度：低，中，高 |
| 修改人 | 主要负责实现变更的人 |
| 提交人 | 提交变更请求的人 |
| 提交人优先级 | 提交人认为的实现变更的相对重要程度：低，中，高 |
| 计划发布版本 | 已批准的变更所排期的产品发布版本或迭代 |
| 项目 | 变更请求的项目名称 |
| 响应 | 变更请求的自由形式的响应，随着时间进展可以给出多个响应，输入新响应时，不变更已有的响应 |
| 状态 | 请求变更的当前状态 |
| 标题 | 针对提议变更的一句话总结 |
| 验证人 | 负责评估所做变更是否正确的人 |
变更控制委员会
项目总是有一个小组负责行使变更决策权。
CCB的组成：
考虑从如下功能区域选择代表：
>项目或项目集管理人员
>业务分析或产品管理人员
>开发人员
>测试或质量保障人员
>市场人员，应用构建所服务的业务人员，或是客户代表
>技术支持或客服人员
CCB章程
>决策
每个CCB需要定义其决策流程，应该明确如下内容：
>CCB成员或关键角色构成决策群体的数量
>打算使用的决策规则
>CCB主席是否可以驳回CCB的集体决策
>高级CCB或管理层是否必须批准集体决策
CCB在预期收益和接受变更所带来的影响之间进行平衡。改进产品后得到的收益包括节省财务开支，增加收入，提高客户满意度和竞争优势。可能的负面影响包括增加开发和支持成本，延迟交付和产品质量降低。
>重新协商承诺
项目受制于排期、人力、成本和质量.
在接受重大需求变更前，要重新和管理层与客户再次协商承诺以适应变更。
变更控制工具
>允许你定义变更请求的属性
>允许你通过多个变更请求状态实现其生命周期
>强制执行状态转换模型以便只有授权用户才能执行特定的状态变更
>记录每个状态变化的日期及操作人的标号
>当提交人提交新的请求或一个请求的状态更新时，提供定制的自动生成的电子邮件通知
>同时提供标准的和可定制的报告与图表
度量变更活动
考虑跟踪需求变更活动的如下几个方面：
>接收到的变更请求总数，当前打开和关闭的需求总数
>增加、删除和修改需求的累积数
>每个变更来源提出的请求数
>每个需求基线化之后收到的变更数
>处理和实现变更请求的总投入
变更影响分析
重大改进需要做影响分析。
影响分析是负责需求管理的重要方面。
影响分析过程
影响分析包含以下三个步骤。
1.理解变更的可能影响。需求变更经常会产生连锁反应，导致对其他需求、架构、设计、代码和测试的修改。变更也可能导致与其他需求的冲突或向质量属性妥协。
2.识别团队决定进行变更时需要修改的所有需求、文件、模型和文档。
3.识别实现变更所需要的任务并估算完成这些任务所需的投入。
表：用于帮助理解提议变更潜在影响的问题
| 该变更是增强还是损害满足任何业务需求的能力？ |
| 基线中是否有需求和该变更相冲突？ |
| 是否有其他待处理的需求变更和该变更冲突？ |
| 如果不进行该变更，业务上或技术上有哪些后果？ |
| 加果接受该变更，是否有不利的剧作用或其他潜在风险？ |
| 该变更是否会损害性能或其他质量属性？ |
| 该变更在已知的技术限制或人员能力下是否可行？ |
| 该变更是否对开发|测试或操作环境所需的任何资源提出了无法接受的需求？ |
| 是否需要购买工具才能实现并测试该变更？ |
| 该变更加何影响当前项目计划中的任务的顺序、依赖、投入或持续时间？ |
| 是否需要原型或用户输入验证该变更？ |
| 加果接受该变更，项目中已投入的努力会被浪费掉？ |
| 提议的变更会导致产品单位成本增加吗？比如是否会增加第三方产品许可使用费? |
| 此变更会影响到市场营销、生产/制造、培训和客服计划吗？ |
表：用于帮助识别一个变更可能影响的工作产出的检查清单
| 识别用户接口所需要的任何变更、增加或删除 |
| 识别报告、教据库或文件中的任何变更、增加或删除 |
| 识别必须创建、修改或删除的设计组件 |
| 识别必须创建、修改的或删除的源文件 |
| 识别构建文件或过程中需要的任何变更 |
| 识别现有的单元测试、集成测试和系统测试中所需要的修改或删除 |
| 估算所需要的新的单元测试、集成测试和系统测试的教量 |
| 识别需要创建或修改的帮助界面、培训或支持材料或其他用户文档 |
| 识别受变更影响的其他应用、库或硬件组件 |
| 识别任何需要购买或修改的第三方软件 |
| 识别该变更对项目管理计划、质量保障计划、配置管理计划或其他计划的影响 |
表：估算需求变更投入的工作表
| 工时 | 任务 |
| 更新SRS或需求库 | |
| 开发并评估原型 | |
| 创建新的设计组件 | |
| 修改已有的设计组件 | |
| 开发新的用户接口组件 | |
| 修改已有的用户接口组件 | |
| 开发新的用户文档和帮助界面 | |
| 修改已有的用户文档和帮助界面 | |
| 开发新的源代码 | |
| 修改已有的源代码 | |
| 获取授权并集成第三方软件 | |
| 修改构建文件和过程 | |
| 开发新的单元测试和集成测试 | |
| 修改已有的单元测试和集成测试 | |
| 实现后执行单元测试和集成测试 | |
| 开发新的系统测试和验收测试 | |
| 修改已有的系统测试和验收测试 | |
| 修改自动化测试套件 | |
| 执行回归测试 | |
| 开发新报告 | |
| 修改已有的报告 | |
| 开发新的教据库元素 | |
| 修改已有的教据库元素 | |
| 开发新的教据文件 | |
| 修改已有的数据文件 | |
| 修改各种项目计划 | |
| 更新各种文档 | |
| 更新需求跟踪矩阵 | |
| 评审修改工作产出 | |
| 进行评审和测试后的返工 | |
| 其他任务 | |
| 总估算时间 |
很多估算问题的发生，是因为估算人没有考虑到完成一个活动所需要的全部工作。
为改进日后的影响分析，将实现每个变更所需要的实际投入和估算时间进行比较，理解差别背后的原因。
影响分析模板
图：影响分析模板
第二十九章 需求链中的链接
需求跟踪（或可跟踪性）。需求跟踪信息记录单个需求和其他系统元素之间的依赖和逻辑关联。
系统元素包括其他各种类型的需求、业务规则、架构及其他设计组件、源代码模块、测试和帮助文件。
实施建议需求变更时，跟踪信息通过帮助确定需要修改的所有工作产出来进行影响分析。
需求跟踪
通过跟踪链接，可以跟踪需求从提出到实施的生命周期。
可跟踪性作为优秀需求的特征之一。
对于可跟踪的需求，每一个必须是唯一和持久的标记以便可以在整个项目中无歧义地引用。
客户的需要可以清楚表达为商业目标、市场需求和/或用户需求。
“孤儿代码”，一种镀金功能的实例，不属于产品本身。
从每个需求衍生的测试（同时也可以向后追溯回需求）提供了一种机制，可以用来检测未实现的需求，因为测试的系统中找不到预期的功能。
跟踪链接还可以帮助记录每个需求之间的父子关系、互连关系和依赖关系。当一个特定需求被删除或修改时，这些信息能够揭示可能引发的变更蔓延。
图：一些可能的需求跟踪链接
需求跟踪的动机
需求跟踪提供一种方式来说明产品是符合规范、合同或法规的。
随着系统开发和维护的进行，保持链接信息更新既需要纪律，也需要时间。
>发现遗漏的需求：查找未能跟踪到任何用户需求的业务需求，同时也能查找未能跟踪到任何功能需求的用户需求。
>发现不必要的需求：找出无法跟踪到任何用户需求或业务需求的功能需求，它们可能并不必要。
>认证与合规认证：跟踪信息说明合规要求所对应的需求都已经包含在内并得以妥善处理。
>变更影响分析：如果没有跟踪信息，在增加、删除或修改特定需求时，很有可能会忽略可能会受到影响的系统元素。
>维护：可靠的跟踪信息可以助力你在系统维护期间正确而完整地实现变更。
>项目跟踪：缺链接则表明工作产品尚未创建。
>重建：可以列举现有系统中准备换掉的功能并将它们跟踪到新系统的需求和软件组件中进行解决。
>复用：跟踪信息通过识别软件包中相关的需求、设计、代码和测试来促进产品组件的复用。
>测试：当测试失败时，测试、需求和代码之间的链接可以帮助开发人员定位到可能的代码区域检查缺陷。
将需求跟踪视为一种投资，将极有可能趁此机会交付一个可以满足所有确定客户需求的可维护的产品。
一边开发一边收集信息来建立跟踪数据不需要太多工作，但在已完成的系统上这样做既枯燥乏味又昂贵。
需求跟踪矩阵
代表需求和系统其他元素之间的链接，最常用的方式是使用需求可跟踪性矩阵（requirements traceability matrix，需求跟踪矩阵或跟踪表）。
表明每个功能需求如何向后链接到某个具体的用例，同时向前链接到一个或多个设计、代码和测试元素。
要在工作完成后而不是按照计划再填入信息。
重点提示：为每个需求列出测试用例并不是指软件已经通过了这些测试。它只是表明这些测试已经写好，可以在合适的时间用于验证需求。跟踪测试状态是另外一码事。
跟踪链接能够定义不同乐统元素之间的一对一、一对多或多对多的关系。
跟踪链应该由掌握合适信息的人来定义。
工作一完成就抓取跟踪信息，付出的额外成本很小，基本上是一种习惯和纪律，把存储方案建立起来即可。
陷阱：收集和管理需求追踪数据这一责任，必须明确到特定的个人，否则不会有人管。通常情况下，业务分析师或质量保障工程师会负责收集、存储并报告追踪信息。
表：跟踪链接信息的可能来源
| 链接源对象类型 | 链接目标对象类型 | 信息来源 |
| 系统需求 | 功能需求 | 系统工程师 |
| 用户需求 | 功能需求 | 业务分析师 |
| 业务需求 | 用户需求 | 业务分析师 |
| 功能需求 | 功能需求 | 业务分析师 |
| 功能需求 | 测试 | 测试人员 |
| 功能需求 | 架构元素 | 架构师或开发人员 |
| 功能需求 | 其他设计元素 | 设计师或开发人员 |
| 设计元素 | 代码 | 开发人员 |
| 业务规则 | 功能需求 | 业务分析师 |
需求跟踪过程
在具体项目中开始实现需求跟踪时，可以考虑如下几个步骤。
1.要求所有参与者做出责任承诺，从而负起责任。
2.选择自己想定义的链接关系
3.选择自己想用的跟踪矩阵类型
4.确定自己希望维持跟踪信息的产品部分。
5.确定将要提供每种链接信息的个人以及协调跟踪活动和管理数据的人员（通常是业务分析师）。
6.修改开发过程以提醒开发人员在实现需求或批准的变更后更新链接。
7.定义标签使用约定以保证每个系统元素都有一个唯一的标识。
8.每个参与者在完成一小块儿工作后提供要求他们收集的跟踪信息。重点强调持续积累跟踪数据比在重要里程碑或项目结束时批量收集数据的优势。
9.定期审计跟踪信息以确保其保持最新。
发表回复