产品需求文档模板

1. 产品需求文档模板

首先告诉你产品需求文档肯定是有的！一个经过实际工作检验、经历过“质疑”、“挑战”和“斗争”之后沉淀下来的模板，肯定是已经吸收了各类人的偏好、意见，固化了很多符合实际业务必须的内容要求，能够起到很好的业务承接作用。格式化、标准化本身是一个很好的思维、工作方式，可以让你在编辑文档和接受文档的双方关系中建立一种“标准”的沟通机制和预先定义的沟通基础，减少额外的沟通成本，提高效率。

不过，在享受别人智力和经验梳理好的模板进行需求编写的同时，还是应该了解模板形成的原因，并在此过程中形成自己对于模板的理解，进而形成对于产品需求文档的理解，在理解中使用，裁剪和优化。

要理解和分析模板，理解和分析产品需求文档，可以运用以下几个方法：

一、描述-解释-预测-监控

描述，是对观察过程和观察结果的描述。观察的对象因不同的研究而有差异，其目标是尽可能完整地将观察者根据自己的观察得到的现象、由此现象所产生的思想和感觉，以及在观察过程中选择纳入的过程参与者对现象的反应等信息进行描述。
解释，是回答 “为什么”，是对于描述的理解、归类、定义和解释。其目标是将描述内容背后的成因、原理、动机，内容中各部分之间的相关，依存、依赖和影响关系等进行说明，以便对于描述内容有更清晰、更细致、全面的了解。
预测，根据以因果关系为内容的内在联系，相互影响来推导未来的发展或者将要发生的事情。通过研究解释内在的联系，准确地表达内在联系，从中推导出正确的预测。
监控，是对于预测行为、现象的观察和监督，包括了观察到的预测中的行为、现象的发生或者预测以外的行为、现象的外发生，以及因此而采取的对应的反映动作；这些反映动作是预测过程中根据内在联系制定的“响应”机制，并任其自然发生或者通过提供“系统”的自制能力来实现。

二、需求准备、编写和检查
回归到产品经理的日常工作中，在时间占比上较为集中的就是产品需求管理了，包括了需求的准备、分析、编写和检查过程。在这个过程中，描述——解释——预测——监控这个通用的科学分析过程也同样使用，且可以贯穿其中，并可以帮助理解、形成并固化成我们前文提到的需求文档的模板。这个科学分析的过程、方法在不同阶段运用的侧重点会有所不同。

1. 描述
描述的过程是客观的进行“需求向”描述的过程，是一个“背景”信息的补充，用来说明，这个需求文档的源出是什么，是针对什么问题，这个问题是在具体什么领域，在怎样的范围内，涉及到的是那些人；在需求相应的功能设计实现之前，当前的解决方案存在的问题是什么，参与者是怎么解决的，解决的情况怎么样，是好，还是不好，还是勉强可以，对于新的需求的紧迫性是什么样的。此外，描述的过程还需提供一个基础的概念和流程的解释，用来统一作为背景去理解一个现实的业务场景和“沟通字典”，避免在沟通中因为误解而产生不必要的偏差。

需求准备的过程：了解需求来源（管理部门、市场部门、运营部门等），需求背景（行业、同业规则现状等）；
需求分析的过程：了解需求目标、预期效果（时间、结果等）、使用者习惯、相关人影响；
需求编写的过程：描述需求目的、背景、时间和结果要求、业务流程、交互过程、系统架构、干系人角色和影响范围；
需求检查的过程：需求的背景、目标、过程、干系人、结果预测和预防的完整性检查；

2. 解释
解释在需求来源的基础上描述了 “为什么”接下来这个需求可以解决遇到的问题，同时还加入了“是什么”和“怎么样”的部分。就是这个需求是通过怎么样的方法解决了“描述”过程中提到的问题，这个新的解决方法需要要做什么，对于原有的业务过程有哪些改变，会提升什么，会降低什么，会影响哪些人、哪些业务部分、哪些业务系统以及哪些数据的产生。这个部分，是需求文档的最主要、最核心的内容部分，也是在内容上占比最大的一部分。

这里的解释根据产品需求面向的要解决的问题不同，而可能存在多个层面，多个维度的层面，比如对于运营的影响，对于前端市场的影响，对于用户的影响，对于财务、法务的影响；从技术开发、技术实现维度，比如对于前端开发的影响、对于服务端开发的影响、对于数据平台的影响，还可能涉及到对于运维资源的影响等；因此对应到实际的产品需求工作中：

需求准备的过程：了解需求可能涉及的相关业务系统及系统对应的数据流程和逻辑、了解需求可能涉及的外部服务的数据流程和逻辑；了解面向的内外部用户的产品使用水平、学习能力和使用习惯；
需求分析的过程：选择和制定最有效的，满足时间、资源投入等要求的方案；
需求编写的过程：详细描述需求的业务流程，通过各种图表格式说明新的解决方法在各服务系统之间、各业务部门之间、用户与产品，产品与后服务之间的数据、文件和行为的交互过程、详细的信息输入、信息处理和信息输出；每个业务节点明确的输出物和节点标志，重要性和优先级；系统架构、干系人角色和影响范围；
需求检查的过程：需求的流程、用户交互动作、系统信息交互等完整性检查；

3. 预测与监控
预测与监控在产品需求文档的管理上是联动的，是对于预测的事件发生的时候，进行管理的机制，监控=预测+干预。在产品需求文档的管理上，对于设计好的业务流程、使用功能，在实际过程中可能会出现这样或者那样的 “非规划”的使用，也就是我们通常说的“用户并不总是按照产品设计的方式来使用产品，而且，往往相反。”因此，这部分内容很大的比例需要来对于用户的行为进行预测和监控，并提供“预防”或者“解决”方案。其中：

预防在于，预测产品的用户在使用的过程中，可能会进行的一些超过产品使用半径的操作，一旦进行这些操作，操作的任务流程会中断，掉出，进入其他业务流程中且无法回滚，从而使得操作无法进行下去，功能使用失败，使用者会感觉产品、功能没有包容性，缺乏引导性，导致了最后操作的失败，预想的结果没有实现，而且造成了一定的挫败感，甚至造成了一定的损失。预防的具体方法多采用导航、提示等，不同的系统都有各自标准化的控价，我们在这里不做展开。

解决在于，预测产品的用户在使用产品的过程中，因误解、操作手误而进行了“非标”、“超规”使用“掉出”原本设计的业务流程和操作流程的情况下，需要提供额外的流程和控制来“回转”用户的操作，来帮助用户回到预先设定和他所需要的流程上来。解决的具体方法多通过“导航”引导“跳转”和“返回”、“回退”来实现。对应到实际的产品需求工作中：

需求准备的过程：了解用户特征和使用水平、评估、比较不同方式实现需求对于用户行为的可控性和“非常规”操作的危害程度；
需求分析的过程：选择和确定需求实现方案，评估行为管理方式和管理机制；
需求编写的过程：详细描述需求的业务流程和交互过程中可能出现的用户异常操作，相应异常操作中系统反应，系统对应的控制和引导；
需求检查的过程：需求“异常”流程和相应引导、控制地完整性检查；
在需求管理的过程中，就可以按照这个 描述——解释——预测——监控流程来进行。这四个既是步骤，是需求文档内容的组成部分，也是需求编写完成之后的检查。

四个模块构成了需求文档的完整性，且同时有各自独立，有对应的说明，引导、要求和标准。所谓标准文档，就可以按照这四个模块作为框架、内容和格式。

写在最后
产品需求文档作为产品经理同视觉设计、交互设计以及技术开发人员进行需求沟通的一个载体，我平时用的比较多的是摹客的服务进行创作。一个完整的、充分沟通确认，并最终达成多方理解和共识的产品需求文档，能够最大限度的还原产品、功能的设计，保证产品、功能的实现，最大限度的减少因为各方理解的偏差而造成的时间、人力和经济资源的浪费及复工。

2. 如何写好一份需求文档

作为一名合格的产品经理我们都要学会输出一个需求文档。我是将需求文档和产品文档进行了区分。这里的需求文档他们之间的区别是，这里需求文档不涉及界面原型和交互。（因为交互和原型里面有很大细节，经常改动hi是文档变得不易维护，又一些耗费精力。也会使文档呢的内容变得很复杂之类。）
  
 
  
                                          
 要给需求起一个方便理解的名称，让团队成员快速理解要做什么样的事情以及实现的目标。最终也会成为项目名称。（有机会或者有条件的情况下，产品经理可以把需求的名称给到技术同事、业务同事看一下 · 问下他们对名字的理解是否有歧义。）
  
 背景在这里描述需求的背景及为什么要做这个需求。
  
 在文档中讲清楚，做这个需求的预期收益以及想实现怎样的目的。
  
 背景、目标和收益的内容，可以来自我们之前做的商业需求文档、用户调研报或者市场需求文档 ，不管信息的来源是哪里。需求实现的目标是最关键的，它能够让团队不忘初心。
  
 需求以列表和用例图的方式展现出来，可以大致知道这些需求包含嘛些内容，为后续评估工作量和阅读文档提供便利。
  
 
  
                                          
 以下是大家最熟悉的模块了
  
  6.1业务概念 
  
 在这一部分放上需求分析时的实体关系图。在实体关系图之后，解释每一个元素具体定义是什么，以及具体包括的属性数据有哪些。产品经理提供这些描述，有助于理清业务概念，也可以帮助技术同事拿到需求设计。
  
  6.2流程展示 
  
 在这里加入流程图和数据流程图 （下一篇文章给大家介绍数据流程图） ，用可视化的方式一让大家快速了解业务和需求。
  
  6.3需求描述 
  
 需求描述是比较重要的一部分，我们可以用前面提到的用例的方式来描述需求。
  
 需求描述可以包括的内容有哪些，通过填写需求描述，将需求一并描述清楚。
  
 
  
                                          
 非功能需求是一个系统的特征，一般是用形容词或者副词来表示，比如快捷、安全、高效、稳定等。这些词语可以用在功能与功能之间、系统与系统之间、产品与产品质检之间的比较。用户用这些形容词和副词对产品进行了比较，进而就会对产品进行选择。
  
 想要打造出一款触动人心的产品，需要产品经理的心思多分给非功能需求一些。当然，并不是要求系统和功能要满足。
  
 
  
                                          
 非功能需求清单书写非功能需求就像对手机进行测评一样，总是要把性能的好坏拆分成各种具体的参数和跑分，量化的标准才可以进行参考和比较。所以，非功能需求也要做到量化。
  
 比如，搜索单号要在 0 . 5 秒内反馈结果。同时，非功能需求也是，整体系统和软件的要求。比如，搜索单号要在 0 . 5 秒内反馈结果，那么整体白软件功能都要符合这样的要求。
  
 以上就是我们在分析需求阶段要得到的需求文档。（产品需求文档则比本章讲的需求文档多了2个点产品需求说明以及产品原型）

3. 如何编写优质的需求文档?

尽量简短
没有比这更重要的文档写作建议了。简洁意味着清晰的思路和沟通，也意味着你的文档更加易于阅读和理解——这一点至关重要。

使用平白的语言和简单的格式使用简短而不是花哨的语句，使用列表和加粗强调可以使文章更一目了然，以放松有趣的方式写作而不是一板一眼，如果你有得体的幽默感就再好不过了。

为开发团队预留时间通过评审并且达成一致通过的文档才是完善的文档。如果你希望在未来的某一个迭代 Sprint 中开发此项目，就应该提前两到三周开始这个产品文档写作流程。

像工程师一样思考在项目得以进入开发之时，常常会发现大量未预料到的边缘情况——但这种情形其实可以避免。如果你认真考虑过项目进入开发的所有必要条件，你就可以提前发现这些问题（例如，是否在移动设备中可以使用在线聊天功能？）。

确保每一个人都跟上了你的节奏当我组织产品评审时，会议室里的大部分人都已经大致了解我要讲的内容——因为我已经提前在讨论会和日常聊天中沟通过这个事情了。既然大家都已经清楚了「做什么」和「为什么要做」的问题，文档评审会上我们只要关注实施细节就好了。

在图表中下功夫流程图、线框图等图表可以通过易于理解的方式提供很大的信息量，同时也需要消耗非常多的时间来制作这些图表。

在思考和写文档上花 0.5-3 天时间具体时间根据项目大小而定。花费在写文档上的时间越长，所带来的边际收益就会递减。特别需要指出的是，没有人能够读的下去超过 5-6 页的文档。

指明方向，明晰愿景你不仅仅是在定义一个功能，也是在解释「为什么我们要做这件事情」以及「我们的目标是什么」，在文档中指出这个项目将会对更高层面的规划造成什么影响，以及接下来会发生什么。

确保你的观众阅读了文档如果你的文档又臭又长，或者从来不分享给对应的人，那你还不如不写文档。务必确保你的文档被对应的人阅读了，我上面关于评审开始时留时间给大家读文档的建议值得大家参考。

获取真诚的反馈你的文档是否是在赘述人尽皆知的事情？或者是文档缺乏足够的细节？是否在后续实施中发现了太多的边缘情况？又或者，是否在制定计划和文档评审上耗费了太多的时间？你应该和你的团队时刻保持沟通。

4. 如何编写优质的需求文档

需求文档被用来定义开发任务，协调大规模的研发计划。对于最终的产品，需求文档扮演着开发者行为和消费者行为之间沟通纽带的角色。当需求文档书写正确的时候，便可以发挥巨大的作用。然而，如果你在嵌入式开发领域工作的时间足够长，你就会很快发现，这个领域里不合格的需求文档实在是太多了。当你尝试对这些不合格的文档进行修复时，你又会很快发现，书写正确的需求文档绝非易事。在这里，我们提出一些建议，希望能将书写正确需求文档这件事情变得清晰一些。 从较高的层次来看，书写需求文档的目的就是要提供对所需行为的有效描述。该所需行为可用一个黑盒系统描述，并需要注意以下细节：工程师可以根据系统所说进行实现测试人员，在不与开发人员沟通的前提下，可以利用满足硬件要求的设备验证需求。最终产生的成果满足终端用户的要求。黑盒测试 书写优质的需求文档： 最基本的原则是：需求文档应当尽量简洁，用最易懂的描述来约束系统的预期行为。如果你遵循这个原则，剩下的那些重要因素（可测试性、避免过度设计等等）都将变得顺理成章。 列举一下更详细的规则，通常会更有帮助。下面是书写优质需求文档需要遵循的步骤： 1. 定义系统的边界。这也是黑盒系统所必要的。 2. 定义输入和输出。这也应当是你看待内部系统的唯一方式。 3. 用最易懂的方式描述系统的预期行为 4. 除了输入和输出之外，你的需求是不是还涉及了系统的其他部分？如果是，那么你的需求就设计过度了。重构需求，让它变得精简。 5. 你的需求是不是过于模棱两可？加入更多的限定规范。注意：有些模棱两可的描述并不是坏事，假设描述所包含的所有情况均可被接受，且测试的时候不需要附加的信息加以说明，那么就没关系。你不需要（也不应该）把系统的行为限制得过头。 6. 你的需求是否可测试？（这里指的是黑盒测试）如果不是，你最好返回到第 4 步。如果这种返工发生很多次，那就说明你的黑盒无法正确描述系统，或者你的测试工具不够优秀。无论是哪种情况，不可测试的需求文档几乎就是一文不值的。 7. 你的需求文档通俗易懂么？如果你的需求文档非常难以读懂，那就说明你写得不好，只能给那些照着你的需求负责实施的人带来无尽的痛苦。如果是这样，回到第 3 步。 8. 你是不是真的做到了第 4 步？你确认么？再检查一下。 例子：下面的例子，让我们描述一个自制的嵌入式设备的需求，这个设备能从弯曲传感器上读取弯曲的频率，并根据不同的频率值让一个 LED 闪烁。 显然，我们已经完成了步骤 2 和步骤 3 了! · 输入：从弯曲传感器读取数据。 · 输出：LED。 但是我们跳过了步骤1： · 在这个例子里，我们将把黑盒画到设备的微处理器上。 让我们继续往下进行, 第四步：除了输入和输出以外，我们是否还涉及了其他的系统边界？ · 微处理器并不关心从弯曲传感器读取什么样的数据，从处理器的角度来看，仅需要做的是测量 ADC 脚的电压而已。 · LED 仅由数字输出脚控制。 下面，让我们来修正这个问题： 第0 版本的需求： 1. 该设备应当根据 ADC 脚的不同频率的电压，来切换数字输出端的状态。 第五步: 需求写模棱两可么? 恩，我们的描述太模棱两可了.输出端切换的速度要多快? 跟电压的关系如何? 输入电压的范围是多少? 让我们加一些更细节的描述吧: 版本0.1 1. 输出端应当由一个自由活动的定时器进行控制 2. 自由运行定时器的频率最高不得高于每秒 10 次，不得低于每秒 1 次. 3. 自由运行定时器的触发频率应当在最高和最低值之间呈线性变化，并与 ADC 端的输入电压成正比. 4. ADC 端的输入电压应当每 100 毫秒读取一次 5. 当 ADC 端的输入电压端被读入时，控制自由运行定时器周期时间的注册值也应当被更新. 6. ADC 输入端的电压有效范围应当被控制在 0 到 1 伏之间. 第六步: 你的需求是可测试的么? · 首先，自由运行的定时器在这里不需要提及. 因为对它基本上无法进行黑盒测试，它既不是输入也不是输出，而且跟这两者也没有什么联系。 让我们用“数字输出端变化的频率应控制在每秒 10 次和每秒 1 次之间”来代替自由运行定时器的测试标准。 · 对于上述的第四条需求，可能需要一些小修改才能作为测试标准。让我们用“ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次”来加以描述，这样的描述能让我们预期的测试行为显得更加通俗易懂。 · 需求的第五条也需要一些小修改。我们如何才能检测电压的输出范围是在 0 到 1 伏之间呢？ 总不能给个 2 伏的电压，然后看看元器件有没有被烧毁吧？ 那么，说“检验系统在 ADC 端输入电压为 1 到 2 伏之间的时候，工作是否正常”，这样就检验就容易多了。需求描述应当是“正面”的，应当描述设备“应该”的行为，而不是设备“不应该”的行为。否则的话，测试将会无法进行。 版本0.2 1. 数字输出端的切换频率应当控制在每秒 10 次到每秒 1 次之间 2. 数字输出端的切换频率应当在最大值和最小值之间呈线性变化，并与 ADC 端的输入电压成正比 3. ADC 端的输入电压应当保证在每 100 毫秒内至少被读取一次 4. 检验当 ADC 端的输入电压范围在 0 到 1 伏之间的时候，系统工作是否正常 第七步：你的需求是否通俗易懂？ 相比于我们原来的描述：“根据弯曲传感器的输出不同频率来控制 LED 闪烁”，我们上面的那些需求描述显得难以阅读和理解。 我发现，让需求文档变得通俗易懂，最简单办法莫过于，把过于细节的东西抽取出来，然后以条目的形式单独定义。 版本1 1. 弯曲传感器应当保证至少在 100 毫秒内读取一次数据（放到注释单独列出） 2. 切换 LED 的状态，使其与弯曲传感器的读数保持一致 3. 当弯曲传感器的读数为 1 伏特时，LED 状态切换的次数应当保持在平均一秒十次；当传感器的读数为 0 伏特时，LED 的切换次数应保持在一秒 1 次。 定义： · 弯曲传感器：输入电压位于 ADC 的X端。安全电压范围为 0 到 1 伏特（放到注释单独列出） · LED 状态：数字状态由Y端输出 这样就好多了（尽管还不完美）。这些需求通俗易懂，不涉及到系统内部实现，且易于测试。对于系统行为的限定也仅仅限于需要做什么，点到为止。（例如，对弯曲传感器的采样频率，在实现上也可以更高，只要不产生非预期行为，一切都可以）。 编写需求就仿佛是在大脑中构建软件的过程。因此要重于实作。 编译：伯乐在线 – 黄小非

5. 如何正确的看待：产品需求文档和产品需求？

做产品的第一要素就是发掘用户的需求，寻找刚需，寻找痛点，然后再做成产品。如果需求找错了，做什么都是错。人生也是这样的，为什么很多人会困惑，就是因为不知道自己的“需求”是什么。
人之所以迷茫就是因为没有方向而原地踏步。每个产品经理都知道不断发掘用户需求然后把它变成产品，而我们在人生中在做的事情也是不断发现自己的需求然后把它变成执行方案。

怎么样快速知道自己的“需求”？产品经理的方法是用户访谈，市场调研。而对于我们自己来说，就是不断的自我发问，自我反省。当自己不开心的时候，反复问自己为什么，到底是什么问题造成的。深挖几次之后，几乎就到了“人性”层，知道自己内心什么因素在“作怪”了。
而产品需求文档则是一篇不仅包含产品需求（已整理完善）还要包括产品概况、市场营销、后续运营发展及原型的一份综合性文档，是产品经理的重要输出品。
总的来说，两者是一种包含的关系，我觉得可以这么理解——产品需求是产品需求文档的子内容，也是其最核心的内容。
首先产品经理要做的事是确认产品的需求再进行会议甄选，在得到多方认可的情况下再处理产品需求文档，产品需求文档一般是给内部开发人员及市场人员使用的，所以如何使自己的意思表达的准确非常的关键。
在产品需求文档建成后也就是PRD弄好后，就可以进行开发动作了。

6. 如何正确的看待：产品需求文档和产品需求？

直面上讲：产品需求是『需求』，产品需求文档是『文档』。产品需求文档与产品需求的关系，类似创意作品与创意的关系。
通常产品需求是天然存在的，发散的，把产品需求变成产品需求文档的过程，是一个收敛与落地的过程，这也是产品经理的基础工作。

上面的图，可以将最左侧蓝色的所有小块理解为产品需求，最终红色框内合并之后形成的输出产物便是产品需求文档。产品需求文档的形式不定，可以以固定的MRD、PRD格式输出，也可以用草纸规划，总之，能将项目方案完整无缺并可查证的传递给设计、研发、测试角色，即可。

7. 如何写好产品需求

产品经理日常一项重要工作就是收集整理产品需求，转化为产品需求文档，将需求传递给项目团队成员，完成需求功能开发测试上线。如何写好产品需求属于技术活，好的产品经理的需求有条理，由浅入深阐明问题及解决方案，而一般的方案会让人看过后不知所云，需要再次澄清需求。
  
 如何写好产品需求，有小窍门或理论可以参考，比如金字塔原理，在产品初期，我们往往会犯思路不清晰、无法明确表达自己的想法，或者提炼不出产品核心需求点的问题。这时，运用金字塔原理可以帮助我们构建清晰的逻辑思路，更好地表达产品观点。
  
 根据金字塔原理的指导，从分析需求产生的背景，到根据背景认清冲突点，分条列出冲突问题，归纳整理思路；最后根据已知问题，针对性地提出解决方案，寻求解决问题之道。以上步骤完成后，便可以将所有思路总结成文档，具体实施。这种构建方式可以很明确地表述自己的思想，增强代入感。
  
 归纳总结共三点：
  
 1、分析背景，提炼关键需求点
  
 关键需求点不用长篇大论，最好能一句话说明要做的事情，如果要深入细节，再详细描述。
  
 2、用归纳法理清你的思路
  
 提炼关键需求点后，可以针对需求点提出相应解决方案，多个需求或解决方案之间可能存在逻辑关系或冲突，通过归纳法来总结梳理，帮助把握核心需求点、区分优先级。
  
 3、寻找问题解决知道
  
 归纳总结问题后，剩下就是针对问题寻找解决方案了，解决方案的好坏取决于产品经理的经验与学习能力。

8. 如何撰写市场需求文档

什么是市场需求文档？ 
  
 具体来说下，市场需求文档（Market RequipmentDocument，MRD）要有更细致的用户、市场和竞争对手分析；
  
  通过哪些功能来实现商业目的； 
  
  功能、非功能需求分为哪几块； 
  
 功能的优先级等。市场需求文档（MRD）是商业需求文档（BRD）的进一步细化和论据支撑，其内容主要包括用户描述，市场描述和需求描述。
  
  1.目标用户 
  
 用户主要包括两大类：目标用户和企业用户。
  
 目标用户主要是指：有着共同动机、行为方式和特征的目标用户的集合。
  
   “产品的价值取决于目标用户群”  
  
   “产品在非目标用户群里可能会一文不值”  
  
  2.用户需求痛点 
                                          
  3.用户特征 
                                          
  用户特征 包括：用户特点和用户行为。用户特点包括：人口统计信息、性格、爱好、需求特征等。用户行为包括：频率、习惯和消费。
  
  4.用户动机 
  
  用户动机 是指：谁推动用户，从某种事情的念头或愿望。用户动机与用户需要层次是密切相关的。
                                          
  5.用户角色建模 
                                          
  6.用户场景 
                                          
 
  
  
  1.市场规模定义 
  
  市场规模 即 市场容量 ，是指一个特定市场供应品的 使用或购买人数。 
  
 市场规模 大小 与 竞争性 可能直接决定了对新产品 设计开发 的 投资规模。 
  
 市场规模主要 研究目标 产品或行业的 整体规模 ，具体可能包括目标产品或行业在指定时间的 产量、产值 等。
  
 市场规模是 需求测量 的目标。
  
  2.占比加权法估算 
  
 （主流品牌A销售额+主流品牌B销售额+主流品牌C销售额+主流品牌D销售额+主流品牌E销售额）/权重数=市场总容量约数
  
 区域越小，数据越精准。
  
 取悦越大，权重数越难估算。
  
  此方法适用于成熟产品进入成熟市场。 
  
  3.核算经算法估算 
  
 基于产品和 营销策略 出发，操作过程 可控制、信誉度很好 ，调查的 规模适中 。
  
 此方法适用于 消费时间、场所 相对 集中 的产品。
  
  4.替代品类比法估算 
  
 能够比较准确的反应市场状况，并且与销售策略关系极大。
  
 选择正确的营销策略能够有效地扩大市场需求空间。
  
 此方法适用于新类别地产品，对产品的竞争力和营销策略要求比较高。
  
  5.统计调查法估算 
  
 逻辑性强，精密可控制，对市场整体把握性强。
  
 成本高，规模较大，操作人员的专业性要求高。
  
 此方法适用于铺市场面广、销售点分散、消费时间分散的产品。
  
  6.历史数据分析法估算 
  
 公式：去年销量*（1+增长率）N（N为幂值，表示年份）
  
 此种方法适用于已经在区域市场比较成熟的产品，但精度不高。
  
  7.用户规模估算 
                                          
  8.竞争对手分析 
                                          
 9.SWOT分析