产品需求管理规范
产品需求管理规范
梁勋州
目录
1 目的 (4)
2 适用范围 (4)
3 需求管理过程 (4)
3.1 需求概念定义 (4)
3.2 需求处理流程 (5)
3.2.1 需求收集 (5)
3.2.2 需求分析 (5)
3.2.3 需求实现与验证 (5)
4 需求属性定义 (6)
4.1 需求名称 (6)
4.2 需求描述 (6)
4.3 需求类别 (6)
4.3.1 系统需求 (6)
4.3.2 产品需求 (6)
4.3.3 子模块需求 (7)
4.4 需求标识 (7)
4.5 需求状态 (8)
4.6 其它属性 (8)
5 需求基线管理 (9)
6 需求跟踪管理 (9)
6.1 角色与职责 (9)
6.1.1 原始需求提出人 (9)
6.1.2 产品开发核心组 (9)
6.1.3 项目经理/产品经理 (9)
6.1.4 子模块经理 (10)
6.1.5 需求管理员 (10)
6.1.6 产品测试人员 (10)
6.1.7 子模块测试人员 (10)
6.2 需求跟踪关系 (11)
6.3 需求跟踪流程 (12)
7 需求变更管理 (13)
7.1 角色与职责 (13)
7.1.1 变更提交人 (13)
7.1.2 变更审核人 (13)
7.1.3 变更实施人 (13)
7.1.4 修改审核人（同行评审人） (13)
7.1.5 测试经理 (14)
7.1.6 测试责任人 (14)
7.1.7 各指定跟踪人 (14)
7.1.8 CCB (14)
7.1.9 配置管理员 (14)
7.1.10 需求管理员 (14)
7.2 需求变更流程 (15)
7.2.1 01 变更提交 (16)
7.2.2 02 03变更审核 (16)
7.2.3 04 变更实施 (16)
7.2.4 05 修改审核 (16)
7.2.5 06 二次审核 (17)
7.2.6 07 配置项与基线管理 (17)
7.2.7 08 09 测试审核与验证 (17)
7.2.8 10 同步需求跟踪矩阵 (17)
8 需求度量 (17)
8.1 需求状态统计 (17)
8.2 需求变更统计 (18)
8.3 需求稳定度 (18)
产品需求管理规范
1 目的
规范产品开发需求管理，更好的为产品开发建立统一的需求管理机制和跟踪机制，保证产品开发成果与需求的一致性，减少产品开发的风险。
2 适用范围
本规范适用产品开发阶段需求管理的定义和规定，包括属性定义、基线定义、需求跟踪、需求变更和需求度量五个方面。
3 需求管理过程
3.1 需求概念定义
I E E E软件工程标准词汇表（1 9 9 7年）中定义需求为：
用户解决问题或达到目标所需的条件或权能（ C a p a b i l i t y）。
系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
一种反映上面（1）或（2）所描述的条件或权能的文档说明。
从上面的需求定义我们可以了解到需求的关键问题是一定要编写需求文档，需求文档是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。
3.2 需求处理流程
3-1 需求处理流程
如图3-1所示，整个需求处理流程分为需求收集、需求分析、需求实现、需求验证四个阶段，而需求管理贯穿整个需求处理流程。
3.2.1 需求收集
需求收集涉及各个部门，由市场部汇总形成原始需求库。
3.2.2 需求分析
需求分析的接口部门为SE或相关技术部门。
3.2.3 需求实现与验证
需求实现由产品开发团队完成，产品开发团队由产品经理或项目经理组织，对需求进行分析形成产品需求规格说明书，同时建立产品需求管理数据库。
产品开发项目团队负责对产品需求进行设计实现，并提交进行需求验证，输出满足需求的产品。
4 需求属性定义
4.1 需求名称
需求名称要求最简捷的语言描述需求的最核心内容。统一定义为用自然语言描述，采用中文或英文命名，不允许出现中英文并存。
4.2 需求描述
需求的最本质内容、可以用模型、图、表表示。应准确描述出需求的输入、输出关系。
4.3 需求类别
4.3.1 系统需求
网络系统需求：指从整个网络系统角度提出的需求，涉及到研发各部门的需求；
业务需求：从系统级别提出的业务需求，涉及到研发各部门。
4.3.2 产品需求
产品开发系统需求：指为了实现产品所必须的有关系统级需求，如操作系统、网
络平台、配置要求、内存与外围设备要求，以及所需的软件包等。
功能需求：指产品在完成系统需求和业务需，所实现的功能上的需求。产品开发
人员对系统需求、业务需求和原始需求进行分析，从分析描述输入、输出等方面进行
具体的定义。
性能需求：指产品在完成业务的性能方面的需求，如射频指标、功耗、省电、环
境适应性、EMC等要求。
可靠性需求：指整机产品或半成品可靠性方面的设计需求，涉及产品的环境、振动、老化、失效分析等方面。
可维护性：指产品在生产、售后方面要具备可维护性，便于操作和远程控制。
可安装性：指从工程角度定义产品的可安装性。
可生产性：从生产工艺、生产流程控制、提供的生产工具、生产速度等方面定义的需求。
可测试性：具备生产、制造、现场测试、远程测试方面的需求描述。
成本需求：指产品在成本方面的需求，如物料成本、制造成本、运输成本、宣传成本、市场价格等要求。
造型需求：产品外形及造型方面的需求，如颜色、外形；
附件和包装需求：指对产品附件和包装等方面的需求，如包装、说明书、保修卡、随机附件、安装指导书等。
认证需求：指产品为了满足认证标准而提出的需求，如入网认证、型号核准、3C 认证、绿色认证等。
其它需求：除以上方面外，产品需满足的其它需求。
4.3.3 子模块需求
硬件需求：指产品在硬件方面的需求，如器件、接口定义、工艺要求、外协件、替代件、可生产性、硬件可测试性、环境适应性、EMC等。
结构需求：指产品在结构设计、结构件、开模、外协厂家、布局、防水、防尘、防火、防潮等要求。
软件需求：指产品在软件方面的需求，如人机界面、软件可测试性、接口定义等要求。
4.4 需求标识
X YYYYYY
需求级别
说明：
X，需求级别：
Sys 系统需求
P 产品需求
H 产品硬件需求
S 产品软件需求
C 产品结构需求
4.5 需求状态
需求状态是用来在需求跟踪过程中标志其需求实现过程的阶段。包括：建议、批准、实施、已测试、完成或拒绝、推迟、删除。
图4-1 需求状态跟踪图
4.6 其它属性
?需求来源，需求的更高层依据、来源、提出群体；
?原始需求ID，对应原始需求的序列号；
?需求优先级，表明高、中、低，以备需要取舍或先后响应时决策；
?需求负责人，实现需求的责任人，需跟踪到具体项目；
?需求可行性，可行、不可行；
?需求工作量，实现需求需要投入的人力、时间，分为巨大、大、小；
?需求风险，分为高、中、低三个级别，主要从满足市场方面进一步确定级别，
涉及到研发周期、市场需求等方面；
?需求易变性，按易变属性定义为很可能、可能、不大可能；
?需求验收标准，确认需求实现的结果，定义为满足、部分满足、不满足；
?需求的版本，需求变化时的演进版本；
?需求变更ID；
5 需求基线管理
基线是指在产品开发过程中的里程碑，这些里程碑的标志是一项或多项经过正式的技术评审并一致认同的成品或制品的提交。
产品开发过程的制品经过正式评审并被相关人员一致同意，可以作为以后产品开发的基础。在用户和产品组之间达成共识、并已经按需求属性建立需求数据库的需求，就可以认为是完成建立需求基线的基本条件。对已经基线化的制品修改必须要通过正式的变更控制流程。
需求基线的核心是按基线进行控制。配置管理组或委员会（CCB）按照需求基线，对整个项目的进程，进行控制和把握，配置管理员负责把符合基线要求完成的构件，放进配置管理库中，并及时发布相关需求基线，这样确保了整个需求的基线化。
6 需求跟踪管理
6.1 角色与职责
6.1.1 原始需求提出人
?收集来自各方面的原始需求；
?制定原始需求表，入原始需求库，跟踪原始需求实现；
6.1.2 产品开发核心组
?制定产品需求规格书，建立产品需求基线；
?进行产品的需求分解；
6.1.3 项目经理/产品经理
?负责根据项目进展调整项目计划，及时通知相关人员；
?组织确认产品需求实现结果，重点关注项目里程碑关键点；
6.1.4 子模块经理
?组织制定子模块需求规格书，进行需求分解；
?组织确认子系统需求实现结果，重点关注子模块设计关键点
6.1.5 需求管理员
?制定需求跟踪矩阵；
?跟踪项目进度，及时更新需求跟踪矩阵；
?处理需求变更，及时调整需求跟踪矩阵；
6.1.6 产品测试人员
?制定产品测试方案，形成测试用例；
?产品系统测试；
6.1.7 子模块测试人员
?制定集成测试方案，形成测试用例；
?产品集成测试；
图6-1需求跟踪关系
图6-2 需求跟踪流程
01原始需求人收集原始需求，形成原始需求表或入原始需求库；
02产品核心组制定产品需求规格书，建立产品需求基线，进行产品需求分解；03项目经理根据项目进展，制定项目计划；
04需求管理员根据产品需求规格书制定需求跟踪矩阵中产品需求属性部分；
05产品测试人员根据产品需求规格制定测试方案，形成产品测试用例；
06子模块经理组织制定子系统需求规格，建立子系统需求基线，进行需求分解；
07子模块测试人员根据子系统需求规格制定测试方案，形成测试用例；
08需求管理员跟踪项目进展，在各子系统需求基线建立后，及时更新需求跟踪矩阵中子系统相关属性；
09集成测试、硬件测试或相关正样测试；
10集成测试、硬件测试或相关正样测试后，子模块经理组织相关技术专家进行子系统需求回溯，需求管理员进行跟踪；
11系统测试；
12系统测试完成后，项目经理组织相关技术专家进行产品需求回溯，需求管理员进行跟踪确认；
7 需求变更管理
7.1 角色与职责
7.1.1 变更提交人
产品开发团队中任何一个成员都可以作为变更提交人提交本项目的变更单。变更提交人必须准确填写需求变更的各种属性信息、变更原因。
7.1.2 变更审核人
变更审核人包括项目经理、软件经理、硬件经理、工艺结构经理等，原则上一般各只有一个成员，符合每个当前处理人只有一个的原则，以明确每个状态的当前处理责任。项目经理对提交的本项目范围的变更单进行评审，以决定该问题的处理方式。
7.1.3 变更实施人
负责对审核人安排的需求变更进行需求实现，如提交设计方案或直接提交需求实现结果，并同步更改相关需求规格文档。
7.1.4 修改审核人（同行评审人）
同行评审人对需求实现的处理结果进行审查，审核需求文档的一致性，降低变更
可能引起的风险。
7.1.5 测试经理
每个项目都指定一个测试经理，可由项目经理执行操作，其职责是对变更的需求进行测试组织分派。
7.1.6 测试责任人
一般由测试部或中试人员担任，根据变更的需求设计测试用例，更新测试用例文档，实施测试验证，根据验证的结果进行不同的操作处理。对于处理结果和拒绝理由成否决态度的都交由其项目经理进行下一步处理。
7.1.7 各指定跟踪人
各指定跟踪人包括指派分析研究人和延期跟踪人。对于需要进行进一步分析研究的问题，指定项目成员组中一个人去进行分析研究，到指定日期前必须提交研究提案。延期跟踪人一般由变更审核人担当，对需要延期的变更进行跟踪，到指定日期前重新审核（可不设定延期期限，此类变更视为变更挂起）。
7.1.8 CCB
CCB由产品经理、市场经理、开发代表（硬件、软件、结构）、项目经理、质量保证工程师。对于审核人不能做决定处理的问题需要提交到ＣＣＢ进行决定，ＣＣＢ的决策反馈是审核人处理变更的依据，包括产品需求的取消、删除、拒绝和变更。
7.1.9 配置管理员
配置管理员主要负责配置项的管理、入库、基线管理。
7.1.10 需求管理员
需求管理员主要负责本项目需求的跟踪，及时将变更情况更新到需求跟踪矩阵中。
7.2 需求变更流程
图7-1 需求变更流程
7.2.1 01 变更提交
变更提交人建立需求变更单，准确填写需求的属性、变更原因。
7.2.2 02 03变更审核
变更单在提交成功后的第一个状态就是待产品/项目经理决策，目前主要由变更审核人对变更的信息进行分析，以决定将采取哪个动作，使状态进入到下一个状态，可选择下面一条路径：
A）指派实施人：指派修改处理人、同行评审人，测试验收人。必须填写紧急程度、引入阶段、实施人、完成期限。如果变更实施人不唯一，可以通过分解
单实现指派多人实施修改。
B）提交上级：提交CCB进行研究决策。
C）指派研究：确定需要研究的变更，指定项目组人员进行研究。
D）项目产品经理打回：如变更单基本信息不完整或不充分，审核人将变更单打回提交人重新填写基本信息。
E）关闭：变更审核人判定不需提交此单更时，变更请求可直接关闭，并抄送申请人。
F）延期：暂时没有时间解决的问题，变更审核人可以做延期处理。延期处理要提交CCB审核；
7.2.3 04 变更实施
A）变更实施：变更实施人根据变更审核人指定执行各种可能的动作。情况1，修改后提交同行评审，再提交入版本库审核；情况2，直接提交入版本库审
核；
B）跟踪CCB反馈：上级领导提供反馈执行后状态迁移到“待产品项目审核”对变更重新审核。
C）提交分析结果：指定紧急程度、缺陷引入阶段等。
7.2.4 05 修改审核
修改审核（即，同行评审）：由评审人（开发人员验证）对变更实施人的修改结果进
行评审，以确定修改结果是否合理，并根据评审结果确定是否通过。
7.2.5 06 二次审核
1）对变更波及因素批准变更合入路径和版本。可以合入多个版本，即一个变更可能引起的多个版本修改。
2）更审核根据配置项特点，决定是否需要测试验证，如需进行测试，二次审核中需指定测试经理组织测试。
7.2.6 07 配置项与基线管理
配置管理员执行，当变更审核完成后并提交合入受控库后，即由配置管理员纳入配置库集成流，按项目基线规定完成版本制作。
7.2.7 08 09 测试审核与验证
1）测试审核：完成变更实施，通过修改评审及二次审核后，如果二次审核判定需进行测试验证，同由指派的测试经理组织测试人员从基线库取得测试
配置项基线进行测试，测试审核需根据项目版本测试计划确定此变更的配
置项是否延期测试（限定延期期限），做好进度安排。
2）测试验证：对变更的需求制定测试方案，形成测试用例，进行测试验证，给出测试结论及意见。
7.2.8 10 同步需求跟踪矩阵
需求管理员跟踪需求变更情况，及时更新需求跟踪矩阵。
8 需求度量
8.1 需求状态统计
需求状态包括建议、批准、实施、已测试、完成或拒绝、推迟、删除。需求状态的统计有助于了解分析需求和项目进展的状况，了解项目是否如期进行，及时发现需求管理中的问题。
需求的状态统计可采用图表或公式方法进行统计，用于表示不同状态下的需求数目
占总需求数目的比例。
需求状态统计在项目开发阶段每两周统计一次。
8.2 需求变更统计
需求变更统计主要进行需求变更数量、需求变更趋势的统计；
需求变更数量可采用图表和公式的形式统计各模块需求的变更数量，同时用表格形式列出所有变更的需求；
需求变更趋势采用图表趋势图形式统计需求变更的总体趋势。
8.3 需求稳定度
需求稳定度可采用需求稳定指数来衡量。
需求稳定指数＝100％×（需求增加、删除、变更总数）/需求总数，需求总数指产品需求规格中确定的需求数。
产品管理规范
产品管理规范 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-
产品管理规范 公司管理体系文件编号： 产品管理规范版号： 页码：共21页 编制：日期： 审核：日期： 批准：日期： 1 目的 实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。 有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。 2 范围 本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据，各相关营销、生产部门必须遵照执行。 3 职责 产品管理是企业在产品生命周期中对产品规划、开发、生产、运营和支持等环节进行管理的业务活动，包括需求管理、市场管理以及开发管理 4 内容 具体如下： 产品战略规划
产品战略包含：1 产品路线 2 产品策略 3 产品计划 产品研发 产品研发包含：1 需求阶段 2 设计阶段 3 开发阶段 4 测试阶段 5 发布阶段（上线） 产品生命周期 产品生命周期包含：周期管理（1 导入期 2 成长期 3 成熟期 4 衰退期）组织、主要人员及职责 1组织结构 2重要角色 重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负 责人。 重要角色包括：产品经理（需求提出人）、需求管理员、技术人员、运 营人员。 3其中对重要角色职责及相关要求定义如下： 产品管理会 产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划经理、用户研究人员、产品负责人、开发负责人、运营负责人等共同组成。 主要职责： （1）制定运营计划，确定运营目标； （2）优化产品，制定运营策略； （3）监控产品质量，把控经营结果；
需求管理规范V
密级：内部公开 文档编号：SL_RD_XQGLGF 需求管理规范 ------------------------------------------------------------------- XXX科技公司对本文件资料享受着作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
目录
1.目的 为了保证需求得到有效的处理，客户的需求得到准确的理解和实现，同时也为了规范需求的管理过程，明确需求各个阶段的活动和输出，保证项目的开发前 期获得有效的输入，特制订本规范。 2．范围 本规范适用于公司所有产品研发类、产品开发类、合同开发类以及维护开发类项目。 3．术语 4.部门/角色与职责
5.内容 5.1流程图 图1需求开发与管理过程活动示意图
5.2主要活动 需求管理的目的是在客户与项目组之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求确认，需求变更和需求跟踪控制。 （需求的收集和整理） 产品经理作为需求的唯一接入口，应基于现有产品的业务发展方向，通过与用户的交流、问卷调查等方式，收集用户对于该产品业务的看法，并对这些看法进行归类整理和登记，达成口头或者是书面的需求意向协议书。 （这个过程需要对产品的业务建立起一个概念模型，以便对其进行抽象描述。用户很多时候都不懂专业术语，所以需要尽可能的使用场景化的语言描述方式去进行描述。比如想调研用户的理财方式，很多用户可能不清楚“理财”的具体意思，但你问他“平时是如何管理多余的资金，是变成银行存款还是有别的方式？”可能他会更容易明白。） 产品经理就获得的需求意向或者意向协议书，围绕产品的业务核心，进行初步的评估，预判其成本、时间、资源、技术等可行性和必要的风险评估，以确认需求是否要接受。 除了要从收集回来的需求当中找到要做的真实需求外，还要基于需求的业务价值评判出需求执行的优先级。 其评估的过程，产品经理可以召集研发负责人，组织一次需求的分析讨论会，以便对需求更全面的分析。 根据需求调研和需求分析的结果，进一步定义准确无误的产品需求。完成需求的分解工作，并输出产品功能需求文档，包括但不限于以下内容：详细的《产品需求说明书》，《功能列表》，《技术指标参加资料》等。 产品功能需求文档编写完成后，产品经理召集产品设计启动会，向UE、UI、研发人员宣讲产品功能需求，讨论实现方案，启动开发设计工作。 （需求定义的过程更多的是对需求进行准确的描述，从用户使用场景的角度、功能操作流程的角度等方面，对分析出来的真实需求做出完整、无二义性的定义，让其他相关人员能准确的理解需求。） 需求确认是指项目组和客户（或客户代表）共同对《产品需求说明书》、原型等进行评审，双方对需求达成共识后做出承诺。 UI/UE工程师在规定的时间内完成产品设计文档（效果图和原型），召集产品设计评审会（同时也是产品开发启动会），向需求部门、产品经理、研发、测试宣讲产品开发需求，各部门对产品设计文档进行评审确认，达成统一认知和共识，使需求能够推进实现落地。 在需求评审的过程中，一定要说明清楚需求的背景、价值、意义，而不是纯粹的需求讲解，这样有助于各方对需求的理解。 需求确认包含两个重要工作：“需求评审”和“需求承诺”。 需求的评审 应对所形成的需求文档进行评审，以便作为下一阶段工作的基础。需求评审
《产品需求管理》
●理解产品包需求（OR，Offering Requirements）的概念、产品包需求分层、需求工 程方法论 ●如何与其他部门协作采集高价值的用户需求、掌握需求的变化 ●掌握如何用模板和工具来参与并指导相关部门识别、采集高价值的用户需求 ●如何透过需求描述的表象得到的顾客效用与价值，即掌握顾客的心声 ●基于培训和讨论、整理出需求调研访谈指南 ●掌握筛选、解释需求的工具，评审分析市场需求的价值 ●学习如何有效的激励其他部门配合，让需求管理流程形成一个快速畅通的闭环 ●分享讲师在著名企业产品开发、研发管理实践经验和十多年的咨询/培训经验，并 通过现场的互动和全方位案例资料（如：流程、模板、查检表等）的展示帮助学员“学以致用”，理清适合自己企业在产品需求管理方面的工作思路以及具体的实践方法和工具。 客户的需求不断变化，如何快速高效地推出满足客户需求、具有差异化优势和竞争优势的产品，并最终获得市场的成功，是企业的核心问题！我们发现国内许多科技型企业在产品需求管理方面存在如下问题： 1. 产品开发没有实现市场驱动，是“闭门造车”，关注技术而不关心客户；产品开发出 来后才找客户、找卖点； 2. 缺乏完备的需求收集、汇总、整理和分析机制，导致研发和市场脱节，需求无法有 效传递和落实，相关环节和部门（如：客户、市场部、开发部、测试部等）对需求 的理解也不一致，经常针对需求“吵成一锅粥”； 3. 对客户/市场需求分析不充分、不透彻、不完整，导致产品需求变化频繁，产品开发 大量返工，“计划不如变化快”，开发过程“失控”； 4. 需求管理各个阶段的职责不清晰，也缺乏组织支撑；往往了解市场的不懂技术，懂 技术的不了解市场，不知道需求应该由谁负责；
需求管理规范
目录 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.合理性评价...........................................................................................................
业务需求管理制度
业务需求管理制度 第一条总则 规范各部门有关业务需求的提出、变更及维护，为整体业务系统建立统一的需求管理机制和跟踪机制，从而提高沟通效率及需求反馈的响应速度和透明度，保障产品开发结果与需求的一致性，特制定本细则。 第二条适用范围 本规定适用于管理所有业务部门提交到本部的所有需求。 第三条定义 1、业务需求：对需要在整体业务系统中实现或调整的业务功能的说明或描述； 2、业务需求方：为公司整体业务系统提出所要实现或调整功能的部门，包括无线运营部、销售服务部和财务结算部等； 3、业务需求承接方：负责承接业务需求，目前由产品技术部的产品专员对接各部门的需求。 第四条需求的重要程度 需求部门所需功能对整体业务系统的影响程度，可分为非常重要、重要和一般三个级别，非常重要为最高级别。 a)非常重要：业务系统所需的该项功能对整体业务系统影响非常大，如该需求为关键流程的关键环节； b)重要：业务系统所需的该项功能对整体业务系统影响大； 页脚内容1
c)一般：业务系统所需的该项功能对整体业务系统影响一般，如页面显示文字、字体、颜色等。第五条需求的紧急程度 需求部门所需功能的急迫程度，可分为非常紧急、紧急和一般三个级别，非常紧急为最高级别。 a)非常紧急：所提业务需求非常急迫，如不尽快实现，关键业务流程不能被正确执行、且无可替代措施； b)紧急：所提业务需求比较急迫，如不尽快实现，业务流程不能被正确执行，但存在可替代措施或方法； c)一般：所提业务需求急迫性一般，不会对现有流程存在较大影响。 第六条需求提交 各部门通过JIRA填写详细需求信息，向需求承接方发起需求任务，在需求提出时需注意以下几个方面： 1、详细描述需求背景、需求内容，包含需求介绍、功能性需求详细描述及数据需求描述，明确本部门需求对接人； 2、提出需求时应说明需求的重要程度和紧急程度； 3、提出需求时应认真考虑业务需求的合理性、完整性和前瞻性，充分考虑各种流程、各个环节以及异常流程的处理； 4、为更加清楚地说明业务需求变更情况，可附带附件、附图等文档。 第七条需求分析 1、需求承接方就接受到的需求进行需求分析，需求不明确的地方与需求方及时进行沟通，并在 页脚内容2
产品需求分析管理和产品规划培训课程
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
需求管理规范 (2)
需求管理体系改进方法研究 需求管理过程 当软件开发完成需求开发工作之后，不可避免地会遇到软件需求的变更。有效的需求管理需要对变更带来的潜在影响及可能的成本费用进行评估。变更控制委员会与关键的项目风险承担者要进行协商，以确定哪些需求可以变更。同时，无论是在开发阶段还是在系统测试阶段，还应跟踪每项需求的状态。需求管理的主要工作如下： 1) 确定需求变更控制过程：确定一个选择、分析和决策需求变更的过程。所有的需求变更都需遵循此过程，商业化的问题跟踪工具都能支持变更控制过程。 2) 建立变更控制委员会：组织一个由项目风险承担者组成的小组作为变更控制委员会，由他们来确定进行哪些需求变更，此变更是否在项目范围内，估价它们，并对此评估作出决策以确定选择哪些，放弃哪些，并设置实现的优先顺序，制定目标版本。 3) 进行需求变更影响分析：应评估每项选择的需求变更，以确定它对项目计划安排和其它需求的影响。明确与变更相关的任务并评估完成这些任务需要的工作量。通过这些分析将有助于变更控制委员会作出更好的决策。 4) 跟踪所有受需求变更影响的工作产品：当进行某项需求变更时，参照需求跟踪能力矩阵找到相关的其它需求、设计模板、源代码和测试用例，这些相关部分可能也需要修改。这样能减少因疏忽而不得不变更产品的机会，这种变更在变更需求的情况下是必须进行的。 5) 建立需求基准版本和需求控制版本文档：确定一个需求基准，这是一致性需求在特定时刻的快照。之后的需求变更就遵循变更控制过程即可。每个版本的需求规格说明都必须是独立说明，以避免将底稿和基准或新旧版本相混淆。最好的办法是使用合适的配置管理工具在版本控制下为需求文档定位。 6) 维护需求变更的历史记录：记录变更需求文档版本的日期以及所做的变更、原因，还包括由谁负责更新和更新的新版本号等。 7) 跟踪每项需求的状态：建立一个数据库，其中每一条记录保存一项功能需求。保存每项功能需求的重要属性，它包括状态（如已推荐的，已通过的，已实施的，或已验证的），这样在任何时候都能得到每个状态类的需求数量。 8) 衡量需求稳定性：记录基准需求的数量和每周或每月的变更（添加、修改、删除）
XXXX-需求管理规范V1.1
密级：内部公开 文档编号：SL _RD_XQGLGF 需求管理规范 编制：XX生效日期：2018-03-09 审核：XXX批准： ------------------------------------------------------------------- XXX科技公司对本文件资料享受著作权及其它专属权利，未经书面许可，不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
2017-07-21 0.1 创建XX XXX
目录 1.目的.............................................................................................................................. - 3 -2．范围........................................................................................................................................ - 3 -3．术语........................................................................................................................................ - 3 - 4. 部门/角色与职责.................................................................................................................... - 3 - 5. 内容......................................................................................................................................... - 4 -5.1 流程图................................................................................................................................. - 4 -5.2 主要活动............................................................................................................................. - 5 - 5.2.1需求获取（需求的收集和整理）..................................................................... - 5 - 5.2.2需求分析............................................................................................................. - 5 - 5.2.3需求定义............................................................................................................. - 5 - 5.2.4需求的确认......................................................................................................... - 6 - 5.2.5需求的实现......................................................................................................... - 7 - 5.2.6需求的测试......................................................................................................... - 7 - 5.2.7需求跟踪............................................................................................................. - 7 - 5.2.8 需求变更............................................................................................................ - 7 - 6.相关附件、表单....................................................................................................................... - 8 -
产品需求开发管理规范
产品需求开发管理规范 为规范需求管理流程，特制定本规范。请相关岗位人员参考执行，以提高沟 通效率，降低项目风险。 0 流程图 需求处理流程 产品业务客户技术测试与售后阶段 沟通处理需求提出需求收集需求问题反馈整理分析需求需求设计 （原型）接收反馈客户打回/接收 需求评审需求文档编写通过不通过需求评估开发排期确认不通过 通过 功能开发单元测试 功能测试性能测试确认验收 发布使用商务沟通 收费功能 上线检测 涉及部门/岗位人员类型说明： 客户：包括已经购买或潜在客户，及终端用户。 业务：是指销售、代理商或其他一线与客户接触的工作人员。 产品：产品规划设计人员。 技术：技术经理、开发工程师、设计师（UE\UI ）等人员。 测试：测试经理、测试工程师等。 售后：售后服务人员，包括热线电话或在线客服等。
需求收集一般分为两种途径，一线业务人员（销售或代理商）与售后服务部。需求收集后需要提交至产品部进行需求分析，根据具体情况给出需求处理结果，如果需求存在异议产品人员可以与客户联系沟通确认清楚。在此过程中产品人员应该根据客户所处的商务阶段（如有合同条款）判断是否需要另行收费，技术人员需要配合产品评估大致工时，以确定收费金额。 在此过程中可能存在需求打回的情况，需要产品人员给出分析结果并与相关人员沟通确认。在确定打回后业务人员应积极配合沟通客户，以确保客户满意度。无论是打回还是受理都需要向客户反馈情况。 输入：需求收集表（根据具体情况可能包含可行性分析，或与产品一起提出）、需求检测工单 输出：需求跟踪表 参与人：业务、售后、产品 2原型设计 原型设计是产品人员根据所确定的需求进行功能设计的过程，用相应方法能完整的展示传递功能、交互、验证等信息。可以用word、Excel、PPT等方式进行描述，最好是使用Axure。 输入：需求跟踪表 输出：功能原型（rp文件） 参与人：产品
需求管理制度
零壹移动互联 需求管理制度（版，2015年） 修改记录
目录 第一章总则................................................. 错误!未定义书签。第二章职责与分工........................................... 错误!未定义书签。第三章需求总体说明......................................... 错误!未定义书签。第四章需求提交............................................. 错误!未定义书签。第五章需求评估............................................. 错误!未定义书签。第六章需求开发............................................. 错误!未定义书签。第七章系统测试............................................. 错误!未定义书签。第八章需求上线............................................. 错误!未定义书签。第九章生产问题管理......................................... 错误!未定义书签。第十章需求变更控制与管理................................... 错误!未定义书签。第十一章需求进度监控及查询................................. 错误!未定义书签。第十二章附则............................................... 错误!未定义书签。
需求管理制度V2.0
零壹移动互联 需求管理制度（2.0版，2015年） 拟制人肖波日期20150630 审核人日期 批准人日期 修改记录 日期版本 作者/修 改者 描述审核人 20150701 V2.0 肖波修改需求开发管理流程与相关人员 分工 -1-
目录 第一章总则 (3) 第二章职责与分工 (3) 第三章需求总体说明 (4) 第四章需求提交 (7) 第五章需求评估 (7) 第六章需求开发 (10) 第七章系统测试 (11) 第八章需求上线 (13) 第九章生产问题管理 (14) 第十章需求变更控制与管理 (14) 第十一章需求进度监控及查询 (17) 第十二章附则 (17) -2-
第一章总则 第一条为规范零壹移动互联（以下简称“零壹”）需求管理，明确各阶段的工作内容、处理流程、参与人员以及相关干系人的职责，在保证需求质量的同时，提高需求实现效率，特制订本制度。 第二条本制度适用于研发部的所有系统开发需求。 第三条本制度适用的读者包括需求开发负责人、需求提交人员、需求评估人员、开发人员、测试人员、生产运维人员、项目管理员等。 第二章职责与分工 第四条职责分工 角色职责 需求提交人员1.负责需求调研与编辑、编写业务需求申请表、提交业务需求审批。 2.根据需求评审和评估意见，及时修改业务需求，并发给需求相关干 系人。 3.配合需求开发、测试人员提供业务知识的支持。 4.协助确认需求开发结果。 5.负责需求上线后验证工作。 项目管理人员1.负责需求审批、评估、技术文档评审、测试、上线等需求管理流程 的整体协调工作。 2.组织需求评估会议。 3.处理测试申请----提交测试部门进行分配与测试。 4.维护需求信息、跟进需求变更以及需求处理进展，定期向相关领导、 部门汇报需求进展。 需求开发负责人1.参与需求评审，从技术角度对需求实现方式、风险等进行评估。 2.制定需求开发计划，分配需求开发人员。 3.负责需求所有工作的沟通、协调管理。 4.负责需求开发进度、成员、变更管理。 5.负责或参与需求所有成果的审批。 需求评估人员1.从架构、业务、技术、风险等方面对业务需求的内容和实现方式进 行全面评估，并提出评估意见。 2.审核根据评估意见修改后的业务需求。 -3-
需求管理系统要求规范说明书V1.0-20140412
需求管理规范说明数据产品事业部-生产部-采集部
文档履历
发布范围
目录 1.目的 (2) 2.适用范围 (2) 3.术语及定义 (2) 3.1需求管理 (2) 3.2需求获取 (2) 3.3需求列表 (2) 3.4需求状态 (2) 4.执行准则 (2) 5需求管理过程 (3) 5.1需求过程所涉及工作 (3) 5.1.1需求定义 (3) 5.1.1.1需求获取 (3) 5.1.1.2需求分析 (4) 5.1.1.3需求说明 (4) 5.1.1.4需求验证 (6) 5.1.2需求维护 (6) 5.1.2.1需求基线定制 (6) 5.1.2.2需求变更 (7) 5.1.2.3需求跟踪 (9) 5.1.2.4需求状态 (10)
1.概述 需求管理，需要明确需求管理流程，并对每个相关部门所应有的责任与权利进行界定，同时要建立有效的监管措施，使流程中的每个环节都能发挥有效作用。 需求管理不是项目前期的一个环节，而是贯穿整个项目的关键流程。在具体进行需求管理时，应该着重注意明确职责避免缺位、需求应分层沟通和确认、分步实施和先易后难的原则。 2.目的 为了阐述清楚一个项目需求各个层次中的每一个环节设计考虑。保证项目执行的质量、进度、需求的完整与可追溯性。保证业务需求提出者与需求分析人员、项目执行人员、验收人员及其也相关利益人对需求达成共识。 3.适用范围 本管理规范只适用于数据产品事业部-采集部需求管理人员。 4.术语及定义 4.1需求管理 是一种获取、组织、并记录项目所产生或接受的技术性、非技术性需求，以及组织项目的需求。 通过需求管理能够管理所有的需求变更、维护需求与项目实施过程的关系、识别需求与工作产品间的不一致，使客户、与项目团队对不断变化的需求达成并保持一致。 4.2需求获取 是业务规划部门依据需求方提交的业务需求，经过分析、整合、加工而形成的按系统、分功能抽象记录的需求概述。它是项目管理的基本单元，也是用户需求编写的依据。 4.3需求列表 是需求分析人员依据需求条目，通过分析，按照需要实现的目标点组织编写的需求清单。 4.4需求状态 指某时间点上反映出的需求问题情况。 5.执行准则 1、必须列明需求条目 2、必须列明用户需求列表 3、需求一定要进行分类 4、需求需分优先级
软件项目管理系统要求规范
软件项目管理规范 一、软件项目管理的定义 软件项目管理是软件工程和项目管理的交叉学科，软件项目管理的概念涵盖了管理软件产品开发所必须的知识、技术及工具。根据美国项目管理协会PMI对项目管理的定义可以将软件项目管理定义为：在软件项目活动中运用一系列知识、技能、工具和技术，以满足软件需求方的整体要求。 软件工程的活动包括问题定义、可行性研究、需求分析、设计、实现、确认、支持等，所有这些活动都必须进行管理，软件项目管理贯穿于软件工程的演化过程之中，如图1所示。 图1 软件工程的演化过程 二、软件项目管理的过程 为保证软件项目获得成功，必须清楚其工作范围、要完成的任务、需要的资源、需要的工作量、进度的安排、可能遇到的风险等。软件项目的管理工作在技术工作开始之前就应开始，而在软件从概念到实现的过程中继续进行，且只有当软件开发工作最后结束时才终止。管理的过程分为如下几个步骤： （1）启动软件项目 启动软件项目是指必须明确项目的目标和范围、考虑可能的解决方案以及技术和管理上的要求等，这些信息是软件项目运行和管理的基础。 （2）制定项目计划 软件项目一旦启动，就必须制定项目计划。计划的制定以下面的活动为依据。 ·估算项目所需要的工作量 ·估算项目所需要的资源 ·根据工作量制定进度计划，继而进行资源分配 ·做出配置管理计划 （3）跟踪及控制项目计划 在软件项目进行过程中，严格遵守项目计划，对于一些不可避免的变更，要进行适当的控制和调整，但要确保计划的完整性和一致性。 （4）评审项目计划 对项目计划的完成程度进行评审。并对项目的执行情况进行评价。 （5）编写管理文档 项目管理人员根据软件合同确定软件项目是否完成。项目一旦完成，则检查项目完成的结果和中间记录文档，并把所有的结果记录下来形成文档而保存。 三、软件项目管理的内容
产品管理规范
产品管理规范 1 目的 实现以市场为导向的产品规划，有计划有组织地进行研究与产品开发活动。有效地调动营销部门以及生产部门的创造性思维，把市场与消费者的认识转换在新产品中，确保产品开发和企业产品战略的一致性，快速、合理应对市场需求，规避产品投资风险，并为企业获得最大限度的利润。 2 范围 本制度适用于本公司产品开发、上线、管理全过程，对产品管理的流程做出规定，是公司管理产品规划工作的依据，各相关营销、生产部门必须遵照执行。 3 职责 产品管理是企业在产品生命周期中对产品规划、开发、生产、运营和支持等环节进行管理的业务活动，包括需求管理、市场管理以及开发管理 4 内容 具体如下：
?产品战略规划 产品战略包含：1 产品路线2 产品策略3 产品计划 ?产品研发 产品研发包含：1 需求阶段2 设计阶段3 开发阶段4 测试阶段5 发布阶段（上线） ?产品生命周期 产品生命周期包含：周期管理（1 导入期2 成长期3 成熟期4 衰退期） ?组织、主要人员及职责 ?1组织结构 ?2重要角色 重要角色负责人：产品负责人、研发负责人、产品管理负责人、运营负责人。 重要角色包括：产品经理（需求提出人）、需求管理员、技术人员、运营人员。 ?3其中对重要角色职责及相关要求定义如下： ?产品管理会 产品管理会由产品中心、运营中心、产品研发中心总监以及参与在产品生命周期过程中的产品规划经理、用户研究人员、产品负责人、开发负责人、运营负责人等共同组成。 主要职责： （1）制定运营计划，确定运营目标； （2）优化产品，制定运营策略； （3）监控产品质量，把控经营结果； （4）对产品进行全生命周期管理； （5）对产品需求的提出、终止和变更进行决策； （6）监督产品管理相关制度的执行。 ?评审委员会
需求管理规范
需求管理规范 需求采集 采集说明 1.通过各种形式对用户的需求进行收集，通常的形式有：用户访谈，调查问卷，数据分析，领导提供需 求，产品人员需求等。 2.在这个阶段对需求的属性详细记录，并且记录可追溯的反馈人员。 采集要求 1.采集的需求必须符合运营需求。 2.需求必需符合icage产品定义。 3.需求必需具有可实现性、拓展性、可开发和合理性。 4.项目组成员确认，对人员进行限制，不能有过多相关人员加入 5.满足用户需求和业务需求一致性。 6.对开发周期进行安排，计算人力成本并分析工期合理性。 采集流程 采集阶段的文档
需求分析 分析说明 1.对需求进行一番分析，确定其基本属性，做了之后会对产品带来哪些商业价值？用户量的提高？一级 实现改项目需求最多要付出的人员、时间等系数，确认需求性价比。 2.对于一些bug或是功能的小修改，不做详细分析，直接转为需求处理。 分析要求 1.需求分析人员必须完成相关需求分析文档； 2.分析人员要使用符合大众的习惯性语言表达； 3.分析人员要了解业务及需求 4.需求文档中不能含有模棱两可的文字，如可能、一般等 5.需求分析工期不能超过预期时间 6.需求分析应具备合理性 分析流程
分析阶段的文档 需求评审 评审说明 1.结合现状对需求进行处理，主要解决做不做？什么时候做，做什么的问题； 2.需求评审以会议形式展开，邀请与项目相关人员及领导参加 3.通过评审，对多个需求进行打包，整理所需的需求点 4.对打包后的需求形成文档，提交领导复核，确认后进行开发周期 评审要求 1.符合icage产品定义 2.需求形式化语言清晰易懂 3.需求必须符合运营需求 4.标示将来产品迭代可预测的需求 5.需求必须可拓展性及可实现性或者后续产品迭代时人力成本和开发成本及技术实现的难易程度 6.满足用户需求和业务需求一致性 7.需求必须合理 8.开发周期、人力成本、工期需合理
CMMI需求管理规范
CMMI需求管理规范
目录 一．概述 (3) 二．需求管理的基本活动 (3) 1、需求提出 (3) 2、需求分析及评审 (3) 3、需求计划定制及跟踪 (3) 4、需求变更控制 (3) 5、需求制度建立及其优化 (4) 6、需求成本控制 (4) 三．项目实践过程示例 (4) 1 、建立需求管理制度 (4) 2、需求接收及其分析 (5) 3、需求评审 (5) 4、需求计划定制及跟踪 (5) 5、需求开发及更新过程 (5) 6、需求变更 (5) 7、团队培训 (5) 8、过程改进 (6)
一．概述 项目需求管理（Requirements Management, REQM）的目的，在于管理项目产品及产品组件的需求，并界定这些需求与项目计划及工作产品间的差异。项目实行适当的步骤，确保议定的需求是受管理的，以支持项目策划和执行的需要。需求管理也须记录需求变更及其理由，并维护原始需求与所有产品和产品组件需求的间的双向追溯性。 从实践意义上讲，需求是针对客户各类需求经双方（或多方）沟通确认后形成的一种协议，协议的范围是明确的、可控的。在协议签订后，需求的计划有定制、进度有跟踪、结果有度量。针对需求的变化，需要明确需求变化的原因及变更内容。需求的紧急程度及严重程度可评估，以确定需求及其变更的优先级，从而排定切实可行的需求计划。 下面我们就如下几个方面对需求管理体系进行分析、研究： 1，需求的管理的基本活动 2，结合当前项目简述需求管理实践中的问题、解决方案（结合7命题）。 二．需求管理的基本活动 在需求管理过程中，包含如下关键活动： 1、需求提出 针对客户的需求提出，开发方进入需求了解环节。需求了解采用访谈、文档、多方会议等形式采集基础信息，在此基础上结合系统原型进行差异化分析。 2、需求分析及评审 需求分析中，针对需求、系统差异进行差异记录并制定相应的矫正方案。 3、需求计划定制及跟踪 需求计划的定制以用户、开发团队、计划跟踪者协商一致的结果为依据。其过程实质是取得用户对于进度的认可、取得团队对于进度的承诺。其成果物—需求跟踪表，对于后续的需求跟踪起到警示标的作用。 4、需求变更控制 用户对于系统、需求的理解是渐进的过程，因此某种意义上说需求变更存在必然性。 如何有效率和有效果地管理这些新增需求或变更需求是很重要的。如果需求变更控制不当，不但造成新的需求变更得不到满足，而且对于需求进度的管理、对于系统稳定性的影响都将是负面的。变更控制，需要追溯变更的缘由，记录变更的原因、内容，并做好变更比例的度量。保证需求的可追溯性，对于需求变更管理至关重要；在进行需求变更对项目计划、活动及工作产品的影响评估时尤其需要需求追溯表这些管理工具。
产品需求分析与需求管理--如何搞定市场需求
产品需求分析与需求管理－－如何搞定市场需求 主讲：董奎（Don）（研发管理咨询资深顾问INCOSE（国际系统工程师联合会）会员） 课程对象：企业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个基本点： 1)差异化 2)成本优势