项目需求确认方法(需求分析方法)

1.需求分析有哪些方法

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

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

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

2.需求确认的方法

有效提问 为什么我们要提问？ 收集信息和发现需求时 开始和结束谈话 控制谈话方向时 制止别人滔滔不绝的谈话时 征求别人意见 不明白或不相信需要确认时 提出建议时 处理异议时 有效应用两种提问方式： 通 常， 我 们 会 用 开 放 式 问 题 开 头， 一 旦 谈 话 偏 离 你 的 主 题， 用 封 闭 性 问 题进 行 限 制， 如 果 发 现 对 方 有 些 紧 张， 再 改 用 开 放 式 问 题。

请注意：避免用“为什么”开始沟通！ 避免无用的问题： 引导性问题 多重问题  积极聆听的作用： 为了获得更多信息 帮助把谈话继续下去 处理不同的意见 有效发表自己的意见 保持沟通气氛的友好  反省自己是否做过： 当别人讲话时，你在想自己的事 听别人讲话时，不断比较与自己想法的不同点 打断别人的讲话 为讲演者结束他的讲演 当别人讲话时谈论其他的事情 忽略过程而只要结论 仅仅听那些自己想听的或希望听的事和内容 是否人的外观或他们的说话方式给你客观的听造成困难 是否很容易被其他的背景或声音分散注意力 。

3.简述采购需求数量确定的方法

1.采购预测——商品采购市场的预测，是在商品采购市场调查取得的资料的基础上，经过分析研究，并运用科学的方法来预算未来一定时期内商品市场供求及其变化趋势，从而为商品采购决策和制定商品采购计划提供科学的依据

2.商品采购市场预测的目的

1）为参与产品设计而进行采购市场预测

2）为参与市场竞争而进行采购市场预测

3）为商品采购决策和制定商品采购计划而进行采购市场预测

3.预测在采购中的作用P95（看）

4.独立需求物料的采购需求确定

1）独立需求物料与相关需求物料

相关需求是指某种物料的需求量与其他物料有直接的匹配关系，当其他某种物料的需求量确定以后，就可以通过这种相关关系把该种物料的需求量推算出来

独立需求是指某种物料的需求量是由外部市场决定的，与其他物料不存在直接的对应关系，表现出对这种库存需求的独立性

5.定量订货模型和定期订货模型

在定期订货系统中，每次订货数量都不尽相同，定购量的大小主要取决于各个时期的使用率，它一般比定量订货系统要求更多的安全库存

6.物料需求计划（MPR）

MPR既是一种管理理念，生产方式，也是一种方法技术，一个信息系统，即是一种库存控制方法，也是一种时间进度安排方法

7.分销需求计划（DRP）

8.物料采购订单容量的确定

1）分析采购项目供应资料

2）计算总体定单容量

3）计算承接定单容量

4）确定剩余定单容量

9.下单数量=生产需求量-计划入库量-现有库存量+安全库存量

下单时间=要求到货时间-认证周期-定单周期-缓冲时间

10.采购预算——就是一种用数量来表示的计划，是将企业未来一定时期内经营决策的目标通过有关数据系统的反映出来，使经营决策具体化，数量化的表现。

11.采购预算的主要作用

1）保障企业战略计划和作业计划的执行，确保企业组织目标一致

2）协调企业各部门之间的合作经营

3）在企业各部门之间合理安排有限的资源

4）对企业物流成本进行控制，监督

4.需求分析的步骤有哪些

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

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字）。

五、系统功能分析。

5.需求分析常用方法都有哪些,请举例说明

问卷调查法，是指设计方就用户需求中的一些个性化的、需要进一步明确的需求或问题，通过采用向用户问卷调查表的方式，达到彻底弄清项目需求的一种需求获取方法。

这种方法适合于设计方和建设方、使用方都清楚项目需求的情况。因为建设方和使用方都清楚项目的需求，需要双方进一步沟通的需求或问题就比较少，通过采用这种简单的问卷调查方法就能使问题得到较好的解决。

显然对于乐百氏集团这样规模庞大的公司，简单的问卷调查是不能够满足准确获得需求的需要的。会议讨论法，是指设计方和用户相关人员召开若干次需求讨论会议，达到彻底弄清项目需求的一种需求获取方法。

这种方法适合于设计方不清楚用户的详细业务需求，但使用方清楚项目需求的情况。因为使用方清楚项目的需求，他们能准确地表达出他们的需求，而设计方有专业的需求，而我们有专业的软件开发经验，经过回忆讨论交流之后，能够对用户的需求进行准确描述和把握。

这个方法对于准确的获得乐百氏公司的需求是一种不错的选择。在本案例中系统的设计人员也是这么做的，他们通过和乐百氏项目组经理的讨论，很快了解了乐百氏的运作过程的数据。

界面原型法，是指设计方根据自己所了解的用户需求，描画出应用系统的功能界面后与用户进行交流和沟通，通过“界面原型”这一载体，达到双方逐步明确项目需求的一种需求获取的方法。这种方法比较适合于设计方和用户都不是非常清楚项目需求、只是大概了解用户需求的情况。

因为设计方和用户方都不能非常准确的描述出客户的需求，因此此时就更需要借助于一定的“载体”来加快对需求的挖掘和双方对需求理解。

6.我们应当怎样做需求确认：快速原型法

常常听到许多朋友跟我埋怨，需求分析之难，就在于用户自身就常常弄不清楚自己的需求。起初在需求确认的时候说得好好的，一到软件上线的时候就不是那么回事了，这可没法整。但我们只要坐下来仔细分析就会发现，在需求分析的时候我们跟用户是在空对空地讨论问题。用户不是专业人士，他也搞不清楚软件到底会做成啥样，所以你跟他确认的时候他就点头了。但是，用户不是傻子，当你软件上线时，他拿到了实物了，知道软件做成啥样了，一旦不满意他就开始提变更了。所以，需求分析的症结就在与这个实物。

既然症结在此，毫无疑问，我们就应当在需求分析阶段拿出实物，用实物与用户确认需求，这就是快速原型法的基本思想。快速原型法，简称原型法（Prototyping），是20世纪80年代提出的一种从设计思想、工具、手段都全新的系统开发方法。它摒弃了那种一步步周密细致地调查分析，然后逐步整理出文字档案，设计开发，最后才能让用户看到软件结果的繁琐作法。当我们捕获了一批业务需求以后，就立即使用快速可视化工具开发出一个原型，交给用户去试用、补充和修改。再提出一些新的需求以后，再开发一版新的原型。原型法的关键就是这个快速开发。不用考虑性能、美观、可靠，原型的目的就是模拟客户的需求，与客户进行确认的。整个需求分析的过程就是“捕获需求->原型开发->确认需求->再捕获需求”的过程。

原型开发的快速与模拟到什么程度，是一对矛盾，我们要去把握。要快速开发，必然不可能和最终交付的软件系统一模一样，许多复杂问题被简化，非关键性流程被忽略，这就是所谓的模拟。因此，模拟到什么程度是关键，既能说明问题，又不耽误时间。根据我的经验，一般能拿出界面，并可以走通关键性流程就可以了。一些快速开发平台为快速原型法提供了可能。

当用户拿到原型可以自己操作时，需求研讨的气氛立即变得不太一样了。当用户享受原型给他们带来体验的快感时，需求被源源不断地被提出来。这时候的需求，就不再是枯燥无味的文字游戏，而是生动形象的图形界面。日后，如果项目采用迭代开发，让用户看着软件一点儿一点儿地成长，这又是多么美妙的体验啊。与此同时，你与用户的信任也在一步一步建立起来，软件风险在降低，项目将朝着正确方向前进。

快速原型法是美妙的，它给你与用户带来了从未有过的体验。但美妙的同时，也会带来一些的尴尬，不必要的误会，我们一定要注意。最常见的误会就是让用户将原型误以为最终交付的系统。开发一个系统需要持续数月，但你倒好，几天就搞定了，为什么还要在这个系统上投入大量资金呢？如果对方领导开始有这样的想法时，双方就开发费用进行的谈判就有一些不妙了。所以在给用户看到原型前，一定要跟用户解释清楚。

既然是原型，必要的校验、非正常操作的处理通通都被忽略。因此，当演示原型出错时，用户你可千万不要较真哟！这丑话可得说在前头，否则用户跟你较起真来，你在用户心目中的形象可就要大打折扣了。

我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：用例说明我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：子用例与扩展用例我们应当怎样做需求分析：行动图和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：需求列表我们应当怎样做需求确认：一个需求列表的实例我们应当怎样做需求确认：需求规格说明书我们应当怎样做需求确认：评审与签字确认会（续）

7.我们应当怎样做需求确认：评审与签字确认会

时间过得真快，经过一系列需求研讨、需求分析和整理确认，我们整理出了需求列表，编写出了需求规格说明书，一切似乎该到结束需求分析阶段的时候了。但是，敏捷大师的一句话让我们彻底心凉到了骨头里。敏捷大师说了，我们不可能在需求分析阶段完成所有的需求分析工作，它将延续到设计、开发，甚至测试阶段。

一直以来，我对这句话非常困惑。既然需求分析阶段不能完成所有的需求分析工作，那么完成多少才算结束呢？80%?60%？或者更少？大师没有给出一个标准。大师就是大师，生活在太空里的，我们慢慢理解吧。经过多年的实践，我慢慢理解了。我们说这种需求分析工作不可能完全完成，或者说日后用户的需求会变，其实并不是毫无规律可循的。通常，用户对需求的变更只发生在某些固定的范围内，弄清楚了这些范围，我们的问题就迎刃而解了。

1. 整体需求不变，具体细节变化。我们说需求是分层次的，整体框架、功能模块、每个操作的细节。如果用户变更到了将整个框架都推翻了，这个项目就别做了。所以整体框架是必须在需求分析阶段完成的，是日后不可能改变的。功能模块可能要变，但通常是某个部分在变，而更多的是那些具体操作的细节在变。

2. 界面风格与操作易用性是最容易发生变更的。我们说用户看到软件以后不满意，其实主要是对界面风格与操作性不满意，而不是软件功能。界面不够美观，操作不方便，不符合用户的操作习惯，都是造成用户不满意的地方。

3. 增加其它功能。软件是对现实的模拟，而现实也是复杂多变的。我们与用户在进行业务流程分析时，也许一些流程没有考虑到，或者还有特殊情况需要处理。这些是客户要求增加功能的主要动因。

OK，万事俱备只欠东风，当所有工作都完备以后，我们的需求分析工作开始进入最后收尾的阶段。我们说，需求分析阶段的产出物是需求列表与需求规格说明书，而最终结束的里程碑无疑就是需求评审会了，或者说与用户的签字确认会。

需求评审会的主要目的就是确认需求，以便以此开始我们的设计开发工作。从理论上说，需求评审会应当由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理，还有公司相关领导参加。但实际上，让如此多不同角色的人聚集在一起开会是不现实的。因此，我们可以将需求评审会分为内部评审会与外部评审会两部分来开比较现实。

处理外部问题，必先要从内部统一思想。先召开一个内部评审会，听听系统架构师、设计人员、测试人员、QA经理对需求分析工作的意见，然后由领导讲讲话，布置一下后面的工作，是十分有必要的。按照我的经验，系统架构师这时的作用相当重要，他应当仔细阅读需求，仔细思考技术是否可行，以及预测该系统是否能够达到用户方领导对该项目制订的目标。如果答案是否定，立即进行调整。

最后就是与用户的外部需求评审会了。外部需求评审会，也可称为签字确认会议，就是与用户就需求规格说明书进行评审，最后签字确认。用户签过字的东西，不可能完全抑制住用户的变更，但至少从很大程度上抑制住了用户的大改。然而，在召开外部需求评审会之前，我们建议大家就需求规格说明书，先与各个单位或部门的用户代表讨论并确定下来，避免在最终的签字确认会上出现分歧，影响工作进度。毕竟大家都不容易，工作一大堆，聚在一起不容易。

经过数月的分析讨论，最终在一片和谐的气氛中，双方领导在需求规格说明书上签字，项目开始进入一个新的轮回。在这个轮回中，是焦头烂额、不胜其苦，还是如履薄冰、最终顺利交付，是与许多因素有关的。但我想说，一份高质量的需求分析必定起到决定性的作用，必定为日后的软件开发扫清了许多许多的地雷。

我们应当怎样做需求分析我们应当怎样做需求调研：初识我们应当怎样做需求调研：拜访我们应当怎样做需求调研：研讨会我们应当怎样做需求调研：需求研讨我们应当怎样做需求调研：迭代我们应当怎样做需求调研：需求捕获（上）我们应当怎样做需求调研：需求捕获（下）我们应当怎样做需求分析：功能角色分析与用例图我们应当怎样做需求分析：业务流程分析（上）我们应当怎样做需求分析：业务流程分析（下）我们应当怎样做需求分析：用例说明我们应当怎样做需求分析：查询报表分析我们应当怎样做需求分析：子用例与扩展用例我们应当怎样做需求分析：行动图和状态图我们应当怎样做需求分析：业务领域分析我们应当怎样做需求分析：原文分析法我们应当怎样做需求分析：领域驱动设计我们应当怎样做需求分析：非功能需求我们应当怎样做需求确认：需求列表我们应当怎样做需求确认：一个需求列表的实例我们应当怎样做需求确认：快速原型法我们应当怎样做需求确认：需求规格说明书（全文终）

8.确定信息需求的三个步骤

收集需求，分析需求的重要性，确定需求。

1、需求优先级的定义应根据当时的环境和实际情况，是否有足够的理论支持和数据支持，满足需求后的分析结果是否清晰等。当定义一个需求是否被确定为一个明确的需求时，这些都被考虑在内。

2、有四个要求优先：重要和紧急；重要和不紧急；紧急和不重要；不紧急和不重要。这四种情况也是我们处理需求优先的原则，即重要性+紧迫性。

3、还应考虑需求的风险与价值之间的关系。高价值-高风险的功能需求应优先考虑，即优先考虑获得高价值回报，而早期处理可以有效地消除重大风险。

4、对于高值低风险的功能需求，所提供的价值是等价的，但由于风险较低，可以以后进行。

5、对于低价值低风险的功能需求，应该排在第三位，放弃它们对产品总价值的影响很小，而且风险也很低。

6、对于低值高风险的功能需求，显然最好尽量避免开发或推迟工作。

扩展资料：

信息需求的内容构成

1、信息要求，包括信息内容和形式的要求。信息的内容反映了信息所属的学科，如“生物信息”、“经济信息”、“环境保护信息”；信息的形式多种多样，如“知识信息”或“信息信息”、政策信息、市场信息或“产品信息”。

2、对信息源的要求，包括信息源的范围和载体形式。用户对这些方面有不同的要求。

参考资料来源：

百度百科-信息需求