需求分析模板_正确的产品来之正确的需求，从0到1的需求过程你掌握了吗？

第一、了解业务问题的基本事实

1.1需求就是软件产品、服务、硬件产品想要做的事或要成为的东西，所以不论你发现没有发现，需求都是存在。所以需求活动主要不是编写需求文档，相反，应该专注于理解业务问题，并为之提供解决方案。

1.2构建软件的最终目标就是为拥有它的人提供最理想的价值。可以思考一下如果产品没有为拥有者提供价值，用户是不会付钱的。

1.3如果开发的软件要获得成功，你就必须知道标准和要求是什么，这样才能构建正确的软件。只有你思考了要求是什么，你才能正确的理解产品打算为用户完成什么，并且以怎么样的方式完成这些产品才最有用。那么怎么才能做到这些呢？答案就是你必须理解产品拥有者的业务工作，并决定将来工作如何进行。

1.4思维角度变化，从原来的的关注软件产品本身转变到关注拥有者的业务问题上，这样才能对软件拥有者产生价值。

1.5对产品文档有全面的认识，现在很多产品经理感觉写厚厚的产品文档交给技术人员，他们也不看，最终还得沟通交流，感觉写文档浪费了时间。首先我们承认口头沟通效率很高，但是所有需求都用这种方式行不通。我们还需要对需求的追踪、以及需求的唯一性、需求变更确认，以及测试人员编写测试用例等，都需要产品文档作为依据。

1.6产品经理不只是简单的把客户的需求设计成软件功能这么简单。客户每提出一项需求的同时产品经理应该考虑用户操作时遇见的困难以及当时的场景。还有产品经理别被用户带跑偏了，用户大多数是在现有基础上提出改进需求，我们简称这种需求为“增量改进”问题，这种增量改进方式容易排除重大创新想法，最终导致产品变得很平庸，不能满足期望。同时产品经理要学会发现需求本质问题，说服用户做到创新。

1.7需求不是偶然得到的，需要是需要按照有序的过程进行，有序的过程由一组任务构成并实现预期的结果。当然这些需要团队根据业务目标决定。

1.8要想成功实现需求，需求就必须可度量、可测试。从本质上说功能需求是产品拥有者购买产品的目的，非功能需求是产品要在拥有者的环境中取得成功的量化描述。所以要求编写需求时必须准确可测量尽量用数字表达需求准确度。

1.9需求究竟是什么呢？需求就是产品满足其拥有者的业务必须完成的事，或则让拥有者接受并感兴趣所必须具备的品质。

第二、从零到一的掌握需求过程

需求模板从零到一的整个过程，有“产品大烩”提供

2.1项目启动会议

召集项目涉及的所有相关人员组织起来开会确立目标，确定需求范围、评估风险、确立业务存在的问题，以及业务环节的上下模块范围对需求达成进行或终止的一致意见。

2.2收集需求

确认业务本质问题，理解产品的功能性，通过访谈、用例场景、问卷、竞品等和本产品的利益相关者确认，拆分业务环节、建设业务用例，确定最佳的功能指标。

2.3快速建模

根据产品启动大会的产品目标，和收集确认的核心需求快速建模“草图”，如果是在多人或则会议的形式下，可以推荐使用“即时贴”方法对功能建模，每张即时贴表示一个功能事件的活动，最后用线框图展示可能实现的需求。

2.4场景分析

场景展示了业务过程的功能性，将业务过程分解为一系列容易识别的步骤，当然场景分析的时候可以和产品相关人员头脑风暴。不同的产品利益相关者对场景不同部分感兴趣，这样产品经理在较短的时间内容易让每个人理解的具体工作，并达成一致。达成一致后场景就成为需求的基础。

2.5编写需求文档

系统开发的一个主要问题就是需求被误解，为了避免需求误解，产品经理必须以一种无二义的、可测试的方式写下需求，同时确保写下的需求经过系统所有利益相关者同意后再交给技术人员，当然有的产品经理感觉写需求文档很费事、也不知道怎么写，那“产品大烩”有一个办法很实用，推荐给大家，第一种就是需求规格模板，它是需求规格说明的一个提纲，产品经理用它作为一个检查清单，检查哪些需求应该询问，同时也作为组织需求文档的一致方式。第二种就是需求项框架也成为“卡片模板”，每项需求都有一些属性组成，卡片也是一种方便的方式，确保每项需求都有正确的组成元素。

2.6需求分析

在产品开发周期中，需求时所有工作的基础。所以要开发正确的产品，必须保证需求再交给技术人员之前保证需求正确。为了确保需求的正确性，这个时候就需要对需求进行分析过滤筛选，可以由产品经理、利益相关者领导确认需求是否通过筛选，在需求写入需求文档之前他们必须检查每项需求的完整性、相关性、可测试性、一致性、可追踪性和其他一些质量属性。需求分析是需求传递给技术人员的唯一通道，这样项目团队就能控制需求。

2.7复用需求

开发任何一款产品的需求都不会完全是独一无二的，所以在开发新的需求项目之前，可以浏览一下以前的产品需求文档，寻找可以重复利用的需求模块，比如非功能需求是相当标准的可以拿来就用，不用重新开发。

2.8需求迭代和增量过程

传统的项目开发模式是先收集所有的需求，才能够进入到下一步的设计和构建工作。这就是传统的瀑布流式过程。在某些情况下这种模式比如需求外包，那么很显然需要完整的需求文档。另为一种就是目前比较火的敏捷开发模式，在已知总体架构，那么技术人员就可以在需求全部收集完成之前就开始工作，所以这个时候就是先收集核心需求，然后通过需求分析过滤后就可以让技术人员先工作起来，这样投放市场循环迭代的开发方式。

2.9需求反思

反思也可以成为经验总结，时发现过程的优缺点，并提出改进行动的最有效方法，反思可以对利益相关者访谈，以及和开发小组访谈，可以主要问一下几个问题：

1.我们哪里做的最好？

2.我们做错了什么？

3.如果重新做一个哪些地方会做的不同？这样总结一下有效的事多做，无效的事少做。当然反思可以在你日常的任何时候进行。

2.10需求演进

项目开始时对项目将来的工作只是模糊的想法，产品经理早期可以利用各种模型帮助利益相关者了解项目的最终工作效果，并达成一致理解。随着对工作的深入了解，利益相关者可能在产品经理和技术总监的指导下，确定改进工作最佳的产品。可以认为这些需求是业务需求，怎么才能让利益相关者了解系统的本质需求，这需要抽象的思维。如下是整个需求演进流程：

需求演进流程整个过程，有“产品大烩”提供

2.11需求模板指南

如果你在编写需求时有一份指南，就会更容易、更方便。该模板的设计目的是作为一份成熟的检查清单，提供一份要记录的事情的清单，并对如何编写需求给出建议。模板清单如下：

需要详细的模板详解条例关注作者，私信给你发。“产品大烩”

2.12需求卡片模板

需求指南模板是要写什么的指南，卡片是怎么写的指南。每一条单独的需求都有一个结构，即一组属性，每个属性对理解该需求有贡献，对需求的精度有贡献，从而对产品开发的准确性有贡献。卡片模板如下：

需求卡片模板有作者提供，有问题可以私信作者。谢谢