技术分析工程师英文（史爱武需求分析师）

来源于计算机大学生

需求分析师从事的是一个类似技术翻译的工作，是业务和技术、外部用户和内部工程师的桥梁。

对外，他能够与不懂技术的其他行业用户迅速沟通，了解用户的想法、要求和目的，整理用户原始需求的业务规则、业务范围、业务流程等。对内，他能基于用户的需求提出技术系统的描述和要求，输出为开发工程师等内部人员看得懂的文档（比如流程、方案、界面、UML图、需求规格说明书等），让内部的开发、测试、项目经理等人员理解用户想要的东西，然后在遵守项目流程要求的基础上实现满足用户需求的东西。

实际上，软件工程历史上的很长一段时间内，需求分析一直被认为是整个软件工程中最简单的一个步骤。近些年，越来越多的人意识到，需求分析在整个过程中是至关重要的——如果需求分析师没能正确地理解用户的需求，最终结果往往是差强人意的：最终产品可能达不到用户的要求，或者根本无法在规定的时间里完工。

岗位职责

需求分析师的工作就是分析用户的要求，是开发设计系统（产品、项目）的起点，其结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的完成，最终影响到实现的系统是否合理和实用。

需求分析师一般是由具有业务知识背景和技术背景的人员担任，具有相关行业技术产品开发经验的人员肯定是更好的。在不同的企业，这个角色的名称可能不一样，工作内容也各有侧重，有的企业叫做 BA（业务分析师），侧重业务分析；有的企业叫做SA（系统分析师），更侧重系统分析。真正的需求分析师的工作往往包括这两部分内容，既有业务分析，也有系统分析。

下面是一个需求分析师招聘信息的岗位职责描述。

岗位职责：

1、根据概要需求（客户及内部需求）编写详细需求规格说明书。

2、 系统规划，与产品人员进行前期调研和产品设计工作，编写调研报告和项目解决方案。

3、 参与系统功能验收工作及用户手册、产品功能培训资料的编写。

4、 负责客户需求调研及需求反馈的分析。

5、 配合测试人员编写测试计划、测试用例、测试报告等测试文档，编写产品用户手册，发现及跟踪问题缺陷等。

6、协助系统架构师、系统分析师对需求进行理解。

从岗位职责描述来看，需求分析师和前面章节介绍的产品经理（特别是初级产品经理）的职责有很多相同之处。实际上，在产品经理的产品规划和产品设计阶段，他们所做的工作基本和需求分析师是相同的，也可能，这些阶段本身就是需求分析师协助产品经理来完成的。

但是，需求分析师和产品经理这两个角色以及他们的岗位职责还是有很大不同的。需求分析师主要负责分析和细化用户的需求，并把用户需求用技术的语言“翻译”出来。产品经理则是负责产品的整个生命周期——从产品的定义、需求分析、开发进度跟踪、产品发布推广、运营、市场反馈收集、运营状况追踪等，简单来说，也就是一个产品在市场上从无到有，从有到热销甚至退出市场，整个过程都由产品经理来负责。

总体来说，需求分析师和产品经理这两个工作岗位的区别主要在于：需求分析师的职责范围只是产品经理的小部分，工作权限也比产品经理要小；产品经理在工作中一般要包括全部或部分需求分析师职能的，但是产品经理还有更多的事情要做，比如跟踪产品开发、执行产品更新迭代、产品推广战略及商业模式等等，也就是说，产品经理可以取代需求分析师，反之则不然；需求分析师偏重业务和技术，着眼于微观的需求细节，产品经理则偏重管理和整体把控，更着眼于宏观的产品生命周期。

所以，产品经理的工作内容链条比较长，需求分析师的工作内容可能和初级产品经理有较大重合。从职业发展路径来看，产品经理也是需求分析师的未来职业晋升方向之一。

具体来说，需求分析师主要面对的是用户的需求，其核心工作职责包括： 需求调研、需求分析、需求确认、需求变更。

一、需求调研

需求分析师的工作是从需求调研开始的，其目的是尽可能地收集到用户的原始需求，比如前期通过对用户的拜访、反复的需求研讨（不限于形式，可以是会议、电话、面谈）来调研需求。需求分析师完成背景调查和相关资料准备，再结合其他项目调研工作经验梳理出要明确的问题，带着这些问题去调研——这一点至关重要。需求调研前要做好准备工作，做足功课，准备工作越充足，调研效果越好；反之，提不出问题，就得不到结果。

常用的需求调研方法包括现场参观和当面访谈、电话访谈、在线聊天、线上或线下调查问卷等。一般来说，现场参观和当面访谈应该是最常用、最有效的需求调研方式。需求分析师参观用户工作场所、工作流程、设备等，通过与用户各层级人员及时交谈提问的方式来获取原始需求。

依项目类型的不同，需求调研要收集的内容会有些不同。下面以一个软件系统为例，软件系统的需求调研一般要尽可能地调研了解如下内容：

1、业务场景：充分了解系统有哪些业务场景；具体了解每个业务场景要解决的业务问题、业务工作方式等；

2、业务流程：每个业务场景的业务流程；每个业务流程有哪些步骤环节、路径、异常情况处理方式等；

3、用户：系统有哪些用户；每个业务环节有哪些用户；用户有什么权限等；

4、系统功能：系统要具备哪些功能；每个业务环节要实现哪些功能；每个业务环节的用户要进行哪些操作等；

5、数据：系统数据、用户数据等；每个功能、业务环节要操作哪些数据；数据从哪里来，到哪里去；数据产生的时间段、时间粒度是怎样；数据的类型和范围；数据接口等；

6、规则：系统规则、业务规则等；数据生成规则，指标计算规则，操作处理规则等规则类需求；

7、非功能需求：系统界面风格、版式、颜色的界面需求；开发语言、软件架构等特殊技术要求等；系统部署使用的硬件、操作系统、网络、中间件等环境需求；业务处理量对系统性能影响的性能需求；系统安全、数据隐私等的安全需求；

8、其他约束：如系统上线等时间进度约束；建设场地、大型设备等资源约束；法律法规、技术标准、社会文化等其他约束

需求调研完成之后，需求分析师要把调研内容进行统一整理，然后输出需求调研报告，一般包含调研对象、需求描述、业务流程、非功能性需求、需求优先级等内容的描述。需求调研报告也是后续需求规格说明书的主要内容来源。

二、需求分析

需求分析就是把需求调研收集的原始需求进行业务分析，理清业务模型，然后进行系统分析，确定系统需求，最终形成需求规格说明书。这一过程中需求分析师可能还要与客户沟通交流，不断重复之前的需求调研过程，不断充实和具体化需求内容。如果有必要，需求分析师还要为用户设计方案、制作产品原型，有利于用户更直观地理解和感受系统的真实需求。

业务分析就是需求分析师要对用户的业务情况进行调查分析，充分理解业务，在此基础上定义需要系统支持的业务需求。业务分析的目标是让需求分析师深刻理解业务，然后提出具有商业价值的业务需求。所以，需求分析师需要尽可能地建立业务模型，它是深入理解业务和描述业务分析结果的重要工具。简单的业务可以采用业务流程图来描述；复杂业务得依赖于包含业务目标、业务场景、业务流程、业务对象等内容的业务模型来表达。

系统分析的重点任务就是定义能够有效支持业务的系统需求，也就是从系统角度来理解和确定所开发系统的综合需求，并提出这些需求的实现条件以及应达到的标准。这些需求包括：功能需求(要做哪些功能)、性能需求(各项功能要达到什么指标)、环境需求(所需的服务器型号、操作系统、中间件、数据库等基础软件)、可靠性需求(灾备和冗余机制）、安全保密需求、资源使用需求(软件运行时所需的CPU、内存、网络带宽等)、软件成本与开发进度需求等。对于一般用户来说，他们没有能力提出清晰、完整的系统需求。所以，需求分析师在系统分析阶段要对系统需求进行完善的分析，合理的定义。

需求分析阶段的成果是需求规格说明书初稿，和产品经理章节谈到的产品需求文档PRD基本是一回事。需求分析师交付的一般叫需求规格说明书，产品经理交付的一般叫产品需求文档。实际上，他们可能用的就是同一个文档模板。

另外，基于需求分析的结果，需求分析师往往会制作一个用户易于理解的原型Demo,既便于用户直观理解系统的需求，也有助于需求分析师在后续的需求评审和确认中讲解系统的各项需求。

三、需求确认

需求分析过程完成需求规格说明书初稿后，这个需求说明书所描述的需求一定要经过双方（用户方和开发团队）确认，没有确认的需求不能算作正式的需求。需求确认一般是通过需求评审来完成，需求分析师可以分别与外部用户或者内部开发团队组织召开需求评审会议，也可以组织用户方和开发团队一起召开需求评审会。总之，这个评审和确认环节很重要，是用户方和开发团队就需求达成一致的过程。所以，这个需求评审和确认过程往往要重复好几次，评审、修改、确认，再评审、再修改、再确认……。需求评审和确认环节一般至少要重复2~3次，所以在做时间计划的时候一定要留出充足的时间。

如果用户方不积极确认需求，一味催促开发实施，需求分析师应该和用户方多沟通，让他们认识到，未经确认的需求，如果投入开发，会浪费双方的成本，而且可能会因为不必要的变更影响交付时间。开发团队对需求是否可实现的反馈更是需求确认的重要任务，不能实现或者实现成本超出预期的需求、 对功能的正确性、完整性和清晰性以及其它需求给予的评价都应该及时反馈给用户。需求规格说明书通过评审确认后才可以交付给开发团队进行开发,否则需求分析师还需要重新进行需求调研、需求分析等先导工作。

基于需求规格说明书初稿，反复评审、修改、确认后的需求就是最终的需求，即可发布为需求基线版本。确认后的需求规格说明书就可以交付给开发人员来按需求实现系统，也是测试人员、项目管理等人员的最重要技术文档。

四、需求变更

对确认后的需求，如果要发生变更，就需要做需求变更。需求变更的原因可能来自市场、管理、客户、软硬件工程环境和测试等方面，对于这些变更来说，如果不控制或者控制不好就会导致项目陷入混乱、不能按进度执行或软件质量低下等一系列的问题。

需求变更应该是需求分析师最头痛的事情。一旦要变更需求，也就意味着上述需求调研、需求分析和需求确认的流程又得再走一遍。所以，对于需求变更，需求分析师既不能一概拒绝用户的要求，也不能一味地迁就用户，实施需求变更之前必须做好管理和控制。

需求变更控制是需求管理的主要工作之一，需求分析师要能正确判断内在或外在原因导致的变更所带来的影响，并且调整开发过程以控制和适应这些变化。在管理和控制需求变更的时候，需求分析师一般要考虑：变更对已有的需求以及开发、测试成本的影响；变更应该划分优先级，有序处理；变更可以设置一个缓冲期，这样有助于让变更更稳定，避免反复变更。需求变更需要经过评审后才决定是否接受、拒绝或者延迟，最终确保项目开发范围可控。

在需求分析师的整个工作流程中，他们可能面对如下问题：用户缺乏技术知识，不能准确地表达自己的需求，所提出的需求往往不断地变化；需求人员缺乏用户的专业业务知识，不易理解用户的真正需求，甚至误解用户的需求；需求人员不清楚需求有哪些内容和层次，需求工作太被动，主要是等待用户提出需求；对需求缺乏系统的分析和长远的规划，造成需求变更出现的时候疲于奔命，等等。

解决这些需求问题的方法其实也就一条——需求分析师必须不断深入地与用户进行交流，才能逐步确定用户的实际需求，也就是需求调研、需求分析、需求确认这三个过程不断地重复。只有前期的工作做到位，后面的需求变更才可能是比较少，或者根本没有需求变更。

不过，从我十多年的项目经验来看，没有需求变更的项目好像也是屈指可数！

,