ISO 20000体系：需求管理与容量管理含义与解释

原创已于 2025-05-27 11:05:49 修改 · 1.2k 阅读

15 ·

CC 4.0 BY-SA版权

文章标签：

#学习方法

于 2025-05-25 21:53:14 首次发布

质量体系专栏收录该内容

6 篇文章

订阅专栏

文章目录

一、前言
二、需求管理
三、容量管理
四、参考文档

一、前言

需求管理和容量管理是ISO 20000体系8.4供应与需求章节中的重要内容，本文将针对这两部分的内容浅析含义和解释，并提供案例用于辅助理解。

二、需求管理

需求管理（Requirement Management）是 ISO 20000 IT服务管理体系中的核心流程之一，其核心目标是准确捕捉、记录、跟踪和实现用户与业务的需求，确保IT服务的设计、交付和改进始终围绕业务目标展开。它的本质是在用户期望与IT能力之间建立桥梁，避免“开发出来的功能不是用户想要的”或“业务需求被技术实现带偏”。

2.1 需求管理是什么？

定义：
需求管理是通过系统化的方法，从业务方或用户处收集、分析、优先级排序、记录和验证需求，并确保这些需求在服务设计、开发、交付和维护过程中被完整实现和跟踪。
核心输出：需求文档（如《用户需求说明书》《功能规格书》）。

类比：就像建筑施工前的“设计蓝图”——明确房子要建几层、房间布局、材料标准等，施工时按图作业，避免返工。

关键要素：

需求收集：通过访谈、问卷、工作坊等方式获取用户需求。
需求分析：筛选合理需求，排除冲突或不可行的部分（如用户要求“系统响应时间≤1秒”，但现有技术无法实现）。
需求优先级：按业务价值、紧急程度排序（如核心功能优先于优化项）。
需求跟踪：确保需求在开发、测试、上线各阶段被落实。

2.2 为什么需要需求管理？

对齐业务与IT目标：
避免IT部门“自娱自乐”，确保服务真正解决业务痛点（例如业务方需要提升订单处理效率，而非仅仅开发一个复杂报表）。
减少资源浪费：
避免开发错误功能或重复功能（如用户需要A功能，IT误开发了功能B）。
控制变更风险：
需求变更是引发项目延期或失败的常见原因，需求管理通过流程化变更控制降低风险。
提升用户满意度：
通过透明化需求实现过程，增强用户信任（如定期向用户汇报需求进展）。

2.3 需求管理的关键流程

（1）. 需求收集与分析
常用方法：

用户访谈：直接与业务方沟通，挖掘真实需求（例如用户抱怨“系统慢”，实际可能是网络延迟而非代码问题）。
原型设计：用低保真原型（如线框图）快速验证需求理解是否一致。

示例：业务方提出“需要移动端报表功能”，需求分析发现真实需求是“随时随地查看实时数据”，进而设计为数据同步功能而非单纯报表。

（2）. 需求优先级排序
常用方法：

MoSCoW法则：Must have（必须实现）、Should have（应该实现）、Could have（可以实现）、Won’t have（暂不实现）。
成本收益比：评估需求开发成本与预期收益（如修复高危漏洞优先级高于界面美化）。

示例：某电商平台在版本规划中，将“支付系统安全加固”列为Must have，“商品推荐算法优化”列为Should have。

（3）. 需求跟踪与验证

工具：使用需求管理工具（如JIRA、TFS）跟踪需求状态（待办、开发中、已测试、已上线）。
验证方法：
- 用户验收测试（UAT）：由业务方代表参与测试，确认需求是否满足。
- 需求追溯矩阵：建立需求与设计、代码、测试用例的映射关系，确保无遗漏。

示例：某系统上线前，业务方通过UAT确认“批量导入数据”功能符合需求文档中的格式要求。

2.4 需求管理与其他流程的关系

关联流程	协同作用
服务设计	需求管理为服务设计提供输入，确保设计方案覆盖所有需求。
变更管理	需求变更需通过变更管理流程评估风险并批准（如新增功能需走变更审批）。
服务验证与测试	测试用例需基于需求文档编写，验证服务是否满足需求。
持续改进	通过需求回顾（如用户反馈）发现服务改进点，驱动下一轮需求收集。

2.5 实际案例

案例1：银行系统需求管理

背景：某银行要求升级网上银行系统，业务方提出“支持指纹登录”。
需求管理过程：

收集：访谈发现用户真实需求是“提升登录安全性”，指纹登录只是候选方案。
分析：技术团队评估指纹登录需硬件支持，成本过高，建议改用动态口令。
优先级：动态口令列为Must have，指纹登录列为Could have（后续版本实现）。
验证：UAT阶段用户确认动态口令满足安全需求。
效果：项目按时交付，用户满意度提升。

案例2：需求蔓延导致项目失败

反面案例：某公司开发内部管理系统时，业务方不断新增需求（如从“基础审批流程”扩展到“预算分析模块”），导致项目延期超支。
根本原因：缺乏需求优先级排序和变更控制流程。
改进措施：

引入需求管理工具，冻结范围外的需求。
按季度评审需求优先级，分阶段交付。

2.6 ISO 20000对需求管理的要求

文档化：需求需形成正式文档，经业务方签字确认。
用户参与：需求收集和分析需业务方代表全程参与。
变更控制：需求变更需记录原因、影响范围，并经审批。
可追溯性：确保需求从提出到实现全程可跟踪。

2.7小结

需求管理就是给IT开发“定方向”——明确用户想要什么、什么最重要，并确保开发过程不偏离目标。就像导航软件——输入目的地（需求），规划最优路线（开发路径），途中实时调整（变更控制），最终准确抵达（交付验收）。

三、容量管理

容量管理（Capacity Management）是 ISO 20000 IT服务管理体系中的核心流程之一，其核心目标是确保IT基础设施的资源（如服务器、网络、存储等）能够以合理的成本，持续满足当前和未来的业务需求。它的本质是在资源供给与业务需求之间找到平衡，避免因资源不足导致服务中断，或资源过剩造成浪费。

3.1 容量管理是什么？

定义：
容量管理是通过规划、监控和调整IT资源，确保其性能、可用性和扩展性能够支持服务级别协议（SLA）的达成，并适应业务增长或变化。
核心输出：容量计划（Capacity Plan）、资源优化建议、性能报告。

类比：就像高速公路的交通管理——根据车流量预测和实时监控，动态调整车道数量或限速标志，确保道路畅通且不浪费资源。

关键要素：

容量规划：预测未来资源需求（如服务器扩容时间点）。
性能监控：实时跟踪资源使用率（如CPU、内存、磁盘I/O）。
需求分析：将业务目标转化为技术资源需求（如用户增长需增加服务器数量）。
资源优化：调整资源配置以降低成本（如虚拟化整合服务器）。

3.2 为什么需要容量管理？

避免服务中断：
防止资源不足导致的系统崩溃（例如电商大促期间流量激增，未扩容服务器导致宕机）。
控制成本：
避免过度采购硬件或云资源（如预留10倍算力但实际仅用20%）。
支持业务增长：
确保IT资源能弹性扩展以适应业务扩张（如新市场上线需快速部署资源）。
优化性能：
通过调整资源配置提升用户体验（如数据库查询速度慢时增加缓存节点）。

3.3 容量管理的核心流程

（1）容量规划
步骤：

需求预测：基于历史数据、业务计划和行业趋势，预测未来资源需求（如用户量增长30%需扩容服务器）。
场景建模：模拟不同业务场景下的资源需求（如峰值流量、故障切换）。
制定计划：明确资源采购、部署时间表和预算。

示例：某视频平台预计世界杯期间流量增长5倍，提前租用云服务器弹性扩容。

（2）性能监控与分析
工具：使用监控系统（如Prometheus、Zabbix）实时跟踪资源使用率。
关键指标：

利用率：CPU使用率、内存占用率、存储IOPS。
性能阈值：设定资源使用上限（如CPU超过80%触发告警）。

示例：发现某数据库服务器磁盘写入速度接近瓶颈，提前升级为SSD。

（3）容量调整与优化
方法：

垂直扩展：升级单台服务器配置（如增加内存）。
水平扩展：增加服务器数量（如部署负载均衡集群）。
资源回收：释放闲置资源（如删除未使用的虚拟机）。

示例：将物理服务器迁移至云平台，按需启停实例以节省成本。

（4）定期评审与改进
频率：每季度或半年一次。
内容：

分析容量计划执行情况（如预测偏差是否需调整模型）。
优化监控策略（如新增关键指标）。

3.4 容量管理与其他流程的关系

关联流程	协同作用
服务级别管理（SLM）	容量管理确保资源能支持SLA中的性能指标（如可用性≥99.9%）。
变更管理	容量扩容或技术升级需通过变更管理流程审批和执行。
财务管理	容量规划需考虑成本效益，避免超支（如云资源按需付费 vs 预留包年包月）。
事件管理	容量不足引发的故障（如服务响应缓慢）需快速定位并扩容。