需求分析方法

① 需求分析有哪几个步骤

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

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

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

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

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

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

1）需求要素分析

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

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

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

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

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

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

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

4）优先级分析

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

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

1）缺乏系统性

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

2）缺乏深度

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

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

② 需求分析的步骤有哪些

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

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 应用系统的用户口令进行加密

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

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

④ 需求分析有哪三种方法2，什么是面向数据结构方法

它首先用结构化分析（SA）对软件进行需求分析，然后用结构化设计（SD）方法进行总体设计，最后是结构化编程（SP）。它给出了两类典型的软件结构（变换型和事务型）使软件开发的成功率大大提高。

三种基本的结构形式就是顺序、选择和重复。三种数据结构可以进行组合，形成复杂的结构体系。这一方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其它细节，就可得到完整的程序结构图。这一方法对输入、输出数据结构明确的中小型系统特别有效，如商业应用中的文件表格处理。该方法也可与其它方法结合，用于模块的详细设计。

⑤ 需求分析怎么做

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)信息建模方法。
它从数据角度对现实世界建立模型。大型软件较复杂；很难直接对其分析和设计，常借助模型。模型是开发中常用工具，系统包括数据处理、事务管理和决策支持。实质上，也可看成由一系列有序模型构成，其有序模型通常为功能模型、信息模型、数据模型、控制模型和决策模型。有序是指这些模型是分别在系统的不同开发阶段及开发层次一同建立的。建立系统常用的基本工具是E—R图。经过改进后称为信息建模法，后来又发展为语义数据建模方法，并引入了许多面向对象的特点。
信息建模可定义为实体或对象、属性、关系、父类型/子类型和关联对象。此方法的核心概念是实体和关系，基本工具是E-R图，其基本要素由实体、属性和联系构成。该方法的基本策略是从现实中找出实体，然后再用属性进行描述。

⑦ 项目需求分析的分析方法

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

⑧ 需求分析方法主要包括哪些

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

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

⑨ 测试需求分析方法有哪些

什么是测试需求?
确切地讲，所谓的测试需求就是在项目中要测试什么。我们在测试活动中，首先需要明确测试需求(What)，才能决定怎么测(How)，测试时间(When)，需要多少人(Who)，测试的环境是什么(Where)，测试中需要的技能、工具以及相应的背景知识，测试中可能遇到的风险等等，以上所有的内容结合起来就构成了测试计划的基本要素。而测试需求是测试计划的基础与重点。
就像软件的需求一样，测试需求根据不同的公司环境，不同的专业水平，不同的要求，详细程度也是不同的。但是，对于一个全新的项目或者产品，测试需求力求详细明确，以避免测试遗漏与误解。
为什么要做测试需求?
如果要成功的做一个测试项目，首先必须了解测试规模、复杂程度与可能存在的风险，这些都需要通过详细的测试需求来了解。所谓知己知彼，百战不殆。测试需求不明确，只会造成获取的信息不正确，无法对所测软件有一个清晰全面的认识，测试计划就毫无根据可言。活在自己世界里的人是可悲的，只凭感觉不做详细了解就下定论的项目是失败的。
测试需求越详细精准，表明对所测软件的了解越深，对所要进行的任务内容就越清晰，就更有把握保证测试的质量与进度。
如果把测试活动比作软件生命周期，测试需求就相当于软件的需求规格，测试策略相当于软件的架构设计，测试用例相当于软件的详细设计，测试执行相当于软件的编码过程。只是在测试过程中，我们把“软件”两个字全部替换成了“测试”。这样，我们就明白了整个测试活动的依据来源于测试需求。
测试需求的收集主要通过对测试依据进行分析整理，最后生成一个以测试的观点出发的checklist(检查表)，用来作为测试该软件的主要工作内容。检查表的检查要点包括需求的正确性、必要性、优先级、明确性、可测性、完整性、一致性、可修改性：
在整个信息收集过程中，务必确保软件的功能与特性被正确理解。因此，测试需求分析人员必须具备优秀的沟通能力与表达能力。
以上主要描述了测试需求相关理论和获得测试需求树的一般过程。为具体项目实施测试中提供了一套获取测试需求树的参考方案。实际的测试类型划分和测试需求树生成的形式或粒度，因项目而不同，需灵活应用。

⑩ 如何做需求分析

1:抓核心点，不是所有用户诉求都是需求
我们每做一个项目迭代或者新项目一定有目的，而需求分析阶段，需求采集渠道中的需求往往是零散的、无重点的、逻辑性不强的，所以我们需要从这些离散的需求点中要抓住核心，梳理实际使用场景去分析问题，所有的核心点一定是以最终目的为导向的，不是所有用户诉求都是需求。
以我的项目为例，由于历史原因，自配送人员关系没有进入OA系统，所以配送员工资结算数据只能做进配送系统，相当于是一个简单考勤记录，其实最早之前系统是有这个功能的，但是由于之前没有仔细整理需求，导致这个功能白做了，所以这次我接手几乎从做，我以为这个事情比较简单就让一个产品助理先去整理需求，当把原型图出出来时发现并不能解决结算工资的功能，只是一个简单的排班。
所以，当时我就跟那小兄弟说，你这东西只是完成了排班，然而排班的目的为了结算工资这还不能满足需求。所以我跟他强调，我们做这个需求的目的是为了考勤，诸如请假、值班、加班工时、轮休日加班等数据要能提供出来，他的第一版原型其实没有充分了解到我们为什么要做这个排班功能，所以在了解需求过程中没有抓住核心点，导致需求不明确。
2:制定规则、改善复杂流程
我的上一家企业做的是互联网电商，其实在我看来电商和O2O有很大的区别点就是电商在当下盛行的情况下已经变的很有规则了，首页、产品列表页、详情页、下单页等等，每个页面展示的信息也大相径庭，而O2O不一样，一方面是O2O差不多13年才兴起，到目前为止（15年）还没有一个标杆行业，另一方面是O2O与日常生活联系的太紧密，落地下来就是很复杂的业务流，这些是to C产品的规则化和流程化，而流程化的东西在to B产品上体现的尤为明显，to B产品最经典的例子就是公司后台系统。
不论是一个to C的产品还是to B的产品，我们都要考虑到用户使用场景，PM需要把自己当作用户，充分考虑各种情况下的用户思维才能设计一个满足用户需求的产品，这里并不是一味的去迎合用户，做互联网的都知道当一个业务不是规则化时很难用产品去满足用户，所以我们有必要制定规则，或者优化不完善、流程复杂的
规则。
下面说说制定规则，其实统一规则有利有弊，举个例子，滴滴打车的订单是抢的，uber打车的订单是系统自动分配的，滴滴那种做法能提高司机积极性、自主性，司机可以选择高金额的订单，但是这种做法也会影响用户体验，比如说万一以后不补贴了，我只是一个起步价，有些司机就不愿意接单，要等待很久；而uber打车制定了自动分配的规则，先分配目前离乘客最近的空闲司机，如果他不接再分配给下一个，这种做法能不能满足用户我不说，我只说这种规则简化了下单流程，司机和乘客只有两个选项，接还是不接，坐还是不坐，司机如果不接，但他并不知道下一单能等到什么时候，订单金额有多大？虽然司机间的积极性和自主性减少，但是对用户来说体验很好。
说完了制定规则，再说一下改善流程，我上面说了这种流程化精简在to B产品上尤为明显，很多人有个看法就是后台系统反正是自己人或者其他企业人员用的，完成功能就行，没必要做的这么便捷和细致，其实不然，优秀的PM在这方面总能善始善终，因为在他们眼里一点点的产品优化或者流程优化能为企业带来很多的效益，这个我有切身的体会。
之前做的多个项目，其中有两个就是我在做需求的时候发现业务部门在实际运营中思维定势或者每日重复做属于他的工作，但是他们并没有发现这样做其实效率很低，在没人观察流程有问题的时候，业务部门已经形成规范，但是这种规范并不是最优的，当PM做需求分析的时候需要细致观察他们部门或者个人的工作内容，想一想为什么这么样做，有没有其他方案能提高其工作效率。
在做数据统计需求的时候我发现业务部门某同事每天要先导出所有新用户电话、订单号、餐厅金额、订单金额等数据用于考察配送员满意度、用户满意度，然而她每天导出的数据其实有另外两个同事也需要用，只是使用目的不一样，但是他们都很死板，他们三个每天导出一份完整数据，然后筛选条件，组合成自己要的数据，这种工作其实很没必要，我们可以每天为他们部门发一份当日订单报表，标注新用户即可。
还有个例子是，财务在结算物流人员工资的时候很多计算公式是相互关联的，比如说A=B+C，D=A*E+B-C，然而他们就计算成D=(B+C)*E+B-C，暂且不说他们部门管理流程怎么样，但是PM在遇到这样业务流程的时候结合产品设计考虑是否可以精简流程，实现产品设计的初衷的同时也能简化流程。
3:离散需求整合
在和业务部门打交道的时候发现他们的思维逻辑性可能稍微差点，在PM了解需求的时候业务人员或者用户表述的没有前因后果，也就是没有逻辑性，这时如果PM不追问下去自己很容易被带到坑里面，合格的PM应该在这种情况下峰回路转，把问题再阐述一遍，如遇到稍微强势一点的PM，此时应该会指出刚才的表述有错误。
还有的业务部门人员在你去沟通的时候哗啦啦的说了一大推产品改进意见或者新需求想法，此时PM应该细心聆听，记录下需求点，千万不要给他们答复这个功能什么时候做、什么时候上线，因为系统永远是不完善的、需求却永远是数不尽的，而资源是有限的，你给的答复实现不了别人会有不好的看法，优秀的PM需要大局观，能够和团队一起评估需求优先级，规划产品生命周期，这才能推进产品迭代。
4:技术人员参与需求分析阶段
现在很多互联网公司基本上都是产品驱动，很难说技术驱动，因为产品团队可以知道用户想要什么，我在参与需求分析过程中事业部技术负责人喜欢跟着我一起去了解需求，这在我之前的工作组中没遇到过，现在做需求的时候他参与进来后我发现整个产品需求被乱了，阻碍了我需求分析进度，因为他总是以技术的角度考虑这样实现的难度，由于他是技术负责人，逻辑思维能力很强，每当听到这个数据没有需要新增一个入口去维护时他就站出来说为什么要这样做，然后劝说业务部门说这个数据提供不了，能不能先不做。
但是从产品角度上考虑，既然选择做这个项目那么就该从产品角度去设计好，等一整套产品方案出来之后再去精简功能是一个很好的方法，还有一些情况是当有一个比较好的idea产生时技术人员会首先考虑能不能实现、实现的复杂度，如果有一点困难或者技术可行方案不能当场给出时，这个功能就暂且搁置了，也许就会提出另一个不会错但是并不是最好的方案，所以技术人员参与需求分析阶段最容易把原本一个好的产品扼杀在摇篮之中。综上考虑，我的理解是技术人员在需求分析阶段暂且不要参与进来，等产品团队内部讨论之后技术团队参与审评，这样也许能达到事半功倍的作用。