上周刚结束了软考考试，接下来计划写3篇与学习内容有关的产品推文。

系统分析师教程中关于需求工程这一章提到了三个概念：业务需求、用户需求、系统需求。这是令豆芽君最深刻的一种分类方式。

互联网时代，【需求】这个词高频出现，且每个地方还常出现不同的术语，大家往往可能说的还真不是同个层级的东西。今天豆芽君要分享的这3个，我认为是清晰明了地讲清楚了需求的层次。

最高层：业务需求。系统分析师主要的系统对象是政府、企事业单位的信息化。简单地说，就是2B的项目。所以书中提到的业务需求，就是指甲方高层（决定做这个项目的人员）以及实际负责系统所对应的业务的高管对项目的目标、需求描述。业务需求是后面两类需求的主要来源。

为了便于理解，我们还是举个业务需求的例子：公司希望通过建设XX系统项目，改变目前信用管理的授信额度受人工主观因素影响较大的问题。

从这个例子来看，业务需求是项目的主要目标，要解决什么关键的问题？作为企业高层，他们基本没有参与具体一线业务，这时他们主要是从企业经营的降本、增收、控风险等抽象化的视角（这三类需求，几乎在任何企业都适用）对企业经营、管理提出要求。

中间层：用户需求。用户需求主要来自未来实际需要使用系统的用户，他们希望通过系统实现什么功能？系统如何辅助他们的日常业务工作。

同样以上面的业务需求对应的用户需求为例，可能包含的用户需求描述就是

1、首先要解决授信额度计算的过程透明化，防止业务人员故意碰撞规则，防止出现先要结果，再凑过程的情况。

2、增加信用人员对业务人员提交的信息的复核力度。对不同的信息类型，由不同岗位的人根据各自的专业分工，各自独立复核，最后由风控委员会再做最后的交叉复核。

说实话，对于这类管理类的用户需求，我们一定需要找到负责这个业务的高层领导充分调研。这里提的两点内容，都是非常大胆、革命性的流程/规则调整。没有决策权利的人，无法拍板。哪怕真的做了，往往也无法推行下去。

其他普通的操作性需求，一般到用户经理层确认就基本可以了。

从这个例子来看，用户需求是对业务需求进行策略级的细化。光有业务需求，对于系统建设方，他们还是不知道如何下手。只有实际负责一线业务管理、实操的人，才能讲清楚应该怎么做？

所以，用户系统就是指未来系统要如何具备哪些可能的业务能力、功能。

最底层：系统需求。请注意，我用最底层不是指它最low，而且指从项目顺序来看，它排最后。实际上大部分的建设方唯一能发挥作用的就是这一层。这样你就知道它同样也有多重要。

系统需求主要应来自于项目经理、产品经理、系统分析师这类负责需求分析的岗位角色的人。

现实工作却是系统需求常常来自系统用户。认真去看大部分用户提交的需求，都有类似的描述：请在XX功能内添加某个按钮，这个按钮要求实现的功能是XXXX。

大家可以认真想下这种需求描述有没问题？（建议先思考1分钟再往下看）

典型的问题如下：

1、开发人员很可能不加思索，就按用户说的做，结果系统就做成一个四不像。每个人都把个人的“需求”，放到一个产品内。这些需求还往往互相“打架”、重复（有细微区别，不知道要听谁的）

2、开发范围、成本无限蔓延。大部分公司都没有对业务单位的需求做成本管理。作为用户，最好所有能讲清楚，哪怕不能讲清楚（但只要可以讲）的需求，我都可能提给系统来做。

3、需求管理混乱。用户直接对接开发人员。开发不知道听哪个用户的？最终做了一堆功能，没有赞美，只有批评。

所以系统需求最好有统一的负责人、归口。用户可以提出初步的系统方案建议，但最终的系统需求应该由项目经理或产品经理或系统分析师来统一确认。确认完后，再对需求做优先级分配。这样开发人员接到的需求就不会有上述三类问题。

分清楚了业务需求、用户需求、系统需求应来自谁？它们的内容区别？未来做需求调研时，你就知道每类需求找哪类人？每类需求细到什么颗粒度？