一个业务分析师被派到一个项目中，面对纷繁复杂的业务，该从何处入手呢？
我试着从这几个角度来剖析，
###准备工作-人员分析：
干系人的背景，在公司呆了几年，对业务的熟悉程度，对系统的熟悉程度
###准备工作—项目分析
项目目标、项目当前状态、项目类型
项目大小、项目边界、项目风险、项目复杂度
项目组织架构（人员）
###准备工作—需求分析方法论、所用技术和交付物
所用技术和交付物就不细讲了。重点说需求分析方法论。
在准备工作中确认需求分析方法论，是指选择几种在本项目中会应用的技术。这样做有个好处，避免同一项目中出现不同的交付物形式，给沟通增添阻碍。
抛砖引玉，我讲一下我在实际工作中总计出的一套方法论：
1> 首先，和用户沟通时，视情况确认是否选择用户故事来记录需求。
2> 其次，将收集到的需求归类，是业务需求，功能需求，非功能需求还是技术需求？
3>然后，使用一种非常强大实用的方法，即核心需求组件分析。将一个需求抽象拆解为 数据、过程、外部主体、业务规则（核心需求组件的构成）。
比如有这样一个需求，采购代表可以对供应商进行评审。
数据——各项评分。业务规则——评审规则。角色——采购、供应商。过程——采购对供应商进行评分。
听上去有点复杂是不是？其实并不复杂，只要经常练习，就会成为本能。这个技术能帮你在千头万绪中快速理顺需求，是业务分析师必备技能之一。
###4> 选择一种或几种需求分析技术进行需求分析。
常见的需求分析技术有：
流程图、原型、用例描述、用例图、用户故事（3C原则）、 词汇表、工作流图（流程图）、实体关系图ERD、分解图。每种分析技术无好坏之分，只需看是否适合当前场景。
我曾经写过一篇日志，详细论述了各分析技术的前世今生，包括它们的适用场景、通用的格式／组件、推荐使用的工具/方法、使用频率、优缺点等等。
想了解更多，可以阅读这篇日记，https://www.douban.com/note/695856562/
#列出业务分析师工作计划和任务清单
根据以上的准备工作，就可以比较容易地列出工作计划和任务清单了。
所以，我们把以上内容整合起来，就得出如下图中的需求分析方法论了：
