序号

主题

内容

1

需求完整性检查

²  需求录入完成后，产品经理对录入PLM/IT系统的需求信息进行正确性和完整性审核，必要时与提出者进行沟通，对相关信息进行更新及补充；

²  需求提出者在获取任何需求的更新信息时需及时通知产品经理，以便产品经理对录入系统的需求信息进行完整性审核，并补充必要信息。

2

商务可行性分析

²  需求录入后对需求进行一定的筛选，给出可过滤的需求的标准，一般筛选时考虑是否与公司策略、公司投资方向、公司产品范围、公司主要市场、国家相关法规相违背；

²  产品经理根据需要组织相关的商务可行性分析人员，并组织开展商务分析活动，商务可行性分析人员通常来自营销、产品规划等部门。若需求较简单，产品经理也可不召集分析人员，由产品经理自己进行分析。进行商务可行性分析时，主要分析该需求的市场背景、商务前景、投入产出比、建议定价等，以确定该需求值不值得去投入，形成初步市场需求；

²  根据商务可行性分析结论，可以有以下几种处理方式：该需求从商务上分析可行，需要提交研发副总裁批准进一步进行技术分析，则进入技术可行性分析步骤。必要的情况下，研发副总裁将商务可行分析结论提交高层决策，决策通过后，方可进入技术分析环节。该需求从商务上分析可行，但需要长期规划的，需要纳入需求库。该需求在商务上没有前景，不需要实现，取消该需求，结束。需求信息不完善，需要进一步补充，返回到需求池，待补充后再进行规划

3

技术可行性分析

²  产品经理向研发中心各部门经理协调资源，成立技术可行性分析小组，对需求进行技术可行性的分析。产品经理需要同时明确技术可行性分析的时间要求。如果产品经理有能力自行分析，也可以不组建分析小组，而由产品经理自行给出分析结论和建议；

²  技术可行性分析小组负责对需求进行技术可行性分析，从软件、硬件、结构等各个领域进行全面分析，同时对需求实现过程中需要的资源、工作量及交付周期进行评估，确定所提出的需求，在技术上、资源上、时间上的可行性；

²  技术可行性分析小组需在指定的时间内得出并汇总分析结论，包括技术可行性、总体工作量、开发交付周期、资源计划、必要的技术方案及对需求决策的建议等，并在《需求管理表单》的技术分析部分填写分析结论，反馈给产品经理；

²  技术可行性分析过程中产生的分析文档等，可作为需求管理表单的附件提交，对技术可行性分析结论进行支撑。分析过程中，产品经理可根据需要组织技术可行性分析小组召开讨论会议

4

需求决策

需求分析完成后，产品经理负责向研发副总裁提交技术可行性分析结论，并进行需求处理方式决策

序号

主题

内容

1

需求分析的关键是明确用户的本质需求，即挖掘表面需求背后更深层次的需求

收集来的用户需求甚至可能不是用户的真实需求，只有明确了本质需求，才能确定更好的产品方向，以更好地满足客户

2

优先满足真需求，减少或者不做伪需求

²  收集到很多需求，但资源显然有限，于是就需要对需求的优先级进行筛选和排列。怎么区分真需求和伪需求？用英文很可以清晰区分，伪需求叫Want，真需求叫Need。Want的东西用户不一定会掏钱，Need的东西用户一定愿意掏钱。所以识别出Need的需求是优先需要实现和满足的。

²  对单个需求通常可以问的问题有：需求强度，用户是否痛？需求频次，多久痛一次？持续时间，是否持续地痛？广度，有多少用户有类似的痛点？付费意愿，用户为此痛点付费的意愿如何

3

优先实现有先后顺序要求里靠前的需求

产品开发的不同阶段需求关注点也有区别，一个全新产品最该实现的是用户最迫切的需求。产品逐渐成熟，需要实现的内容就越来越多，各种细节的体验需要提升

序号

要素

描述

内容

1

＄价格

客户为一个满意的产品希望支付的价格。从实际和感觉两个方面来考虑客户能接受的购买价格，包括技术先进性、低成本制造、人力成本、制造费用、简易型和可生产性等

设计、可生产性、技术、原材料、生产、供应商、制造、人力成本、管理费用、工装

2

A保证

考虑客户在可预测的环境下的可靠性安全、质量、性能方面的评价

销售、渠道、交货期、广告、配置、定价和客户定制

3

P性能

从实际和感觉两个方面来考虑交付产品功能特性的性能，从客户角度是否能提供更好的性能，如速度、功率、容量等

功能、吸引力、规格、功率、速度、容量、适应性、多功能、尺寸

4

P包装

包装的设计质量、性能和外观等视觉特征，包括样式、模块性、结构、颜色、图形、工艺设计等

风格、尺寸、数量、几何设计、模块性、界面、图形

5

E易用

交付的易用性，包括舒适度、文档支持、人性化、直观性、输入输出方便性等

用户友好、操作控制、显示、培训、文档、帮助系统、人为因素、接口、操作

6

A可获得性

用户容易购买到，包括预售、购买渠道/供应商选择、交付时间和客户定制能力等

可靠性、质量、安全性、误差极限、完整性、强度、适应性、负荷量

7

L生命周期成本

用户使用的生命周期成本，如安装成本、培训、服务、供应、效率、价值折旧、处理成本等

寿命、正常运行/停工时间、可维护性、服务、备件、升级、运维成本、安装成本

8

S社会接受度

影响用户购买的其他影响，如第三方评价、形象、政府或行业标准、法规、法律关系等

间接影响、采购代理商、社会认可程度、法律关系、工作产所、政治

序号

主题

内容

1

正确

不要缺少信息，不要包括不需要的信息，每一项需求都必须准确地陈述其要开发的功能。只有用户代表才能确定用户需求的正确性，这就是一定要有用户的积极参与的原因

2

清楚、明确、无二义性、无冗余

每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。对所有需求说明的读者都只能有一个明确统一的解释，所以尽量把每项需求用简洁明了的用户性的语言表达出来。需求的详细程度和可理解性是一个抛物线轨迹，适中的那个高点是我们追求的方向，也是需要学习和积累的技能。需求分析最重要的是和用户沟通，少用行话，以免造成用户理解上的困难

3

完整

考虑分界条件、例外情况、不要落下需求，需求的完整性是非常重要的，因遗漏需求而不得不返工代价会增大几倍。但需求的遗漏是经常发生的事情，因为用户不知道该做些什么

4

一致性、可追溯的

用户需求必须和业务需求一致，功能需求必须和用户需求一致，保证最后开发出来的产品不会偏离最初的实现目标，例如用户需求不能超出先前指定的范围

5

可验证的

检查一下每项需求是否能通过设计测试用例或其他的验证方法，如用演示、检测等来确定产品是否确实已按需求实现。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析。一份前后矛盾，不可行或有二义性的需求也是不可验证的

6

可理解的

必须书面记录下来，能让所有利益相关人都能理解需求内容

7

可测试的

一个项目的测试不是从编码完成后开始，也不是编码的时候同时进行单元测试，编码完成后进行系统测试，实际上测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照，这就要求需求分析是可测试的。如“我们要用新的系统完成报表自动化处理”，这样的需求就不是可测试的，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明

8

可行的

每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的

9

必要性

每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。必要性也可以理解为每项需求都是用来授权编写文档的“根源”

10

优先级

给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量，如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度