![](https://csdnimg.cn/release/download_crawler_static/9129079/bga.jpg)
我们应该怎样做需求分析
第
10
页 共
55
页
业务研讨
业务研讨
业务研讨
业务研讨
前面我们探讨了业务研讨会应当怎样组织 , 下面我们再具体讨论一下我们应当怎样与客户讨
论业务需求 。 如果说组织业务研讨会是项目经理的功底 , 那么讨论业务需求就是需求分析人
员的功底。
以往我们常常认为 , 需求分析是一件最简单的事情 。 客户说他们需要做一个什么软件 , 有些
什么功能 , 我们照着做就可以了 , 所谓的需求分析员就是需求的记录员 。 我要说 , 这是一个
极大的错误 , 许多失败的软件项目 , 或者说软件项目中的需求问题 , 大多都源于此 。 经过人
们多年的研究发现 , 在需求分析过程中 , 客户存在的最大问题就是提不出正确的需求 , 这表
现为几种形式:
1. 由于对软件不了解 , 客户提不出需求 , 不知道软件最终会做成什么样子 。 这类客户在需求
讨论过程中,往往只能描述目前自己手工管理的方式是怎样的,不知道计算机会怎样管理 。
2. 能提出一些业务需求 , 但当软件做出来摆在自己面前时 , 需求就变了 。 这类客户 , 他们能
熟练使用电脑 , 对信息化管理是清楚的 。 他们提出的业务需求从整体上应当是八九不离十的
。
但是 , 由于没有实物 , 在软件中的一些具体操作并没有完全想清楚 。 因此 , 当软件真正做出
来摆在自己面前时 , 甚至经过一系列流程操作以后 , 会对一些操作提出变更需求 。 他们正如
那句经典的话说的 : “ I have changed when it saw it. ”
3. 能非常详细地提出业务需求 , 甚至有时候该怎么做的提出来了 。 这类客户 , 参与过很多软
件信息化建设,甚至有些还是软件开发的半专业人士。但是他们提出的业务需求过于具体
,
甚至怎样实现都说出来了 , 但这些有时候不是最佳设计方案 、 可能在技术上难于实现 , 甚至
有些就是过于理想化而不可实现。
因此 , 我在进行需求研讨的时候 , 首先跟客户探讨的不是软件功能 , 而是客户现有的业务知
识,用专业的话叫 “ 业务领域分析 ” 。客户现有的业务流程是什么样的,都有些什么操作?
客户在业务中都有些什么事物 , 什么专用名词 , 都是怎样定义的 , 相互之间的关系是什么?
客户在每一项操作中的目的是什么 , 为什么要这样做 , 他们制作的手工报表都说明了什么问
题?后面我会更加详细地描述怎么进行业务领域分析。
在认识了客户的业务领域之后 , 我们才能去分析他们提出的所有原始需求 。 他们为什么要提
出这项需求,提这项需求的目的是什么?只有经过这样的分析,我们才能深刻地理解需求
,
进而运用我们的专业知识 , 提出更加合理的技术方案 。 但非常遗憾 , 我们在需求分析中常常
不是这样做的 , 甚至当软件都开发出来了 , 需求分析人员都说不出客户为什么要提出这个需
求,更谈不上了解业务操作流程。一句经典的话是 : “ 客户让我们这样做的 。 ”
总之 , 我们做需求分析 , 眼界不能仅仅停留在软件本身 , 应当更开阔一些 , 应当扩展到跟这
个业务有关的那些领域知识中。
当然 , 另一个极端就是为了开发软件 , 无限地扩大学习领域知识的范围 。 为了开发财务软件
去考会计师 , 为了开发税务软件去学习税法等等 。 开发软件不是让我们成为这个领域的专家
。