主要作用是根据甲方的业务目标和需求，进行需求调研、需求分析等工作，将业务需求转化为具体的软件功能需求，并形成需求基准。需要特别说明的，需求包括功能需求及非功能需求两类。
需求分析阶段工作成果和质量是后续软件设计和开发的依据，也是后续项目系统评估和验收的重要依据。需求分析的内容极大的影响着软件开发的成本、技术、周期、质量及客户满意度，在整个软件项目的执行阶段占有非常重要的位置。
二、公司现状及行业特点
2.1.公司现状及团队特点：
公司业务模式是为银行、保险公司提供软件项目实施。采用的是项目经理责任制，因此对项目经理的定位和要求较高：
为了表述方便和清晰，项目核心团队成员仍旧分为项目经理、产品经理、技术组长三种角色去描述。在需求分析阶段职责如下：
各位小伙伴也可以根据各自公司的实际情况，对团队成员结构和岗位职责进行调整和裁剪。
2.2.行业特点
银行、保险行业的业务及需求有自己独特的行业特定，我们从时代特点、项目类型、业务复杂度、项目干系人等多个维度进行分析，从而有助于后续开展需求分析工作。
时代特点：目前银行、保险行业的软件项目处于数字化转型的大周期内，并且以传统以金融产品供给为中心的体系向以客户为中心的体系进行转型
项目类型：
①改造/优化类项目：基于现有系统进行升级和业务流程优化类；
②新建类项目：可细分为有明确业务方案落地类项目和大方向明确但无具体落地方案类项目；
业务复杂度：银行、保险公司由于其行业特点，具有业务流程长、业务复杂度高和涉及多部门、多岗位的特点。
2.3.需求分析阶段常见问题
参照团队以往项目经验和业界先进理念，我们把需求分析分为需求调研、需求分析、需求设计、需求评审四个大的阶段，总结了以往项目中遇到的常见问题。通过团队特点、行业（项目）特点、常见问题，就可以指导我们形成可落地的需求分析阶段工作内容及流程。
三、工作内容拆解
需求阶段工作，我们将工作内容拆解为纯项目事务类工作以及需求分析工作。
3.1.纯项目事务类工作
3.2.需求分析工作
根据业界实践经验和理论，结合公司外部顾问及各项目总监的项目经验，需求分析工作细分为四个子阶段：需求调研、需求分析、需求设计及最终的需求评审。
１.需求调研
利用各种需求调研方法，收集客户的需求，并将调研过程收集的资料进行汇总，为需求分析提供依据。
２.需求分析
基于需求调研资料，对客户的需求进行分层、分类、归类、梳理，最终确认系统需要实现的功能。
３.需求设计
根据需求分析的结果，结合项目的范围、进度、质量、成本等约束，形成最终的需求设计方案，形成详细的需求规格列表及需求规格说明书。
４.需求评审
根据需要进行内部及外部需求规格评审，在需求层面尽量消除项目各干系人分歧，并最终推进需求规格说明书签字，确定需求基线。
本文介绍的需求调研-需求分析-需求设计-需求评审阶段划分的方法，经过实践对于200-500万左右的软件项目相对比较适用。
若实施更大规模的软件项目，譬如保险核心业务系统或银行核心业务系统建设，则需要对各个阶段进行更加详细的划分。
大家运用一种方法或理论的时候，一定切记每种方法或理论都有自己的适用场景和边界，不能拿一个方法或理论适用所有的场景，需要做的是吸收其核心精华和思想。
四、工作流程及支撑工具
01
工作流程
需要说明的是，需求调研、需求分析、需求设计并不是完全的线性先后关系，它们是相互伴随、交叉进行的：
02
需求调研子阶段支撑工具及交付物
需求调研阶段主要目的是利用需求访谈、需求问卷、现状调研等手段和方法收集和记录客户的需求、期望、痛点和难点，从而为需求分析阶段提供的依据和材料。
项目经理需要从全局上进行把控，制定整体的调研路线图和计划。（需求调研有多种方法，本文仅介绍最通用的用户访谈方法）
用户访谈方法
１.调研准备阶段
①项目背景资料汇总
项目经理尽量收集以上资料，使得产品经理在详细调研开始前有一个整体的、全面的了解，从而提升专业性、增强客户信任感，提升沟通效率。
②调研内容准备
项目经理与产品经理紧密配合，根据项目的实际情况确定访谈对象、调研顺序及编写访谈提纲。
对于银行、保险类软件项目，一般甲方会指定1-2位具体业务负责人和岗位专家进行需求调研。项目经理进行必要的干系人分析与协调访谈计划，在这里不做赘述。
在进行正式访谈前，项目经理及产品经理共同ReView访谈提纲，确保访谈提纲的质量。
这里提供一个小技巧：
*一般来说访谈提纲中“确认”内容为主则说明准备较为充分；
*若“询问”内容为主则说明准备尚不充分，需要进一步准备；
当然对于系统规模较大、业务链路复杂、需求尚不明确的软件项目，第一次需求访谈“询问”的内容会比较多，需要项目经理及产品经理根据实际情况灵活掌握。
2.调研实施阶段（用户访谈）
需求调研有多种方法，本文仅介绍最通用的用户访谈方法。
在具体访谈过程中，项目经理、产品经理把控好访谈的节奏并做好访谈记录。
5W1H是需求访谈中较为通用的方法
项目经理、产品经理在进行访谈时要尽量挖掘出客户真正的业务需求，而不是业务老师有可能给出的“解决方案“级别的需求，要多问几个Why。
举个不完全恰当的例子，当一个人问你要一瓶可口可乐，可能他真正要解决的是口渴了的问题。
3.需求调研成果整理
在需求访谈结束后，要对访谈内容进行整理和汇总，最终形成需求访谈成果。
需求调研阶段的原则是对客户需求内容进行“记录”，形成的资料避免加入产品经理个人见解，整理的资料需要保持“原始性”。
一般调研成果经过梳理后，以现状构成（业务现状、业务逻辑、业务流程、IT现有系统及功能）、访谈记录以及发现的各种表单（纸质表单、电子表单）来呈现和存储。
流程名称
需求调研
参与角色
事业部经理：指导、监督
业务及技术顾问：必要时参与或指导
项目经理：总责
产品经理：主要执行
技术组长：辅助执行
思考工具/过程产物
项目事务类工作清单
需求调研提纲
需求调研方法：用户访谈、原型法、问卷法、文档调研等
里程碑
及交付物
需求访谈成果
03
需求分析子阶段支撑工具及交付物
需求分析子阶段是对收集到的客户原始需求进行拆解、归类、梳理，最终明确系统最终必须实现的功能需求。
需求分析子阶段分为2个大的工作内容：分析需求及确定需求。
1
分析需求
分析需求是通过对原始需求从不同层次、不同颗粒度及不同的维度进行拆分、归类、梳理，形成最终的功能需求清单列表及各个功能的具体业务规则的过程。
业务运营
业务节点
2
确定需求
需求确定工作主要完成两项内容：①形成最终需求功能清单列表，②对需求功能进行优先级排序并确认核心业务功能主线。
1.形成最终需求功能清单列表及具体内容：
对比
合同及SOW阶段需求功能清单
需求分析阶段功能清单
颗粒度
粗
细
梳理程度
简要的梳理
详细的规划、梳理
功能内容
仅包含功能的简要说明
包含业务功能详细说明：
业务流程
业务原型
业务数据
业务规则
管理规则
涉及用户
项目经理及产品经理以合同及SOW工作说明书范围为依据，以满足客户真实业务价值为灵魂，以项目工期、成本、技术为限制条件，最终确定需要实现的系统功能。
目前的银行、保险行业的数字化项目建设所处的阶段，客户需要软件供应商提供的是有价值、可真正支撑其业务运转的数字化能力，而不仅仅是一堆系统功能。此时对项目经理、产品经理的能力要求较高，若能够达到这个标准和要求，会非常有利于项目顺利开展：
2.需求优先级排序及确认核心业务主线
在项目启动阶段，已经根据SOW中的需求功能制定了整体的上线计划，经过需求分析子阶段后形成的最终需求功能列表有可能发生改变。
根据需要，项目经理与甲方项目及业务负责人进行沟通，进行相应的需求变更及项目计划优化调整。
需要特别注意的是在需求分析子阶段，项目经理及产品经理需要与涉及的上下游系统项目组保持充分沟通和交流，确保：
因上下游系统项目组对项目需求范围、需求场景等理解不一致导致的需求返工和技术架构及代码修改是最常见的问题，而且往往会产生极大不利影响，需要认真对待。
需求分析
事业部经理：指导、监督（必要时参与）
技术组长：辅助
需求分析、需求确认
需求功能清单列表及具体内容
核心业务流程及功能
04
需求设计子阶段支撑工具及交付物
根据实践经验，需求设计子阶段不仅仅是产品经理的工作，还需要技术组长及项目经理积极参与和讨论，以确保形成的需求设计符合技术条件、项目进度和成本的约束。对于新建项目或复杂系统的需求设计，更需要业务/技术架构师的参与和指导。
需求规格说明书一般由以下几个部分组成：概述、系统整体方案、系统功能模块、非功能需求等；
１.概述
概述介绍系统的背景、目标、范围、假设、约束等。
业务术语：是本系统涉及的业务术语定义及解释，若涉及的业务术语较多可以通过附件形式保存。
系统角色说明：本系统使用的角色说明。譬如保险公司客户、保险公司内勤人员、保险公司代理人等
2.系统整体方案
介绍系统的总体架构、业务流程、功能结构等。
根据需要，其一般包括如下内容：
3.系统功能模块
介绍系统各个功能模块的详细描述、输入输出、界面设计等。
一般包括如下内容：
4.数据设计
数据设计内容包括：
5.非功能需求
非功能性需求是指软件产品除了功能需求之外，为满足用户业务需求而必须具特性，通常体现在系统的“质量”方面。针对银行、保险行业的特点，需要重点以下几个方面的非功能需求：性能需求、安全性、可扩展性与可维护性、可靠性和易用性等。
安全要求：根据根据业务用户的类型、系统的运行环境、监管法规的要求，分析并提出系统的安全需求，如身份认证、数据加密、访问控制、日志审计
易用性需求：根据银行、保险行业的工作特点，设计合理的交互风格和页面布局，参考以下依据：
需求设计子阶段
各种设计图（框架图、流程图、分解图、用例图、原型图等）
工具：Axure、摹客、VISIO、UML
需求规格说明书
业务术语一览表
05
需求评审子阶段支撑工具及交付物
需求评审子阶段是整个需求分析的最后一个环节，其关键里程碑是召开需求评审会议对需求规格说明书进行确认和签字。
其作用是项目各个关键干系人（甲方业务发责人、项目负责人、周边上下游系统项目团队负责人等）对需求方案的范围和具体内容进行确认，消除重大错误和分歧，达成一致，形成需求基准。
需求评审子阶段可以分为内部评审和外部评审2个大的阶段。
１.内部评审
内部评审主要目的是在正式的外部评审之前，对需求分析的所有内容及最终的需求规格说明书做检查，尽量减少各种错误和歧义。其中每个参与人员的侧重点不同：
产品经理：需求规格的主要责任人，需对需求规格说明书进行全面的扫描，包括功能框架、业务流程、具体功能，尽可能修正错误及歧义。
2.外部评审
外部评审会一般分为三个阶段：评审准备、评审召开、评审后
①评审准备
充分的评审准备工作为需求评审顺利完成提供基础保证。
②评审阶段
项目经理组织召开需求评审会，此时项目经理/产品经理要能够把控全场节凑，聚焦核心业务流程，以及业务重点和难点。
③评审后
需求评审完毕，项目经理做好评审后续工作
需要说明的是，在实际的工作中，需要根据项目规模、项目重要程度等
根据需要进行多层次、分阶段的各种需求确认和评审工作。
需求评审工作的一般原则：
需求评审子阶段
产品经理：主要责任人
开发骨干:第一次正式进入项目
自检清单、内部评审、外部评审
需求规格说明书及签字确认
需求规格确认及正式邮件
需求分析阶段总结
需求分析的目的是收集和定义用户和客户对于软件系统的需求，包括业务需求、功能需求、非功能需求等。
需求分析的质量直接影响了软件系统的设计、开发、测试和发布的效果，也决定了软件系统是否能够满足用户和客户的期望和目标。
在整个过程中，项目经理需要从宏观及关键节点进行管理和支持，确保需求分析的顺利开展，为后续阶段的打好基础。