网上科普有关“需求分析方法有哪些?”话题很是火热
，小编也是针对需求分析方法有哪些?寻找了一些与之相关的一些信息进行分析，如果能碰巧解决你现在面临的问题 ，希望能够帮助到您
。

问题一：需求分析有哪些方法 三种需求分析的方法：结构化分析方法、面向对象的分析方法 、面向问题域的分析方法。

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

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

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

问题三：如何做好需求分析 ，需求调研 转载以下资料供参考

从广义上理解：需求分析包括需求的获取
、分析、规格说明 、变更
、验证、管理的一系列需求工程
。

狭义上理解需求分析指需求的分析 、定义过程。

原因

需求分析就是分析软件用户的需求是什么 。如果投入大量的人力，物力
、财力、时间
，开发出的软件却没人要，那所有的投入都是徒劳。如果费了很大的精力 ，开发一个软件
，最后却不满足用户的要求，从而要重新开发过 ，这种返工是让人痛心疾首的(相信大家都有体会)
。比如：用户需要一个for linux的软件
，而你在软件开发前期忽略了软件的运行环境，忘了向用户询问这个问题 ，而想当然的认为是开发for windows的软件。当你千辛万苦地开发完成向用户提交时才发现出了问题
，那时候你是欲哭无泪了，恨不得找块豆腐一头撞死 。

需求分析之所以重要 ，就因为他具有决策性 、方向性、策略性的作用
，他在软件开发的过程中具有举足轻重的地位，大家一定要对需求分析具有足够的重视
。在一个大型软件系统的开发中 ，他的作用要远远大于程序设计。

任务

简言之，需求分析的任务就是解决“做什么的问题
，就是要全面地理解用户的各项要求，并准确地表达所接受的用户需求 。

过程

需求分析阶段的工作,可以分为四个方面：问题识别
、分析与综合、制订规格说明 、评审
。

问题识别：就是从系统角度来理解软件 ，确定对所开发系统的综合要求
，并提出这些需求的实现条件，以及需求应该达到的标准。这些需求包括：功能需求(做什么)
、性能需求(要达到什么指标)、环境需求(如机型 、操作系统等)
、可靠性需求(不发生故障的概率）、安全保密需求 、用户界面需求
、资源使用需求(软件运行是所需的内存、CPU等) 、软件成本消耗与开发进度需求
、预先估计以后系统可能达到的目标 。

分析与综合： 逐步细化所有的软件功能 ，找出系统各元素间的联系
，接口特性和设计上的限制，分析他们是否满足需求 ，剔除不合理部分
，增加需要部分
。最后综合成系统的解决方案，给出要开发的系统的详细逻辑模型(做什么的模型)。

制订规格说明书： 即编制文档 ，描述需求的文档称为软件需求规格说明书 。请注意
，需求分析阶段的成果是需求规格说明书，向下一阶段提交
。

评审： 对功能的正确性 ，完整性和清晰性，以及其它需求给予评价。评审通过才可进行下一阶段的工作,否则重新进行需求分析 。

方法

需求分析的方法有很多
，这里只强调原型化方法，其它的方法如：结构化方法、动态分析法等 ，从来没用过这些方法在此不讨论。

原型化方法是十分重要的
，原型就是软件的一个早期可运行的版本，它实现了目标系统的某些或全部功能
。

原型化方法就是尽可能快地建造一个粗糙的系统 ，这系统实现了目标系统的某些或全部功能。但是这个系统可能在可靠性 、界面的友好性或其他方面上存在缺陷 。建造这样一个系统的目的是为了考察某一方面的可行性
，如算法的可行性、技术的可行性或考察是否满足用户的需求等
。如：为了考察是否满足用户的要求，可以用某些软件工具快速的建造一个原型系统 ，这个系统只是一个界面
，然后听取用户的意见，改进这个原型。以后的目标系统就在原型系统的基础上开发 。

原型主要有三种类型：探索型
、实验型、进化型
。

探索型：目的是要弄清楚对目标系统的要求 ，确定所希望的特性
，并探讨多种方案的可行性。

实验型：用于大规模开发和实现前，考核方案是否合适 ，规格说明是否可靠 。

进化型：目的不在于改进规格说明，而是将系统建造得易于变化
，在改进原型的过程中，逐步将原型进化成最终系统
。

在使用原型化方法时有两种不同的策略：废弃策略 、追加策略。

废弃策略：先建造一个功能简单而且质量要求不高的模型系统 ，针对这个系统反复进行修改,形成......>>

问题四：请问常用的需求分析方法有哪些？ 结构分析方法和面向对象分析法

问题五：培训需求分析的方法有哪几种 组织资源分析

如果没有确定可被利用的人力
、物力和财力资源
，就难以确立培训目标 。组织资源分析包括对组织的金钱、时间 、人力等资源的描述
。一般情况下，通过对下面问题的分析 ，就可了解一个组织资源的大致情况。

组织特质与环境分析

组织特质与环境对培训的成功与否也起重要的影响作用 。因为
，当培训规划和组织的价值不一致时，培训的效果则很难保证。组织特质与环境分析主要是对组织的系统结构
、文化、资讯传播情况的了解
。主要包括如下内容：

系统特质指组织的输入 、运作
、输出、次级系统互动以及与外界环境间的交流特质 ，使管理者能够系统地面对组织
，避免组织分析中以偏概全的缺失。

文化特质 。指组织的软硬体设施 、规章
、制度、组织经营运作的方式 、组织成员待人处事的特殊风格，使管理者能够深入了解组织 ，而非仅仅停留在表面
。

资讯传播特质。指组织部门和成员收集、分析和传递信息的分工与运作
，促使管理者了解组织信息传递和沟通的特性 。

问题六：在需求分析阶段常用的图形工具有哪三种 1. 需求分析是准确的理解用的需求将其转换成需求定义，然后由需求定义转换成形式化的功能规约
。需求分析的困难表现在问题的复杂性
、交流的障碍、不完备和不一致性 、需求易变性。 2. 结构化分析方法是采用自顶向下逐层分解的分析策略把一个复杂的系统分解成若干小问题然后分别解决 3. 数据流即数据通过一个系统时的变化方式 。输入数据首先转换成中间数据 ，然后转换成输出结果数据
。在此期间可以从已有的数据存储（如磁盘文件或内存缓冲区）中引入附加数据。对数据进行转换是程序中应有的功能或子功能 。两个转换功能之间的数据传递就确定了功能间的接口
。 4. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口
，就属于横向分解。 5. 把一个功能分解成几个子功能，并确定这些子功能与父功能的接口 ，就属于横向分解 。但如果继续分解
，把某些子功能又分解为小的子功能，某个小的子功能又分解为更小的子功能 ，这就属于纵向分解了。 6. 数据流图是用来表示系统的功能的工具它表示系统的逻辑模型描述了数据流在系统中流动的情况它是一种功能模型
。

问题七：如何做需求分析 随着技术的不断发展和用户对网站功能性的需求不断提高
，如今网站项目的设计已经不能再仅仅简单地利用静态Html文件来实现，与前几年网站设计由一两名网页设计师自由的创作相比 ，网站项目的设计和开发越来越像一个软件工程
，也越来越复杂，网站项目的设计和开发进入了需要强调流程和分工的时代 ，建立规范的
、有效的、健壮的开发机制
，才能适应用户不断变化的需要，达到预期的计划目标。

网站项目管理（WPM）的含义为Web-based Project Management ，即以Web 应用程序为主要表现方式的架构来进行的项目设计及管理，这样的架构中包含了浏览器 、网络和Web

服务器等关键主体
，主要体现在网站设计
、以浏览器为客户端的Web应用程序开发（例如信息类网站、网上商店 、虚拟邮局
、客户关系管理 。）等项目管理中
。

按照笔者的经验，网站项目管理可以分为以下l六个阶段进行控制：

1. 需求分析及变更管理

2. 项目模型及业务流程分析

3. 系统分析及软件建模

4. 界面设计、交互设计及程序开发

5. 系统测试和文档编写

6. 客户培训 、技术支持和售后服务

需要说明的是 ，这些阶段虽然具有一定的延续性
，但是并非完全隔断的，例如需求变更管理和测试工作
、文档编写都是贯穿整个项目过程的 ，许多工作时交叉进行或同时进行的。

（一）如何做好需求分析及变更管理？

业务员与客户进行的沟通
，撰写需求分析报告是项目展开的基础 。项目是以客户的需求为中心，而不是为技术而迁就需求
。

一：让客户畅所欲言 ，罗列出所有的需求

让用户将所有的想法尽可能的阐述清楚
，并把所有的要求罗列出来，不要遗漏。这时候不应该害怕“勾引 ”起客户的潜在需求而增加设计开发的工作量 ，从而被今后客户无止境的变更拖入泥潭
，直接明白地跟客户把问题和要求一条条地列出来，把条理、归纳 、分析先都扔到一边去 ，将用户最原始、最完整的要求准确地记录下来就完成了第一步的工作 。

很明显，假如客户的需求做的都不完整
，随时可能会产生意想之外的变更，甚至这个变更会破坏已经做的模型及结构 ，那么这个项目从开始就注定了会失败；比如站点所有的功能都实现了
，本地测试起来也没有什么问题了，但是你却不知道客户的系统是要承受每天100万独立IP的访问 ，而你原来想当然的以为了不起就是1万独立IP访问的访问流量
，稍微有经验的开发人员都会明白这样的设计是个灾难，无论是应用服务器
、数据库还是程序全部要重新开发！

二：透过现象分析潜在的需求

很多情况下客户并非专业人士 ，在他们滔滔不绝的描述中不能指望他们帮助我们整理出重点和技术难关
，这需要我们去为客户进行分析、归纳和整理，尤其是客户谈的不多却又是技术上实现难度和强度很高的地方特别值得注意
。

客户往往对需求的概念是非常模糊的 ，大多时候给出的需求都是笼统而且尺度难以控制的
，这就要求业务人员在倾听了客户的详细说明以后，帮助客户进行整理和分析 ，同时预测客户在开发过程中变更及今后应用中可能进行修改升级的潜在需求。

比如在为客户设计办公自动化系统的时候，也许就要为客户预留将来与他们的业务单位进行交互的通道；在设计邮件系统的时候要考虑可能会需要广告管理服务器；设计网络电子商店时今后增加库存产品进销存统计分析等等；限于时间财力的考虑
，客户通常能够接受分阶段实施的开发过程，在需求分析时 ，提早为客户设想到今后的需求变更除了使项目开发更加顺利以外
，也为今后业务的进一步深入打下......>>

问题八：软件需求分析的方法和工具有哪些内容 1. 问卷调查法， 开发方就用户需求中的一些个性化的 、需要进一步明确的需求 ，通过采用向用户发问卷调查表的方式
，达到彻底弄清项目需求的一种需求获取方法 。这种方法适合于开发方和用户方都清楚项目需求的情况
。因为开发方和建设方都清楚项目的需求，则需要双方进一步沟通的需求就比较少 ，通过采用这种简单的问卷调查方法就能使问题得到较好的解决

2. 会议讨论法 
，开发方和用户方召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法 ，这种方法适合于开发方不清楚项目需求（一般开发方是刚开始做这种业务类型的工程项目）但用户方清楚项目需求的情况。因为用户清楚项目的需求
，则用户能准确地表达出他们的需求，而开发方有专业的软件开发经验 ，对用户提供的需求一般都能准确地描述和把握

3. 界面原型法 ，开发方根据自己所了解的用户需求
，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型
”这一载体 ，达到双方逐步明确项目需求的一种需求获取的方法 。这种方法比较适合于开发方和用户方都不清楚项目需求的情况。因为开发方和用户方都不清楚项目需求
，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解
。这种情况下，采用“可视化 ”的界面原型法比较可取

自从互联网行业的兴起 ，需求这个词也从原本传统行业的定义中不断延伸
，对于互联网行业的从业者，在每天接收到的海量信息中 ，懂得哪些是需求
，如何筛选，归纳 ，分析需求
，更是尤为重要的能力。通过了解需求，分清轻重缓急 ，事半功倍的达成目标，而不是成为需求的奴隶
，每天被来自各方的需求鞭策，却不知为何而忙碌 。

本文结合了笔者在产品行业工作的微薄经验 ，整理出从需求收集—需求整理—需求分析的方法论
，未必会适用于所有的互联网工作流中，但希望系统性的思考过程可以帮助理清思路 ，在繁杂的需求中找到那个破局的线头
。

在进入具体的分析前
，我们要知道， 什么是需求？

首先要明确的一点 ， 需求不等于需要。

需要是因某种“缺乏
”而产生的物质需要和精神需要
，例如，我想要吃饭 ，这是一种物质需要 。我想要开心
，这是一种精神需要
。需要是结果型的指向，而且可能会因为各种因素而不断变化和发展。

而需求可以当做更为具体的需要 ，要有具体场景具体人物 。满足需求可以当做一种可行的选择，在互联网的语境下就是
，要在什么场景下，解决了什么人 ，的哪些问题
。核心关键在于解决问题。

例如
，我想要吃饭，但是没有工具 ，问题产生了
，这个就是需求，为了解决这个问题 ，我们可以提供多种选择
，筷子，勺子 ，叉子等等
，而哪个选择是真正能满足需求的选择，哪个工具能满足吃饭的这个需求？这个可能又要具体分析 ，为什么想要吃饭？在哪吃饭？是谁在吃饭？等等，这些就后文再提到了 。

由此可以看到
，当面对需求的时候，要警惕它是不是个需求 ，也要将需求的颗粒度拆解到尽可能的细
，只有把需求的颗粒度变细，我们才能做出满足需求的产品 ，当你想从“我想吃饭”这个高度去满足用户
，而不去分析里面的原因，很有可能发生的是 ，用户只想要个饼
，你却给了个满汉全席，成本无限高 ，这的确是一种选择
，却未必是分析后的最优选择
。

在需求收集的阶段，并不需要对需求进行归类或者分析 ，重要的是将需求在避免收集人主观意识的影响下，完整的收集起来。

收集需求时一定要真实
、客观的记录需求提出者的描述
，包括需求背景，产生原因 ，具体期望等等
，以便后续分析时做到可追踪，可体验 。

可追踪即可以再次找到需求提出者 ，针对不清晰的地方进行沟通
，因为很多时候，需求收集人和产品设计人未必是一个人 ，需求可能由客服
，市场调研，销售等各处收集而来 ，所以需要尽可能避免需求在转述中产生的理解歧义
，在有不理解的时候也可以找到需求提出者进行再次沟通

可体验即对于需求发生的场景及问题，可以复现并再次体验 ，方便产品设计人真实体验理解需求或找到准确的目标用户群去验证需求。

从需求来源的不同，需求收集有以下几个渠道：

（1）其它业务部门：此渠道的需求多应用于支撑型或平台型的产品
，例如OA，CRM等
。此类需求由于通常是为业务部门的工作服务 ，所以需求通常都比较明确
，但是沟通成本仍然很高。

因为业务部门提供的需求虽然明确，但解决方案未必能真正解决问题 ，甚至成本还通常较高 。此时则需要产品设计人去跟业务部门了解沟通
，去了解组织机构，业务部门在组织机构的业务流中处于哪个位置 ，业务部门的职能职责及工作流程
，业务部门的目标及战略等
。

通过了解这些关键节点，可以梳理清支撑业务部门的方式 ，也帮助理解业务部门提出需求的真实原因
，然后由产品设计人给出可行的解决方案。

（2）客户需求：如来自项目投资人，购买产品的用户等的需求 ，要去从为客户达成目标，带来的价值
，提高效率的方面考虑 。

（3）老板需求：之所以将这个单拎出来，是因为来自老板的需求在产品经理的职业生涯中是不可避免的 ，如果不正确对待老板的需求
，甚至会打乱产品正常的迭代节奏
。所以要去了解老板需求的来源，是由于公司战略 ，商业价值
，还是体验中产生的需求，或者是看了下其它的文章等。如果是由于公司战略 ，优先级通常要放到最高 。

（4）测试需求：一般都是测试中产生的bug或体验缺陷等
，这些需求由于通常来自已经完成的功能或产品，所以考虑下性价比 ，具体问题具体分析即可
。

（1）竞品分析：竞品分析是产品经理提供新需求的重要渠道
，竞品分析适用于产品生命周期的各个阶段，通过研究竞品 ，可以了解市场动态和竞争对手的产品方案，挖掘出适用于自身产品的需求
，也避免新的idea没有经过系统性的沉淀和思考。

（2）用户研究：用户研究也是了解产品，获取需求的重要方式 。用户研究发展到现在 ，也已经有很多切实可行的系统性用户研究方法
，用户研究可以帮助产品设计者了解真实的目标用户群体和潜在用户的需求，避免产品设计天马行空 ，脱离真实用户

（3）数据分析：通常与竞品分析和用户研究结合起来运用
，也在产品迭代中可以做行为数据分析，通过数据来挖掘出需求点
。

尽管需求的来源渠道有很多种 ，但在处理这些需求的时候
，有个共同点就是要去了解需求产生的真实原因。

当产品不断迭代，各方产生的需求越来越多时 ，整理需求可以避免需求遗漏
，同时梳理清需求的开发周期 。

（1）分类：可以按照各个产品设计者在实际处理需求时的习惯分类方法，例如按照功能需求和非功能需求分 ，按照业务需求，项目需求和用户需求分等等
，笔者通常按照用户体验/新增功能/视觉优化/质量缺陷的需求种类分类。

（2）需求描述：包括问题描述，使用场景 ，用户痛点和具体功能描述
，这里的问题描述和使用场景主要由需求提出者提供，用户痛点和具体功能描述可以由产品设计者经过沟通和分析后写出

（3）需求处理状态：针对每一条需求 ，给出需求处理的状态
，如不处理，规划中 ，暂未启动
，开发中，暂停开发 ，已处理
。

（4）需求进度：当需求正在开发阶段
，可以一目了然看出各个需求进展到哪个环节及需求的排期，如产品设计 ，技术，交互
，UI，测试 ，发布

（5）优先级：对每一项需求进行优先级判断
，通常高/中/低的优先级已经可以整理需求，具体判断优先级的方法在后文需求分析的部分提到。

（5）其它：包括功能模块——需求是哪个功能模块的需求 ，提出时间——需求提出时间
，提出者——需求提出人，方便追踪 ，版本号——可以为问题产生的版本
，也可以为需求解决的版本，责任人/责任部门——对于需求收集人来说 ，收集到的需求可能需要由多个部门解决 。

本篇是需求分析的前置准备
，需求收集及需求整理篇，下一篇则进入需求分析篇 ，面对收集来的海量需求，我们如何分析需求的价值
，可行性和优先级，仅供参考 ，欢迎各位互联网行业从业者一起交流
。

关于“需求分析方法有哪些? ”这个话题的介绍
，今天小编就给大家分享完了，如果对你有所帮助请保持对本站的关注！