需求管理 PPT
合集下载
需求管理流程ppt课件
“软件需求可定义为： 用户解决某一问题或达到某 一目标所需的软件功能。系统或系统构件为了满足合同、 规约、标准或其他正式实行的文档而必须满足或具备的 软件功能。”
2
为 什 么 要 进 行 需 求 管 理?
评测和验证有效的软件开发流程标准得到了推广 和普及 为什么现在仍然频繁发生的软件项目失败的事件？ 为什么仍有那么多的项目受到延期、预算超支和 质量问题的困扰？ 如何才能提高系统的质量？
不接受
接受
小问题 自行解决
变更影响分析报告
修改SRS
修改开发计划
修改其它相关文档
17
需
• 一、职能：
求 管
• 评审——需求分析及讨论 • 跟踪——需求修改进度 • 监督——需求整改质量保证
理
委
• 二、会议制度：
员
• 每周定期召开需求管理会议
会
18
• 产品研发步骤：
• 一、产品需求文档：
职
• 二、讨论（发散思维），排列出优先等级
提供一种机制，以分析需求、评估可行性、协商
是 合理的解决方案、无歧义地规约解决方案、确认规约
需 以及在开发过程中管理这些被确认的需求规约。包括6
求 个步骤：
管
获取（需求诱导）
理？ 分析（需求分析和谈判）
规定（规约）
系统建模
验证（需求确认）
需求管理（控制与变更管理）
5
需
1. 需求不总是显而易见的，它可来自各个方面。
管
• 变更过程管理：确定一个选择、分析和决策需求变更的
理
过程
的
• 需求跟踪：定义需求之间的关系及需求和设计之间的关
规
系，记录并维护这些关系
2
为 什 么 要 进 行 需 求 管 理?
评测和验证有效的软件开发流程标准得到了推广 和普及 为什么现在仍然频繁发生的软件项目失败的事件？ 为什么仍有那么多的项目受到延期、预算超支和 质量问题的困扰？ 如何才能提高系统的质量？
不接受
接受
小问题 自行解决
变更影响分析报告
修改SRS
修改开发计划
修改其它相关文档
17
需
• 一、职能：
求 管
• 评审——需求分析及讨论 • 跟踪——需求修改进度 • 监督——需求整改质量保证
理
委
• 二、会议制度：
员
• 每周定期召开需求管理会议
会
18
• 产品研发步骤：
• 一、产品需求文档：
职
• 二、讨论（发散思维），排列出优先等级
提供一种机制，以分析需求、评估可行性、协商
是 合理的解决方案、无歧义地规约解决方案、确认规约
需 以及在开发过程中管理这些被确认的需求规约。包括6
求 个步骤：
管
获取（需求诱导）
理？ 分析（需求分析和谈判）
规定（规约）
系统建模
验证（需求确认）
需求管理（控制与变更管理）
5
需
1. 需求不总是显而易见的，它可来自各个方面。
管
• 变更过程管理：确定一个选择、分析和决策需求变更的
理
过程
的
• 需求跟踪：定义需求之间的关系及需求和设计之间的关
规
系，记录并维护这些关系
第4课 需求管理
市场调查：一种系统、规范和有意识的
了解和确定客户观点和意向的方法。 历史类比方法：将新产品与同类产品的 市场导入及成长进行比较分析，希望新 产品也走同样的路 德尔菲 (Delphi) 法：组织一些专家对可能 发生什么发表各自的意见和看法
9
定量预测技术
过去的需求是未来需求的好的指标 依赖于数学公式分析历史的需求模式预
11
内部预测技术
应用公司内部的历史数据进行预测 基本假设是，过去发生的将来还会发生
12
移动平均法
设1至10周的销售量是50，60，73，36
，40，48，55，70，69，30， 10周的销售总量是540，平均值是54， 即作为第11周的预测值。 去掉第1周的销售量，添上第11周的销售 量，计算出新的平均值，作为第12周的 预测值。
时间宽松的预测消耗
FCST CD
跨入下一时段
时间宽松的预测消耗
FCST CD
跨入下一时段
时间宽松的预测消耗
Today
ST CD
转入下一时段
6
预测的特征
预测通常都会出错 每个预测都应该包含一定的误差估计 对产品族的预测比对单项产品的预测更
准确 时间越近，预测越准确
7
预测技术
定性预测技术 定量预测技术 外部预测技术 内部预测技术 定性预测和定量预测既可以基于内部信
息，也可以基于外部信息
8
定性预测技术
13
指数平滑法
Ft+1=αVt+(1-α)Ft
α(o<α<1)
称为平滑因子
Ft+1=αVt+α(1-α)Vt-1+α(1-α) 2 Vt-2+ ...
了解和确定客户观点和意向的方法。 历史类比方法：将新产品与同类产品的 市场导入及成长进行比较分析，希望新 产品也走同样的路 德尔菲 (Delphi) 法：组织一些专家对可能 发生什么发表各自的意见和看法
9
定量预测技术
过去的需求是未来需求的好的指标 依赖于数学公式分析历史的需求模式预
11
内部预测技术
应用公司内部的历史数据进行预测 基本假设是，过去发生的将来还会发生
12
移动平均法
设1至10周的销售量是50，60，73，36
，40，48，55，70，69，30， 10周的销售总量是540，平均值是54， 即作为第11周的预测值。 去掉第1周的销售量，添上第11周的销售 量，计算出新的平均值，作为第12周的 预测值。
时间宽松的预测消耗
FCST CD
跨入下一时段
时间宽松的预测消耗
FCST CD
跨入下一时段
时间宽松的预测消耗
Today
ST CD
转入下一时段
6
预测的特征
预测通常都会出错 每个预测都应该包含一定的误差估计 对产品族的预测比对单项产品的预测更
准确 时间越近，预测越准确
7
预测技术
定性预测技术 定量预测技术 外部预测技术 内部预测技术 定性预测和定量预测既可以基于内部信
息，也可以基于外部信息
8
定性预测技术
13
指数平滑法
Ft+1=αVt+(1-α)Ft
α(o<α<1)
称为平滑因子
Ft+1=αVt+α(1-α)Vt-1+α(1-α) 2 Vt-2+ ...
《需求管理》PPT课件
销售部门根据客户的售出清单开具委托代销结算单。企业
根据审核后的结算单，开具销售发票并进行销售出库处理
及结转销售成本。
代销商按照企业开据的销售发票付款。
代销商可以将有质量问题的产品或未销售出去的产品，退
回本企业，并完成退货入整理库pp处t 理。
10
案例:红罐王老吉品牌定位战略
整理ppt
11
ERP 内部集成应用
需求类型 分销需求 销售合同
需求预测 其它
需求响应策略
备注
现货生产(MTS) 定单组装（ATO）
补库定单、分销合同、 预测
定货生产(MTO) 定单组装(ATO) 定单设计(ETO)
合同（计划）的对象是 最终产品
现货生产(MTS) 定货生产(MTO) 定单组装(ATO)
预测对象：产品 原材料
基本组件和可选件
整理ppt
5
ERP 内部集成应用
销售管理业务类型
•普通销售业务——完成响应客户的询价、签订销售订单、完
成销售出库、开据销售发票等工作
•直运销售业务——指企业与客户签订销售订单后，确定企业
的供应商。企业与供应商签订采购订单后，供应商将商品直 接发给企业的客户，企业无需实物的出入库即可完成购销售 业务。
备品备件、试验品、破 坏性试验品等
整理ppt
3
ERP 内部集成应用
•分析广告宣传的效果：
ห้องสมุดไป่ตู้
创
——广告宣传投入与销售收入增长的关系
造
——寻求最有效的广告宣传形式
需 •促销规则：
求
——折扣规则（按金额、数量、品种、客户）
——折让规则（回款时间）
——商品在商场摆放位置对经销商实行优惠策略
需求管理规范流程课件(PPT 44张)
©2008 BOCO Inter-Telecom Co. All rights reserved.
KANO模型
客户满意度 最好满足的需求 兴奋需求 很好的执行 很差的执行 基本需求
Kano模式
客户不满意度
©2008 BOCO Inter-Telecom Co. All rights reserved.
★ ★ ★
★
现场支持
售后反馈
©2008 BOCO Inter-Telecom Co. All rights reserved.
★
★
★
★
需求整理和分析过程
So urces Qu estio ns Statemen ts Key Check Ch eck Key Ch eck Check Key Ch eck Ch eck 1 2 3 4
系统能够进行高品质 地光盘刻录
数据传输快
抗干扰性强 传输速率快 传输方式多
缓存内存容量大 烧盘概率小
刻写过程稳定
©2008 BOCO Inter-Telecom Co. All rights reserved.
识别冲突（冲突矩阵法）
优化方向
需求1 需求1 需求2
需求2
需求3
需求4
++
©2008 BOCO Inter-Telecom Co. All rights reserved.
需求收集的方法
效果
方法
短期
用户大会 专家顾问团 需求探针
★
时间范围 中期
★ ★
产品范围 长期
★ ★ ★
当前
未来
★ ★
直接
★ ★ ★ ★ ★
★
★
[新版]华为的需求管理.pptx
![[新版]华为的需求管理.pptx](https://img.taocdn.com/s3/m/89b75210e53a580217fcfe39.png)
服务
核心
产品
售前
功能
售中 售后
体 验
性能 包装
可获 得性
口 碑
价格
发货
品 牌
保修
建议
企
业
客户需求不仅仅是软硬件，而是一个完整的交付！
形
象
如苹果、三星产品
Document NO.:
© Rosary Consultant 2008
22
什么是产品包？
核心产品 服务 无形效益
Document NO.:
© Rosary Consultant 2008
产品包需求要分层描述，必须包括客户问题、系统特性、系统需求及其 各层之间的跟踪关系
问题problem
描述市场机会， 包括客户面对的
挑战与机会
1. 屏幕太小 2. 已有大量大屏手机上市
1. 提供比以前版本更大
产
特性Feature
阐述产品为解决客 户问题需要支持什
么能力
的显示面积，同时： 2. 不增加重量，不减少
软件分配需求
1111
基于Feature-Function的设计方法原理
feature1
feature2
FunctionA1 FunctionA2 FunctionA3
FunctionB1 FunctionB2 FunctionB3
Document NO.:
© Rosary Consultant 2008
需求实现阶段
从客户需求到最终研发完成，需求会不断转化和分解，如 特性需求到功能需求的转化，从对问题的描述转化为对解 决方案的描述，然后逐层展开分解，这就需要需求的跟踪 和变更控制。对于大型项目，需求可以按子系统来进行分 类，如飞机的需求包括飞机总成的需求，发动机的需求， 通讯系统的需求，控制系统的需求。
需求管理与采购计划课件
（2）一个上属项对构成它的下属子工页的数量
要求。 BOM 给出了每个子项在其父项中的需要
量。
•需求管理与采购计划
•19
2．低位码
所谓低位码是指某个物料在所有产品结构树中所 处的最低层数，因此可以通过零部件所在产品结构树 中的层次来决定它的低位码。
一个物品只能有一个低位码，当一个物品在多个
产品中所处的产品结构层次不同或即使处于同一产品
计算毛需求
逐 层
计算净需求
逐
项
处 理
净 需 求 ＞ 0？
否
各
个
项
目
生成订单计划
下达订单计划
是
还处理其他项目？
•需求管理与采购计划
结束
•26
2．MRP中每个项目的计算步骤
具体计算如下： （1）计算物料毛需求量。
考虑相关需求和低位码推算计划期全部的毛需求。 项目毛需求量＝项目独立需求＋父项的相关需求 其中 父项的相关需求＝父项的计划订单数量×项目用量因子 （2）推算PAB初值。 考虑毛需求推算特定时段的预计库存量。 PAB初值＝上期末预计可用库存量＋计划接收量－毛需求量 （3）计算净需求量。考虑安全库存推算特定时段的净需求量。 当PAB初值≥安全库存时，净需求＝0 当PAB初值＜安全库存•需时求管，理与采净购计需划 求＝安全库存－PAB初值•27
1．BOM与产品结构树
一个BOM文件，至少应包括3个数据项：物料 标识（或物料编码）、需求量（每一个父项所需 该子项的数量）、层次码（该物料在结构表中相 对于最终产品的位置）。
•需求管理与采购计划
•18
在BOM中，可以得到的信息是：
（1）一个上属项 ( 产品、部件、组件等 ) 是由 哪些下属项 ( 原材料、坯料、零件等 ) 所组成的。 同理，也可以说明某个下属项应用于哪些上属项。 上属项为父项，下属项为子项。
需求管理流程教材(PPT 31页)
U需T求-S管C-理MB、-0需01求-20变08更—管—理、模工板程档变案更使用控指制引流程
7
需求的重要性
权威统计表明，软件开发，40%--60%的问题都是在需求 阶段埋下的。
未确定或不明确的需求 未发现或未经交流的假设 不完善的需求描述 需求变更管理不恰当
U需T求-S管C-理MB、-0需01求-20变08更—管—理、模工板程档变案更使用控指制引流程
U需T求-S管C-理MB、-0需01求-20变08更—管—理、模工板程档变案更使用控指制引流程
25
U需T求-S管C-理MB、-0需01求-20变08更—管—理、模工板程档变案更使用控指制引流程
26
目的、范围
目的
规范工程变更的提出、沟通、评审、开发、跟踪、验证等，确保 与客户定制需求的一致性。
15
流程
需求管理流程（第1页 共2页）
001
外部客户
销售人员 工程人员 技术人员
提出需求
产品规划工程师
市场需求清单
战略与规划部经理
产品构想模版
技术委员会
潜在项目负责人 产品经理 研发副总
002
接收需求、 沟通与完善
需求
003
组织评估需求 实现优先级
产品副总
IPMT
IPMT主席 多项目管理专员 营销工程部经理
需求管理流程 需求变更管理流程 工程变更控制流程
为电力自动化领域提供最佳解决方案
目录
项目与需求 需求管理程序 需求变更管理程序 工程变更控制程序
U需T求-S管C-理MB、-0需01求-20变08更—管—理、模工板程档变案更使用控指制引流程
2
项目与项目管理
需求和技术解决方案PPT课件
➢需求跟踪矩阵：是需求跟踪链的具体化，能够反映需求 文档和后续工作成果（包括概要设计文档、测试需求等） 的对应关系。
➢需求跟踪矩阵分为： 纵向跟踪矩阵，包括：需求之间的派生关系（客户 需求到产品需求）、实现与验证关系（需求到设计， 需求到测试需求等）、需求的责任分配关系（需求
第24页/共54页
RM在标准过程体系中的实现
吗？
失效 后果
测试工作量增加或者返工导致成本增加； 性能不能满足客户需求有业务流失风险； 产品不能适应技术发展和未来业务发展。
第30页/共54页
技术解决方案内容
需求开发
选择产品组 件解决方案
开发设计
实施产品设计
备选设计 评估标准
设计细节 文档
第31页/共54页
开发产品
SG 1 – 选择产品组件解决方案
第4页/共54页
需求开发（RD）
目标 产生并分析客户、产品以及产品组件需求。
失效 征兆
需求不明确，客户和开发团队不能正确理解需求； 设计、实现和测试的工作产品和需求产生不一致； 难于对产品设计达成共识，花费更长的不必要的时间。
失效 后果
交付产品的不可用和客户的不满意会导致未来业务流失； 时间和资源的浪费会影响我们的绩效； 需求不稳定而导致不停地返工使团队很厌烦失去信心； 当你不能很好理解需求的时候，客户会对你失去信任。
企业总体架构＝架构的模块和组件＋模块之间的关系＋构架治理 原则
业务架构：是建设银行全面的IT 战略和IT 体系架构的基础，因为 业务架构是数据、应用、技术架构的决定因素。业务架构将高层 次的业务目标转换成可操作的业务模型，描述业务应该以何种方 式运作才能满足成功必须的能力和灵活性。
业务架构＝流程+数据+位置+角色+业务规则+时序
➢需求跟踪矩阵分为： 纵向跟踪矩阵，包括：需求之间的派生关系（客户 需求到产品需求）、实现与验证关系（需求到设计， 需求到测试需求等）、需求的责任分配关系（需求
第24页/共54页
RM在标准过程体系中的实现
吗？
失效 后果
测试工作量增加或者返工导致成本增加； 性能不能满足客户需求有业务流失风险； 产品不能适应技术发展和未来业务发展。
第30页/共54页
技术解决方案内容
需求开发
选择产品组 件解决方案
开发设计
实施产品设计
备选设计 评估标准
设计细节 文档
第31页/共54页
开发产品
SG 1 – 选择产品组件解决方案
第4页/共54页
需求开发（RD）
目标 产生并分析客户、产品以及产品组件需求。
失效 征兆
需求不明确，客户和开发团队不能正确理解需求； 设计、实现和测试的工作产品和需求产生不一致； 难于对产品设计达成共识，花费更长的不必要的时间。
失效 后果
交付产品的不可用和客户的不满意会导致未来业务流失； 时间和资源的浪费会影响我们的绩效； 需求不稳定而导致不停地返工使团队很厌烦失去信心； 当你不能很好理解需求的时候，客户会对你失去信任。
企业总体架构＝架构的模块和组件＋模块之间的关系＋构架治理 原则
业务架构：是建设银行全面的IT 战略和IT 体系架构的基础，因为 业务架构是数据、应用、技术架构的决定因素。业务架构将高层 次的业务目标转换成可操作的业务模型，描述业务应该以何种方 式运作才能满足成功必须的能力和灵活性。
业务架构＝流程+数据+位置+角色+业务规则+时序
软件项目的需求管理
感谢您的观看
求的完整性和准确性。
案例三：某智能硬件产品的功能需求管理
总结词
功能完善、性能优先
VS
详细描述
某智能硬件产品在需求管理上注重功能完 善和性能优先，通过与用户沟通、竞品分 析和技术评估，确定产品的核心功能和性 能指标。采用硬件描述语言和嵌入式系统 开发方法，确保功能的稳定性和性能的优 越性。
THANKS FOR WATCHING
对变更申请进行评估，分析其对 项目进度、成本和资源的影响， 以及是否符合项目目标和干系人 期望。
变更决策
根据评估结果，决定是否接受变 更请求。如果接受，则制定实施 计划；如果不接受，则向干系人 说明原因并拒绝变更。
变更申请
当项目干系人提出需求变更时， 需填写变更申请表，说明变更原 因和影响范围。
变更实施
需求管理工具的使用
使用需求管理工具进行需求收集
通过工具收集和整理来自不同利益相关者的需求。
进行需求变更控制
使用工具跟踪和管理需求的变更，确保所有变更 都经过适当的审查和批准。
ABCD
创建和管理需求规格
在工具中创建详细的需求规格，包括需求描述、 优先级、验收标准等。
生成需求报告和文档
根据需要，使用工具生成需求报告和文档，以便 团队更好地理解和管理需求。
对收集到的需求进行分类、整理和筛选， 明确需求的优先级和重要性。
编写需求规格说明书
评审与确认
根据需求调研和分析结果，编写详细的需 求规格说明书，包括功能需求、非功能需 求、约束和假设条件等。
组织相关人员对需求规格说明书进行评审 ，确保其准确性和完整性，并得到干系人 的确认。
ห้องสมุดไป่ตู้
需求变更控制流程
求的完整性和准确性。
案例三：某智能硬件产品的功能需求管理
总结词
功能完善、性能优先
VS
详细描述
某智能硬件产品在需求管理上注重功能完 善和性能优先，通过与用户沟通、竞品分 析和技术评估，确定产品的核心功能和性 能指标。采用硬件描述语言和嵌入式系统 开发方法，确保功能的稳定性和性能的优 越性。
THANKS FOR WATCHING
对变更申请进行评估，分析其对 项目进度、成本和资源的影响， 以及是否符合项目目标和干系人 期望。
变更决策
根据评估结果，决定是否接受变 更请求。如果接受，则制定实施 计划；如果不接受，则向干系人 说明原因并拒绝变更。
变更申请
当项目干系人提出需求变更时， 需填写变更申请表，说明变更原 因和影响范围。
变更实施
需求管理工具的使用
使用需求管理工具进行需求收集
通过工具收集和整理来自不同利益相关者的需求。
进行需求变更控制
使用工具跟踪和管理需求的变更，确保所有变更 都经过适当的审查和批准。
ABCD
创建和管理需求规格
在工具中创建详细的需求规格，包括需求描述、 优先级、验收标准等。
生成需求报告和文档
根据需要，使用工具生成需求报告和文档，以便 团队更好地理解和管理需求。
对收集到的需求进行分类、整理和筛选， 明确需求的优先级和重要性。
编写需求规格说明书
评审与确认
根据需求调研和分析结果，编写详细的需 求规格说明书，包括功能需求、非功能需 求、约束和假设条件等。
组织相关人员对需求规格说明书进行评审 ，确保其准确性和完整性，并得到干系人 的确认。
ห้องสมุดไป่ตู้
需求变更控制流程
需求管理培训课件.pptx
绘制系统与系统外 的界限和接口关系
创建用户界面原型
分析需求的可行性
确定需求的优先级
寻找意外需求
描述字段属性
建立需求模型
需求文档
目的是使用户和开发人员对需求有一个共同的理解，使之成为整个开发工 作的基础，也是需求的基线。
范围
1、文档用户和内容概述；2、需求范围；3、涉及部门及岗位；
需求
1、业务需求；2、功能需求；3、相应规则；
小组会议
收集需求的时间更快； 对于一些有歧义的问题、不清晰的需求，
十分有用；
要考虑多方的时间，会议的组织难度大； 对于会议的主持和把控需要技巧； 气氛很重要，要开放，言之有物；
合理的提问和引导出全面的需求并记录下来
需求八要素
需 求：差旅费报销 价 值：为一线员工提供差旅报销功能，便于………… 触 发：差旅申请单 前 提：有部门预算，审核通过的差旅申请…… 频 率：平均每天100单 关键情况：关联多张差旅申请单报销
vanKe 让 建 筑 赞 美 生命
THANKS
可追溯性
文档中需求与系统需求的双向可追踪性；
引用文件
1、制度、规范；2、公司发文；3、其他参考文档；
避免长篇大论式的文档描述
文不如字，字不如表，表不如图。
…………
需求确认
对需求文档进行评审和确认的过程。
需求评审
1、分层次评审；2、正式与非正式评审结合；3、事后跟踪工作；
需求测试
1、准备“概念”测试用户；2、基于“概念”测试用例模拟需求测试；
用户访谈
ห้องสมุดไป่ตู้1、准备访谈；2、主持访谈；3、访谈后续工作（吸收，理解，未明确问题跟进，访谈备忘录）
问卷调查
需求管理模板
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
所属模块(*)
描述(*)
提出者
提出时间
分类
新增功能 功能改进 界面友好性 Bug修复 运营需求 接口需求 功能改进 新增功能 新增功能 新增功能 新增功能 新增功能 新增功能 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 新增功能 新增功能 新增功能 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进
开发工程师
版本号
开始时间 结束时间
备注
优先级
低 高 低 中 低 中 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低
紧迫度
持续时间 产品负责人(*)
状态(*)
待讨论 暂缓 拒绝 需求中 开发中 已发布 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论
所属模块(*)
描述(*)
提出者
提出时间
分类
新增功能 功能改进 界面友好性 Bug修复 运营需求 接口需求 功能改进 新增功能 新增功能 新增功能 新增功能 新增功能 新增功能 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 新增功能 新增功能 新增功能 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进 功能改进
开发工程师
版本号
开始时间 结束时间
备注
优先级
低 高 低 中 低 中 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低 低
紧迫度
持续时间 产品负责人(*)
状态(*)
待讨论 暂缓 拒绝 需求中 开发中 已发布 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论 待讨论
《需求管理》PPT课件
代销商销售产品。
ERP 内部集成应用
•零售业务——指商业企业将商品销售给最终用户的销售业
务，这种业务适用于商场、超市等零售企业。零售业务是 整个分销业务的最终环节。
•销售调拨业务——是处理集团企业内部有销售结算关系
的销售部门或分公司之间的销售业务。
•受托代销业务——指在产品所权归属委托企业的情况，由我
ERP 内部集成应用
委托代销业务基本业务流程
企业销售人员按照销售计划，与各代销商签订委托代销销 售订单。主要内容包括委托代销产品、代销数量、供应价、 销售价格等。
企业的销售人员填写发货单，库存管理人员按照发货单发 货给代销商，发货后的产品所有权仍然属于本企业。
代销商接收产品，并在销售产品后开具售出清单 销售部门根据客户的售出清单开具委托代销结算单。企业
需求预测 其它
需求响应策略
备注
现货生产(MTS) 定单组装（ATO）来自补库定单、分销合同、 预测
定货生产(MTO) 定单组装(ATO)
合同（计划）的对象是 最终产品
定单设计(ETO)
现货生产(MTS)
预测对象：产品
定货生产(MTO)
原材料
定单组装(ATO)
基本组件和可选件
备品备件、试验品、破 坏性试验品等
erp内部集成应用需求管理整理ppterp内部集成应用供应链管理scm客户关系管理crm分销需求计划drp资源计划销售与运作计划sop需求管理竞争情报主生产计划mps总装计划fas需求管理在erp系统中的位置整理ppterp内部集成应用需求类型与需求响应策略需求类型需求响应策略备注分销需求现货生产mts定单组装ato补库定单分销合同预测销售合同定货生产mto定单组装ato定单设计eto合同计划的对象是最终产品需求预测现货生产mts定货生产mto定单组装ato预测对象
ERP 内部集成应用
•零售业务——指商业企业将商品销售给最终用户的销售业
务，这种业务适用于商场、超市等零售企业。零售业务是 整个分销业务的最终环节。
•销售调拨业务——是处理集团企业内部有销售结算关系
的销售部门或分公司之间的销售业务。
•受托代销业务——指在产品所权归属委托企业的情况，由我
ERP 内部集成应用
委托代销业务基本业务流程
企业销售人员按照销售计划，与各代销商签订委托代销销 售订单。主要内容包括委托代销产品、代销数量、供应价、 销售价格等。
企业的销售人员填写发货单，库存管理人员按照发货单发 货给代销商，发货后的产品所有权仍然属于本企业。
代销商接收产品，并在销售产品后开具售出清单 销售部门根据客户的售出清单开具委托代销结算单。企业
需求预测 其它
需求响应策略
备注
现货生产(MTS) 定单组装（ATO）来自补库定单、分销合同、 预测
定货生产(MTO) 定单组装(ATO)
合同（计划）的对象是 最终产品
定单设计(ETO)
现货生产(MTS)
预测对象：产品
定货生产(MTO)
原材料
定单组装(ATO)
基本组件和可选件
备品备件、试验品、破 坏性试验品等
erp内部集成应用需求管理整理ppterp内部集成应用供应链管理scm客户关系管理crm分销需求计划drp资源计划销售与运作计划sop需求管理竞争情报主生产计划mps总装计划fas需求管理在erp系统中的位置整理ppterp内部集成应用需求类型与需求响应策略需求类型需求响应策略备注分销需求现货生产mts定单组装ato补库定单分销合同预测销售合同定货生产mto定单组装ato定单设计eto合同计划的对象是最终产品需求预测现货生产mts定货生产mto定单组装ato预测对象
需求管理和需求分析
需求工程简介
把全部与需求直接有关旳活动通称为需求工程。需求工程中旳活 动可分为两大类，一类属于需求开发，另一类属于需求管理。 需求工程旳构造图
需求工程简介
市场
顾客/系统
管理者
初始需求
获取,分 析,定义, 验证需求
需求规格阐明
需求开发
变更旳需求
控制需求 变更
项目 环境
需求管理
需求工程简介
需求开发过程
系统需求(1) 系统需求(2) 系统需求(n)
软件需求
序言
➢“顾客”（user）是一种泛称，它可细分为“客户” （customer）、“最终顾客”（the end user）和“间接顾客” （或称为关系人）。掏钱买软件旳顾客称为客户，而真正操作软 件旳顾客叫最终顾客。客户与最终顾客可能是同一种人也可能不 是同一种人。 ➢客户是掏钱买软件旳人，所以他是“上帝” 。某饭店经理在解 释“先有鸡还是先有蛋”这个哲学问题时，精辟地论述了客户旳 地位：假如顾客先点鸡，那么就先有鸡；假如顾客先点蛋，那么 就先有蛋。 ➢客户旳需要才是最精确需求之源
需求开发旳主要困难与对策
7 顾客经常变更需求
需求变更一般会对项目旳进度、人力资源、经费产生很大旳影响，这是开发 商非常畏惧旳问题。
假如在项目开发旳初始阶段，开发人员和顾客没有搞清楚需求或者搞错了需 求，到了项目开发后期才将需求纠正过来，造成产品旳部分内容需要重新开 发。毫无疑问，这种需求变更将使项目付出额外旳代价。这种损失是因为双 方工作失误造成旳，双方应该好好反省，仔细学习需求开发和管理旳措施， 防止再犯相同旳错误。
需求开发旳主要困难与对策
5 双方误解需求
人们在交流旳时候，经常会发生“问非所求，答非所问 ”旳事情。
需求管理流程教材.ppt
需求管理流程教材.ppt1. 引言本文档介绍了需求管理流程的教学材料，旨在帮助读者了解和掌握需求管理的基本概念和流程。
需求管理是软件开发过程中至关重要的一环，它确保项目的需求与客户的期望保持一致，并且在整个项目生命周期中管理和跟踪需求的变化。
2. 需求管理概述需求管理是软件开发过程中的重要环节，它包括需求的收集、分析、确认、跟踪和控制等一系列活动。
需求管理的目标是确保项目团队对客户需求的理解一致，并且能够及时有效地变更和管理需求。
2.1 需求管理的重要性需求管理的重要性体现在以下几个方面：•需求一致性：需求管理能够确保项目团队对客户需求的理解一致，避免因为需求理解的差异而造成项目失败的风险。
•需求变更控制：需求管理可以帮助项目团队及时识别和管理需求的变化，以减少变更对项目进度和成本的影响。
•项目范围管理：需求管理是项目范围管理的重要组成部分，它能够帮助项目团队明确定义项目的范围，防止范围的蔓延和扩大。
2.2 需求管理流程概述需求管理流程是一个连续迭代的过程，包括需求收集、需求分析、需求验证、需求变更控制和需求跟踪等环节。
下面简要介绍每个环节的主要活动：1.需求收集：通过与客户直接沟通、接触，收集项目所需的需求，并记录在需求文档中。
2.需求分析：对收集到的需求进行详细分析，澄清和理解需求的背景、目标、功能，识别需求之间的关联和优先级。
3.需求验证：与客户确认需求的准确性和完整性，确保需求的描述准确反映客户的期望。
4.需求变更控制：管理和控制需求的变更，确保变更经过评审和批准后才能执行。
5.需求跟踪：跟踪并记录需求的变更和状态，确保项目团队能够及时了解需求的变化和影响。
3. 需求管理流程详解3.1 需求收集需求收集是需求管理流程的第一步，它主要包括以下活动：•与客户沟通：通过面对面的交流、电话会议等方式与客户沟通，了解客户的业务需求和期望。
•文档分析：审查现有文档，包括需求说明书、业务流程图等，以获取更多的需求信息。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
周 一
周 二
周 三
验收 验收
周 四
周 五
业务 产品
需求评估、原型设计 反复确认、正式回复 RPD UI设计
评 审 评 审 研 发 研发、测试
研发
修正 体验
THANKS
需求共识，目标被认可
• 需求目标与团队目标的一致 • 所需资源（成本、人员等）得到认可
负责人
BOSS
4
案 例
需求优先级
• 优先级得到明确
负责人 BOSS
1 3
公司战略和规划 相关需求 提升工作效率 相关需求
2 4
业务发展/增收/成本降低 相关需求 用户体验和认知 相关需求
公司战略和规划相关需求 提升工作效率的相关需求
需求管理
精准高效 从容不迫
总做迫在眉睫的事，会让人丧失目标
目录
目标
需求分析
方案
需求设计
实施
需求研发
检验
用户反馈
目标
需求产生、描述、共识、优先级
1
需求来源于目标
• 业务的阶段性战略任务 • 团队的头脑风暴结果 • 工作过程中的经验和感悟 • 数据或KPI的驱动 • 用户或客服的反馈 • 领导要求 合作意向
需求人 负责人 产品经理
实施
自测与联调
技术架构设计、代码编写
测试用例、问题沟通
对不起，这部分对我也是黑盒
检验
发布前：需求验收、体验官体验
发布后：数据分析、用户反馈
1
需求验收
设计
• 需求人和负责人：验收是否满足需要（可用） • 产品经理：验收是否完成逻辑（不出错） • 设计师：验收是否还原设计（美观，好用）
讨论：适合咱 们平台的优先 级策略是什么?
业务发展/增收/成本降低 相关需求
用户体验和认知相关需求
出现的需求干系人和职责 产品经理 技术负责人 需求人 • 产生需求 • 分析需求 • 描述需求 • 为需求目标 负责 客服 用户 外援专家 负责人 • • • •
BOSS 负责人
（业务对接人）
需求人
业务节奏把控 审核需求 优先级确认 审批流程
• 通过模板文档，模板文档会提示一些重
要的问题
需求人
• 参考竞品或类似产品的方案
• 任何可以帮助你描述想法的工具，甚至
是纸笔
2
需求如何描述？
• 如果你的需求别人没有插手的余地，是 危险的信号 • 如果你的需求，没有不良效果，是危险 的信号 • 如果你无法用30个字说清楚你的目标， 是危险的信号
3
产品经理
需求人 负责人
2
体验官体验
• 条件各异的人：帮助发现不可预知场景
（需求干系人认知存在盲区）
产品经理
• 不知情人：验收是否吻合预期（合理）
设计
测试 技术负责人 需求人 负责人
3
数据分析
• 分析的周期 • 预测变化：增长、减少 • 业务关键指标 • 回到目标，当初做这个是为了什么？现在达 到了么？
产品经理
负责人
需求人
4
用户反馈
• 体验官是用户？是 • 是什么用户？内部用户/核心用户 • 可局部定性，可初略定量 • 用户访谈：定性 • 客服数据、针对性的统计、问卷：定量
产品经理
负责人
需求人
落地
结合我们的需求管理流程
N周
周 一
需求确认
周 二
周 三
周 四
周 五
周 一
周 二
周 三
周 四
评 审
周 五
需求人
2
如何描述需求？
描述清楚目标 就完成了需求描述的第一步
需求人
2
如何描述需求？
寻找多种解决方案，并记录
我知 我不知
需求人
他知
他不知
共识
短版
负责人
特长风险专家外援 Nhomakorabea2
需求如何描述？
挖掘多种使用场景，并记录
我遇到 我少/不遇到
需求人
他遇到
他少/不遇到
普需
兼顾
客服
兼顾
边际
产品经理 你的用户
2
需求如何描述？
负责人 产品经理
3
PRD撰写
• 原型绘制 • 流程图绘制 • 产品规格描述 • 异常的处理方案
产品经理
4
PRD评审
• 方案认可 • 需求细节讲解 • 最终技术用时评估，研发人员分工 • 验收目标明确
测试
设计 负责人 需求人 产品经理
技术负责人
5
界面设计
设计
• 文案设计（理念传达） • UE设计（交互流程） • UI设计（信息呈现） • 视觉设计（风格润色） • 确认
• 为时效性负责
讨论时间
方案
需求可行性评估、排期回复、PRD撰写、
PRD评审、UI设计
1
需求可行性评估
• 产品经理与需求人、负责人沟通和确认需求 • 产品经理与技术负责人评估可行性
产品经理
负责人 需求人
技术负责人
2
排期回复
• 可行，大概XX上线 • 可行，需要时间较长，XX时间回复您 • 有问题，我们一起找XX再协商一下 • 优先级不OK，排到XX时间是否可以 • 不行，有大问题，具体细聊