需求分析怎么做

10月22日 10:37 尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。Gause 和Weinberg（1989）提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗？”这些回答可以更直接地认识问题，而这是封闭（close-end）问题所不能做到的。

需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式（Kiel and Carmel 1995）。与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统（MIS）的应用来说是一种传统的需求来源。直接聘请用户进行获取需求的过程是为项目获得支持和买入（buy-in）的一种方式。

尽量理解用户用于表述他们需求的思维过程。充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。流程图和决策树是描述这些逻辑决策途径的好方法。

在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。当前的范围太小，以致不能提供一个令人满意的产品。需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。

正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。这样说虽然很简洁，但似乎过于简单化。需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。你可以使用假设“怎么做”来分类并改善你对用户需求的理解。在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。

需求获取讨论会中如果参与者过多，就会减慢进度。人数大致控制在5到7人是最好的。这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。

没有一个简单、清楚的信号暗示你什么时候已完成需求获取。当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。

1 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。用户总是按其重要性的顺序来确定使用实例的。

2 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。这些新的使用实例可能是你已获取的其它使用实例的可选过程。

3 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。

4 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。

5 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。

以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。

用例在需求分析中的使用

多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求（McGraw and Harbison 1997）。Ivar Jacobson（1992）把这种看法系统地阐述成用例（用例）的方法进行需求获取和建模。虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。

用例的重要功能是用画用例图的功能来鉴别和划分系统功能。它把系统分成角色（actor）和用例（用例）。角色(actor)表示系统用户能扮演的角色（role）。这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。它们必须能刺激系统部分并接收返回。用例描述了当角色给系统特定的刺激时系统的活动。这些活动被文本描述。它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。

这样说可能会非常复杂，其实一个用例描述了系统和一个角色（actor）的交互顺序。用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。用例可以:

· 用例捕获某些用户可见的需求，实现一个具体的用户目标。

· 用例由角色激活，并提供确切的值给角色。

· 用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。在UML中，用例表示为一个椭圆。

角色是指用户在系统中所扮演的角色。其图形化的表示是一个小人。在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。一个用户也可以扮演多种角色。例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。

我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。角色触发用例，并与用例进行信息交换。单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。

一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。因此，一个用例是相关的用法说明的集合，并且一个说明（scenario）是用例的实例。这种关系就像是类和对象的关系。在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基本过程，普通流，或“满意之路” (happy path)。在描述普通过程时列出执行者和系统之间相互交互或对话的顺序。当这种交互结束时，执行者也达到了预期的目的。

在用例中的其它说明可以描述为可选过程(alternative coruse)。可选过程也可促进成功地完成任务，但它们代表了任务的细节或用于完成任务的途径的变化部分。在交互序列中，普通过程可以在一些决策点上分解成可选过程，然后再重新汇成一个普通过程。

角色类和角色实例

软件产品最终是给一些用户来使用的，而用户之间的差异是非常大的。造成差异的原因包括了对计算机的认知程度的不同，使用习惯的不同，在软件目标组织中所处的地位不同，地理位置不同，业务熟练程度不同。

不同的用户都有自己一系列的功能需求和非功能需求。对电脑熟练程度不同的人可能就会有不同的要求，熟练程度低的用户可能希望有一个友好的界面，熟练程度高的用户可能更希望有快捷键或宏的 *** 作以提高工作效率。考虑到用户的差异性，将用户分类并研究用户类的行为特征是非常有必要的。所以在做具体的需求之前，先将用户分局行为和特点进行分类，对于研究、收集用户的需求是非常有帮助的。

可以利用一个简单的表格列出一些原始的分类，然后不断的完善这个表格。确认你的分类之间没有交集。并充分描述用户分类的行为，目的，要求等。在企业分析中，比较常见的分类可能包括，供应商，客户，部门等。

就像C++中的类和对象一样，我们把分析出的用户分类称为“角色类”，把实际的用户称为“角色实例”。在得到用户分类之后，最重要的就是要选出用户代表，用户代表不仅仅是在需求阶段中参与项目，还必须对项目的全过程负责。用户代表能够代表用户分类的需求。抓住用户代表的需求就大致把握住了用户类的需求。当然，需求分析还是需要在用户中做大规模的调查的，只是要把重点放在用户代表上。

确保和用户直接进行沟通！大家有没有玩过传话的游戏，可能看过。一群人排成一列，一句话从排头挨个向后传，到最后，那句话已经是面目全非了。所以，一定要保证项目组能够直接和用户接触。

对于和用户直接沟通这一点，一般的针对特定企业的应用系统当然是不成问题，可是如果是开发行业软件，和用户直接沟通就成为一件几乎是不可能的事情。在这种情况下，一般有几种解决的办法：

做大规模的市场调查，针对你的目标市场做市场调查，并根据统计学的理论建立你的数学模型。这部分的工作效果最好，其性质有些象一些游戏公司会发布一些Demo版的游戏。可是对于一般的企业来说，这项工作费时费力，高昂的成本往往使大家知难而退。我的意见是，方法是非常好的，但是可以采用折衷的办法，例如选取有代表性的企业，为特定企业制作一个较小的版本并收集反馈意见等。这涉及到很多市场营销的内容，并不是我的专业所长，这里就不多弄斧了。

聘请行业专家，一个行业专家往往可以在项目需求方面发挥极为重要的作用。一个行业专家往往都有大量的行业经验和行业的人际关系网络。在产品的设计方面，这个行业专家提供很多宝贵的意见。在目前很多的软件的开发过程中都采用了这种方式。行业专家有两种：一种是在这个行业中有很深的资历，但是对软件技术并不熟悉；第二种是开发过同类软件的软件专家，这种人在开发同类软件过程中已经积累了大量的项目经验，并且具有软件开发的知识。这种方式是获取需求的最好的方式。 分析对比同类软件，微软在开发Office、Visual Studio的时候，也是参照了Lotus和Borland的成熟产品。这种方式的特点在于成本很低，比较适合和其他的方式配合使用。但是，要注意自己有没有触犯专利法。

需求的冲突

有的时候，虽然已经将用户分类并选出了用户代表。但是需求的来源众多，往往会发生需求之间自相矛盾的事情。需求从四面八方收集来后，人们难以解决冲突，澄清模糊之处以及协调不一致之处。某些人还要对不可避免要发生的范围问题单独作出决定。在项目的早期阶段，你必须决定谁是需求问题的决策者。如果不清楚谁有权并且有责任来作出决策，或者授权的个人不愿意或不能作出决策，那么决策者的角色将自然而然地落在开发者身上。这是一个非常糟糕的选择，因为开发者通常没有足够多的信息和观点来作出业务上的决策。

在软件项目中，谁将对需求作出决策的问题并没有统一的正确答案。分析员有时听从呼声高的或来自最高层人物的最大的需求。即便使用用户代表这一手段，必须解决来自不同用户类的相冲突的需求。通常，应尽可能由处于公司底层的人作出决策，因为他们与问题密切相关，并能得到关于这些问题的广泛信息。

如果不同的用户类有不一致的需求，那么必须决策出满足哪一类用户的需求更为重要。了解可能使用产品的客户种类的信息和他们的用法与产品的业务目标的关系如何，将有助于你决定哪一个用户类所占份额最大。

当开发者想象中的产品与客户需求冲突时，通常应该由客户作出决策。然而，不要陷到“客户总是对的”的陷阱中去，对他们百依百顺。现实中，客户并不总是对的。客户总是持有自己的观点，开发者必须理解并尊重这一观点。

用例

在具体的需求过程中，有大的用例（业务用例），也有小的用例。主要是由于用例的范围决定的。用例像是一个黑盒，它没有包括任何和实现有关或是内部的一些信息。它很容易就被用户（也包括开发者）所理解（简单的谓词短语）。如果用例不足以表达足够的信息来支持系统的开发，就有必要把用例黑盒打开，审视其内部的结构，找出黑盒内部的Actor和用例。就这样通过不断的打开黑盒，分析黑盒，再打开新的黑盒。直到整个系统可以被清晰的了解为止。

为什么要采用这种分析方法呢？计算机系统除了在与外界系统、人员有一系列的交互，在系统内部也往往存在着复杂的交互。因此，在系统建模时，除了描述系统与外界的交互，同时还要描述系统内部的交互。传统的MIS系统中，系统与外界的交互较多。典型的，如ATM取款机：存在着大量的用户与ATM，ATM与其它系统的交互。而电信领域的系统，与外界的交互较少。例如，系统的输入可能仅仅是从交换机上采集信息，然后由系统进行处理。系统的复杂逻辑包含在系统内部处理的流程上，而非与外部系统的交互。建模主要任务是表达系统内部的交互。

用例图适于表达交互，之所以上面使用了电信系统，是因为用例最早来自于Ericsson的交换机系统。当时，还是Ericsson雇员的Jacobson初步建立了用例图的概念，并于1994年提出了OOSE方法，其最大特点是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精确描述需求的重要武器，比较适合支持商业工程和需求分析。随着用例的发展，用例被大量的用于对功能进行描述。每个用例代表了系统与外部ACTOR的交互。可以采取顺序图来表达用例的具体 *** 作程序。ACTOR用于确定系统的边界。

ACTOR、用例可以从不同的层次来描述信息。采用该原则的原因有：

1 需求并不是在项目一开始就很明确，往往是随着项目的推进，逐渐细化。

2 人的认知往往具有层次的特性。从粗到细、从一般到特殊。采用不同的层次来描述，适于认知的过程。

使用用例开发系统的一般过程

在开发过程的初始阶段，可以根据具体的项目特点，制订开发各个视图之间的关联原则，指导规范。在开发的过程中，视图的组织原则应不断进行维护、更新。

识别ACTOR来识别系统与外界交互的实体。ACTOR具有特定领域的特征，例如：交换机（采集系统）、97信息系统等。在系统层次的ACTOR确定了系统的边界。

识别用例。同ACTOR一样，用例具有不同层次。对较为概括的USECASE，需要细化。注：系统开发需要一定的规则来确定，如何来分解用例；可能基于原有系统的经验，或是参考现有资料。

当用例细化到可以被理解的层次。需要基于用例进行下一步的开发。如前面提到的，用例主要用来描述交互。因此，存在交互的实体和交互的细节。交互的实体采用类图来描述；而交互的细节，采用顺序图来描述。

当系统复杂到一定层次时，类图和顺序图可能不能足以描述其复杂程度。在该情况下，需要使用状态图来辅助阐述。状态图和顺序图之间使用事件联结在一起。它们之间的一致性问题，目前UML和ROSE没有提供解决方案。相对折衷的方法是使用事件的命名规范强制一致性。

可以说，之前说的所有的东西都是为了能够导出用例在需求中的作用。用例是从用户的角度看待系统，而不是基于程序员的角度。这样的话，用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整的体现。用户和程序员间通过用例沟通，避免了牛头马嘴的尴尬局面。 从前，系统开发者总是通过情节来获取需求，是问用户希望系统为他做什么。在Jacobson发明了用例的概念之后，需求获取就变成问用户要利用系统做什么。这是立场不同导致的结果。用户通常并不关心系统是如何实现的（也有少数可爱的技术狂是例外）。对他们来说，更重要的是要达到他的目的。相反的，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例是来源于用户，服务于用户，但是它同样可以用于开发的流程。当系统的开发过程都是基于用例的，用用例获取需求，用用例设计，用用例编码，用用例测试的时候。这个开发过程就是用例驱动的。 用例和用例文档

《软件需求》一书中提到了几种方法来确定用例：

· 首先明确执行者和他们的角色，然后确定业务过程，在这一过程中每一个参与者都在为确定用例而努力。

· 确定系统所能反映的外部事件，然后把这些事件与参与的执行者和特定的用例联系起来。

· 以特定的说明形式表达业务过程或日常行为，从这些说明中获得用例，并确定参与到用例中的执行者，有可能从现在的功能需求说明中获得用例。如果有些需求与用例不一致，就应考虑是否真的需要它们。

用例代表了用户的需求，在你的系统中，应该直接从不同用户类的代表或至少应从代理那里收集需求。用例为表达用户需求提供了一种方法，而这一方法必须与系统的业务需求相一致。分析者和用户必须检查每一个用例，在把它们纳入需求之前决定其是否在项目所定义的范围内。基于“用例”方法进行需求获取的目的在于：描述用户需要使用系统完成的所有任务。在理论上，用例的结果集将包括所有合理的系统功能。在现实中，你不可能获得完全包容，但是比起我所知道的其它获取方法，基于用例的方法可以为你带来更好的效果。

当使用用例进行需求获取时，应避免受不成熟的细节的影响。在对切合的客户任务取得共识之前，用户能很容易地在一个报表或对话框中列出每一项的精确设计。如果这些细节都作为需求记录下来，他们会给随后的设计过程带来不必要的限制。你可能要周期性地检查需求获取，以确保用户参与者将注意力集中在与今天所讨论的话题适合的抽象层上。向他们保证在开发过程中，将会详尽阐述他们的需求。在一个逐次详细描述过程中，重复地详述需求，以确定用户目标和任务，并作为用例。然后，把任务描述成功能需求，这些功能需求可以使用户完成其任务，也可以把它们描述成非功能需求，这些非功能需求描述了系统的限制和用户对质量的期望。虽然最初的屏幕构思有助于描述你对需求的理解，但是你必须细化用户界面设计。

建立用例文档。在每一次的需求获取之后，都会生成很多未整理的需求，你必须将它们组织成用例文档。使用诸如模板的技术能够提高你的速度和需求的复用性。一个用例文档可以使用表格来组织，主要的要素包括了用例标识号、用例名称、父用例标志号、创建者、创建时间、审核者、修订记录、角色、说明、先决条件、请求结果、优先级、普通过程、可选过程、例外、非功能需求、假设、注释和问题。

虽然列举出了这么多的属性，但是实际中使用的属性这要看你的团体而定，看项目的大小而定。把大量的时间花在用例的描述上是没有意义的。用户需要的是一个软件系统，并不是一大堆的用例说明。

由于软件开发项目和组织文化的不同，对于需求开发没有一个简单的、公式化的途径。下面列出了一些基本步骤，可以利用它们指导需求开发活动。对于需求的任何子集，那么你就可以很有信心地继续进行系统的每一部分的设计、构造，因为你将开发出一个好的产品：

1 定义项目的视图和范围，确定每个功能的实现目的。

2 确定用户类（涉众）。

3 在每个用户类中确定适当的代表。

4 确定需求决策者和他们的决策过程。

5 选择你所用的需求获取技术。

6 运用需求获取技术对作为系统一部分的使用实例进行开发并设置优先级。

7 从用户那里收集质量属性的信息和其它非功能需求。

8 详细拟订使用实例使其融合到必要的功能需求中。

9 评审使用实例的描述和功能需求。

10 如果有必要，就要开发分析模型用以澄清需求获取的参与者对需求的理解。

11 开发并评估用户界面原型以助想像还未理解的需求。

12 从使用实例中开发出概念测试用例。

13 用测试用例来论证使用实例、功能需求、分析模型和原型

end

2018-5-19

本文梳理了什么是做需求分析与需求管理，以及为什么要做与如何去做。

01 概述

本文是梳理需求分析与需求管理方法-产品经理工作职责&工作核心技能之一，笔者写本文的目的一是把自己的知识体系做个输出，包含来自己的经验总结和最近学习到的知识总结，其二顺便分享。知识方法无定论，任何内容先看思路，实战为主。

在分析一个问题时，可以用一个通用的框架方法论，WWH法：是什么？为什么？怎么做？这样可以把思路理清晰。因此引出了本文的主要内容：什么是需求？为什么要做需求分析？什么时候做需求分析？怎么做需求分析？

说明：时间有限，本文的案例不代表实战解决方法案例，更为了快速说明和应用方法而举例。

02 需求定义

1 什么是需求？

需是是用户在某种场景下的未被满足的期望。

为什么要明确需求的定义，需求很容易被误解，这里我们要区分下用户需求和产品需求。

我们的产品在未被定义之前，我们研究的需求是用户需求，我们通常也会叫作问题（没有明确的解决方案），当我们定义产品时，我们就要把用户需求转化为产品需求，提供具体的可落地的解决发难，才能实现产品。

我要吃饭睡觉打豆豆，这不是需求，这种需求对于产品没有任何价值。

看定义，用户需求是用户基于某种场景下的未被满足的期望，在这里提炼出需求的基本结构：用户+场景+期望。强调：需求不是独立存在的，是依附于用户+场景一起存在的。

用户需求案例： 小明（用户），每天早上起床后就要赶着去上班，没有也不想在家吃早餐，但是到了公司就要工作，所以常常没有早餐吃，又饿又不健康（场景），小明又想多睡会儿又想在上班前吃上早餐（期望）

2 什么是需求分析？

需求分析，就是挖掘和提炼用户需求，解决用户痛点问题，即找到用户需求，并把用户需求转为产品需求（解决方案）的过程。

这里强调两点：

找到用户需求

解决用户问题

案例： 还是小明吃早餐的案例，目前小明希望在上班前能吃上早餐这个是用户需求，只找到用户需求，没有解决方案，等于0，我们还要帮小明解决问题。如，提供早餐外卖，小明可以提前在手机上预定早餐外卖，一起床就有早餐可以吃。这是一个较完整的产品需求。

03 为什么要做需求分析

产品首先要满足的就是用户需求，为用户产生价值，才能创造商业价值。满足用户需求是产生商业价值的本源。

04 在什么阶段做需求分析

需求分析贯穿在产品整个生命周期。

1 产品概念期

这个阶段做需求分析，更强调需求调研，目的是定位目标用户群，做产品定位，市场研究并确认细分产品市场。提炼产品核心功能，解决目标用户群痛点问题。 交付物：BRD需求文档。（或类似的相关的文档，如需求调研报告、市场调研报告等）

2 产品设计开发期

这个阶段的需求分析，目的是要设计一个可落地的解决用户痛点，满足用户需求的产品。设计一个目标用户可用好用的产品。深层次的挖掘和分析用户，描述需求，解决问题。实现用户如何通过一步步的使用产品满足其需求。该阶段交付物：产品原型+PRD *** 作文档。

3 上线后-成长期

上线后的需求分析，目的是验证真实产品满足真实用户需求的结果，收集用户需求，优化产品。

4 成熟运营期

本阶段需求分析，目的在为产品提供更好的运营方案，制定竞争策略。让产品持续更好的更多的为企业创造商业价值。

5 产品衰退期

当产品进入衰退期时，需求分析重在研究市场发展趋势，以帮助决策是调整发展战略。

05 需求分析方法

需求分析可以分为三大步： 明确问题–拆解需求–提供解决方案。

1 明确问题

明确问题之前，我们首先要从各方搜集需求，然后经过分析，提出真正的需求。

需求获取渠道

以下是我们常用的一手需求获取渠道：

收集到的一手需求还不是真正的需求，要先进行一个清洗过程，把一些无用的无根据的站不住脚的异常的等等都过滤掉。具体过程不做介绍啦。

明确问题（提出要解决的问题）

这里一定要注意，提问题的标准：提出的问题要聚焦，明确、开放。不能泛，模糊。要又用户、场景、问题。还要明确该需求带来的价值。需求最终是要交换成价值的。

正确的问题VS错误的问题：

明确需求的价值：

2 拆解问题（需求）

拆解需求指的是把已经明确的问题，从多个维度进行拆解，目的就是为了找到更合适的解决方案。 该方法是某课程老师总结的拆解方法，笔者认为非常好，非常清晰和明确的一个方法，这里直接引用。（该方法也是老师对《六顶思考帽》里的解决问题方法做的灵活应用，同时书也推荐给大家）

拆解问题的5个维度：

积极层面：通常可以拆解出怎么做对用户来讲可以产生更积极的情感。

否定层面：通常可以拆解，即使不做什么，依然可以产生好的结果。

转移层面：转移指的是不直接单独解决当前用户的问题，通过转移法，用户转移、问题转移等。

拆解：把当前问题刨根问底的拆，挖掘更多的可能性、找到问题本质。

脑洞：这个更多的靠灵感、经验等进行头脑风暴，补充其他维度考虑不到的地方。

案例： 问题：某视频APP，用户次日留存率低于30%，需要提高次日留存率 拆解过程如下图：

注意在拆解问题的时候，不要去考虑能不能实现，先去拆解一切想到的问题，最后在分析解决方案的时候再来进一步筛选。

3 提供解决方案

问题拆解完后，对所有提出的问题列出解决方案，这里注意，一开始思考解决方案的时候也不要去考虑实现的可行性，尽管去提供。等所有的解决方案都列出来之后，再进行方案分析、评估、排序。

06 需求管理

需求管理指的是如何安排已经明确产生的需求，工作中我们通常会遇到四面八方包括产品经理自己给的需求，但是资源和精力无法让做到有求必应，我们需要去把需求做一个分类和排序，尽可能的去做性价比高的需求开发。 这里我们介绍几种方法，帮助我们做需求分类和排序。

1 Kano 模型

KANO 模型是东京理工大学教授狩野纪昭（Noriaki Kano）发明的对用户需求分类和优先排序的有用工具，以分析用户需求对用户满意的影响为基础，体现了产品性能和用户满意之间的非线性关系。

Kano模型把需求分为5类：

基本型需求

该类需求代表的用户的核心痛点，是产品的必备功能，如果没有该功能，用户会极度不满，甚至不用你的产品。但是如果有了该功能，用户并不会对你的产品的满意度增加。如微博的发布微博功能、社交APP的聊天功能、共享单车的开锁功能等。

期望型需求

这类需求代表的是用户的痒点，代表的是品质，对用户来讲是最好有的功能。好比我们的生活，我们都期望我的生活是有一定品质的。拥有此功能，用户满意度会明显提升（过的还可以），没有此功能，用户满意度会明显下降，但是凑合可以用户（过得下去）。这种需求一定要去努力挖掘和分析，并做好。代表了产品的竞争优势。如社交软件的语音聊天视频功能。

兴奋型需求

这类需求所在暗处，用户自己都想不到的需求。拥有此功能，即便表现的并不完善或完美，用户满意度也显著提升，但即便没有此功能，用户也并不会对产品对满意度降低。如，在微信刚刚推出红包功能的时候，这是一个非常典型的兴奋型需求。

无差异型需求

该功能对用户来讲，是不痛不痒的需求。可用可不用，有或者没有都不会影响用户的满意度。如，我们在设计某个按钮，是20px，还是22px，是第一个还是第二个位置。无论怎么做，对用户并无明显影响。我们就尽量不要去花精力在这上面，只需要执行任意一种即可。

反向型需求

该类需求提供对应的功能后，用户会对产品的满意度降低。该类需求，最好不做。如，前段时间上热搜的一款监测学生上课是否集中注意力的智能科技“紧箍咒”，得到的是网友几乎一边倒的差评和抵制。

Kano模型实施方法：

如何评估需求属于Kano模型中的哪一类需求，我们可以实施以下方法：

Kano模型问卷调研法 可以直接设计问卷调研，通过定量问卷调研得出需求属于哪一种：

按照上表的格式，对每一个功能做一个的调研，充分收集用户的数据并得出结果。

2 时间管理四象限法

本方法可以快速帮助我们评估需求开发的时间优先级。从紧急重要程度两个维度比较合理的帮助产品有条理的安排开发秩序，避免盲目排序。

3 ICE排序法

ICE排序法也是一种比较严谨科学的需求排序方法，通过从几个维度考虑给需求打分，以总分高低去排序。

I（Impact）：影响范围

C（confidence）：对上线效果的自信程度评估

E（ease）：开发难易程度（工作量+技术难易程度）评估

应用实例：

本文由 @娟姐 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。

它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。

1）企业的组织模型

即企业的组织结构关系，包括部门设置、岗位设置、岗位职责等。树型组织结构图是描述企业的组织模型的一种常用方法，它可用来搞清各部门之间的领导关系,每个部门内部的人员配备情况,职责分工等情况,它是划分系统范围,进行系统网络规划的基础。在组织结构图中应将用户的组织结构逐层详细描述，每个部门的职责也应进行简单的描述。组织结构是用户企业业务流程与信息的载体，对分析人员理解企业的业务、确定系统范围具有很好的帮助。取得用户的组织结构图，是需求获取步骤中的基础工作之一。

用户环境中的企业岗位或角色，和组织机构一样，也是分析人员理解企业业务的基础，也是分析人员提取对象的基础。

对用户角色的识别常常遗漏的是计算机系统的系统管理人员，角色识别不全，对以后的功能识别会造成盲区。

（2）企业的流程模型

即企业的业务流程，包含哪些流程、流程之间的关系、每个流程中包括哪些活动、每个活动涉及到的岗位。企业的作业流程首先要有一个总的业务流程图，将企业中各种业务之间的关系描述出来，然后对每种业务进行详细的描述，使业务流程与部门职责结合起来。详细业务流程图可以采用直式业务流程图形式。对企业而言需要定义关于业务流程图的描述标准，大家采用相同的图例来描述，便于管理。

业务流程图的优点:

■绘图的过程,实际上是作业流程条理化的过程

■表达形象直观,易于和用户交流,易于项目组内部交流调研的结果,需要得到用户的认同,这就需要和用户交流调研的结果,交流的文档要通俗、易懂,不能采用专业术语。

■可以作为培训实施人员与技术服务人员的文档

业务流程图的缺点:

■对高层管理人员的实际需求调查的不清楚

这一方面是由于用户没有接触过计算机,对采用计算机后的管理会是什么样子计算机能够完成当前手工 *** 作的哪些内容能够作哪些现在手工无法完成的工作等等没有清楚的概念,因此用户无法将这些问题反应出来另一方面说明分析人员没有经验,对原始材料挖掘不深,不能从用户提供的材料中提炼处来用户的真正需求,不能找到当前管理中的问题。

■对各种业务之间的总体关系没有表达出来

采用直式业务流程图可以将企业的每一种业务的处理流程清楚地表达出来,但是各业务之间的联系却没有表示出来,单看一种业务的流程图很清楚,但是却不能综合在一起,没有整体的概念,作为需求分析的文档,在这方面表达的不够完整。

■在不利用工具的情况下,画法烦琐。

图形可以将流程描述的很清楚，但是还要附加以一些文字说明，如关于业务发生的频率、意外事故的处理、高峰期的业务频率等，不能在流程图中描述出的内容，需要用文字进行详细描述。

（3）企业的数据模型

即企业中的信息载体有哪些？以及对这些信息载体的详细刻画，包括企业的各种单据、帐本、报表的描述。在需求报告中，应该将单据的描述格式化，需要描述的内容包括：

单据的用途，即单据用在什么地方？

单据的格式：需要明确的画出来，并有实际的有数据的样例，能够具体直观地说明问题；

单据中的数据项的具体描述：长度、类型、计算生成方法、约束条件等；

单据的数据项是由哪些不同类型的角色来填写地，包括用计算机可以填那些数据项。

单据中哪些数据是必填的，哪些是可以不用填的。

单据流量：平均每天产生多少条记录，高峰期的数量；

单据的分类：可以从多个角度上进行分类，如：按业务类型来分类（采购/销售/生产），按生成的方式来分类（手工录入型/自动生成型），按格式变化的频繁程度来分类（易变型/稳定型），按表现形式来分类（列表型/卡片型）等等。

单据之间的关系：引用关系等等。

同样对于需要的报表与帐本也可以参照上面的条目进行详细的刻画。

以上就是关于需求分析怎么做全部的内容，包括:需求分析怎么做、软件项目需求开发基本步骤、需求管理的手段有哪些等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！