需求分析之路专题（1） 需求分析全景

引言

在讲述需求分析之前，我先抛出一个问题，看看大家对于软件开发中，需求工作的目的是否理解了。

有以下4个选项，请选择一个：

A. 让系统更好卖      B.更好的指导设计    C. 对系统做概要的描述   D. 满足软件工程需求规范  

请你认真思考半分钟.....

好了，上面题目的正确答案应该是 A，软件开发中需求工作的目的是为了让系统(也就是公司产品)更加好卖。一个企业要生存就必须赚取利润。而利润来自于收入减去成本，要增大利润只有两条路径：1 增加收入；2 减少成本。

而其中增加收入就是要多卖产品和服务，想要用户多买产品和服务，这就要求你的产品和服务能满足用户的需求，而用户的需求就是软件开发中的需求。所以软件开发中需求的最终目的就是为了更好满足用户，让产品服务更加好卖。

在我所接触的产品经理或需求分析师当中，能第一次就做对这道题目的人还不到一半，也就是说很多人对为什么要做需求分析都还不清楚，这就很难做好需求分析了。

相信通过这道题目，大家已经将需求工作的认知对齐了，那么接下来就讲讲既然需求分析如此重要，那么我们应该如何才能将这件事情做的又快又好。

业务驱动需求

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

简单的说就是用户提的方案不是需求，用户存在的问题才是需求。

在软件需求中，从宏观角度来看，组织应用类软件系统需求可以分为价值需求（目标场景、干系人关注点、干系人阻力点）、详细需求两大部分。

价值需求包括目标场景，干系人关注点、阻力点两个角度；而详细需求则由功能需求、数据需求、非功能需求三条主线组成。

软件需求的全景图如下图所示：

对于项目、产品的需求，我们需要先澄清问题（Why）、了解背景（场景——功能，术语——数据，环境——质量），确立好目标场景，这就是成功标准是什么。

从目标场景出发，识别对于系统来说，最关键的干系人有哪些？他们各自的关注点是什么？有哪些担心？可能会带来哪些阻力？

然后结合关注点与阻力点进行详细的需求分析，在分析的过程中可以拆分为功能性需求分析、数据需求分析、非功能需求分析三大部分。

价值需求分析

很多人可能对价值需求这个名词比较陌生，其实说白了价值需求就是你这个系统或产品的商业价值。从黑盒子的角度来回答：

• 整个软件系统为客户解决了什么问题、创造了什么机会？

• 对于系统而言，最关键的干系人有哪些，各个重要干系人对系统的关注点是什么？有哪些担心？

价值需求是组织应用类软件系统需求的灵魂和方向,但是实际情况是做的都很薄弱。

一个是在目标分析方面，经常会看到很多放之四海而皆准的、定性的描述，例如“打造一套先进的信息化系统，有效地推进管理的提升……”这都是一些正确但没有意义的废话。

如果说目标分析方面只是做得不到位，那么在干系人识别与分析方面则经常是干脆直接省略了，大部分需求人员或产品经理靠拍脑袋来出需求。

详细需求分析

如果说价值需求是方向，是成功的标准。那么什么是详细需求呢？简单来说，详细需求是从灰盒子视角来完成三个主题的分析：

• 为了给客户提供业务、管理、维护支持，需要提供哪些功能？（功能需求）

• 系统所涉及的问题域中有哪些数据，之间是何关系？（数据需求）

• 所处的业务环境会带来哪些约束和质量要求？（非功能需求）

一般比较复杂系统不会直接从整个系统角度来进行功能、数据、非功能主线的梳理，需要先进行系统分解，划分成问题子域，再逐个分解。

功能主线

在整理功能主线的时候，我们需要站在更宏观的角度看，一个组织应用系统无外乎包含如下几个方面：

• 降本增效：通过系统固化、优化业务流程，提升流程执行效率、节约成本、降低风险等

• 业务拓展：通过系统拓展业务的渠道，使其延伸到电话、互联网、移动互联网等通道上

• 组织赋能：通过系统将个人知识、能力转化为组织知识、能力

• 管理决策：通过系统实现数据的信息化，辅助管理、决策

前3种实际上可以归结为一类，用于业务支持，而第4种则是另外一类，用于管理支持。软件系统对管理的支持，主要可以体现在三个方面：

• 1.事前风险避免，通过增加管理流程

• 2.事中风险控制，通过规则和审批

• 3.事后总结优化，通过数据分析

在业务梳理过程中，应该以业务流程为主线作为分析入手点，而不是从人或岗位角度。因为系统要支持的是业务，而在业务领域中通常是先有业务，再明确岗位及岗位职责。

系统投入使用之后，还需要对其进行维护，最典型的包括初始化、配置、排错等，而这些运营维护场景也需要有相应的功能来支持。

数据主线

功能主线代表的是工作流，数据数主线代表的就是信息流。

在一个组织中有四个最核心的流：工作流、信息流、资金流、物流。而在一个组织应用类软件系统中，资金流和物流是不会真实出现的，而是以信息流的形式呈现。

它们的关系如下图所示：

数据主线的关键任务有两个：一个是“领域建模”，也就是用领域类图的形式刻画出问题域中所有业务数据实体之间的关系；另一个是对每个业务数据实体进行“业务数据分析”，详细定义数据构成与推演过程。

非功能主线

由于系统部署、应用的环境不同，会带来不同的约束、不同的质量要求。

这部分的需求分析，在很多实践中存在很大的缺陷，大部分产品不懂技术，很难写出恰到好处，所以普遍会存在下列一些典型的问题：

• 定性描述：直接写“高可靠、高易用、高灵活……”之类的要求，而实际上并没有传递出任何有效的信息

• 盲目定量：拍脑袋写出量化指标，写出一些客户、需求人员、开发人员都无法清晰理解的似是而非的量化要求

• 以偏概全：诸如“所有查询都在7秒内响应”之类的全局性描述，这种描述缺乏实际有效的落地性

实际上我们可以根据系统的特点，决定非功能需求的分析深度。也就是通过质量树梳理的任务，找出最为重要的质量类型，并以一张《关键质量》列表方式呈现。

另外对于非功能需求的分析工作，最核心的是逆向思维，从威胁入手，反推系统应该具备哪些能力。

小结

本小结介绍了在软件开发中需求分析工作的主要目的其实是为了让系统、产品、服务更加好卖。而要做好需求分析，我们可以需要按照业务驱动的思想去进行，整个工作可以分为两大部分：价值需求分析和详细需求分析。

价值需求分析方向，以终为始的先确立成功标准。详细需求包含三大主题的分析：功能需求、数据需求、肺功能需求。我们可以依照三大主题为工作线进行梳理。

附录

最后在这里给出一个需求分析过程需要进行的任务以及对应输出物。在实际的需求分析实践中，你应该根据实际的产品、项目特点，明确出关键的需求主线，以对其进行合理的剪裁。