CMMI模型解读-需求管理
2025-06-05 18:24:58 0 举报AI智能生成
CMMI模型强调了需求管理的核心过程领域，其中包括需求的收集、分析、记录、维护和追踪等关键活动。通过有效的需求管理，可以降低项目开发中的不确定性和风险，提高软件开发的效率和质量。 需求管理的核心内容包括确保需求的质量、完整性和有效性，同时维持需求在项目整个生命周期内的可追溯性，以便项目的每个阶段都能准确反映用户和利益相关者的要求。这个过程确保项目团队充分理解客户的需求，并将这些需求转化为具体、可实施的设计与产品。
作者其他创作
大纲/内容
项目失败与需求有关的原因
不完整的需求
缺乏用户的介入
不实际的客户期望
需求和规范的变更
提供了不再需要的功能
目的
确保客户的需求和期望得到满足
第1级
1.1 记录需求
传统：输入-处理-输出、用例描述
敏捷：用户故事
第2级
2.1 引导干系人的需要、期望、约束和接口
引导方法
头脑风暴、访谈、原型、现场观摩、问卷调查、用户需求地图
干系人
识别干系人的维度
客户、最终用户、间接用户
间接用户，如监管机构
高层、中层、底层
高层：目标需求，系统要解决的问题、痛点、系统的业务目标
中层：业务层需求，系统要覆盖的业务
底层：操作层需求
内部客户、外部客户
干系人识别不全会导致遗漏需求
需求类别
需要
必须的需求
期望
非必要的需求，对客户来说最好能实现，越多越好，可以裁剪的。
约束
技术、管理、商务、环境的限制条件：如法律法规，政策要求
较容易忽略的需求
接口
系统与其他系统、其他设备的连接
2.2 将干系人的需要、期望、约束、接口或连接转化为排列了优先级的客户需求
价值：确保解决客户的优先问题，以尽量减少验收过程中的返工成本，并最大限度提高客户满意度
优先级划分方法
卡诺模型
按需求实现程度的高低及客户满意程度的高低
必备的需求
如果不能满足这种需求，客户会非常不满意
如在线聊天工具，必备的需求有“在线实时聊天”和“好友列表管理”
期望的需求
如果这类需求得到满足或表现良好，那么可以使产品变得更加优秀，用户的满意度也会显著增加；反之，客户不满也会增加。
如“发送表情包”
用户反馈给我们的需求大部分都是期望的需求
兴奋型需求
用户的潜在需求，需求的满足可以给用户带来极大的惊喜
如“语音识别输入”
卡诺模型中每个需求的类型都不是静态的
如“发送表情包”，当所有实时聊天工具都有这个功能以后，它已经变成了“必备的需求”
百分制法
多人评分，每人100分，按自己理解的需求重要程度分配这100分，然后计算每个需求的得分，从高到低排序
投入产出法
让客户对每个需求的价值进行评分，开发团队对每个需求的成本进行评分，二者相除得到投入产出比，从高到低排序
2.3 与需求提供者就需求的含义达成一致的理解
价值：有助于确保交付正确的项目交付物
解释：甲方和乙方理解一致（外部一致），尽可能的消除模糊性
常见方法
需求交底
需求人员讲解需求
需求评审
原型评审
2.4 从项目的参与者处获得他们对需求可实现的承诺
解释：内部理解一致，是需求实现方对需求提供者的承诺
从技术上和工期上都是可以实现的
常见方法
需求交底
需求人员讲解需求
需求反讲
开发、测试给需求人员讲需求，需求人员纠正理解误差。
2.5 建立、记录、维护需求与活动、工作产品之间的双向可跟踪性
价值：确保需求与项目交付物的一致性
目标
所有的需求都分配到人了
所有的需求都被设计了
所有的需求都被实现了
所有的需求都被测试了
接口需求、非功能需求是最容易被忽略要跟踪的需求
敏捷场景：看板
2.6 确保计划、活动和工作产品与需求保持一致
价值：消除需求和相关工作产品的不一致，来最大限度减少返工
通过各类评审、测试、确认活动确保设计、代码、测试用例、项目计划与需求的一致。
如测试用例是否100%覆盖需求
识别因需求而应对计划和项目作出的变更。
第3级
3.1 根据组织级的流程，开发和保持更新解决方案和其构建需求
需求文档：需求的详细定义
需求变更时要执行影响分析、评审
对管理的影响：对规模、工期、工作量、成本的影响，存在的风险
对技术的影响：对设计、开发、测试以及其他需求的影响
对人员的影响：该变更影响到了谁的工作，需要谁参与进来，需要知会谁。
3.2 定义操作概念和场景
操作概念：对用户在不同场景下如何使用产品的全局描述
操作场景：各种正常、异常的业务操作路径
3.3 分配待实现的需求
客户提的完整需求分配到各个子系统，各个模块上
如水杯容量达到350ml， 350ml容量的需求会分配给杯筒；杯子要能耐高温，耐高温的需求分配给杯盖和杯筒。
3.4 识别、定义、保持更新接口与连接需求
包含外部和内部接口需求，侧重点在内部接口
外部接口需求是在需求获取时获得
内部接口是分配了待实现需求后产生的
如分了杯盖和杯桶，就产生了两者的接口
3.5 确保需求是必要的和充分的
必要的：没有多余的需求
充分的：没有遗漏的需求
需求调研做加法，尽可能挖掘和收集需求；分析需求，做减法，弄清楚可以不做什么，少做什么。
实践案例：最简化可实行产品，快速开发最少的而必须的功能并发布出去，到市场上验证，获得反馈迭代优化。
3.6 平衡干系人的需要和约束
多快好省的平衡：需求=>多，进度=>快，质量=>好，成本=>省
平衡的方法
采用优先级矩阵进行需求平衡
对号称紧急的需求，需要阐述不实现或者延迟实现的后果
对已上线的需求，跟踪实际使用情况，作为后续平衡的依据
3.7 确认需求以确保最终的解决方案可以在目标环境中运行
让客户参与需求评审，demo演示，让客户试运行，让客户持续参与到项目中
0 条评论
下一页
