我在这里谈需求分析，颇有点班门弄斧，但是如果能帮助自己，帮助大家少走弯路、少赔钱，就一起商讨一下怎么在短短的需求分析阶段，把咨询和IT需求分析一起做完。

首先，从拿到RFP开始，最好找一个行业专家，请他来讲讲这类企业的业务流程都是怎么样的，一般这样的系统都干些什么，系统开发是哪些业务是比较难实现的，最近行业上有没有新的增值业务或者新需求。

其次，对RFP大卸八块吧，该重视的重视，该鄙视的鄙视，该记得的归纳起来，该忘记的别记住。

1）识别定性需求。问客户：“你做这个是为了什么？”

归纳出决策层、经理层、操作层的目标。一般会出现在RFP 的最前端，用“目标”、“现状”等字眼。常常被我们忽略，因为一般这些目的都是用一些口号性的语言描述。这些就是该重视的，后面的每个具体功能讨论时，都要常常把这些东西拿出来问一问。因为这就是最后老总拿来考核你项目的标准。（属于决策层的需求）

2）整理定性需求和具体实现方法的对应关系。

一般，通过RFP分析，可以得出三种内容：

a、某一个定性需求，它通过一系列的功能点+流程来实现。某一个定性需求，看似没有具体的功能点对应，其实隐藏大多数功能的实现要求上（性能、操作便利性）

--对于这类情况，注意的是该实现方法能达到需求的目的吗，如何判断他达到了目的呢，该实现方法可行吗，是否考虑了80%的业务Scenario。

b、某一个定性需求，根本没有对应的实现手段。

--对于这类情况，一定要勇敢的提出。定性需求没有满足，会成为后期CCR 的源头。但是要时刻注意项目成本和范围的变动，客户可能因为成本最终取消该需求。

c、某一些功能，根本没有对应的定性需求。

--对于这类情况，要么就是“口号”漏了，要么就是某些功能是经理们、操作员们的个人想法，有这样的功能是我们的福气，绝对不要让步，砍掉它。

3）具体实现方法的功能列表（用客户语言描述的，从客户角度出发描述具体实现什么目的，实现的步骤和相关的报表）

——另外我会在下一篇谈谈我自己的方法，从报表入手做需求分析也是非常好的办法。

4）估算功能点的报价。可以使用IFPUG，COSMIC，对比、代码行，总之用你擅长的、有资料库的、有把握的就好。

5）好了，一般范围都会超过预期。接下来是一场博弈。如果已经签了合同，那么开始说服客户砍功能点吧；如果没签合同那走运了，邀请Sales参加吧，比PM和技术人员谈判能力好多了。

6）得到最终的功能列表（这份才是附在合同后面的商务依据）， 该列表作为项目验收的衡量标准。

这时，我的开发团队问我，这份列表是不是就拿来做详细设计时的依据呢，不，这份只是需求分析的依据，经过对该列表的拆分会得到以后开发所用的画面、按钮、报表等等的数量依据。