需求分析的主要方法是

‘壹’ 需求分析有哪两种主要分析方法

从系统分析出发，可将需求分析方法大致分为功能分解方法、结构化分析方法、信息建模法和面向对象的分析方法。
(1)功能分解方法。
将新系统作为多功能模块的组合。各功能义可分解为若干子功能及接口，子功能再继续分解。便可得到系统的雏形，即功能分解——功能、子功能、功能接口。
(2)结构化分析方法。
结构化分析方法是一种从问题空间到某种表示的映射方法，是结构化方法中重要且被普遍接受的表示系统，由数据流图和数据词典构成并表示。此分析法又称为数据流法。其基本策略是跟踪数据流，即研究问题域中数据流动方式及在各个环节上所进行的处理，从而发现数据流和加工。结构化分析可定义为数据流、数据处理或加工、数据存储、端点、处理说明和数据字典。
(3)信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。

‘贰’ 项目需求分析的分析方法

需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如算法的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.

‘叁’ 软件工程中常用的需求分析的方法有哪些

一、过滤需求的方法
做后端系统，要学会的第一个技能就是砍需求。也就是过滤需求。

这不是一个贬义词，反而是体现后端产品价值判断的基础。

过滤需求的方法，就是通过一定的手段判断需求是否是伪需求，应该被过滤掉。

1. 用户场景模拟法
后端产品的出发点就是帮助业务用户，因此在调研需求的时候要模拟业务的场景，分析业务用户提到的需求是否能解决他的问题。

如果不能帮助用户，那么这个需求就可能是伪需求。

以下面的案例说明：

背景：“货到付款”类型的订单会因为缺货而无法发出，如果超过一定的时间，客服就会跟顾客沟通，帮顾客取消订单。

需求：由于这种订单的数量还是蛮多的，逐个取消太费时间，因此业务用户要求在“缺货订单”列表页增加“批量取消订单”按钮。

分析：调研到业务操作场景,是先找到该类缺货订单，然后和顾客沟通，顾客同意删除，才进行删除。也就是逐个沟通确认，再逐个取消订单的，所以“批量取消订单”无法被有效使用。

因此，该需求是个伪需求，应该被过滤掉。

2. 功能归属分析
专门的系统做专职功能，有助于合理的产品体系建设。

因此需求调研的时候，可以通过系统的定位，判断需求是否应该在该系统完成。

如果不属于该系统范畴，那么直接说服需求方更换方案。以

下面的案例说明：

背景：CRM系统（顾客关系管理系统）有一个顾客标签生成功能，就是根据顾客的消费行为数据，自动对应关联上标签，如优质顾客、高潜力顾客、欺诈顾客等。

需求：业务用户提出需求，除了做上述的基础标签之外，还要做出英语版本的标签（就是把标签文案翻译成英文），这样欧美员工可以在英语版本的系统下使用。

分析：调研到翻译之后的标签不是在CRM系统使用的，而是给到SMS（客服系统）使用的。

所以应该由SMS根据CMS提供的基础标签数据，自己做二次的衍生。

之所以这样，首先是为了避免未来更多语言版本的扩展需求或更多系统提出类似的需求；

其次，CRM系统已经完成了“接力赛”的第一棒，创造了基础数据，那么其他系统要特殊化使用，完全可以自行进行特殊化处理，无需耦合回CRM系统。

结论：案例的需求本身是真需求，并且实现上也没难度，但是该功能的定位超出了本系统范畴，专门系统做专职功能，化衍生需求应该在下游执行。

否则，耦合性过高只会增加系统的复杂程度，难以维护和扩展。

二、拆分和聚合的方法
1. 拆分需求法
业务用户提出一个需求，很可能只是短短的一段话。

但是不要高兴太早，可能这一句话暗含了很多线索，因此要善于拆分：

先找他要解决的核心问题，再围绕核心点，理清前、后、左、右、上、下的旁系需求点。

每个需求点再当做一个子需求进行调研，最后再聚合在一起。

以下面的案例说明：

背景：订单业务的类型很多，订单退货之后需要创建售后单据，但是因为数量大，所以花费很多人力，且手动创建有出错的风险。

需求：业务提出的需求是“增加退货订单自动创建售后单的功能”，这是个一句话需求。

该一句话需求，其实包含了多种具体的订单类型和场景，那么我们就要拆分调研，拆分的维度比如：

自营订单、第三方订单、货到付款订单、先款后货订单、部分退货订单、完全退货订单、服装事业部订单、电子事业部订单等，其中每一个维度就相当于一个小需求。

这里不一一展开。

2. 聚合需求法
拆分法是对单个需求分解成若干小需求进行调研，聚合法相反，是找到许多个相互关联的小需求的共性，然后统筹成一个大需求去完成。例如：

由于业务用户分散在不同的部门，各自为政，于是张三、李四可能都对一个业务流程有相同的需求，或者对同一个功能有相同的优化期望，结果俩人分别提了需求过来。那么产品经理就要找到二者背后的相关性和交叉区。

然后统筹规划，聚合在一起当作一个需求来调研，最终输出一个整体的需求调研结果。

三、利用辅助功能调研需求
调研产品现有功能，可以用来确认原有功能的逻辑，或者确定新需求方案是否可行。

比如业务用户需要更新一个功能，为了避免更新出错或遗漏，产品经理需要知道修改前和修改后是否会能正常运行。

最基础的办法就是自己设计一个测试用例，记录操作方式、状态变化、数据流向等。看看下面的例子：

背景：从销售网站获取到OMS系统（订单管理系统）的订单信息中带着顾客的邮箱。顾客下完单，可能会在销售网站修改邮箱，而此时已经获取到OMS的历史订单中的邮箱是不变的。

需求：顾客若在销售网站修改邮箱，要求已获取到OMS的该顾客的订单中的邮箱也要同步修改。

分析：需求是很明白的，也有它的意义，但有风险。

因为我们知道订单信息贯穿于整个订单流转过程中，牵扯到订单编辑、审核、取消、配货、发货等，而这些环节跳转的触发条件可能就是某个信息更新（这里面就可能包括有邮箱更新）。

因此，更新邮箱是否会影响流程中的某些环节，一时间很难准确知道。

于是，我们可以采用预测试的方式，设计测试用例，在测试机运行一些订单，观察各个环节邮箱变更的影响，然后收集起来分析对策。

测试法就像是探雷一样，主要用来解决未知风险点。这个方式的重点是记录和分析操作前状态、操作位点、操作后状态、操作后触发的连锁反应、数据流向等。

四、“拔萝卜带出泥”的方式调研需求
调研需求时，产品经理要拔萝卜带出泥,挖掘用户没看到的需求点和价值。

举例说明：

背景：公司入驻到销售平台后，销售平台会对入驻的店铺的违规行为进行罚款。

需求：业务用户提出需求，将销售平台的罚款数据抓取到订单系统，关联订单数据，以便进行人工分析。

分析：

第一步，先拆分需求，确定什么是罚款数据，总共有哪些罚款种类，需要对接哪些罚款种类，罚款数据与订单系统关联方式是什么，是否都能关联到，关联不到怎么办，销售平台是否已经提供了公用的罚款接口，Token（请求权限）如何获取，抓取频率怎么样，数据增长幅度多大，获取之后做哪些展示和搜索，用户权限怎么设置，需要和订单系统做哪些交互，该需求的价值是什么……

第二步，挖掘需求：是否需要作分析功能，分析功能的规则是什么；是否需要做监控和预警，是否需要指派负责人；其他业务人员是否也有类似需求，其他平台是否也有类似需求……

通过“拔萝卜带出泥”的方式，连带出更多需求点。将上述调研结果重新组装起来，得到一个系统化的完整需求。

罗列出需求要点和对应的验收目标，这样使得需求具象化，同时又不会遗漏细节，内部充实，外部闭环，并且进行了价值挖掘，做成控制阈值、预警、责任人分派、趋势分析、损失分析等高价值的功能，超出业务的预期。

‘肆’ 需求分析具体要怎么写要包括哪些内容

方法
⑴首先调查组织机构情况
包括了解该组织的部门组成情况，各部门的职能等，为分析信息流程作准备。
⑵然后调查各部门的业务活动情况
包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么。
⑶协助用户明确对新系统的各种要求
包括信息要求、处理要求、完全性与完整性要求。
⑷确定新系统的边界
确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。
常用的调查方法有：
⑴跟班作业
通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。
⑵开调查会
通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。
⑶请专人介绍。
⑷询问
对某些调查中的问题，可以找专人询问。
⑸设计调查表请用户填写
如果调查表设计得合理，这种方法是很有效，也很易于为用户接受的。
⑹查阅记录
即查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。
通过调查了解了用户需求后，还需要进一步分析和表达用户的需求。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。

‘伍’ 需求分析的步骤有哪些

一、需求识别
需求人员在此步骤应该分析需求类别、需求复杂度和需求价值用来确定需求实施的优先级。

1.需求类别确认：

需求类别包含流程类需求、统计分析类需求、接口类需求，一个需求可能为某一类型需求，也可能包含多类需求。

确认需求类别后应对每类需求的数量进行初步分析（比如流程类需求包含几个流程、统计分析类需求包含几个报表、接口类需求包含几个接口）。

2.需求复杂度分析：

一般需求受理工作量在1-5人天的需求复杂度低，工作量在5-15人天的需求复杂度中，工作量在15人天以上需求复杂度高。（工作量表示需求受理全过程需求人员需要付出的工作量）。

3.价值分析：

需求人员收到需求后应根据收集需求内容初步分析需求痛点/目标、需求复杂度、业务重要程度确定需求价值，需求价值分析
二、业务流程/统计查询/接口分析
针对流程类需求必须进行业务流程分析，统计查询和接口类需求可不进行详细的流程分析。

1.业务流程分为部门级、组织级和岗位级

部门级流程关注脉络需要分析涉及哪些具体岗位、执行活动、每个活动之间的关联关系，它是需求分析的主线条，也是流程分析的主要产物。
组织级流程关注宏观一般不会直接绘制，是对部门级流程的概括和抽象。
岗位级流程关注每个业务活动的执行步骤属需求细节范畴，在流程分析阶段不要过度进入细节。
2.需求识别阶段确认的流程均为部门级流程

需求人员在进行流程分析应遵循如下方法：

（1）业务流程确认：

一个流程为一个业务事件，一般是外部角色发起或系统内部主动发起（比如时间事件或状态事件），发起后会触发一系列业务活动。

（2）角色及业务活动确认：

流程图中的每个泳道都必须对应到角色，每个角色对应多个业务活动。需求人员在确认业务活动时一定要保证活动的粒度，一个业务活动一定是由一个角色完成且每个业务活动都是有价值的活动。

比如项目输入项目名称是一个执行步骤，这个动作没有价值，项目经理查询项目信息就是一个业务活动。

在需求描述时针对线下活动或新增活动应该应标识区分。

（3）业务活动间关系及数据确认：

确定所有业务活动的前后置关系，并明确流程间的传递的数据实体。

（4）流程整体瓶颈分析：

一般若某个角色业务活动工作量较大，或流程涉及高级领导，一般都会造成瓶颈，这种情况需求人员应想办法分散工作量提出流程优化建议。

3.针对统计查询类需求及接口类需求，按照上述业务活动确定原则分析、确定角色，并明确每个角色所执行的业务活动即可。

三、数据实体分析
针对流程类需求需要分析各业务活动传递的数据实体，统计分析类需求需要分析统计查询条件和查询展现两类数据实体、接口类需求需要分析接口传递数据实体，具体分析包含如下内容：

1.明确数据实体：

确认需要分析的所有数据实体，明确哪些为系统原有实体、哪些为新增实体、哪些为改造实体。

2.明确所有数据实体间关系：

实体间关系包含（1对1、1对多、多对多），另外需要分析数据实体变更是否需要保留版本，实体删除（逻辑删除、物理删除）是否影响其它数据实体。

3.明确数据实体字段：

针对新增数据或改造数据实体需要明确新增字段的名称、字段类型、是否必填、字段取值方式（人工输入、系统自动继承自其它数据实体、系统自动计算需要明确计算公式）。

4.数据权限分析：

需要分析不同角色在数据权限方面的差异，若涉及纵向多级用户，要说明对于集团/省/地市用户的数据隔离。

四、角色及使用场景分析
一般来说每个业务活动是对用户使用场景的抽象，每个业务活动可能包含多个场景，分析使用场景时应按照业务活动为主线逐个进行分析，每个业务活动分析时应包含如下内容：

1.明确活动执行角色。

2.明确活动执行的前置条件和后置条件。

3.明确不同场景：

一个业务活动可能包含正常的使用场景、备选使用场景和异常使用场景；

4.明确每个场景的执行步骤：

描述执行步骤时应使用简单的语法，主语明确语义易于理解，每个步骤不应该在任何一方（执行角色、系统）停留两部以上，重点描述如何交互。

5.业务规则和约束：

明确在每个业务活动下应遵循的业务规则和约束，这里一般是与业务流程相关的行为规则（比如项目周期时长超过90天必须提交二级领导审批），或与数据实体相关的数据规则（需求交接单拒收时候必须填写拒收原因，且拒收原因不能超过500字）。

五、系统功能分析

‘陆’ 需求分析方法主要包括哪些

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

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

‘柒’ 需求分析的建模分析方法有哪两种

数据库设计需求
1. 需求概述
建立完善的数据库结构管理设备的基本参数、运行状态和各种工作计划。

数据库的框架和结构必须根据设备和运行状态而设计，方便提供强大的录入、查询、统计、分析和报表等各种功能操作，较好的反映平台业务的基本情况和运行状况，满足平台的基本要求。

2. 外部设计需求
2.1 标识符和状态

数据库表前缀：根据模块名定义（如用户模块：sys_）

用户名：root

密码：待定

权限：全部

有效时间：开发阶段

说明：系统正式发布后，可能更改数据库用户/密码。

2.2 使用它的程序

本系统主要利用java作为后端的应用开发工具，使用MySQL作为后台的数据库， Linux或Windows均可作为系统平台。

2.3 约定

所有命名一定要具有描述性，杜绝一切拼音、或拼音英文混杂的命名方式。
字符集采用 UTF-8，请注意字符的转换。
所有数据表第一个字段都是系统内部使用主键列，自增字段，不可空，名称为：id，确保不把此字段暴露给最终用户。
除特别说明外，所有日期格式都采用date格式。
除特别说明外，所有字段默认都设置不充许为空， 需要设置默认值。
所有普通缩影的命名都是表名加设置缩影的字段名组合，例如用户表User中name字段设置普通所以，则缩影名称命名方式为user_name_index。
2.4 专门指导

对本系统的开发者、使用这、测试员和维护人员，提出以下参考意见：

在使用数据库时，首先要参考上面的约定内容，做好软件的安装以及表格的建立。
数据库的输入统一采用键盘。对于数据库的使用权限，请参考本系统其他相关文档。
数据库的后台管理员没用等级差异，可根据实际情况添加删除管理员。
2.5 支持软件

操作系统： Linux / Windows

数据库系统：MySQL

查询浏览工具：Navicat Premium

命令行工具：mysql

注意：mysql 命令行环境下对中文支持不好，可能无法书写带有中文的 SQL 语句。

3. 结构设计需求
3.1 概念结构设计需求

概念数据库的设计是进行具体数据库设计的第一步，概念数据库设计的好坏直接影响到逻辑数据库的设计，影响到整个数据库的好坏。

我们已经得到了系统的数据流程图和数据字典，现在就是要结合数据规范化的理论，用一种模型将用户的数据要求明确地表示出来。

概念数据库的设计应该极易于转换为逻辑数据库模式，又容易被用户所理解。概念数据库设计中最主要的就是采用“实体-关系数据”模型来确定数据库的结构。

数据是表达信息的一种重要的量化符号，是信息存在的一种重要形式。数据模型则是数据特征的一种抽象。它描述的是数据的共性，而不是描述个别的数据。一般来说，数据模型包含两方面内容：

数据的静态特性：主要包括数据的基本结构、数据间的关系和数据之间的相互约束等特性。
数据的动态特性：主要包括对数据进行操作的方法。
在数据库系统设计中，建立反映客观信息的数据模型，是设计中最为重要的，也最基本的步骤之一。

数据模型是连接客观信息世界和数据库系统数据逻辑组织的桥梁，也是数据库设计人员与用户之间进行交流的共同基础。概念数据库中采用的实体-关系模型，与传统的数据模型有所不同。“实体-关系”模型是面向现实世界，而不是面向实现方法的，它主要是用使用方便，因而在数据库系统应用的设计中，得到了广泛应用。“实体-关系”模型可以用来说明数据库中实体的等级和属性。

以下是实体-关系模型中的重要标识：

在数据库中存在的实体；
实体的属性；
实体之间的关系；
3.2 逻辑结构设计需求
物理结构设计需求

1）定义数据库、表及字段的命名规范：

数据库、表及字段的命名要遵守可读性原则。
数据库、表及字段的命名要遵守表意性原则。
数据库、表及字段的命名要遵守长名原则。
2）选择合适的存储引擎：
3）为表中的字段选择合适的数据类型。

4）建立数据库结构

4. 运用设计需求
4.1 表名的命名规范

表名以英文单词、单词缩写、简写、下划线构成，总长度要求小于30位。

4.2 表字段的命名规范

字段名以英文单词、单词缩写、简写、下划线构成，总长度要求不超过30位。
字段名以名词或名词短语，字段采用单数形式。若表名由多个单词组成，则取各个单词的缩写组成，单词缩写间使用下划线作为分隔。
若某个字段是引用某个表的外键，则字段名应尽量与源表的字段名保持一致，一面混淆。
5. 安全保密设计需求
5.1 防止用户直接操作数据库的方法

通过把关键应用服务器和数据库服务器进行分离，防止用户对数据库服务器的直接操作，保证数据库安全。

5.2 应用系统的用户口令进行加密

在软件系统中，对于数据的保护、业务操作的许可是通过识别用户身份和权限来完成的。用户口令相比较，相同的话系统将该用户的操作权限分配给用户，用户再根据所分配的权限对系统进行操作。

由以上过程可知，用户口令在传输过程中容易被窃取泄漏，另外如果数据库被非法进入则其中保存的口令能够被非法查看。因此，在传输过程中和数据库中的口令记录字段不应使用明文传递和保存，应该在口令被传递前对其明文口令使用有效的主流技术，对传输数据进行加密部分描述的加密算法进行加密，在加密后传输到系统。系统将用户提交的经过加密的口令数据保存的加密口令进行比较，相一致则进行后续操作。

‘捌’ 需求分析有哪几个步骤

一、需求获取阶段
在需求获取阶段，需要做好收集和管理两件事。

这些需求既有产品经理主动挖掘的，也有从用户、运营、业务方、领导等渠道被动获取的，无论哪个渠道来的需求，都需要有一个正式的地方进行管理，也就是我们通常所说的需求池。

不过，对于多方关注的重点需求，通过需求池来向各方同步就不太合适了：

一是因为需求池内容太多、太杂，向业务方、领导汇报的时候会有很多干扰信息，难以快速抓住重点；
二是因为需求池里面可能有些需求不适合完全公开。
这时我们就需要使用《事项跟踪表》来单独跟进，形式上用Excel、PPT都可以。

而放在《事项跟踪表》里的需求，也要在需求池里记录下来，即需求池是做全量需求管理的，《事项跟踪表》是做重点需求跟进、汇报的。

二、需求分析阶段
1. 分析内容
需求分析主要从需求要素、定位、分解、优先级四个方面进行。

1）需求要素分析

需求要素分析是从需求本身出发，不考虑其他因素。

这些要素包括：内容、用户/角色、频次、价值、场景-动机、强度六个方面，这些要素的含义大家应该都比较清楚了，这里说一下分析各个要素的目的是什么：

分析需求内容，是为了弄清楚需求是什么；
分析需求用户/角色，是为了弄清楚需求为谁服务；
分析需求频次、强度，是为了弄清楚需求对用户的重要性、紧迫程度；
分析需求场景-动机，是为了弄清楚需求真伪、用户目的，更深入的理解需求；
分析需求价值，是为了弄清楚需求值不值得做。
2）定位分析

需求的定位分析是分析需求对产品当前阶段目标的意义。

分析需求的定位，有以下两个目的：

一是作为优先级排期的判断条件之一，如果需求与产品当前阶段的目标密切相关，则需要作为高优先级上线；
二是为了框定需求范围。每个需求的实现程度都有深有浅，可以很简单，也可以很复杂，了解了需求之于产品的定位，就能判断需求要做到什么程度。如果一个需求对产品很重要，那就需要做得很丰富，如果只是辅助需求，则需要适当轻量。
3）需求分解

原始需求的颗粒度往往较粗，不利于后续的分析、设计、开发等工作，所以我们需要对这些颗粒度较粗的原始需求进行分解，分解为一个个完整、独立、可实现的子需求。

4）优先级分析

优先级分析是以拆解后的子需求为单位进行的，根据各类优先级的判断方法、原则，初步评估各个子需求的上线顺序及时间。

2. 常见问题
需求分析应该是大家从入行那天就知道要做的事，但大多数同学在做需求分析时会犯以下三个比较常见的错误。

1）缺乏系统性

这是在分析中最常见的问题，即很多同学在分析需求时没有系统性的框架，导致很多方面没有分析到、考虑到，从而对需求认识不全面。

2）缺乏深度

对需求某些要素认识比较浅，不够细致深入，例如在分析需求的用户时，没有对用户分层、切片，对各个分层的用户也缺乏足够的了解，导致对用户只有一个笼统、模糊的认识，最后自然无法深入进去。

不过分析是否有深度的定义其实很难把握，也缺乏明确的判断标准，需要随着分析者思维能力的提升、信息量的提升来加强。

‘玖’ 什么是需求分析需求分析阶段的基本任务是什么

需求分析也称为软件需求分析、系统需求分析或需求分析工程等，是开发人员经过深入细致的调研和分析，准确理解用户和项目的功能、性能、可靠性等具体要求，将用户非形式的需求表述转化为完整的需求定义，从而确定系统必须做什么的过程。

需求分析阶段的基本任务：

1、需求分析是软件计划阶段的重要活动，也是软件生存周期中的一个重要环节，该阶段是分析系统在功能上需要“实现什么”，而不是考虑如何去“实现”。

2、需求分析的目标是把用户对待开发软件提出的“要求”或“需要”进行分析与整理，确认后形成描述完整、清晰与规范的文档，确定软件需要实现哪些功能，完成哪些工作。

3、此外，软件的一些非功能性需求（如软件性能、可靠性、响应时间、可扩展性等），软件设计的约束条件，运行时与其他软件的关系等也是软件需求分析的目标。

(9)需求分析的主要方法是扩展阅读：

需求分析应符合以下一般原则：

1、能够对所建模型按一定形式进行分解

分解是为了降低问题的复杂性，增加问题的可解性和可描述性。分解可以在同一个层次上进行（横向分解），也可以在多层次上进行（纵向分解）。

2、建立描述系统信息、功能和行为的模型

建立模型的过程是＂由粗到精＂的综合分析的过程。通过对模型的不断深化认识，来达到对实际问题的深刻认识。