结构化需求分析方法通过哪些步骤来实现

㈠ 需求分析过程是什么

简述为什么要进行需求分析？需求分析的内容和主要步骤
数据库需求分析阶段的主要任务：对现实世界要处理的对象（组织、部门、企业）等进行详细的调查，通过对原系统的了解，手机支持新系统的基础数据并对其进行处理，在此基础上确定新系统的功能。

系统分析报告的主要内容：1.系统概况，系统的目标、范围、背景、历史和现状；2.系统的原理和技术，对原系统的改善；3.系统总体结构域子系统结构说明；4.系统功能说明；5.数据处理概要、工程体制和设计阶段划分；6.系统方案及技术、经济、功能和操作上的可行性。
软件需求分析的过程
软件需求分析所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其它系统元素的接口细节，定义软件的其它有效性需求。进行需求分析时，应注意一切信息与需求都是站在用户的角度上。尽量避免分析员的主观想象，并尽量将分析进度提交给用户。在不进行直接指导的前提下，让用户进行检查与评价。从而达到需求分析的准确性。分析员通过需求分析，逐步细化对软件的要求，描述软件要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计和过程设计的数据和功能表示。在软件完成后，制定的软件规格说明还要为评价软件质量提供依据。
需求分析的详细分析
从广义上理解：需求分析包括需求的获取、分析、规格说明、变更、验证、管理的一系列需求工程。狭义上理解需求分析指需求的分析、定义过程。 需求分析就是分析软件用户的需求是什么。如果投入大量的人力，物力、财力、时间，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力，开发一个软件，最后却不满足用户的要求，从而要重新开发过，这种返工是让人痛心疾首的(相信大家都有体会)。比如：用户需要一个for linux的软件，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死。需求分析之所以重要，就因为他具有决策性、方向性、策略性的作用，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视。在一个大型软件系统的开发中，他的作用要远远大于程序设计。 需求分析阶段的工作,可以分为四个方面：问题识别、分析与综合、制订规格说明、评审。问题识别：就是从系统角度来理解软件，确定对所开发系统的综合要求，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)、性能需求(要达到什么指标)、环境需求(如机型、操作系统等)、可靠性需求(不发生故障的概率）、安全保密需求、用户界面需求、资源使用需求(软件运行是所需的内存、CPU等)、软件成本消耗与开发进度需求、预先估计以后系统可能达到的目标。分析与综合： 逐步细化所有的软件功能，找出系统各元素间的联系，接口特性和设计上的限制，分析他们是否满足需求，剔除不合理部分，增加需要部分。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。制订规格说明书： 即编制文档，描述需求的文档称为软件需求规格说明书。请注意，需求分析阶段的成果是需求规格说明书，向下一阶段提交。评审： 对功能的正确性，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析。 需求分析的方法有很多，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等，从来没用过这些方法在此不讨论。原型化方法是十分重要的，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能。原型化方法就是尽可能快地建造一个粗糙的系统，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性、界面的友好性或其他方面上存在缺陷。建造这样一个系统的目的是为了考察某一方面的可行性，如算法的可行性、技术的可行性或考察是否满足用户的需求等。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统，这个系统只是一个界面，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发。原型主要有三种类型：探索型、实验型、进化型。探索型：目的是要弄清楚对目标系统的要求，确定所希望的特性，并探讨多种方案的可行性。实验型：用于大规模开发和实现前，考核方案是否合适，规格说明是否可靠。进化型：目的不在于改进规格说明，而是将系统建造得易于变化，在改进原型的过程中，逐步将原型进化成最终系统。在使用原型化方法时有两种不同的策略：废弃策略、追加策略。废弃策略：先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想，据此设计出较完整、准确、一致、可靠的最终系统。系统构造完成后，原来的模型系统就被废弃不用。探索型和实验型属于这种策略。追加策略：先构造一个功能简单而且质量要求不高......

需求分析应包括哪些内容
需求分析是指理解用户需求，就软件功能与客户达成一致，估计软件风险和评估项目代价，最终形成开发计划的一个复杂过程在这个过程中，用户的确是处在主导地位，需求分析工程师和项目经理要负责整理用户需求，为之后的软件设计打下基础。需求分析阶段包括：

1.业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。

2·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。

3·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。

4·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。

5·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
软件测试需求分析的主要步骤是什么
软件测试就是在软件交付用户使用或投入运行前，对软件需求规格说明、设计规格说明和编码的最终复审，是软件质量保证的关键步骤。软件测试是为了发现错误而执行程序的过程。软件测试在软件生命周期中横跨两个阶段：通常在编写出每一个模块之后就需要对它做必要的测试（称为单元测试）。编码和单元测试属于软件生命周期中的同一个阶段。在结束这个阶段后对软件系统还要进行各种综合测试，如集成测试、系统测试、性能测试和配置测试等，这是软件生命周期的另一个独立阶段，即测试阶段。软件测试的目的：1、测试的最终目的是为了避免错误的发生，确保应用程序能够正常高效的运行；2、好的测试用例在于发现至今未发现的错误；3、成功的测试是发现了至今未发现的错误的测试；4、好的测试工程师应该做到不仅发现问题，还能够帮助开发人员分析问题；软件测试的原则：1、应把“尽早和不断地进行软件测试”作为软件开发者的座右铭，实践证明单元测试能够尽早发现问题，减少后期测试的错误量。可以采用Junit和Jtest来辅助进行单元测试。2、测试用例应由测试输入数据、测试执行步骤和与之对应的预期输出结果三部分组成。3、应当避免由程序员检查自己的程序。（指后期系统测试阶段，不包括单元测试）4、测试用例的设计要确保能覆盖所有可能路径。在设计测试用例时，应当包括合理的输入条件和不合理的输入条件。不合理的输入条件是指异常的，临界的，可能引起问题的输入条件。5、充分注意测试中的群集现象。经验表明，测试后程序残存的错误数目与该程序中已发现的错误数目或检错率成正比。应该对错误群集的程序段进行重点测试。6、严格执行测试计划，排除测试的随意性。测试计划应包括：所测软件的功能，输入和输出，测试内容，各项测试的进度安排，资源要求，测试资料，测试工具，测试用例的选择，测试的控制方法和过程，系统的配置方式，跟踪规则，调试规则，以及回归测试的规定等等以及评价标准。7、应当对每一个测试结果做全面的检查。8、妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便。软件测试的对象：软件测试并不单纯等同于程序测试。软件测试应该贯穿整个软件定义与开发整个期间。因此需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应该是软件测试（评审）的对象。在对需求理解与表达的正确性、设计与表达的正确性、实现的正确性以及运行的正确性的验证中，任何一个环节发生了问题都可能在软件测试中表现出来 希望对你有用
如何进行软件需求分析
1.概念

需求的定义包括从用户角度(系统的外部行为),以及从开发者角度(一些内部特性)来阐述需求.

关键的问题是一定要编写需求文档.我曾经目睹过一个项目中途更换了所有的开发者,客户被迫与新的需求分析者坐到一起.系统的分析人员说:"我们想与你谈谈你的需求."客户的第一反应便是:"我已经将我的要求都告诉你们前任了,现在我要的就是给我编一个系统".

百事通

而实际上,UGGs,需求并未编写成文档,因此新的分析人员不得不从头做起.所以如果只有一堆邮件、会谈记录或一些零碎的未整理的对话,你就确信你已明白用户的需求,那完全是自欺欺人.

需求的另外一种定义认为需求是"用户所需要的并能触发一个程序或系统开发工作的说明".有些需求分析专家拓展了这个概念:"从系统外部能发现系统所具有的满足于用户的特点、功能及属性等".这些定义强调的是产品是什么样的,而并非产品是怎样设计、构造的.而下面的定义则从用户需要进一步转移到了系统特性:

需求是指明必须实现什么的规格说明.它描述了系统的行为、特性或属性,是在开发过程中对系统的约束.

从上面这些不同形式的定义不难发现:并没有一个清晰、毫无二义性的"需求"术语存在,真正的"需求"实际上在人们的脑海中,这个人们主要是指客户,但一般情况下,用户并不能描述自己的需要,只就需要系统分析人员根据用户的自己语言的描述整理出相关的需要再进一步和客户核对.系统分析员和客户需要确保所有项目风险承担者在描述需求的那些名词的理解上务必达成共识.

任何文档形式的需求(例如如下将要描述的需求规格说明书)仅是一个模型,一种描述.

2.需求分析的任务

开发软件系统最为困难的部分就是准确说明开发什么.最为困难的概念性工作便是编写出详细技术需求,这包括所有面向用户、面向机器和其它软件系统的接口.同时这也是一旦做错,将最终会给系统带来极大损害的部分,并且以后再对它进行修改也极为困难.

目前,国内产品的庞杂,一家企业可能有几个系统并立运行,它们之间接口是系统开发人员最头痛的问题.

对于商业最终用户应用程序,企业信息系统和软件作为一个大系统的一部分的产品是显而易见的.但是对于我们开发人员来说,并没有编写出客户认可的需求文档,我们如何知道项目于何时结束?而如果我们不知道什么对客户来说是重要的,那我们又如何能使客户感到满意呢?

然而,即便并非出于商业目的的软件需求也是必须的.例如库、组件和工具这些供开发小组内部使用的软件.当然你可能偶尔勿需文档说明就能与其他人意见较为一致,但更常见的是出现重复返工这种不可避免的后果,而重新编制代码的代价远远超过重写一份需求文档的代价,这些血的教训正在国内的软件开发者身上发生.

近来,我遇到一个开发小组开发包括代码编辑器在内的一套内部使用的计算机辅助软件.不幸的是,当他们开发完这个工具后,发现这个工具不能打印出源代码文件,使用者当然希望有这个功能.结果这个小组只好手工抄写源代码文档以供代码检查.这说明那怕需求明确无误并构思准确,如果我们没有编写文档,软件达不到期望目标也只能是咎由自取了.

相反的情况,我曾见一个要集成到"错误跟踪系统"中的简单界面写了一页需求说明.而操作系统系统管理员在为处理脚本时发现简单的一张需求清单竟是如此有用.他们依据需求对系统进行测试时,此系统不仅非常清晰地实现了所有必需功能,而且未发现任何错误.

事实上,需求文档在开发过程中一直起指导作用.

3.需求分析过程

......
需求分析的作用及如何进行需求分析
通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明，这一系列的活动即构成软件开发生命周期的需求分析阶段。

需求分析是介于系统分析和软件设计阶段之间的桥梁。一方面，需求分析以系统规格说明和项目规划作为分析活动的基本出发点，并从软件角度对它们进行检查与调整；另一方面，需求规格说明又是软件设计、实现、测试直至维护的主要基础。良好的分析活动有助于避免或尽早剔除早期错误，从而提高软件生产率，降低开发成本，改进软件质量。

需求工程是随着计算机的发展而发展的，在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。后来软件开发引入了生命周期的概念，需求分析成为其第一阶段。随着软件系统规模的扩大，需求分析与定义在整个软件开发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，它贯穿于系统开发的整个生命周期。80年代中期，形成了软件工程的子领域——需求工程(requirementengineering,RE)。进入90年代以来，需求工程成为研究的热点之一。从1993年起每两年举办一次需求工程国际研讨会(ISRE)，自1994年起每两年举办一次需求工程国际会议(ICRE)，在1996年Springer-Verlag发行了一新的刊物——《RequirementsEngineering》。一些关于需求工程的工作小组也相继成立，如欧洲的RENOIR()，并开始开展工作。需求工程是指应用已证实有效的技术、方法进行需求分析，确定客户需求，帮助分析人员理解问题并定义目标系统的所有外部特征的一门学科。它通过合适的工具和记号系统地描述待开发系统及其行为特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。RE可分为系统需求工程（如果是针对由软硬件共同组成的整个系统）和软件需求工程（如果仅是专门针对纯软件部分）。软件需求工程是一门分析并记录软件需求的学科，它把系统需求分解成一些主要的子系统和任务，把这些子系统或任务分配给软件，并通过一系列重复的分析、设计、比较研究、原型开发过程把这些系统需求转换成软件的需求描述和一些性能参数。

需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。80年代，HerbKrasner定义了需求工程的五阶段生命周期：需求定义和分析、需求决策、形成需求规格、需求实现与验证、需求演进管理。近来，MatthiasJarke和KlausPohl提出了三阶段周期的说法：获取、表示和验证。

综合了几种观点，可以把需求工程的活动划分为以下5个独立的阶段：

（1）需求获取：通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求；

（2）需求建模：为最终用户所看到的系统建立一个概念模型，作为对需求的抽象描述，并尽可能多的捕获现实世界的语义；

（3）形成需求规格：生成需求模型构件的精确的形式化的描述，作为用户和开发者之间的一个协约；

（4）需求验证：以需求规格说明为输入，通过符号执行、模拟或快速原型等途径，分析需求规格的正确性和可行性；

（5）需求管理：支持系统的需求演进，如需求变化和可跟踪性问题。...
系统开发过程中,需求分析的步骤是什么？
⑴首先调查组织机构情况

包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。

⑵然后调查各部门的业务活动情况

包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。

⑶协助用户明确对新系统的各种要求

包括信息要求、处理要求、完全性与完整性要求。

⑷确定新系统的边界

确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。

⑸分析系统功能

⑹分析系统数据

⑺编写分析报告
基于用例的需求分析过程包括哪些步骤
基于用例的需求分析需我帮助否？

㈡ 需求分析的十个步骤

1、概念明确----2、需求分析目的------3、如何识别需求---4、判断需求真伪----5、分析[ 用户故事评估框架、马斯洛框架、营销框架定位]---6、评判价值----7、砍需求能力---8、分类----9、排优先级----10、提升需求分析能力

一、什么是产品需求?

1、想要 vs 需要 vs 需求

“想要”(Want)是用户外在表达出来的，而“诉求”(Need)是用户内在的心理预期。产品需求满足的是用户的内在诉求，这是根本。

想要(Want)是外在的、具体的、有指向性的解决方案。

需要(Need)，或者如我们前面说到的“诉求”，是内在的、原始的最终动机。

需求(Demand)是满足内在需要的同时，在可控成本内实现外在想要的解决方案。

二、需求分析的目的

需求分析，本质是动机的分析，目的在于预测用户未来的行为。需求分析阶段的产出 物，需要回答用户要什么、为什么要，还要回答以后什么情况下还可能要类似的东西、这种情

况有什么特点、如何人为的制造这种情况、

需求重要，是因为它是用户行为的动机;需求是分层的，说出来的一个样，实际是另一个样。

用户需求分析，是为了通过分析动机，准确预测用户的行为。不同的需求，代表   了不同的动机，注定会产生不同的行为，应当看做不同类型的用户。

在需求分析中考虑竞争性，是为了比竞争对手预测得更准确，这是我们在后面要说的。

【知识点】需求= 购买欲望 + 购买力 = 需要 + 目标产品 + 购买力

三、如何识别需求？

       分析完需求，那我们如何去发掘新需求呢?这里就涉及如何识别需求。 识别需求可以从三个方面去考虑，分别是视角、效率、体验。

       1、视角

       先说视角。作为产品经理，我们要具备多样化的视角来审视需求和产品，分为用户视角和产品视角。

        比如:开头我们提到的关于微信朋友圈可见范围的例子，相比于之前三天可见和半年可见，增加了一个月可见范围。

        在这个设计里，用户往往会站在自我的角度说，“不想让别人看我的朋友圈”，这是用户视角。而产品视角是考虑群体和整体，是“让用户更小压力去发朋友”。这种视角差异，最终的方案也会有差别。

        用户视角满足的是“想要”(Want)，产品视角实现的是“需要”(Need)。

        2. 效率

        另一个识别需求的维度就是效率。在最优效率的前提下，满足尽可能多的用户需求。

        我们还是用一个例子来说明，用过微信公众号赞赏功能的人都知道，如果自己赞赏过作者，那自己的头   像就会始终排在最前面。

        如果自己没有赞赏过，那每次进入文章，且赞赏人数超过 24 人后，底部的赞赏头像都不是固定顺序展示的。

        3. 体验

            最后一个识别需求的维度就是体验，关于体验，做产品的同学就比较熟悉了。体现在信息架构设计、流程设计、交互设计还有文案设计等方面。

            体验也是一个很虚的指标，很难量化，每个人的认知和感受都会因为习惯、文化、个人倾向产生差别。任何细节的体验设计，都会给用户传递一个认知，而我们要明白的是，独立个体的认知差异是很大的。

            比如:对于“快车”这个概念，刚出来的时候，大众是无认知的，只能找到对标，比如出租车和专车，而快车是介乎于两者之间的一种服务。

            如何更好的设计快车体验呢，其实用价格比专车低、比出租车干净舒服、且车多三个认知来传递给用户，就能让用户快速接受并理解。

四、接收需求判断真伪

真需求要满足三个条件

            1. 该用户属于目标用户

            2. 需求必须符合产品定位

            3. 需求能够实现

五、如何分析需求

1、采用用户故事的方式进行分析

    需求是结合用户表达的外在欲望、内在的核心诉求以及可用成本的综合评估。

    基于这个定论，我整理了一句话，可以作为需求分析的一个评估框架—— 我们为谁用什么方法解决了一个什么问题?

    在这句话里，“谁”指的就是我们的目标用户，我们需要明确用户画像;“问题”对应的是前文提到的需求，而“方法”就是我们基于需求提供的产品方案。

    我们为谁用什么方法解决了一个什么问题?其实就是在反问我们自己，作为产品经理，你在为哪类人服务，他们的核心诉求是什么，你设计了一个什么产品方案去满足他们的需求。

用户分析，我们可以从用户身份和用户特征两个角度出发，用户是什么人群，年龄、性别、地区等都是构建用户画像的基本素材。

目标用户有什么样的特征，比如职业特征、文化特征等，这些都能帮助我们进一步理解用户。

其次是需求场景，说白了，就是用户是在什么环境和状态下来使用我们的产品。

“场”是时间加空间，“景”是情景和互动。当用户停留在这个空间的时间里，情景互动触发并裹挟用户的意见就是场景。

可以用比较通用的马斯洛需求理论对用户需求进行分析，评估满足的是哪个层级的

需求，或者是通过用户体验五层模型来划分需求层级。

用户价值是从体验和效率两方面来衡量的，一个需求能改善现有体验，那就能提升用户价值，能提高使用效率，也能提升用户价值。

如何衡量体验是否有提升呢，可以用新体验减去旧体验的方式，例如针对某个体验改进，简单粗暴的做法就是新旧体验相减得到的用户投诉率，如果为正，说明用户价值有提升。

而效率则可以通过用户完成某一任务的平均时长来衡量，例如在电商产品中，用新旧总平均成交转化时长的差值来衡量提单效率是否有提升。

商业价值就比较直观了，关乎于成本和利润，互联网传统的商业化方式包括了广告、游戏、会员等。目前也有很多做增值服务和第三方能力输出服务的，这都是商业化手段，同时也会对应到一些产品需求上。

2、马斯洛框架和营销层方式结合起来

做需求调研和分析，最尴尬的结局就是:用户以为自己说清楚了，我们以为自己听清楚了，结果两边就这样整差了。

 在产品上线之前，甚至在进入产品设计阶段之前，我又怎么能知道我做的需求分析已经足够深了呢?

  行业给出的一般方法是MVP(MinimumViable Proct)，利用MVP收集线上实际数据。 但MVP只能告诉你，你是错了还是对了，依然解决不了“为什么”以及“应该怎样”的问 题。况且MVP还有覆盖度的问题，怎么设计才能让MVP覆盖所有“应该”被测试的场景呢?

到了1959年以后，马斯洛认为“人本”的导向会产生“自由主义”倾向，从而产生自私、不负责任、不顾他人、自我放纵等自我中心倾向。于是，马斯洛于1969年发表了论文《Z理论 ——两种不同类型的自我实现者》，并依照“超人本心理学”(Trans-HumanisticPsychology)将需求层次理论拆解为三个次理论:X理论、Y理论和Z理论。

依次为:

Z理论

                       最高需求(超越性灵性需求)

Y理论

                       自我实现需求

                       尊重需求

                       社会需求

X理论

                        安全需求 生理需求

营销学中的需求分层

在科特勒老师的《营销管理》(15th Global Edition)中，给出了这样一个案例:

表明了的需求:顾客需要一个便宜的汽车;

真正的需求:顾客需要一个养车比较便宜的汽车，而不是价格便宜的汽车;

未表明的需求:顾客希望零售商提供较好的服务;

愉快的需要:顾客希望零售商给装配车载GPS系统;

秘密的需要:顾客希望朋友们将TA看作是懂行的消费者;

有了前面两套框架，我们就守住了需求的来源和表达过程。但是两套框架的用法正好截然相 反:马老师的框架是“5:1”——从五个层次里选一个当前所在的层次;但营销学的需求理论 是“1:5”——拿到一个需求从五个方面来分解。

我们用卖苹果的例子还原一下需求分析的过程:

用户说:“我要买一个苹果”。此时千万不要直接就套上马老师的需求层次了，因为这根本就不是一个“根本性”的需要，而是一个结合了具体产品——苹果的具体需要。

这时应当用的是营销中的五个分类:

                       表明了的需要:我要一个苹果;

                       真正的需要:可能是解决饿肚子，可能是解决馋，更有甚者是解决低血糖的症状等

  等;

                       未表明的需要:如果为了填饱肚子，就需要个大的;如果为了解馋，就需要味道好

  的;如果为了解决低血糖，就需要一个更甜的;

                       愉快的需要:吃饱了、解馋了、头不晕了(低血糖的症状之一)当然开心，如果买一

  送一、免费加工成苹果汁、还能额外加点糖，有可能就更好了;

                       秘密的需要:可能是工作繁忙，接下来还要赶往别处，实在没时间吃别的了;又或者

  是最近吃胖了，需要用水果当饭吃;

六、评判需求价值

1. 广度:受众人群以及受众面

2. 强度:用户对于需求的迫切程度

3. 频率:间隔时间及可持续性

七、砍需求能力

                        1. 对需求进行价值评估和量化

                        2. 关联性较强的需求进行整合

                         3. 排列优先级

所有对产品的价值判断，都基于对行业、市场的探知程度;对人性的认识和了解程度(发现没有，把握人性始终贯穿产品的各个层面)

八、对需求分类

九、对需求排优先级

能用是基本要求，能用的标准是产品功能完整、没有异常、逻辑闭环，如果功能或流程缺失，或者产品有bug，那是达不到能用的标准的。

易用对应一些锦上添花的需求，在满足能用的前提下，做流程优化和交互优化，使产品达到用户体验良好的状态。

爱用是让用户形成习惯和依赖，例如我们在朋友圈里发布了很多内容，随着内容增多，我们的离开成本就越高，并且每次都能收到朋友圈的正向反馈，这个闭环就能形 成习惯和依赖。

传播能力使产品具备价值可扩散的属性，满足用户需求并获得市场认可后，需要将价值外延以吸引更多的用户，这是建立在基础功能完备、体验优良，并且满足用户价值 的前提下。

十、如何提升需求分析能力？

1. 倾听

首先是倾听，面对需求方，不论是用户还是运营还是工程师，首先做到先听，这是放下自我做产品的前提。

什么是事实? 客观的原因和现象是事实，基于现象去分析背后的原因，基于原因再形成观点。

2. 观察

其次是观察，观察是最好的洞察用户需求的方式，到用户身边去，看他们做了什么，行动往往反映了用户的真实诉求。

3. 同理心

       如何切身感受、设身处地呢?最简单的方式就是到用户的环境中去，感受用户不如变成用户。

只有切身感受，尤其是感受到了痛，你才真的理解了用户。

附记：

需求沟通:需求中的需求?

            至于怎么讲，我们还可以套用前面的框架——老板跟你说:“你做个需求分析”。

 那么:        

表明了的需要:老板需要你做一个需求分析;

真正的需要:老板可能在策划下一款新产品，或者要把一个竞争对手打掉，或者是老板的老板要求下来的，或者......

未表明的需要:时间呢?质量呢?形式呢?汇报对象呢?怎么，你不知道?快问啊!

愉快的需要:老板可能希望你从不同的视角(员工视角、跨行业视角、年轻视角等 等)给出不一样的答案;可能希望你直接做成他能用来汇报的ppt格式，可能......

秘密的需要:老板背负着公司巨大的业绩压力需要寻找突破口、老板“可能”也有自己升职加薪的小算盘......

㈢ 需求分析有哪些方法

三种需求分析的方法：结构化分析方法、面向对象的分析方法、面向问题域的分析方法。
结构化的分析方法是传统的分析法，它的好处是在需求阶段可以不需要精确地定义系统，只需要根据业务框架确定系统的功能范围，以及每个功能的处理逻辑和业务规则，功能需求规格书等。因为不需要精确描述，因此描述系统的方式比较灵活多样，可以采用图表、示例图、文字等等方式来描述系统。在系统开发以前，一般还可以采用更为直观的原型系统方式和最终用户进行交流和确认，因此对业务需求的要求会低一些，业务需求阶段的周期相对容易控制；通过业务全景图，最终用户也能了解系统的功能；通过功能活动图和业务规则的描述，也可以相对精确地描述业务系统；因为没有严格的标记语言，可以采用适当的篇幅描述适当的系统。当然，这种方法的缺点也是明显的，分析人员和业务人员之间可能缺乏共同语言，机器不能识别业务需求书，在设计阶段还需要继续和用户确认一部分功能。

面向对象的分析方法的最大好处是在需求阶段，就能够非常精确地描述一个系统，采用程序语言的方式和最终用户交流（最终用户必须要熟悉这种语言），能够在项目一开始就发现很多问题，避免在开发的过程中出现需求的反复，而且在系统设计和开发阶段不需要最终用户参与。在实施上，一般可以采用场景、业务功能等方式来描述，比较适合于业务流程环节多的系统，或者软件产品的开发。但是，我们也要看到，在现实中，绝大多数的应用系统都很难在需求阶段就可以被精确地抽象化定义，所以这种方法的缺点和困难也是显而易见的：首先，用户要非常清楚地知道最终的业务系统应该是什么样，或者采用一种抽象的方式能够确定最终的应用系统；其次，因为最终用户不需要参与设计和开发阶段的工作，所以双方确定业务需求的过程也会比较长；同时，因为是精确描述，因此描述系统的语言是非常逻辑化的，一般通过某种方式可以使机器识别业务需求，采用这种方式写的业务需求是非常格式化的，一方面描述一个系统需要的信息非常多，可能使需求说明的篇幅非常长，不便于理解和阅读；另外由于通过抽象的方式来推演最终系统的运行方式，对业务人员的要求非常高。

㈣ 结构化工作分析方法

结构化工作分析方法包括职位分析问卷法(PAQ)、美国劳工部工作分析程序和功能性工作分析方法。

具体来讲：

1)职位分析问卷法(PAQ)。

职位分析问卷是由麦考密克、珍纳尔和米查姆设计的。它围绕任职者进行信息收集，以对任职者从事工作需要进行的活动进行统计分析为基础。

①职位分析问卷的项目。

职位分析问卷由194个项目或者职位要素构成，这些项目可分为六个方面：信息输入、心理过程、工作输出、人际活动、工作情景与职务关系以及其他方面。

②职位分析问卷的评分标准。

PAQ给出了6个评分标准：信息使用度、耗费时间、适用性、对工作的重要程度、发生的可能性以及特殊计分。

③职位分析问卷的优缺点。

它真正的优势在于，问卷的实施者可以根据是否负有决策/沟通/社会方面的责任、是否执行熟练的技能性活动、是否伴随有相应的身体活动、是否操纵汽车/设备和是否需要对信息进行加工这五个基本维度对工作进行等级划分，对于每一项工作可以分配到一个量化的分数。职位分析问卷的不足之处在于没有对职位的特定工作活动进行描述，且可读性不强。

2)美国劳工部工作分析程序。

它是由美国劳工部所采用的工作分析方法，核心是对于每一项工作都按照任职者和信息、人、物三者之间的关系来进行等级划分。其基本程序为

①清理出任职者在信息、人、物这三个维度上有哪些基本活动，并予以归纳总结;

②根据目标职位的任职者在理论上需要哪个层次的活动，并赋予相应的分数;

③这三项的分的总和就成为此项工作的等级划分的基础。

(3)功能性工作分析方法。

功能性工作分析方法不仅仅是依据信息、人、物三方面来对工作进行分类，它还考虑以下四个因素：

①在执行工作时需要得到多大程度的指导;

②在执行工作时需要运用的推理和判断能力应达到什么程度;

③完成工作所需要具备的数字能力有多高;

④执行工作时所要求的口头及语言表达如何。

拓展资料：

结构化分析方法（Structured Method，结构化方法）是一种软件开发方法，一般利用图形表达用户需求，强调开发方法的结构合理性以及所开发软件的结构合理性。

结构化分析方法_网络

㈤ 什么是需求分析结构化分析的基本任务是什么结构化分析的步骤有哪些

结构化分析方法（Structured Method，结构化方法）是强调开发方法的结构合理性以及所开发软件的结构合理性的软件开发方法。
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。
它的设计原则包括：
使每个模块执行一个功能（坚持功能性内聚）
每个模块用过程语句（或函数方式等）调用其他模块
模块间传送的参数作数据用
模块间共用的信息（如参数等）尽量少

㈥ 结构化设计的基本步骤

分为概要设计和详细设计两个阶段。 概要设计也称为结构设计或总体设计，主要任务是把系统的功能需求分配给软件结构，形成软件的模块结构图。
概要设计的基本任务：设计软件系统结构：划分功能模块，确定模块间调用关系；数据结构及数据库设计：实现需求定义和规格说明过程中提出的数据对象的逻辑表示；编写概要设计文档： 包括概要设计说明书、数据库设计说明书，集成测试计划等；概要设计文档评审：对设计方案是否完整实现需求分析中规定的功能、性能的要求，设计方案的可行性等进行评审。
概要设计工具：结构图（SC: Structure Chart ），反映系统的功能实现以及模块与模块之间的联系与通信，即反映了系统的总体结构。注意：数据流DFD是软件生命周期的定义阶段中的需求分析方法中结构化分析方法的一种，此外还有数据字典（DD）、判定树和判定表，而SC是开发阶段中概要设计使用的方法。 详细设计的目的：为软件结构图（SC）中的每 一个模块确定采用的算法，模块内数据结构，用某种选定的表达工具（如N-S图等）给出清晰的描述。

㈦ 如何进行结构化需求分析,其建模方法都有哪些

1. 基本型需求，这类需求是应该得到满足，有是应该的，没有是会引起用户不满；所以这类需求是比较重要也是需求挖掘和需求分析应当用心做好的，这是一个产品的基础。举例说明，聊天表情，几乎任何具备聊天场景的IM，都有发送表情的功能，输入法也开发了自己的默认表情，如果你设计一款新的APP，缺少了表情，可能会让用户不满。

2. 期望型需求，在做用户调研或则访谈的时候，用户反馈如果有某个功能，该多好，当你想深入了解的时候，用户或客户自己也说不明白为什么需要这个功能，就是觉得如果你有，就很好，如果没有其实也影响不大；还有种可能，用户使用了竞品友商的产品，进行相互对比的时候，告诉你某某产品有这个功能，我觉得你们也应该有，这类需求属于期望型需求同时也属于基本型需求，所以这类需求不满足，会引起用户的不满，得到满足，会给产品加分但是不会太多。对于期望型需求，我曾经也纠结过苦恼过，也设计过原型，一直迟迟没有提交开发，这类需求收集到了可以提前准备，等时机成熟（有很多用户或则客户都提到这个需求）或则有开发资源的时候，再做。举个例子，我现在在做的是ToB的产品，是专业的销售人员、外勤人员的行为管理软件，提需求的大部分是后勤人员，他们的工作就是使用后台进行监督、管理、汇总等，尤其是刚刚使用我们产品，对考勤管理特别用心，每天都会盯着考勤查看谁请假、出差、迟到早退、各种异常，然后每月工资也会按照考勤来制定，问题来了，用户提到如果考勤能这样排版、这样汇总、如果能够在一个页面看到所有信息等等。其实这些需求都是某些用户频繁使用产品，遇到的麻烦和想偷懒所提出的，他们期望软件帮他们完成所有的工作，然后自己每天就是坐在电脑前静静的等待结果。这类需求，需要慎重容易导致产品变得越来越臃肿，为了满足了任何人的需求，反而满足不了任何人的需求。所以很多文章都提到，产品经理面对需求，需要做减法。期望型需求，就是考验产品经理做加法还是做减法的判断力。

3. 兴奋型需求，让人出乎意料的产品属性，这类需求满足了会给产品增加不少魅力和好评。

1. 生理上的需要：食物 / 水 / 睡眠 / 生理平衡 / 分泌 / 性 / 呼吸；对应的移动互联网产品有美团外卖、陌陌等。

2. 安全上的需要：人身安全 / 健康保障 / 资源所有 / 财产安全 / 道德保障 / 工作保障 / 家庭安全；对应的移动互联网产品有支付宝、咕咚、乐运动、超级减肥王、动动记步、KEEP等。

3. 情感和归属的需要：爱情 / 友情 / 性亲密；对应的移动互联网产品有珍爱网、世纪佳缘、生日管家、她趣等等。

4. 尊重的需要：自我尊重 / 信心 / 成就 / 对他人尊重 / 被他人尊重；对应的移动互联网产品有新浪微博等。

5. 自我实现的需要：道德 / 创造力 / 自觉性 / 问题解决能力 / 公正度 / 接受现实能力；对应的移动互联网产品有在行。

㈧ 结构化分析方法

结构化分析方法（Structured Method，结构化方法）是：一种软件开发方法。

结构化设计的步骤如下：

①评审和细化数据流图；

②确定数据流图的类型；

③把数据流图映射到软件模块结构，设计出模块结构的上层；

④基于数据流图逐步分解高层模块，设计中下层模块；

⑤对模块结构进行优化，得到更为合理的软件结构；

⑥描述模块接口。

㈨ 需求分析有哪几个步骤

需求分析就是对客户提出的“要求”或者“需求”进行深入细致地调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么，为系统设计、系统完善和系统维护提供依据。

需求分析是项目计划阶段非常重要的环节，该环节决定了需要“实现什么”，为下一步如何去“实现”提供了明确的方向。

进行需求分析需要做到以下几点：

（一）需求获取：在准备阶段，我们首先要确定需求获取的目标及范围，根据你的目标来选择对应的方式获取需求。

（二）需求分类：一般情况下，我们会根据对象的不同，将需求分为业务需求、用户需求、功能需求等。

（三）需求筛选：有些需求是伪需求，有些需求则不具备实现价值，我们可以通过真实性、价值性、可行性三个维度来筛选需求，过滤掉虚假的、不可行的、没有价值、价值不大或投入产出比不理想的需求。

（四）需求提炼：对剩下的需求进行提炼，目的在于从获取的表面需求中提炼出客户的本质需求。找出“为什么要做”比“做什么”更重要。

（五）需求优先级排序：挖掘到客户的真实目的后，我们需要根据不同维度的需求归类方法，如KANO模型分析法、投入产出比ROI等，对其进行归纳整理并排出优先级，帮助产品有条理地安排开发秩序，避免盲目排序。

（六）产出需求文档：通过以上的分析，我们需要将收集到的需求进行分析、汇总、归类，输出产出需求文档，为接下来的工作做好铺垫。

以上是对需求分析的一些理解和思路，做好需求分析工作之后，就可以对可实现的需求进行落地方案的跟进。

㈩ 结构化分析方法

结构化分析方法（Structured Method，结构化方法）是一种软件开发方法，一般利用图形表达用户需求，强调开发方法的结构合理性以及所开发软件的结构合理性。

主要用于分析需求,形成需求规约结构化分析方法是以自顶向下，逐步求精为基点，以一系列经过实践的考验被认为是正确的原理和技术为支撑，以数据流图，数据字典，结构化语言，判定表，判定树等图形表达为主要手段，强调开发方法的结构合理性和系统的结构合理性的软件分析方法。

其基本思想主要是把一个复杂问题的求解过程分阶段进行，而且这种分解是自顶向下，逐层分解，使得每个阶段处理的问题都控制在人们容易理解和处理的范围内。而它的基本要点是自顶向下、逐步求精、模块化设计、结构化编码。