需求分析师的岗位是软件项目中不可缺少的岗位，它所做的工作是整个软件生命周期非常重要的环节，承担着由实际业务到业务信息化落地的桥梁工作。所以需求分析是一项十分细致且严谨的工作。

需求分析师的工作由需求调研、需求分析、系统设计、功能测试、用户培训组成，可以说除了在代码实现环节不需要需求人员参与（但代码实现的逻辑还是需要需求人员把关的），其他的环节都有需求人员的影子
。

需求调研
：目的是了解客户的实际业务。通过我之前需求调研的经验，我一般采用的是访谈法
；首先，找到甲方项目的牵头人，了解一些基本的情况，例如客户方的组织架构、系统使用部门和使用岗位；通过了解到上述的情况后，逐一对各部门的关键用户进行访谈；此时的访谈主要是讨论用户的实际业务流程是怎样的
，包括他们的业务审批流程是如何的
。访谈过程中尽量不要提及与软件相关的专业词汇
；如果用户有相应的业务报告、报表最好能提供一下
。需求调研完成后

，需要整理访谈记录与客户确认，目的在于记录的是否与实际情况有冲突
。

需求分析：基于需求调研阶段获取到的成果
，进入到分析环节，通过我做需求分析的经验和习惯
，我一般会把调研完成的内容
，通过Xmind用思维导图的方式将业务进行归类或分解
。最终形成一个个的实体，我对该实体的理解就是后期的功能模块。当然，Xmind仅能抽象出实体，并不能体现出业务流程
；如想更醒目的了解业务流程，那么需要借助Visio等工具绘制业务流程图。将抽象出的功能模块、业务流程整理完成后需要与客户方开需求讨论会
，目的是检验最终形成的功能模块是否合适，业务流程是否正确。

系统设计
：需求设计包含功能设计、数据库设计两个维度，功能设计是由需求人员完成；数据库设计可以由需求人员完成也可由开发人员完成（主要看每个公司的岗位要求）。

功能设计
：基于需求分析的结果可以进入到了功能设计阶段，该阶段需要产出页面原型

、需求规格说明书两个文件；页面原型
，我一般用Axure软件设计功能；这里要注意，设计之前要先考虑公司是否有UI设计岗位
，如有该岗位原型图绘制成线框图即可
，便于给UI人员创造设计空间
；如果没有UI人员
，那么需要需求人员将原型设计成高保真级别的，因为我们画的原型和真实页面一样

，这也是功能建设的一部分；在功能设计的过程中要时刻换位思考，站在业务人员的角度考虑功能设计的业务契合度；在设计某个要素时要参考用户线下使用的相关报表或报告，在细项层面尽量不缺不漏
。功能设计完成后形成需求说明书
，与客户一起进行需求评审。

数据库设计：数据库设计需要参考原型，提取功能中的实体设计成表结构和相应的字段信息。

需求评审
：功能和表结构设计完成

，并且也与客户进行了需求确认后，需要与项目组成员进行需求评审，参加评审有项目经理
、需求人员、研发人员、测试人员；目的在于将功能的业务需求和设计逻辑给开发和测试讲解。支持他们代码实现和测试用例编写。待评审完成后且无问题后可以形成基线版本
。

需求管理：主要对自己负责的需求类别和进度进行管理，并形成需求跟踪矩阵
，管理范围包含功能点名称
、功能描述、业务关键用户、功能优先级
、功能复杂度
、需求来源、研发计划等信息；

需求变更
：需求变更是软件项目建设过程中时有发生的事情，该问题与项目进度
、项目成本
、紧急程度三方面有关
。1、项目进度：客户提出需求变更后
，需求人员需要与项目组同事讨论该需求实现的难易程度
，如果消耗时间过长则会影响原计划完成时间，出现该情况需要与客户方讲明
；2、项目成本：出现了需求变更势必会影响到项目成本，需要与客户方讲明需要的工时。3、紧急程度
：如变更的需求属于非主业务流程内的且不紧急的需求变更可以放到后面做

，这样至少不影响合同范围内的工作进度
。

经验总结：

通过我的从业经验来讲，我将软件系统分为两种：第一种，业务流程类系统；第二种
，统计分析类系统
；

业务流程类系统：业务流程类系统的核心是“业务”，可能有些人会提出不同意见，没有单纯的业务流程类系统，几乎都是包含了统计分析功能的；我想说的是大部分的系统是“业务流程 统计”，仅用表格形式进行了数据呈现
，缺少了分析功能；当然，这对业务流程类系统系统来讲已经满足需要了
。业务流程功能是一线业务人员使用；统计分析功能是部门领导或公司领导进行查看业务数据时用到。

统计分析类系统：统计分析类系统的核心是“数据”，没有数据做支撑的系统是没有任何用处的
。所以要想做分析首先要确保数据的质量
。其次，统计分析类系统较为注重页面的可视化效果，他不同于业务流程类系统
，更多的是满足业务需求及可；他对视觉传达的要求较高，不同的分析采用不同的图形