白皮书 需求工程最佳实践 2015 年 7 月 作者：Kevin Parker， Serena Software（现隶属 Micro Focus®）全球营销副总裁 目录 页码 需求是否仍是“一件事情”？ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 需求是流程 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 管理需求的最佳实践 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 需求的重要属性管理解决方案 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 摘要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 在单个组织内，一个团 队可能需要需求尽善尽 美以及利益相关者的详 细审查，而其他团队可 能从简单想法开始，然 后进行迭代并设计原 型，直至了解程度足以 开始构建解决方案。 需求是否仍是“一件事情”？ 需求用于定义企业为实现其目标而需要或想要的一项（仅此一项）原子级行为。需求 必须可以采用可衡量方式测试。需求必须完整，包含所有必要信息。需求不得与任何 其他需求矛盾，并且必须遵守法律标准。需求必须至少具有一名利益相关者、至少一 名发起人且至少让一名用户受益。 需求用于定义对于企业至关重要的属性 定义直观明了。用于收集和管理需求的方法其范围跨度比任何其他应用程序生命周期 管理 (ALM) 准则都要大。由于产品范围、应用程序复杂性或团队规模和分布，一些 差异源于给定项目所需的特异性级别。在单个组织内，一个团队可能需要需求尽善尽 美以及利益相关者的详细审查，而其他团队可能从简单想法开始，然后进行迭代并设 计原型，直至了解程度足以开始构建解决方案。 IEEE 将需求定义为“...系统（或系统组件）必须满足条件或功能，以便符合合约、 标准、规格或其他正式规定的约束...” 需求工程方面的最重要权威 Karl Wiegers1 将需求的定义简化为产品必须具备的属 性，以便向利益相关者提供价值。软件开发生命周期 (SDLC)2 中的所有工作都始于 想法。这种想法可能是要开发的新系统、现有系统的改进请求，也可能是需要修复未 按预期运行的功能。 __________ 1 www.karlwiegers.com 和 http://en.wikipedia. org/wiki/Karl_Wiegers 2 软件开发生命周期，请参 阅：http://en.wikipedia. org/wiki/Software_ development_process www.microfocus.com 我们将这些称为新系统、增强功能和修复。我们会将这些开发工作进行分类、排定优 先级并组织为发布、版本和补丁。 全新功能 — 新系统或现有系统的新功能，这些通常是组织中的较大型项目，因此 也最昂贵。这些项目的后续融资也更难以获得。估测、规划和执行更加困难，因为 我们将应对许多未知事情。 示例：添加功能以在移动设备上显示产品目录。 1 白皮书 需求工程最佳实践 增强功能 — 现有代码的改进，这是增量工作，因此成本较低、风险较低且融资通 常可较轻松获得。这些可以是短期项目，也可以是长期项目。它们的估测和成本核 算更加轻松，因为它们是已知问题并且拥有解决方案。 打造卓越需求的十大 最佳实践： 示例：让产品目录显示欧元、英镑、日元和美元价格。 1. 使用原型和模拟，而 修复 — 通常是不添加新功能，只是现有代码的小更改，修复会更改当前功能的行 为，以满足企业预期。大多数修复用于解决错误的且会给企业带来损失的行为，但 有时会修改行为来提高性能或速度。 示例：结账时仅针对国内销售添加税费，而不是针对全球所有销售。 接纳想法并将其转变为解决方案就是 ALM 所做的一切。实现此目标就是一段旅程。 事实上，第一时间获取想法不是小任务。 非编写的定义。 2. 与尽可能多的利益相 关者分享想法并获取 反馈。 3. 使用游戏化方法获取 平衡反馈。 4. 每项需求都应可测试。 5. 每项需求都应与一件 需求是流程 事情相关。 6. 维护可追溯性，从请 求到需求再到实施。 定义需求问题可能需要数分钟或数月。这取决于许多因素。下面只是定义需求问题时 组织会考虑的部分因素： 监管和合规性控制 数据的安全性和完整性 访问和鉴定 上市时间 商业解决方案的可用性 技术复杂性 投资回报率 项目计划中断 资源的可用性 融资 性能需要 国际化需要 所有这些都发生在前面，之后我们才会问：“您到底想要这项技术做些什么？” 2 7. 使用故事板、使用案 例、伪代码或提供清 晰含义的任何内容。 8. 测试所有需求，了解 其对现有和将来功能 的影响。 9. 根据业务优先级不断 重新确定优先级。 10. 对需求和文档更改进 行版本控制。 构思是更现代的概念， 在许多组织中未正式 规定。 步骤 1 — 构思和需求捕获：针对不同类型的请求和不同的系统同时使用多个票据 系统很常见。一些系统是自助式系统，而其他系统需要电子邮件或拨打电话。通 常，Microsoft Excel 是这些请求的储存库。大多数组织具有向企业收集想法的方 法，通常通过某种“票据”系统完成，通常称为“更改请求系统”（或 CR 系统）。 这些系统通常由咨询台（又称服务台）托管和管理。 此流程的一个重要元素是以一致且可跟踪的方式收集想法。构思是更现代的概念，在 许多组织中未正式规定。在部分企业中，这涉及变更控制审查委员会 (CCRB) 或变更 咨询委员会 (CAB) 和其他许多类似称呼。通常，MS Excel 是记录系统，这使得协作 性和可见性很难。 步骤 2 — 变更管理：这是进行想法分类的阶段，以便最重要的想法、时间关键型想 法和管理关键型想法获得最高优先级。想法将经过可行性研究、融资、资源分配和日 程安排流程，之后才是开发审批。在业务影响严重时，部分紧迫且紧急的请求将立即 获批。 这有时称为需求管理，是 IT 驱动的较新现象，会更多考虑花费的费用。需求管理的 目的是确保 IT 从事的项目是符合业务优先级的项目。通常，CIO 将谈论“保持一 致”或“让 IT 与业务保持一致”：他们谈论时，实际上是表明需要确保任务关键型 合规项目是最快先实施的项目。审查委员会可能会监督此流程并设定优先级、目标、 甚至预算。 步骤 3 — 需求引出：这涉及从利益相关者和其他来源收集和记录需求。有多种方法 可供使用，包括采访、文档分析、小组讨论、研讨会，较新的方法是原型设计、模拟 和游戏化。迭代原型设计在定义需求时使用的时间比采访和再次采访业务用户所需的 时间短。 www.microfocus.com 3 白皮书 需求工程最佳实践 步骤 4 — 需求验证：这是确认需求集满足业务需要和目标。此步骤旨在确保收集的 信息足以构建所需的解决方案，以及信息遵守组织约束，如合规和管理标准。 通常，需求定义的失败是因为英语语言太不精确，无法反映业务需要的细微细节。开 发使用案例3 和使用“统一建模语言”(UML)4 等正式方法有助于精确定义解决方案 的确切预期行为。这些工具可在开发生命周期后面帮助开发测试案例，而这些案例构 成了根据需求验证实施的基础。 步骤 5 — 需求管理：通常，此活动遵循非常正式的程序，在此流程中将进行需求改 善、版本控制、跟踪、监视、优先级确定、分配，总之就是管理。这些活动包括： 需求的持续优化，因为收集的数据、输入和想法越来越多 需求排序和优先化，具体取决于业务输入 将各个需求划分到相应工作范围 将需求组织为不同的组，这些组形成开发团队将要完成的合理工作块和发布 在 Agile 组织中，遵循 的流程几乎相同，只是 执行较传统需求功能活 动的时间内会有更多 迭代。 Agile 团队的关键人员是 产品拥有者，其工作是 充当业务和开发团队之 间的联络人。 产品拥有者为开发团队 收集需求，并且进行排 序和确定优先级。产品 拥有者执行业务分类， 从而帮助企业专注于 询问什么最重要。 随着业务需要的优化，跟踪需求的更改、更新和修改 可追溯性维护，确保从请求到实施可进行审计追踪 监视针对项目融资所实施的需求的批准 需求之间的关系和依赖性的维护 需求管理流程对于应用程序开发最佳实践至关重要。不了解应该开发的需求，满足业 务需要的可能性就几乎为零。不管如何定义需求术语，不论贵组织发现自己在方法范 围中处于什么位置，都必须在开始构建前了解客户（或潜在客户）的期望。开发阶段 可解决“如何”，但必须在融资获批前了解“什么”。 4 Agile 团队未设计原型。 他们将尽快生成工作 代码。 __________ 3 http://en.wikipedia.org/ wiki/Use_case 4 http://en.wikipedia.org/ wiki/Unified_Modeling_ Language 项目可通过叙事（需求 集合）和案例（需求） 管理，而叙事和案例共 同组成要完成的工作的 冲刺待办事项（分配给 开发人员的尚未完成的 需求）。 管理需求的最佳实践 预计需求每月会变化 1%-5%。— 来源 Gartner “需求管理的最佳实践是将针对配置管理而定义的最佳实践应用于需求管理。” —Kay Fuhrmann，Serena Software（现隶属 Micro Focus）产品经理 1. 命名约定。定义和维护用于识别发布的约定，从批准的需求集到基线发布再到紧急 进度可通过燃尽图（完 成的需求）跟踪，其中 显示当前冲刺的结束进 度。Agile 的主要原则是 自组织，而每日立会让 每个人都在项目内保持 同步。 修复或补丁。 2. 基线要求。软件发布等需求必须确定基线，而且这些基线必须直接映射到它们生成 的发布。 3. 变更控制流程具有明确的定义且被很好地理解。创建基线后，必须控制、跟踪、追 踪、审批和审查更改。 4. 需求审查。必须存在需求审查流程，而且必须强制实施。 5. 更改预期。确保可以轻松进行更改，但遵守严格的访问控制规则，而且完全可