谈一下我对如何做需求分析的理解和思考

背景

需求分析是研发一个软件系统的前期工作，目的是搞清楚系统要做什么，用户的应用场景是什么等。稍微大一些的软件开发团队有专职的需求分析师，他们有的叫BA，有的叫SE；也有由开发骨干兼任的。

从架构设计4+1视图角度来看这部分属于用例设计阶段。从我个人的经验来看需求分析可以按如下几个步骤去完成。

步骤一、梳理客户的业务流

我们所开发的软件系统很少是无中生有的，大部分情况是客户想通过软件对他们现有的业务流程做优化，提升工作效率。在没有IT系统前客户已经有了一套成熟的工作方法可以支撑，只是随着业务快速发展，原有工作方法需要大量投入，成本太高(甚至到了投入再多人也搞不定的情况)；这个时候就需要IT化，云化。

设计这一类IT系统，理清客户现有工作流程非常关键。梳理业务流程可以借助“泳道图”。泳道图描述的是各个角色在各个关键活动中的交互配合关系。如下图所示：



上面的泳道图描述了客户完成一项工作需要经过三个主要活动，涉及三个主要角色，每个角色在这些活动中要做哪些处理；它们的顺序依赖关系是怎么样的。

要搞清楚上述每一步处理的输入和输出是什么，它们可能是报表文档，邮件等，中间每个处理环节的输入就是上一步的输出。要拿到当前输入输出材料的样例模板(如涉及敏感数据可以隐去或做匿名化处理)。

客户业务流程可能很长，还可能涉及一些人工决策地方。通过分析上面的泳道图能确定IT系统能优化哪些环节，哪些环节是无法优化的，跟客户沟通清楚后确定系统和用户界面的边界，以及IT系统上线后如何嵌入到客户现有的工作流程中。

步骤二、设计系统用例

根据上一步的泳道图能确定系统的主要角色，根据不同的角色设计系统用例。用例反应的是用户与系统的交互。用户通过与系统交互，系统做出相应的反应，最终达成用户想要的目的。

所以，用例描述的是用户和系统间一系列的交互过程。以用户从ATM机上取款为例：

用户：插入银行卡。

系统：提示用户输入密码。

用户：输入密码后，点击“确认”。

系统：显示功能面板。有“取款”、“转账”等选项。

用户：点击“取款”。

系统：提示输入取款金额。

用户：输入取款金额。点击“确认”。

系统：吐出指定金额的钞票。

用户：取走钞票，取出银行卡。

系统：回到初始界面。

上面是一个正常的操作流，实际上还有一些异常流程，如：密码错误、余额不足等。在用例设计时异常流程也需要描述。

步骤三、明确系统的规格约束

通过流程梳理和用例设计，已经搞清楚了这个系统要做什么事情。现在要明确的是系统不能做什么或者说有哪些限制条件。例如上面取款的用例，规定单笔最多能取2500，最少取100;一天内总计取款不能超过2万等。这部分也可以在用例设计阶段一起做。

系统规格是与客户协商一致，符合客户当前业务发展需要的一些约束条件。通过这些约束系统提供受限的功能。