如何准确分析需求-编程知识

业务驱动的需求思想

要做好软件需求工作，业务驱动需求思想是核心。传统的需求分析是站在技术视角展开的，关注的是“方案级需求”；而业务驱动的需求思想则是站在用户视角展开的，关注的是“问题级需求”。

变更/优化型需求分析任务执行指引

在软件需求分析实践中，用户提出变更、优化型需求也通常都是直接提出“方案级需求”，因此我们需要还原出“问题级需求”

价值需求主线

什么是价值需求？简单来说，就是从黑盒子视角回答“整个软件系统为客户解决了什么问题、创造了什么机会”，“对于系统而言，最关键的干系人有哪些”，“各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）”三个本质性问题。价值需求是组织应用类软件系统需求的灵魂和方向，但在笔者所接触的很多此类需求分析实践中，这部分做得相对薄弱。这将使得项目范围更容易蔓延，客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。

功能主线

有人说，组织应用类软件系统就是带一定业务逻辑的增删、改查功能；也有人说，做需求就是先搭菜单结构。这些都是典型的白盒子视角，是从开发视角来说的技术驱动需求理念。这一视角，会让用户对需求分析过程敬而远之，写出的需求文档也将令其望而生畏。

有人说，我们应该先找业务用例，再找系统用例，从用户的角度来“发现”。这虽然是一种“黑盒+灰盒”的视角，但大量实践者苦于难以有效地完成思维角度的切换；另外，这种较小粒度的抽象方法，容易在需求分析过程中陷入树木而忽略森林。

实际上我们还有更好的思考角度和做法，那就是厘清系统中的所有功能是因何而存在的。如果我们站在更宏观的角度上来看，实际上最核心的无外乎以下几个方面：

通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等。
通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上。
通过系统将个人知识、能力转化为组织知识、能力。
通过系统实现数据的信息化，辅助管理、决策。

业务支持

业务支持最典型的是三类：首先是固化、优化业务流程，因此业务流程是核心；其次是业务延伸到新的通道（诸如手机端），这从本质来说也是一种流程的重构，核心还是业务流程；最后是将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心。要梳理出业务支持所需要的功能，简单来说，就是从灰盒子视角回答四个问题：“根据目标和干系人关注点，系统涉及哪些业务流程？”“这些业务流程是如何定义的，需要优化吗？”“系统对流程中所有业务场景都要支持吗？还是只支持一部分？”“有哪些业务场景的工作经验需要模型化？”

系统要支持的是业务，而在业务领域中通常是先制定业务流程，再明确岗位及岗位职责的；只有清晰地梳理出流程，才能更好地分析需求。

管理支持

软件系统对管理的支持，主要可以体现在三个方面：

事前风险避免，通过增加管理流程；
事中风险控制，通过“规则”和“审批”；
事后总结优化，通过“数据分析”。

前两种通常会在业务支持分析中统一处理；第三种则应该独立进行分析。要梳理清管理支持所需的功能，简单来说，就是从灰盒子视角回答三个问题：“管理层用户希望通过系统来实现哪些管理、控制需求？”“希望通过系统做哪些辅助决策？”“要实现这些管理、控制、决策支持，需要哪些信息？用什么方法获得它们？”

业务流程分析与优化

在标识出相关的业务流程之后，接下来的关键任务就是逐个流程进行了解与分析，绘制出流程图，并对关键流程做适度的优化。

业务流程八要素

业务流程分析，最重要的是厘清如图7-5所示的业务流程八要素，包括五个基本要素（分工、活动、协作、产物关系、分支），三个管理要素（审核、规则、异常）。

五个基本要素

当我们分析一个业务流程时，首先需要明确出整个流程中涉及哪些分工、每个角色负责执行什么活动，然后选择合适的流程图将其表示出来。当然，这些活动之间不是独立的，存在顺序执行、并行执行、异步执行等多种可能，这就是“协作关系”，在流程图中就是各个活动之间的连线。而且协作过程不是一成不变的，还需要根据实际情况来进行处理，这就是流程中的“分支”。这也是流程图中的一个重要的要素。另外，在协作过程中，各分工之间需要传递工作产物，流程管理者会制定一些表单、单据格式以明确职责，这就是“产物关系”。在流程图中通常以“数据流”或“文档”的形式来表示。这些就是一个流程中五个基本要素之间的关系，除此之外，管理者还会在流程中引入一些用于控制风险、监控进程的管理元素。