产品需求分析与需求管理
产品需求分析与需求管理
－－如何搞定市场需求
通过和众多国内科技企业接触，发现这些企业中普遍存在：
1.技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反
而活的还不错
2.研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发
的越多，死得越快
3.产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、
找卖点
4.了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责
5.需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不
知道如何关注
6.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不
同团队对需求理解的一致性
7.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联
系”
8.不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变
动
9.针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与
测试吵，……
不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威
机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。
本课程重点讲解：
1.如何确定目标客户，如何分析需求关系人？
2.如何从市场（客户）角度进行有效的客户需求收集？
3.围绕产品成功2个核心因素差异化+成本优势，整理产品需求
4.如何对客户需求进行整理和分析，形成产品包需求？
5.如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产
品概念？
课程贯穿案例分享，详细讲解目标客户 ? 客户要求 ? 客户需求 ? 产品包需求 ? 产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、Sweet Point模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。
一、案例分享
二、六个基本概念
1.什么是客户？
1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户
2.什么是需求？
1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、
设计需求、需求规格、技术需求、非技术需求
2)案例：某运营上广告折射对需求五层次的理解
3.需求工作的2个基本点：
1)差异化
2)成本优势
4.需求工程全过程：
1)需求收集?需求整理?需求分析?概念确定?需求分解?需求实现与验
证
5.官方体系对需求的定义：
1)RM（目的、关键实践、典型输出）
2)RD（目的、关键实践、典型输出）
6.产品经理3个核心素质特征：
1)敏锐的市场嗅觉
2)不屈不挠的战斗精神
3)团队协作和领导能力
7.演练与问题讨论
三、市场需求分析
1.产品不同阶段的创新思路不同
1)产品创新阶段（颠覆性创新、应用性创新、产品创新、平台创新）
案例视频：鼠标的产生
案例讲解：Iphone的Siri
2)产品成熟阶段（营销创新、体验式创新、价值工程创新、集成创新、
价值转移创新）
支撑案例讲解：Nike专卖店、游戏卖装备、汽车5S店、星巴克
咖啡
2.产品扩展方法论
1)市场的新颖程度分析
2)公司的新颖程度分析
3.识别客户？
1)跨越鸿沟：5类客户
创新者：特征、关注点、价值
早期接收者：特征、关注点、价值
前期主流客户：特征、关注点、价值
后期主流顾客：特征、关注点、价值
落伍者：特征、关注点、价值
2)早期客户策略：保龄球法则
保龄球道
找准一号瓶
龙卷风、引爆流行
3)客户购买过程回溯分析
最终用户、销售支持、集成分销、增值代理……
4.客户分析
1)决策影响模型分析
2)核心关注点分析
3)实战演练与问题讨论
5.需求收集需要注意的问题
1)一对一访谈的技巧
2)探究原因而非简单问题
3)聚焦期望
4)询问而非推销
6.需求收集基本技能
1)需求收集调查问卷设计
2)需求访谈问题梳理
3)需求问题访谈7步法
4)需求访谈信息记录的方法
5)实战演练与问题讨论
7.需求收集的输出：客户需求收集模板（单项需求收集模板）
1)真正理解客户的意图
“抽象之梯”法：深入探索、了解、洞察客户需求
“客户的一天”：展现客户特征、困惑、渴望
案例分享：听筒10米长的电话机
2)客户描述和需求陈述
3)客户描述? 需求陈述五原则
案例分享：具体产品客户描述到需求陈述案例分享（对应需求工
程的用户需求+业务需求）
案例分享：某业务软件情节串联板需求收集和确认案例分享（对
应需求工程的需求收集、实现诱导用户需求）
4)收集人信息、客户信息、需求信息、优先级、关联需求
5)需求收集和分拣流程介绍
6)案例分享：某公司单项需求描述要素讲解（客户需要翻译）
7)实战演练与问题讨论
8.如何构造例行化的需求收集机制？
1)需求收集的IT支持
2)业务流程改进（出差流程等）
3)员工任职资格牵引
4)员工具体绩效承诺落实
5)案例分享：某公司市场需求管理制度讲解
四、产品需求分析
1.需求群的划分
1)需求群划分的基本原则
2)需求分类方法（KJ亲和图法）
基本类型分类法、生命周期阶段分类法
优先级分类法、来源分类法
稳定性分类法、风险级别分类法
案例分享：某软件产品千条单项需求到产品特性转换的案例分享
（实现需求工程的产品特性和业务需求）
3)如何保证需求的一致性
需求冲突矩阵分析法
案例分享：具体网络产品需求冲突矩阵分析讲解（实现CMMI所
要求的需求一致性）
实战演练与问题讨论
2.如何区分需求优先等级（权重确定）
1)KANO需求类型
最好满足的需求、强制性需求、兴奋需求
如何通过二维矩阵正确区分以上3类需求？（正反求证法）
2)业界最佳产品需求等级划分法（BSA法）
3)需求（群）权重设置方法（AHP）
权重确定4步法
案例分享：具体需求权重设置样例介绍
3.实现成本优势：关注内部需求
1)DFX（DFT、DFM、DFA等）
2)RAS（可靠性、可用性、可维护性）
4.案例分享：具体系统产品需求包（特性需求清单）案例分享（完成需求
工程要求的特性需求、业务需求的分析）
5.产品包需求输出（产品包需求模板（关键要素介绍））
1)优秀产品包需求的标准
五、产品概念确定
1.业界最佳客户需求的八个要素介绍（$APPEALS）
1)每个要素详细定义
2)每个要素的子要素分解
3)案例分享：某应用软件产品客户需求8要素子要素展开讲解（实现
NPD要求的，基于竞争分析，确定不同特性的优先等级）
2.差异化创新，不走寻常路
1)分析客户关心什么
2)分析竞争友商满足程度
3)分析潜在机会
4)确定自己的价值缺陷
5)案例分享：某高端服务器厂商的创新之路
3.创新4象限法
1)减少：案例分析
2)剔除：案例分析
3)增加：案例分析
4)创造：案例分析
4.产品概念确定
1)产品概念的定义
2)产品概念的测试（电梯测试法）
3)针对危害产品概念的客户需求3原则
倾听
赞美
全忘记
4)产品概念确定的7个核心法则：
不走寻常路才会有出路，案例讲解
我是第一，我怕谁，案例讲解
要么最老，要么最新，案例讲解
让客户觉得你有秘方，案例讲解
跟老大对着干，案例讲解
客户总是随波逐流，案例讲解
成为专家，案例讲解
5)案例分享：两个命运迥异的互联网软件的概念分析
6)实战演练与问题讨论
六、设计需求分析
1.需求分解与分配的基本理念
1)物理分解与功能分解
2)哲理案例：从人类飞行的梦想思考需求分解与分配
2.特性需求到设计需求的转化工具：FBS、PBS
1)工具原理介绍
2)案例分享：具体某业务应用软件某特性的FBS样例（实现特性需求
和设计需求的衔接）
3.设计需求（功能需求）定义的工具：UseCase、情节串联板
1)Usecase的基本要素：角色、用例、用例名、系统边界
2)有效识别角色的方法介绍
3)用例识别方法介绍
4)用例的命名原则
5)6种常见的用例描述错误分析
6)实战演练与问题讨论
4.需求分解与分配操作
1)需求分配
需求分配表（RAS）介绍
什么是需求因子？
形成设计需求、产品规格定义
实战演练与问题讨论
2)案例分享：具体系统产品客户需求->产品包需求->设计需求->需求
分解的全称需求案例分享
5.需求双向跟踪机制（RTM）
1)需求编号规范介绍
2)需求跟踪的必要性
3)前向跟踪
4)后向跟踪
七、总结
电子书管理系统需求分析
WEP电子书管理系统需求分析书 （一）读者管理员登陆模块 （二）电子图书馆管理部分 1、图书管理：添加图书、删除图书、改变图书分类和修改图书信息等操作。 2、评论管理：对所有的读者留下的评论进行管理、对相应的好看的书籍进行评 定，而且还可以查询。 3、类别管理：添加图书类别、删除图书类别、修改图书类别。 4、精品推荐：可以把电子图书按不同的等级推荐管理。 5、统计分析：对所有的电子图书进行统计分析。 （二）读者查阅部分 1、最受欢迎的图书：根据用户点击率自动排序，点击率最高的前图书会在电子图书馆中自动显示出来 2、新书快递：根据管理员添加图书的时间进行排序，最新添加的图书会在电子图书馆中自动显示出来 3、推荐图书：按照管理员向读者推荐书，图书将在电子图书馆中自动显示出来 4、图书评论：级别高的读者对图书发表的观点，读者可以看到每个人对该书的评论 5、图书查询：可以按不同的类别查询你想要浏览的图书。例如按照书名检索、按照作者名检索、按照出版社检索等。 6、个人收藏夹：可以将自己喜欢的图书列表保存到自己的收藏夹中，这样下次 登录系统时不必再一一查询，直接从收藏列表中选取要阅读的图书即可。用户需对收藏夹列表具有全功能的管理权限，例如，可以往其中添加书籍，也可以从其中删除书籍等。 7、读书笔记：增加读者看该书籍的时候所有感想，想记下来的笔记，读者可以有感而发。
1.数据库设计： 1)E-R图 表1：图书分类表Catalog：存放电子书籍的分类信息：方便查找读书 表2：图书所属目录表Catalog_Ebook：存放目录的嵌套结构 表3：图书表(book)，存放每本书的详细信息
产品需求管理MRD
产品需求管理M R D 集团文件发布号：（9816-UATWW-MWUB-WUNN-INNUL-DQQTY-
X X X项目/产品M R D XX有限公司 (版权所有,翻版必究)
MRD修改记录 注：MRD提交评审之前的修改也可以记录下来
目录
1项目背景 【在此简单介绍项目/产品产生的背景】 2名词解释 【对文档中出现的新的名词、概念或简略语给出定义和解释。如果没有此项，可以裁剪】 3可行性分析 3.1前期调研信息和数据 【提供前期调研信息和数据作为项目立项的支持，给出一些重要的依据数据（譬如通过某项调研发现存在很大的空间可以提高问题解决率，那么调研的结果应该在此进行表述）】 3.2项目预期目标 【明确项目的预期目标，最好有量化的目标值（譬如用来提高问题解决率的MRD，应该给出预期的解决率的范围或者具体值）】 4综合描述 4.1功能概述 【对功能做整体性的概要描述，包括所包含的功能模块及各功能模块的概要描述，也可以指出本次的开发重点。如果MRD需求功能点较少，此项可以裁剪】 4.2对其它产品的影响 【包括和该需求相关的假设和依赖，即本产品和外部系统的接口关
系，如果接口比较多或复杂，建议以图形方式进行表示。如果本产品没 有外部接口，此项可以裁剪】 5功能详述 5.1功能需求 5.1.1功能点1 5.1.1.1功能点类型和优先级 【功能点类型有新增、旧有功能升级、Bugfix三种类型；优先级分为高、中、低】 5.1.1.2流程图 【如果功能点流程较复杂，可以结合流程图来进行说明。如果流程简单，可以裁剪】 5.1.1.3页面布局 【由TS或UE或其它部门提供的模板页面，如果没有，此项可以裁剪】 5.1.1.4功能点1描述 【针对该功能点做详细的描述，确保描述的一致性、无二义性，并 尽可能量化功能要求】 5.1.2功能点2 5.1.2.1功能点类型和优先级 5.1.2.2流程图 5.1.2.3页面布局 5.1.2.4功能点2描述 ……
新产品开发项目管理办法
Q/ZSZDXM01新产品开发项目管理办法 版本号： 标准化： 审定： 批准： 重庆宗申宏立座垫制造有限公司发布 新产品开发项目管理办法 目的
为建立健全公司制度、规范新产品开发流程，使新品项目按计划进行，特制定本管理办法。范围 本办法适用于公司所有的新产品开发项目全过程的管理。 定义 新产品开发是指从研究选择适应市场需要的产品开始到产品设计、工艺制造设计，直到投入正常生产的一系列决策过程。 职责 公司领导 4.1.1对项目立项、项目撤销进行决策； 4.1.2任命项目主管或经理； 4.1.3对项目计划进行评审；对项目进行过程中的重大里程碑、重大变更计划做出决定； 4.1.4对项目的绩效进行考核。 项目部 4.2.1项目立项前期组织各部门对项目进行可行性评价； 4.2.2召集成立项目小组，召开项目阶段性评审会（主要指手工样件、工装样件、小批送样评审）； 4.2.3适时更新项目进度表，确保新项目按照客户的要求顺利投产，有异常情况时向客户报告。4.2.4定期或不定期组织召开以产品工程师、供应商质量工程师、采购工程师、物流工程师、客户质量工程师、生产管理等为主要成员的项目推进会，督促、协调各部门及供应商按时、保质、保量完成各项工作； 4.2.5协调客户与公司内部各部门的沟通，最大程度地满足客户合理的需求。 4.2.6对开发阶段客户提出的座椅交样数量及试验样椅等各种需求的座椅，项目部下达计划到物流计划部（5套以下手工样件下达计划到技术部）。 4.2.7按照《项目管理考核办法》Q/ZS-MSZDRY03，进行考核。 财务部 4.3.1立项前期对产品进行投资回报分析，确定从财务角度出来该项目是否可行； 4.3.2按客户要求对产品进行报价和议价，并对各种费用进行审核。 4.3.3按项目费用预算计划准备资金。 4.3.4对新产品材料提出目标价格。 技术部 4.4.1项目立项前期对该产品进行技术分析，确定从技术角度出发该项目是否可行，能否满足客户
人事管理系统需求分析
人事档案管理系统需求分析说明书 1 引言 需求规格说明书是需求分析的产物，它是软件系统生存期中软件定义阶段的最后一个步骤。作为整个软件开发过程的指南，它也是软件开发人员开发出符合用户要求的软件的基础。 1.1 编写目的 软件需求说明书的编制目的是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解，使之成为整个开发工作的基础。 本软件需求说明书的读者是系统开发人员或合同约定的人员。 1.2 背景说明 （1）本系统的名称是：人事档案管理系统。 （2）本项目的任务提出者是任课老师，开发者是信息科学学院08计本1班，用户是企业人事及相关部门，实现该软件的计算中心是**信息管理学院电子商务技术中心。 （3）本系统能为其他的系统提供人事数据。 1.3 定义 数据字典：关于数据的信息的集合，也即是对数据流图中包含的元素的定义的集合。 VB：Visual Basic。 1.4 参考资料 （1）企业的人事档案管理系统开发合同。 （2）引用资料 [1]张海藩. 软件工程导论. 北京：清华大学出版社，2005. [2]石柱. 软件工程标准手册. 北京：中国标准出版社，2004. 2 任务概述 2.1 目标 人事档案管理是现代企业人事资源管理中的重要内容，也是人力资源开发利用的基础性工作。人事档案管理在信息化之前，在人员进出、离退休、升迁、岗位变动、职称变动、学位变动，以及档案管理人员的变动等方面存在诸多不利于管理的地方，不适应现代的企业管理形势和人力资源开发利用的要求。 开发人事档案管理系统使企业的人事档案管理工作实现了信息化、规范化，不仅使企业能够高效率完成人事管理的日常工作，还使企业深入开发利用人力资源成为可能。 2.2 用户的特点 本软件的最终用户是企业人事部门的工作人员。部门有专职的人事数据录入人员，具有一定的计算机操作知识；系统的维护人员是企业的信息中心的信息维护员，对网络和数据库的操作比较熟悉，同时对VB或Delphi编程有一定的经验；数据录入员负责人事数据的录入及日常更新，信息维护员负责人事数据的备份和其他管理工作。企业的人员调进与调出比较频繁。 2.3 假定和约束 企业的经费有限，开发时间紧迫，可以使用VB或Delphi进行软件编程。 3 需求规定 3.1 对功能的规定 3.1.1 系统功能 人事档案管理系统的功能可以划分为如下几个部分 （1）系统账户管理：主要是对系统用户进行管理，包括登录、退出、操作记录等。
需求管理规范V
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
产品需求管理流程
中国联通音乐运营中心产品需求管理流程一、目的 为提高技术部与其他部门需求沟通效率，提高需求书质量，规范化需求文档，确保中音与厂商之间建立对需求的共同理解，特制定此需求管理流程。 其中产品包括：下载、流媒体、炫铃、铃音盒、电台、下载包、俱乐部以及对以上产品的组合形式。 产品需求涉及到以下部件中多个的修改：各门户、系统后台和各省分平台及总部平台。 产品需求不包括：单独对门户、后台或接口功能的优化和修改、统计分析、问题和故障的处理等。 二、需求管理流程 需求流程管理主要包含如下三个部分： 1)需求调研：产品需求方的产品负责人主导组织进行需求调研，汇总、分析和整理需求。 2)需求评审：产品需求方召开组织需求评审会，评审团对产品需求进行评审。评审通过则启动开发，由技术部项目负责人组织厂商
制定开发计划，产品需求方确认开发计划。 3)需求变更。 三、需求调研 需求方产品负责人参照需求书模板（见附件章节），拟定需求书初稿，提交技术部，技术部根据需求情况分配需求项目负责人对口需求。 在此阶段由产品负责人主导，技术部配合，协调相关单位、部门同事进行需求调研工作，开展详细的调研，对新产品的需求进行提炼、归纳和汇总，并且按照需求模板的从各方面详细考虑完善需求文档。 在需求的描述中，要首先明确项目的边界，哪些是业务系统内部的，哪些是业务系统外部的，并应该遵循如下规则： ●相关的需求都得到了识别和描述，确保需求的完整性； ●各个需求之间不产生冲突，确保需求的一致性； ●正确描述系统需求，引用的资料有明确的出处，避免模糊词语 的使用，确保需求的正确性； ●定义必要的术语，适当结合图形，结构图等方式进行描述，确 保需求无二性； ●确保描述的需求可以通过适当的方法进行验证，确保需求的可 测性；
库存管理系统需求分析
学号 07730213 《软件需求分析》大作业 2009-2010学年第二学期 学生姓名薛浩 专业名称网络工程2班 指导教师赵黎强 电子与信息工程系 2010 年 6 月 1 5 日
题目 一个物流企业需要部分业务网络化管理，其中需要开发一个库存管理系统货物入库管理系统，主要实现货物入库、库存和出库的管理过程。 货物入库：运输货物到仓库，送货人员把货物交给仓库管理人员，仓库管理员填写入库单（货物分类号、货号、货物名称、规格、数量、单价、供货商、送货人、入库时间、货物存放位置、货物损坏程度、备注），把货物放置库房的相应位置，仓库管理员填写回执单给送货人。管理人员修改仓库数据库信息。 库存管理：管理人员把货物存储到货架，填写存货账目（时间、货号，分类号、货物名称、规格、入库数量、出库数量、入库人、出库人、余额） 货物出库：提货人交给仓库管理员提货单要求提货，仓库管理人员根据提货单要求填写出库单（货物分类号、货号、货物名称、规格、数量、单价、供货商、提货人、出库时间、货物存放位置），提货人员认可出库单签字。仓库管理员监督提货人员把货物提走，管理员根据提货单和出库单信息修改仓库数据库信息。 该系统要求对于仓库管理人员企业人员能随时了解仓库的活动，包括货物的存储情况，库房空闲情况和货物流动，谁进行的货物进出操作等信息。 说明：货物分类号——是由2位字母和4位数字组成； 货号——是由分类号加当前日期组成； 货物名称——是由20位字母汉字组成； 规格——是由10位字母和数字中间加“-”组成； 货物存放位置——是由6为数字中间加“×”组成； 凡未说明的——根据具体情况设定。 要求实现以下设计：
需求管理规范
目录 2 1.前言......................................................................................................................... 3 2.需求管理背景......................................................................................................... 3 3.需求管理流程......................................................................................................... 4 4.指导规范................................................................................................................. 6 5.需求管理体系......................................................................................................... 6 5.1.制度 .............................................................................................................. 7（一）总则 .............................................................................................................. 7（二）机构职责 ...................................................................................................... （三）总体工作流程 ............................................................................................ 10 10（四）需求提出 .................................................................................................... 10（五）需求分析 .................................................................................................... 11（六）需求评审 .................................................................................................... 12（七）需求跟踪 .................................................................................................... 12（八）需求实现 .................................................................................................... 12（九）附则 ............................................................................................................ 13 5.2.细则 ............................................................................................................ 13 5.3.流程图 ........................................................................................................ 14 5.4.评审细则 .................................................................................................... 15 5.5.模板 ............................................................................................................ 5.6.编写指南 .................................................................................................... 16 16 6.合理性评价...........................................................................................................
银行产品研发项目组管理细则
中国ⅩⅩ银行产品研发项目组管理细则 第一章总则 第一条为提高产品创新工作质量和效率，明确产品研发项目组工作职责，规范中国ⅩⅩ银行产品研发项目组工作流程，依据《中国ⅩⅩ银行产品创新与管理委员会工作规则》、《中国ⅩⅩ银行产品创新与管理办法》等制度，制定本细则。 第二条本细则所称项目工作是指根据《中国ⅩⅩ银行产品创新与管理办法》立项并审批通过后进行的产品研发活动。产品研发项目组是具体实施项目的业务团队，具体任务为完成业务需求和制度办法的编制、需求解释与变更、业务测试、验收试点等工作。 第三条本细则适用于项目实施过程中所组建的产品研发项目组。 第二章产品研发项目组构成 第四条总行各部门、分行(分中心)在申请立项时提出项目组组建方案，包括项目组人数、项目组成员来源部门/分行、具体职责及工作任务、技能要求、到位时间等建议。 第五条项目组人员构成 根据项目需要，项目组由总行各部门、分行或外部合作伙伴委派专业人员构成。项目组成员须具备项目所需专业知识，项目经理还需具备组织协调能力和项目经验。 （一）产品研发部是产品研发的综合管理部门，需派出产品经
理或产品经理组参加所有的产品研发项目组，全程参与项目实施。产品经理服从项目组管理，重点进行产品概要设计与把关、对需求说明书规范的应用进行指导和讲解、参与需求说明书编写工作。 （二）项目牵头部门是产品研发的组织实施部门，负责组建项目组，派项目经理和专职人员参加产品研发项目组，负责和参与项目实施全流程的管理工作和相关具体工作。 （三）业务主管部门需派专职人员参加产品研发项目组，参加需求编写，负责制度办法、产品宣传培训方案、广告设计方案的制定，并为接手产品上线后的相关工作做好准备。 （四）科技部门需派专职人员参加需技术开发的项目组，参加需求讨论与技术实现可行性的评估，保证项目进入技术开发阶段的工作效能。 第六条项目实施期间，各部门应保持项目组成员的稳定，不得随意抽调或变更，项目组成员需服从项目组调配。如需调整，各部门应提前与项目牵头部门沟通，在不影响项目组工作进展的前提下，酌情予以变更。如需更换项目经理，项目牵头部门需报产品研发部核准后进行。 第三章产品研发项目组工作职责 第七条项目组职责 （一）负责拟定需求工作计划，报项目牵头部门批准后予以实施； （二）负责分析讨论产品创意，按照需求说明书规范完成业务需求编写工作，完成《XXX产品需求说明书》；具体要求参见《关于规范我行产品需求说明书编写工作的通知》（农银办发【2009】259
业务需求管理制度
业务需求管理制度 第一条总则 规范各部门有关业务需求的提出、变更及维护，为整体业务系统建立统一的需求管理机制和跟踪机制，从而提高沟通效率及需求反馈的响应速度和透明度，保障产品开发结果与需求的一致性，特制定本细则。 第二条适用范围 本规定适用于管理所有业务部门提交到本部的所有需求。 第三条定义 1、业务需求：对需要在整体业务系统中实现或调整的业务功能的说明或描述； 2、业务需求方：为公司整体业务系统提出所要实现或调整功能的部门，包括无线运营部、销售服务部和财务结算部等； 3、业务需求承接方：负责承接业务需求，目前由产品技术部的产品专员对接各部门的需求。 第四条需求的重要程度 需求部门所需功能对整体业务系统的影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a)非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节； b)重要：业务系统所需的该项功能对整体业务系统影响大； 页脚内容1
c)一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。第五条需求的紧急程度 需求部门所需功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。 a)非常紧急：所提业务需求非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施； b)紧急：所提业务需求比较急迫，如不尽快实现，业务流程不能被正确执行，但存在可替代措施或方法； c)一般：所提业务需求急迫性一般，不会对现有流程存在较大影响。 第六条需求提交 各部门通过JIRA填写详细需求信息，向需求承接方发起需求任务，在需求提出时需注意以下几个方面： 1、详细描述需求背景、需求内容，包含需求介绍、功能性需求详细描述及数据需求描述，明确本部门需求对接人； 2、提出需求时应说明需求的重要程度和紧急程度； 3、提出需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理； 4、为更加清楚地说明业务需求变更情况，可附带附件、附图等文档。 第七条需求分析 1、需求承接方就接受到的需求进行需求分析，需求不明确的地方与需求方及时进行沟通，并在 页脚内容2
产品需求分析与需求管理——如何搞定市场需求
产品需求分析与需求管理——如何搞定市场需求 主讲：董奎（十多年高科技企业的研发与管理实践经验，在某著名高科技企业工作期间，先后担当项目经理、系统工程师、产品经理、软件部经理） 课程对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 授课方式：讲师讲授+视频演绎+案例研讨+角色扮演+讲师点评。 【课程背景】 通过和众多国内科技企业接触，发现这些企业中普遍存在： 1、技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2、研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3、产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4、了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5、需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6、需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致性 7、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8、不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9、针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。【课程重点】 1、如何确定目标客户，如何分析需求关系人？
2、如何从市场（客户）角度进行有效的客户需求收集？ 3、围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4、如何对客户需求进行整理和分析，形成产品包需求？ 5、如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户?客户要求?客户需求?产品包需求?产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 【课程价值】 1、掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 2、掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 3、掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 4、掌握产品核心诉求的提炼方法，确定有吸引力的产品概念； 5、掌握支撑研发需求工程各个阶段工作运作的工具和操作方法； 【培训内容】 一、案例分享 二、六个基本概念 1、什么是客户？ 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2、什么是需求？ 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例：某运营上广告折射对需求五层次的理解 3、需求工作的2个基本点：
产品开发项目管理规程(V0.1)2007
产品开发项目管理规程 1目的 本规程基于产品开发系统CPD流程，用于规范产品开发团队在产品开发过程中的管理。目的是保证产品开发的顺利实施，为PDT团队进行项目管理操作提供快捷帮助，统一项目管理步调，提高项目管理效率。 本规程整体上将项目管理各要素按项目启动、项目计划制定、项目执行、项目控制及变更、项目结束过程进行有机融合；各要素的相关详细操作均以模板和附件形式出现；本规程也涵盖了项目依赖管理、对外合作项目管理和项目管理IT指南。 2适用范围 本规程适用于所有产品和技术开发项目过程管理。 3 项目启动 项目概念阶段开工会作为项目管理活动起点。如图1所示：
图1 项目计划制定与CPD流程阶段对应关系 4 项目计划制定 项目计划包括主项目计划（进度计划）、人力资源计划、物料计划、风险计划、质量计划、项目预算。项目计划制定须严格按照对应的模板和规范进行。项目计划归档在IT管理系统中，作为项目过程管理和项目控制的基线。 4.1 主项目计划制定 如图1所示，PDT经理和PDT核心组在CPD主流程相应阶段共同制定主项目计划。
主项目计划由概念阶段项目计划（WBS）、端到端项目计划（WBS）构成，计划一旦经过评审就形成基线，并以此作为项目度量计算进度偏差的基线。 其中，端到端项目计划（WBS）与人力资源计划、项目预算在计划DCP完成后基线化。 主项目计划各基线确定一周内，PDT须在产品开发项目管理IT系统上发布。 计划评审通过后须及时发布，具体操作说明见表1： 表1 项目计划发布操作
4.1.1 主项目计划（进度计划）制定操作指导 项目计划制定的流程图、步骤和方法分别如图2： 图2 项目计划制定流程图 4.1.2 概念阶段项目计划（WBS）制定 计划制定前提：完成概念阶段项目开工会 计划制定责任人：PDT经理（LPDT） 计划制定参与者：PDT核心组成员 输出：《概念阶段项目计划（WBS）》 模板：《概念阶段项目计划（WBS）》模板 计划制定步骤： 1）获取《概念阶段项目计划（WBS）》模板； 2） PDT经理组织PDT核心组成员进行概念阶段的活动分解（WBS）、确定概念阶段主要活动/里程碑和重要的依赖关系； 3） PDT经理分析关键路径，并和PDT核心组成员共同确定主要活动/里程碑的时间； 4）各PDT核心组成员分别制定各功能领域的工作计划。步骤如下： 根据活动分解（WBS）的结果对项目计划模板中的任务进行裁剪；
需求管理规范 (2)
需求管理体系改进方法研究 需求管理过程 当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下： 1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。 2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。 3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。 4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。 5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。 6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。 7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。 8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
IBM软件产品需求管理流程
IBM 软件产品需求管理流程 1. 简介 IBM 软件产品的版本(V.R.M.F)从市场规划和客户需求开始，到研发以及后续的交付遵循IB M软件部集成产品设计(IPD)流程。IBM 软件产品需求管理流程是IPD的一个体现，也就是一个由市场/客户驱动的，跨市场部门、研发产品管理部门及研发工程部门的端到端需求管理流程。同时，此次内容我们将描述IPD和产品需求管理流程，及流程中的角色（市场、研发产品管理部门及研发工程部门），以及他们之间是如何通过协作来管理需求的。 2. 背景——IPD IPD指导如何对软件产品发布版本进行投资决策和如何协调部门间工作以实现这些决策所 定义目标，IBM软件产品需求管理基于IPD流程，要了解这个需求管理的流程，首先我们要了解IBM所有产品开发所遵循的IPD的流程，包括其决策点。 IPD流程分为六个步骤： 1.概念：即概念验证阶段，主要对需求包进行评审，以确定其是否有足够的商业价值； 2.计划：即资源投入计划阶段，主要对需求包进行评估，以确定是否有足够的资源且在 一定的时间范围内将需求包开发出来； 3.开发：即对需求包进行开发成产品阶段； 4.验证：即对产品进行验证阶段； 5.交付：即将产品交付市场阶段； 6.生命周期：即产品在市场上销售，使用，维护和退出市场的阶段。 其中包括了几个重要的决策检查点(DCP)：
1.概念决策检查点：即经过概念阶段各方面进行的一系列评审，在此检查点确定（1） 我们对需求包是否有足够的理解；（2）需求包是否有足够的商业价值。如果是，继续进入计划阶段； 2.计划决策检查点：即经过计划阶段的评估，在此检查点确定（1）我们是否有足够的 资源在既定的时间范围内完成需求包的开发（2）研发部门是否能在(1)的估计上承诺进行开发。如果是，继续进入开发阶段； 3.可交付决策检查点：即经过开发和验证阶段，在此检查点确定（1）产品是否质量合 格以交付给客户（2）我们产品的相应支持和销售是否已经准备好服务客户,如果是，产品交付市场； 4.生命周期结束决策检查点：即产品在市场使用一定时期后，在此检查点确定产品是否 退出市场。 一个产品从市场需求开始，经过概念验证，时间、资源等计划的支持，然后进行开发，验证，直至发布到市场供客户使用，最后在某个特定的时候结束产品在市场上的销售，在IBM都遵循着IPD流程。在其中过程中，这个产品的概念是否被接受，是否能得到资源上的投入的承诺，是否通过最终验证可以在市场上发布，以及什么时候在市场上停售，这些关键的决策都通过相应的委员会在不同的决策点上进行决策。 3. IPD 与产品需求管理流程 以上描述了IBM IPD的基本概念，我们接下来看IBM软件产品的需求管理是如何基于IPD 的。首先，请看下图一：产品需求管理流程。
产品委外合作研发管理规范
产品委外合作研发管理 规范 SANY GROUP system office room 【SANYUA16H-
产品委外合作研发管理规范 XX有限公司 2015年8月 {项目名称} 项 目 合 同
目录 1.合同介绍 (3) 2.开发内容 (3) 3.乙方开发计划 (4) 4.甲方监控计划 (5) 5.甲方验收计划 (6) 6.乙方维护计划 (7) 7.禁止转委托开发 (7) 8.保密 (7) 9.知识产权归属 (7) 10.第三方知识产权 (8) 11.风险责任的承担 (8) 12.报酬及支付方式 (8) 13.违约与赔偿 (9) 14.不可抗力 (9) 15.解除合同 (9) 16.争议解决 (10) 17.一般条款 (10) 18.合同确认 (11) 附件 (11)
1.合同介绍 1.1甲方 1.2乙方 1.3合同目的 甲、乙双方经友好协商,一致达成本协议。双方申明，双方都已理解并认可了本合同的所有内容，同意承担各自应承担的权利和义务，忠实地履行本合同。 2.开发内容 2.1开发内容 （此处将简单描述项目开发内容，详细内容将在附件中包含。） 2.2技术指标和质量要求 （此处为甲方填写，对项目的具体指标和质量要求） 2.3应当遵循的标准和规范 1、此项目将严格按照软件开发标准和规范进行研发。
3.乙方开发计划 3.1开发期限和开发地点 本项目的开发期限为个月，自年月日至年月 日为止。 本项目的开发地点是。 3.2任务与进度 1、甲、乙双方将根据甲方为其业务开发项目及其所需功能的描述和甲方所提供的资料与信息共同制作项目需求分析。甲方在提交有关需求说明、资料和信息时，可以就其中所涉及的软件功能、目标、需求构成及相关技术问题向乙方咨询或征求意见，乙方应当及时予以解释和答复。 2、乙方在获取上述需求信息和资料后，应及时完成需求分析书。该需求分析书经甲方认可，并由甲、乙双方签字后作为本合同的附件。 3、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成需求说明书， 4、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成概要设计说明书， 5、乙方在取得了甲方提供的必要的信息和资料后，将依据本合同所约定的软件的功能、目标与需求分析书，在_________年_________月 _________日之前完成详细设计说明书。 需求说明书、概要设计说明书以及详细设计说明书在完成后，均应提交甲方审核。 3.3开发进度报告
任务管理系统需求分析
项目名称：某企业任务管理系统
1. 项目背景及其需求 1.1 项目背景 xxx有限责任公司（CATTSOFT）（以下简称“xxx”）是xxxx有限公司的全资子公司。xx软件以提供适合各通信网络和通信业务运营商需要的管理软件、支撑软件、增值业务软件系统为业务基础，为各类通信系统运营商或信息系统用户提供业务管理、网络管理、决策支持、系统集成和专业咨询的完整解决方案和服务。 现承接xx软件某业务部门的“业务管理系统”中“任务管理系统”子系统的设计和开发。 1.2 系统需求 1.2.1 术语解释 1.2.1.1 系统管理员 是该系统的一种用户，其权限是添加其他用户并分配其角色（包括主管和员工）。 1.2.1.2 主管 是该系统的一种用户，一个主管下属有一些员工。主管的主要权限是创建任务描述，并将该任务分配给其下属的员工。主管还可以跟踪任务的实施情况。 1.2.1.3 员工 该系统的一种用户，其主要权限是将上级主管分配的任务分解为具体的实施计划。再必要的时候可以调整计划的内容。 1.2.1.4 任务 任务是由主管创建并分配给员工的一项工作。一个任务有“待实施”、“实施中”和“已完成”三种状态。当主管建立一个新任务时，该任务的状态为“待实施”；当承担该任务的员工为该任务制定了计划后，可以将该任务的状态改为“实施中”；主管通过任务跟踪，当认为任务已经完成时，可以将该任务的状态改为“已完成” 1.2.1.5 计划 是由员工创建，表示一个任务的具体实施过程。一个任务可以对应多个计划，计划有两种状态“未反馈”和“已反馈”。当计划刚刚建立时，其状态为“未反馈”，当计划已经完成时，员工可以填写反馈信息并将其状态改未“已反馈”。
产品需求管理文档模板
XXX项目/产品MRD XX有限公司 (版权所有,翻版必究)
MRD修改记录
目录 1 项目背景................................................. 错误!未指定书签。 2 名词解释................................................. 错误!未指定书签。 3 可行性分析............................................... 错误!未指定书签。 前期调研信息和数据............................... 错误!未指定书签。 项目预期目标..................................... 错误!未指定书签。 4 综合描述................................................. 错误!未指定书签。 功能概述......................................... 错误!未指定书签。 对其它产品的影响................................. 错误!未指定书签。 5 功能详述................................................. 错误!未指定书签。 功能需求......................................... 错误!未指定书签。 功能点1 ..................................... 错误!未指定书签。 功能点2 ..................................... 错误!未指定书签。 非功能需求....................................... 错误!未指定书签。 6 其它问题描述............................................. 错误!未指定书签。 7 附件..................................................... 错误!未指定书签。