做需求分析是有章法可循，好的方法论能够帮助自己在讲解需求的时候，能够有效的表达。
为什么写这个，是因为有一次要去和开发讲解需求的时候，我很慌乱，虽然讲过很多次，但这次莫名的慌乱。我想有准备、有章法的把这次需求讲好，而之前的讲解让我一时想不到需求讲解的方法论是什么。
现在说我总结的方法论，每次讲解需求的时候，做好这些，心里不会慌乱。
先清楚，我们表达需求的目标是什么？
（1）需求清晰，能达到多方认可
把与客户沟通确认的需求通过口头表达给开发、测试，开发和测试可以从他们的角度对需求提出疑问，最终使得需求越来越清晰、准确。
对于需求人员，你表达的需求能让别人理解并认可，就很有成就感了。
（2）一次通过需求评审，不会被打回
一份开发和测试很多问题的需求，会通不过评审，被打回，被打回说明自己需求做的不够清楚，还需和客户沟通。
一次通过需求评审，既说明自己需求做的可以，也可以节省大家的时间成本。
（3）提高自己的表达能力
每做一件事情就能提高自己的能力，是不是很开心？
明确自己表达需求的目的后，再来看看要如何向开发、测试或其他人表达需求。
知道我们的目标后，看看如何有效的表达需求？
对于一份以及文档化的需求，需要和开发测试讲解，在讲解前需要做一些准备，才能在需求评审的时候，少一些问题，少一些刁难。
写需求说明书的时候就把需求矩阵建立好，想清楚为什么要做这个需求？也就是业务场景是什么。80%的开发都会想知道做这个功能的原因是什么。
先和需求同事、开发同事、测试同事沟通部分难点需求，事先沟通，看看他们会提什么问题，反正是台下的，也不会尴尬。
需求试讲，自己先讲一篇，就像演讲一样，并假设自己是开发人员会问什么问题。
在打开需求文档讲需求的时候，先讲总的，再细讲分的，最后总结，就像写文章一样的结构：总-分-总。
有些开发只关心自己要开发的东西，对于一些他认为无关的客户背景、部门业务没有那么关注，会让你跳过总体介绍，然后打乱你的节奏。
但我想说！你是主讲人，你有权把控自己的节奏，不要被牵着鼻子走，除非是时间特别赶的情况。
2.1 介绍客户、用户部门、用户数量、业务、功能清单、开发功能需求等等。
上周去了上海电气金融集团做需求调研，客户的背景是为了应对监管以及自身子公司管理，要求上我们这个系统，系统用户是上海电气金融集团的两个子公司，分别是A和B，主要是给两个子公司的业务部和风险管理部使用，信息技术部也会用，用户数量约有二十多个，客户经理有XXX个，客户助理有XXX个。
主要的业务是债券投资业务、融资租赁业务，下面是功能清单，包含XXX功能模块，分别是XXX……
2.2 分解功能，介绍功能要做什么？为什么做？注意事项？难点？异常条件？
这是财报导入的时候，需要对财报的勾稽关系进行校验，为什么不在评级的时候去校验，而是在财报导入的时候做校验，原因是客户经理经常出差，比如：去新疆做尽职调查，从客户那边收集财报后，他们录入到系统，如果导入的时候就发现财报有问题，他们在现场能让客户重新提供财报。
2.3 在讲解的时候，语言要简明、准确、完整。
简明就是直接了当把开发需要做什么讲清楚，就跟写需求一样，看下面两个例子：
例子1：客户会做一些研究，推送过来的舆情消息要写下自己的点评，以便以后他人可以查看。
例子2：在XXX模块XXX菜单，增加一个点评按钮，客户可以发表点评意见，其他人可以查看。
直接告诉开发他需要在哪做什么事情，不要让他再转一道弯思考。
准确，表述要准确，用词要讲究，比如债券和债项不要弄混，身份证号码和证件号码说准确。
完整，除了正常的用户场景，异常的场景也要考虑到。
2.4 在表达需求的时候，可以用一些比喻
这个稍微高阶了，用一些形象化的比喻能很生动的把需求说清，同时也能让需求评审氛围轻松。
记得《大江大河》有一幕是雷东宝在解释联产承包责任制的时候，就用了一个比喻。
你把板凳分给别人，但板凳还是你自己的。
一句话解释了所有权的问题。
不是讲完需求就结束了，总结每次讲解的效果，不断提高自己表达需求能力。
记录开发和测试问的问题，下次做同样需求的时候，可以反过来问客户。
以上是需求表达的方法。
再来说说，要如何提高自己的需求表达能力？
多听：找一位需求讲解不错的同事，学习他需求讲解的方法、措辞、如何回答开发的问题。
多说：每次说都是有计划、有条理，有准备，不要乱说，想到什么就说什么，这样讲很多次需求都不会有提高。
多读：读一下好书，培养阅读的习惯，学习语言表达方式和技巧
多写：写作可以把自己的思维经过加工后呈现出来，培养自己逻辑思维能力。
做需求分析是有章法可循，虽然有人会说“方法是思维的底层”，对于像我这种不聪明的人来说，我希望有一些方法能帮到我工作，等慢慢成长后，自然会去培养思辨的能力。
