1. 三种需求分析
1.1 目标需求分析
目标需求的分析，需求分析师要能从企业决策者、高级管理层的视角，能够理解他们的思考方式、战略构想、未来的期望。目标需求多是抽象的方式描述的，如理念、目的、策略等，目标需求是信息系统规划中顶层设计的指导。
1.2 业务需求分析
业务需求的分析，需求分析师要尽可能地掌握客户的业务知识（或借助业务专家的帮助），同时还要非常熟练地掌握业务的表达方式，因为需求分析师要告知业务分析师：这个业务需求对应的实际业务是什么、业务的构成、业务的逻辑。
1.3 功能需求分析
功能需求的分析，需求分析师要理清每个"功能需求"的内容、功能、规则，以及这个功能需求对应的实际业务处理活动是什么。
2. 需求分析1---现状构成图
现状构成图主要提供了业务需求和功能需求，由于现状构成图可能来源于客户或是需求分析师在调研现场的随手记录，图中的内容和表达可能不规范，因此要对现状构成图进行梳理，梳理主要是基于业务知识、业务经验，采用逻辑的、系统的手法进行。
2.1 资料梳理
图①为现状流程图，梳理为图②的过程如下：
- 节点1：有活动描述、有对应实体（申请单），仅按照规定调整了名称（名词+动词）。
- 节点2：①上没有实体，未来的系统不对应，因此去掉"供货商沟通"节点。
- 节点3：①上只有实体"合同书"，因此在②上增加对应的活动"合同签订"。
- 节点4：①上缺少实体，因此在②上增加对应的实体"验收单"。
2.2 "现状的流程"与"系统的流程"的区别
- 为什么要去掉没有实体的节点呢？
在系统外与"供货商沟通"的工作是存在的，但因为该活动没有附带着实体（没有需要处理的数据），就意味着在信息系统中没有这个节点对应的数据输入活动。因此，这个节点在信息系统中的流程上就是"虚"的，也就是无效的，因此要把它去除，以免给后续设计工作带来不必要的分析成本。
- 为什么流程图的节点不能是实体？
梳理后的刘尘土是按照信息化实现方式对现状构成图优化的结果。因此，业务流程图的流转必须要符合流程标准，即有"实体"就必须有产生它的活动，"实体"是该活动处理的结果。
最终流程图上留下来的是：即有活动又有对应的实体。
2.3 分析与转换
- 转换
对现状构成图的流程图进行梳理后，可以获得业务逻辑（流程）和功能需求（节点），其中功能需求包括输入功能（带有数据输入界面的功能）和打印功能（输入表单的功能）。
- 转换结果
转换形成两个资料，现状构成图一览和功能需求规格书。
3. 需求分析2---访谈记录
需求主要来源于访谈记录（包括问卷），这类需求是以文字形式记录的，需求分析的主要工作量也是集中在访谈记录，访谈记录一般包含三个需求分层，另外无法直接归类到分层需求中的，暂时归集到"待定需求"分类中。
3.1 分析与转换1---目标需求
目标需求不能直接给出对应的功能需求，因为目标需求是用目标、理念、思想、价值等抽象化的形式表达的，因此针对目标需求必须首先找到其对应的业务场景，也就是要先将目标需求转换到业务需求上，然后再提供对业务需求的理解，最后去寻找对应的功能需求。
- 目标需求理解
在理解了目标需求后，可以通过示意图（示意图不特别强调逻辑的准确性）来形象表达，例如"产业互联平台，与合作伙伴形成共生体"示意图如下：
- 目标需求转换
理解了目标需求的含义，然后找寻支持这些含义的业务场景，这些场景可以通过业务需求来表达，实现目标需求的落地。
例如"产业互联平台，与合作伙伴形成共生体"案例中，将要素用排比图（一维）排列出来，此图呈现出了结构化、有规律的形式，给出了要素之间的关系、相互作用，用业务场景表达了目标需求的含义，图例如下：
3.2 分析与转换2---业务需求
- 业务需求的表达
必须是用客户用语表达，业务需求不能是理念、概念层次的内容，业务需求的内容必须要能够用具体的业务场景来描述或是用图形来表达。
业务需求，是客户导入信息系统要解决的具体任务，业务需求是验证系统设计与开发成果的标准，客户验收的不是功能模块的多少，二是业务的需求是否被满足。
- 业务需求的说明
业务需求是什么内容、要解决什么业务；
采用什么方式或是流程，流程上有哪些节点；
业务处理要遵循哪些管理规则。
- 业务需求的转换
例如"企业管理信息系统"案例中，④梳理出实现流程上每个节点的协同工作需要的需求、业务、功能，⑤梳理出每个协作企业自身的需求、业务、功能，图例如下：
- 业务需求的梳理
参照实现过程的流程图，通过对业务内容、业务逻辑、处理方法的研究等，逐一地对上图中④和⑤的每一项进行功能需求的识别和抽提，确定在流程的每个节点上相关方所需要的功能，对各个相关方的需求、业务和功能进行梳理，梳理的结果如下图所示：
3.3 分析与转换3---功能需求
- 功能需求的分类
功能需求分为业务功能和系统功能。
业务功能，是直接用来处理客户业务的功能，如合同签订、计划编制等、企业基础数据维护等，每个业务功能对应着客户的具体功能。通常不加任何特殊说明时提到的功能就是"业务功能"，包括活动、字典、看板和表单。
系统功能，是只有使用信息系统才会出现的功能，间接地为业务功能提供支持，如登录、注册、权限、推送等。
- 功能需求的确认
确认是否为真实的功能需求可以通过业务逻辑和业务数据确认。
业务逻辑确认，从业务逻辑上推演，通过前后节点之间的业务关系，判断功能是否需要。
业务数据确认，可以通过检查从某个功能上输入的数据是否被引用来判断该功能是否需要。
- 转换结果
- 转换完成后，会形成：功能需求一览和功能需求规格书。
功能需求一览，将通过了确认的功能需求录入到功能需求一览中，它是与客户确认的全部功能需求的汇总表，也是后续设计、验收的依据。
功能需求规格书，将每个功能需求的详细内容记录到功能需求规格书（需求4件套）中。
3.4 分析与转换4---待定需求
- 待定需求的类型
在对收集到的需求资料进行分层时发现，存在着很多难以判断是否是需求的说明，从描述上看它们与标准的需求说明（目标、业务、功能）有很大的差异，它们表达方式分为以下两种类型：
类型1---难点痛点，正常说明现实工作中存在的难点、痛点。
类型2---吐槽抱怨，采用吐槽、抱怨的方式讲述工作中存在的问题。
- 待定需求的分析
首先，进行问题梳理，如下图所示：
再次，进行待定需求向功能需求转换，如下图所示：
4. 需求分析3---既存表单
功能需求与实体（表单）存在以下关系：
（1）1个业务功能必须对应1个实体。
（2）1个实体可能不止对应1个功能，例如既存表单在做功能设计时，可能需要有两个功能，即：活动功能--->用于输入数据，表单功能--->用于展示数据。