业务分析师培养指南
- 格式：doc
- 大小：45.50 KB
- 文档页数：6
业务分析师培养指南
By Ada_ThinkAbroad
2008.10
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
一、需求过程总结
1、需求分析的过程：
需求定义→需求捕获→需求分析→需求描述→需求验证需求管理过程贯穿到整个需求分析过程中。
2、需求管理：
需求基线与变更管理
需求跟踪操作要务
需求管理工具
需求工程：RUP Rational Unified Process
使用管理工具来管理各种各样的需求。
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
二、BA概述
1、BA的定位：
Business analyzer，顾名思义，是对业务进行分析的人员，其要职就是要把业务的原貌忠实地反映出来。
作为BA,首先他要懂业务（精通/熟悉/了解，至少是了解）；在此基础上，去了解客户的需求。
获得客户的需求包括三层含义：获得客户对系统的需求、按照信息系统的原理分析客户需求的合理性（包括就需求的讨价还价）、挖掘客户的需求。
2、BA的工作方式：
1)对于中型以上信息系统项目，最好有两个以上的BA,这是因为BA的工作的内容以
及核心是和客户、开发人员进行沟通、交流；而且牵涉的都是业务知识，需要传达和交流的东西最好杜绝只有一个人知道，多个人知道就会互相映证。
2)最好自始至终在同一个场地办公，当然若实在是由于场地所限，在项目的中后期可
以通过网络在异地办公，但要保持必要的沟通网络畅通。
3)从项目的开始到结束，BA都要持续跟踪。
按照软件开发的螺旋迭代模型，一个单
循环包括需求分析—概要设计--详细设计—用户测试—系统验收这几个阶段；BA的
大量工作都体现在第一个即“需求分析”阶段，后面几个过程BA都要随叫随到；
并且，在用户测试、系统验收阶段，也需要BA高密度地和客户进行沟通，以不断
地修正重大的需求中的疑难问题，另外若期间客户有重要的需求变更，BA也需要
记录并进行变更的合理性并形成文档。
另外，如果客户需要，BA需要对用户测试
做相关的指导。
3、BA的工作内容：
1)和客户沟通，捕获、分析、定义用户的需求，形成标准化需求文档；
2)对需求文档进行评估，和设计组、开发组一道从业务、技术角度评价需求的合理性；
其间BA要充分发挥主观能动性，结合自己以往的设计经验从可行性、经济性、全
面性分析需求文档的质量。
3)对项目组其他所有小组进行需求培训，培训内容包括业务基础知识、业务流程、业
务典型场景；全程都要负责跟需求有关的顾问、咨询工作，服务对象包括开发组、
测试组、美工组；
4)负责和客户的持续沟通，保证需求满足客户的需要并且需求是全面的、最新的、合
理的；若客户需求发生变更，则要分析变更的合理性（并且可从技术角度可以先进
行一部分思考），更新文档，保持文档内容的及时、权威、合理。
5)在用户测试阶段要适时地指导用户如何进行系统测试；(问题：用户测试阶段，测
试组需要参与进来吗？我认为应该要派人参与进来。
)
4、BA需具有的能力：
1)较充分的领域业务知识、技能，如保险领域中的保险基础知识、寿险基础流程知识；
当然对于特定的项目有实际的保险业务一线知识和技能则更好，比如对于“保险公
司出单业务系统”，如果BA有承保出单操作经验则最好。
2)有一定的软件工程领域知识，最好曾经做过程序员，经历过若干个IT开发项目实
战，有项目管理、系统设计、架构经验则更好；当然，不同复杂度的项目需要BA
所具有的技能不一样。
但最好BA有较系统的软件开发基础知识；
3)与客户进行有效沟通的能力；时刻保持清晰的头脑；(较好的语言组织、表达能力；
良好的问题分析与综合能力；良好的基础数学知识(数学知识越多越好))；
4)良好的谈判能力，能就领域问题的争执及时有效地提出可选解决方案；能够同时替
客户、开发人员着想，对具体问题具体分析，良好地平滑掉客户与开发人员之间在
系统实现与纯业务之间的隔阂。
5)良好的文档功底，包括良好的文字功底；包括构词造句行文章法、润色修改等技能；
6)良好的协调能力；
5、BA所用的工具：
分析工具：UML工具，如rational Rose、EA等等;
绘图工具：如viso、office等;
数据库工具：如PL/sql、powerdesigner,Erwin等;
项目管理工具：如project,p3等;
文档工具：如office,ultra edit等
6、系统需求分析方法：
1)归纳法：从系统功能所需要的业务原子属性出发，用树状图的形式把需求记录下来，并按各种业务分类方法，绘制不同分类下的树状图，以从各个视角来分析业务；
2)演绎法：从系统功能模块出发，用树状图或者网络图的形式，分析出功能及功能所对应的业务属性。
7、需求分析中遇到的典型问题：
有些业务问题虽然很简单，但在做用例的时候需要考虑到诸如数据库设计、程序性能、操作方便性来考虑。
8、和客户交流的规范和技巧：
8.1会议、事务安排规则概要
1) 每次和客户约定开会之前，要确定好会议的内容、与会人员、会议议程、会议目标、
会议材料。
2) 如果出了问题，则找问题的根源（从业务上、管理体制上），人员的建制以及各自
的职责与权威性应该明确、清楚。
3) 处理问题的方式：开发人员、需求人员、测试人员。
4) 每一次会议后需要对会议效果、质量进行总结。
并对下次的会议以及下一步的安排
作出说明。
5) 人员的安排、事情的安排、要注意轻重缓急。
8.2 用户方人员角色分析
“用户”方是一个广义的定义，按照人员归口管理方法，用户分为高层用户、经营层用户、操作层用户。
对操作层用户，我们要注意一类人员的微妙定位：。
9、文档管理方法的总结：
文档格式可以按照国标的方式进行，也可根据公司成功项目案例来进行，还可根据特性项目或者客户方的相关规定，灵活制定文档格式范本。
文档格式重要，但不是所有信息系统的关键之处。
任何一个信息系统，对于系统分析、需求分析，其要旨是将系统模拟运行、真实运行下的输入、输出，各种交互（包括人人、人机、机机）的场景、时空关系清晰地分析并表达出来，从而便于后续的模型概念设计和模型详细设计。
需求的输入是客户、业务上的原始需求；需求的输出是规范化的文档、流程图、用例、系统功能分解图、关系图、网状图等等。
需求分析的过程中，经常会和客户来回地就业务问题、业务描述、业务映射到系统所涉及到的诸多问题进行探访、反馈、会议确认等等。
每次交流中，除了热烈地讨论之外，需要把当时讨论的诸多问题的起因、讨论过程、阶段性或者最终解决方案忠实地记录下来，及时形成会议纪要。
会议之后，要及时对会议纪要进行分类整理、问题分派、问题再思考。
对于已经明确了解决方法的系统问题，可以以用例、流程图、网络图等形式反映到SRS中去。
需求分析的工作是一项来回反复、逐步验证、最终确认的过程。
其间需要分析人员不断地去挖掘客户的真实意图，通过相应得技术分析手段将客户的需求真实地记录、分析、归档，并形成初步的概念设计文档。
需求分析人员经常和客户、程序员、项目经理打交道，其思维方式应该要相当灵活，抓住事物的本质，按照系统开发的日程尽量将需求分析阶段提前结束，这样为后续设计、开发工作留出充分的时间余量。
三、保险行业业务分析师的知识体系结构
IT背景及经验
保险学系统知识及经验
数学知识
高等数学、线性代数、概率及统计、随机过程、组合数学
项目管理经验
投资理论
四、需求分析待提炼
继续要做的需求分析总结
针对需求分析的每个环节进行总结。
需求分析是一个迭代的过程；
用例的抽取也是一个迭代的过程，先是粗粒度的，然后是第一次精化、第二次精化，第n 次精化的过程。
业务规则
企业通过一组业务规则(Business Rules)来控制整体的运作，包括人员、流程、系统、概念的运作，皆受制于业务规则。
由此可见业务规则之重要。
如何提需求(站在甲方的立场看问题)：
作为公司业务管理层，如何根据公司发展的战略目标提出业务上具体的经营目标需求，这是一个综合问题。
需求不是一个人的需求，是大家的需求，是在组织中的全体成员达成对业务经营目标一致认可的基础上提出来的。
如何提需求，是一门科学，也是一门艺术。
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
其他
需求分析小组的人员分工问题：
要有统一的领导，明确的分工。
和客户联络的方式、机制要明确化、机制长效化。
