1. 什么是Business Analysis (BA)?
商业分析师这个工作最早产生于90年代，是组织机构为了对内部的线下各部门的运营流程衔接以及线上的计算机系统进行整合（因为最容易出现问题的地方往往是各个部门衔接的地方）使之对公司产生好的经济效益。
提主没有特别说明这个需求分析师是针对甲方还是乙方的，这两个地方侧重的方面均有不同，那么我就分开来说吧，两个位置我都做过。
对于甲方的商业分析师来说，你的分析一般需要涵盖自始至终的流程，包含手动和自动任务， 产出是BRD (Business Requirement Doc) 而最终的目的是每部分都可以进行有效的测量，包含生产的产品或服务，方便项目结束以后对每一部分进行追踪，比如从客户登陆网页购买产品开始，order number传给公司后台，包装部门线下进行包装配送，更新配送信息到系统，会计部门准备发票，等等。一般来说系统上线项目交接给运营部门会对该项目进行营利率追踪，普遍为5-10年，然后在追踪过程中，会对线上线下的流程进行优化，也就是我们说的项目之后的phase 2， phase 3 等等。
而甲方的项目往往会拆分成很多的小项目，分配给不同的服务供应商（一般是IT公司）他们所要提供的一般是这个项目的一部分IT系统的研发，比如CRM系统交给乙方1来做，会计系统交给乙方2来做，等等，最后和线下的流程一起交付给甲方的运营部门，那么对于每个乙方项目也会有商业分析师(BA) 偏IT系统技能的，而产出是根据BRD 产出的FRD (Functional Requirement Doc)和TD (Technical Design Doc).
对于甲方的商业分析师，一般用来作商业分析都会会采用Business Process Diagram进说明，这样可以使各个部门以及所对应的工作内容清晰化，并且能够找到流程上的瓶颈，低效率的部门，链接不畅等问题，说明现有流程(As is)，以及将来流程(To be), 这里面涉及到 High level的Business Requirements, 和干系人需求（Stakeholder requirements）以及Low level的解决需求(Solution Requirements) 这个Topic 很大就不展开讲了。
2. 需求记录（注意这里面首先是要记录需求，而不是排序或是辨别伪需求）
根据我的经验一般项目开始作为一个商业分析师，第一阶段首先跟项目发起人沟通，首先项目发起人对自己所要的一定是非常清楚的，但是很可能他要的idea 的范围很大，大到即使他自己也不知道有多大。不要紧，这里需要弄清楚的是项目干系人都有谁，所涉及到的整个流程都有哪些部门，负责人都有谁。并且和项目发起人的沟通过程中我们会产生很多问题，将这些问题写下来，做一个需求Burn down chart, 第一列写上出现的问题，第二列写谁提出的问题，第三列写提出问题的日期，第四列写出期望谁来回答这个问题，第五列记录得到回答的时间，第六列记录答案。
第二阶段就是开很多的work shop和约谈这些项目干系人，这时候当我们约谈越来越多的人时候Burn down chart里面的问题也会增多，一些问题将会被解决，一些问题会出现，我们都将这些需求记录并更新最新的答案。
3.辨别伪需求
第二阶段约谈项目干系人的时候我们可同时进行需求的鉴别。
主要有4个部分：
3.1 这个需求是否是真正的需求？
很多时候项目干系人给出的问题或者需求其实已经给了我们解决问题的方法，比如Digital的经理说，我们需要一个网上博客，这就已经给了你解决方案，但是这并不足够，你的分析是为什么需要博客账号？解决了什么。分析之后会发现因为我们没有博客，而且没有频繁更新，导致我们在网络搜索排名下降，网络无法导流到我们公司的产品主页。Root Cause 是流量导入，那么我分析可以给出很多导流的方案，比如微信，微博，百度购买关键字等。
如果决定了使用博客，那么我们需要分析的是，是我们自主开发博客，还是购买现成的模板，或是直接找公关公司替我们维护等等，我就不展开说了。
3.2 干系人提出的问题是症状还是病根？
比如一个人说他腰疼，那么如果我是医生给他去疼片，吃过之后他感觉不到腰疼了，那我们是在处理他的症状而不是病根，当药效停止之后他肯定还会腰疼的，那么我们需要提供的解决方案是多运动，或者提议作腰部手术，将病根解决，这才是真正的需求。
3.3 如果病根解决之后是否其他的需求也会一并解决？
对照burn down chart 进行需求归类，总结 Root cause, 例如可以将如腰疼导致的腿脚酸软一并解决。
3.4很多情况下在解决root cause 的时候会产生新需求，我们需要再按照3.1到3.3的流程解决一遍。
4 项目范围的界定以及假定。
经过上面的流程我们应该得到大部分的答案了，对于没有解答的问题我们需要进行进一步的分析。
4.1不在项目范围内
如果一个问题即使项目发起人都无法回答，那么大部分是因为这个需求不在项目范围内，这时候我们需要跟项目发起者和关系人声明这一点，并且明确写在商业需求分析文档内，
4.2根据自己的分析理解写出假定的分析
记住将你的假定分析以邮件文本形式发给所有人，告知因为在规定时间内我们无法得到答案，所以我们进行如下假定XYZ.
4.3 将总结好的需求文档给大家审阅，进行MOSCOW分析，哪些功能是Must have, Should have, Could have, Won't have, 并在会上通过。
最简单的需求文档的格式一般包含以下几部分。
a. 交代背景/ 项目的发起原因/ 解决什么样的问题/ 达到什么样的 goal
b. 交代项目大概涉及到什么功能/ 牵扯哪些部门
c. 项目的假设/ 依附关系/ 项目风险/ 声明非本文档内所提及的需求之外的需求皆不在项目范围内。
d. 具体的项目需求/ 流程 等*（主要部分）
e. 非功能性需求
f. 系统需求及权限配置
g. 项目发起人，和关系人对该文档的批准邮件
h. 附录
5.需求表总结。
对于一个高级的商业分析师，可以根据burn down chart来做出很多数据透视表，比如根据问题提出的时间和得到答案的时间大概算出该问题在回答者心目中的重要性，以及在escalation的情况下以此做为你的依据；还有真实需求和伪需求的占比，得出大家对项目的理解程度；最后如果你离职了，也可以把这个表给新人，让他迅速投入到工作中去。
===============================
文章转自知乎，下面为作者介绍
赵国 金融方向企业管理咨询
微信号：红色共产
电邮：crossrnbw@163.com