Part 1 引导篇

1 软件需求全景图

在信息技术深入应用的今天，政府、企业等各类组织都依赖于信息系统来开展自己的业务。针对这些组织应用类软件系统的需求分析工作，核心在于“业务分析”。而要想厘清此类软件系统的需求，就必须要抛开具体的技术实现，站在用户的视角审视用户想要解决的问题、想要达成的业务目的。

1.1 业务驱动的需求思想

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

在这个例子中，小孩提出“要吃饼干”，这实际上是一个方案级需求。由于家里没有饼干，因此妈妈认为孩子提出了一个不合理的需求，于是想办法让小孩放弃这个需求。而老余则快速意识到了这个方案级需求背后真实的问题级需求是“饿了”，因此找到了可行的解决方案——吃面包，小孩的需求也得到了满足。

1.2 组织应用类软件系统需求全景图

针对组织应用类软件系统的需求分析，本质上应该抓住两个层次（价值需求与详细需求），四条主线。首先从宏观上明确系统的价值需求，然后以功能需求、数据需求、非功能需求三条主线完成详细需求的梳理。

价值需求主线包括目标场景，干系人关注点、干系人阻力点两个分析主题；而详细需求则应该从业务支持、管理支持、维护支持三个方向明确场景，梳理出功能需求（也可以称为行为需求），从关系、构成、推演三个角度梳理出数据需求，从质量场景和设计约束两个角度梳理出非功能需求，如图1-1所示。

本章后续内容将对价值需求、功能需求、数据需求、非功能需求四条分析主线的分析要点进行概述，然后在后续章节中详细阐述。

1.3 价值需求主线

什么是价值需求？简单来说，就是从黑盒子视角回答“整个软件系统为客户解决了什么问题，创造了什么机会？”“对于系统而言，最关键的干系人有哪些？”“各个重要干系人对系统的关注点是什么？有哪些担心（阻力点）？”三个本质性问题。

价值需求是组织应用类软件系统需求的灵魂和方向，但在我所接触的很多此类需求分析实践中，这部分做得相对薄弱。这将使得项目范围更容易蔓延，客户从中获得的利益与价值不容易呈现，从而导致客户满意度难以有效提升。

在目标分析方面，经常会看到很多放之四海而皆准的、定性的描述，如“打造一套先进的信息化系统，有效地推进管理效能的提升……”这样的目标自然无法作为“成功标准”来指导系统的开发与实施工作，甚至会陷入“我们走得太远，以至于忘记为何而出发”的尴尬境地。

如果说在很多需求分析实践中，在目标分析方面只是做得不到位，那么在干系人识别与分析方面则经常干脆直接省略，在《需求规格说明书》中根本找不到。而这方面的缺失会导致忽略他们的关注点，陷入他们的阻力点，从而在开发过程中不断受到影响。

如图1-2所示，价值需求分析关键在于执行好目标/愿景分析、干系人识别、干系人分析三个任务。这些任务将分别产出：多份《问题卡片》，场景化地定义项目目标；一张《干系人列表》，列出所有关键干系人；多份《干系人档案》，针对每个关键干系人整理出相应的关注点和阻力点。

在实践中，也可以使用“影响地图”等工具将这些信息整合到一张图中，使其呈现得更加清晰、简洁。

1.4 详细需求

价值需求是方向，是成功的标准。那么什么是详细需求呢？简单来说，就是从灰盒子视角完成三个主题的分析：“为了给客户提供业务、管理、维护支持，需要提供哪些功能？”“系统所涉及的问题域中有哪些数据，它们之间是何关系？”“所处的业务环境会带来哪些约束和质量要求？”

这三个主题实际上就是详细需求中的功能需求、数据需求和非功能需求三条主线。要想清晰地梳理出详细需求，可以先沿着这三条主线厘清脉络、识别出最小粒度的需求单元，然后为识别出的需求单元填充具体的细节描述。

1.4.1 业务子系统划分

由于很多系统会涉及多个问题域，因此如果直接对整个系统进行功能需求、数据需求和非功能需求主线的梳理，就会很困难。如果存在这种困难，我们就应该先从业务的角度，将系统涉及的问题域分解成不同的业务子系统，以便逐一分析。也就是说，“分解的目的是控制复杂度”，而不是单纯为了分解而分解。

如图1-3所示，显然最关键的任务就是业务子系统划分，它将产出一个《系统分解模型》，该模型可以根据实际需要选用层次图、构件图、数据流图等图表呈现分解结果。简单来说，该任务就是从灰盒子视角回答一个问题：“系统涉及哪些子问题域，它们之间有什么关系？”

当完成业务子系统划分后，还需要执行业务接口分析这一任务，定义各子问题域间的业务接口，说明这些接口的用途、由谁实现、供谁使用等细节。

1.4.2 功能需求主线

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

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

有人说，我们应该让现场客户用“作为×××，希望系统实现……以便……”的句型说出他的需求。这也是一种完美的黑盒子视角，但我们真的能够把“讲清需求”的责任转移到用户身上吗？这种转移真的有利于需求分析吗？

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

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

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

（3）通过系统将个人知识、能力转化为组织知识、能力。

（4）通过系统实现数据的信息化，辅助管理、决策。

很显然，前三方面实际上可以归结为一类，用于业务支持；而最后一方面则是另一类，用于管理支持；此外，软件系统不是一成不变的，而是不断演变与优化的，因此还需要提供用于维护支持的功能。也就是说，功能需求主线的梳理可以从业务支持、管理支持和维护支持三个角度展开。

1.业务支持

业务支持典型的三类包括固化、优化业务流程，因此业务流程是核心；使业务延伸到新的通道上，这从本质上来说也是一种流程的重构，核心还是业务流程；将个人能力转化为组织能力，而这种能力存在于具体的业务场景中，因此“专家场景”是核心。

要梳理出业务支持所需要的功能，简单来说，就是从灰盒子视角回答四个问题：“根据目标和干系人关注点，系统涉及哪些业务流程？”“这些业务流程是如何定义的，需要优化吗？”“系统对流程中所有业务场景都支持吗？还是只支持一部分？”“有哪些业务场景的工作经验需要模型化？”

如图1-4所示，梳理业务支持需求的关键是完成四个任务：①业务流程识别，为各子问题域生成一个《业务流程列表》，列出系统涉及的业务流程；②对各业务流程进行分析与优化，绘制一组《流程图模型》；③业务场景识别，识别各流程中系统需支持的业务场景模型；④业务场景分析，描述各业务场景的具体需求。

对于第三个任务“业务场景识别”有一种延伸，当涉及专家系统需求时，需要抽象出“专家场景”，也就是要实现系统模型化，以便新员工能够“复制”执行该任务的经验。

看到这里，或许有人会有所顾虑，在这个面向对象分析的时代，为什么还会以“业务流程”作为分析的入手点呢？而不是应该从“人”这个角度吗？因为系统要支持的是业务，而在业务领域中通常是先制订业务流程，再明确岗位及岗位职责的；只有清晰地梳理出流程，才能更好地分析需求。

2.管理支持

软件系统对管理的支持主要可以体现在三个方面：①事前风险规避，通过增加管理流程；②事中风险控制，通过“规则”和“审批”；③事后总结优化，通过“数据分析”。前两方面通常会在业务支持分析中统一处理；最后一方面则应该独立进行分析。

要梳理出管理支持所需的功能，简单来说，就是从灰盒子视角回答三个问题：“管理层用户希望通过系统来实现哪些管理、控制需求？”“希望通过系统进行哪些辅助决策？”“要实现这些管理、控制、决策支持，需要哪些信息？用什么方法获得它们？”

如图1-5所示，主要关键任务就是管理需求分析。首先从管理者的视角识别出他们的管控点，也就是管理场景，得到《管控点列表》；然后对每个管控点进行分析，得出所需的业务报表、BI需求、数据仓库、数据挖掘需求。而辅助的关键任务就是业务报表分析，对前一个关键任务识别出的业务报表项，从数据项、计算方法、展现格式、统计口径等方面进行具体描述。

对于这个部分的需求分析，在很多需求分析实践中都是从技术角度进行的，无论是开发团队还是客户，都认为应该列出所需的报表格式，但由于用户很难在需求分析阶段清晰地提出业务报表需求，因此经常出现分析不透、变化迅速的问题。

而对于BI需求、数据仓库、数据挖掘需求方面，更是常常脱离用户，不断地试错。归根结底，是缺乏管理场景角度的思考。

3.维护支持

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

要厘清维护需求，简单来说，就是从灰盒子视角回答两个问题：“谁需要对系统进行维护？”“他们需要执行哪些维护任务？”

也就是说，在执行维护支持需求分析这一任务时，首先要识别未来的维护用户，可能是客户自己的维护团队，也可能是开发团队本身。然后根据不同的维护用户列举出与未来维护、运营相关的场景，整理成一张《维护场景列表》，如图1-6所示。

在进行这部分需求分析时，建议不要从功能实现的角度来列举功能，而要从维护场景的角度进行分析，如不是“日志”功能，而是“排错”场景。

另外，这部分内容通常是可以重复使用的，一次整理结果能够在多个同类系统中重复使用。

1.4.3 数据需求主线

大家都知道，在一个组织中有四个核心的“流”：工作流、信息流、资金流、物流。而在一个组织应用类软件系统中，资金流和物流不会真实出现，而会以信息流的形式呈现。在前面提到的功能需求主线中，是以“工作流”为线索进行分析的。而数据需求主线，重点就在于厘清组织中的“信息流”。

对于数据需求主线的需求分析而言，简单来说，就是从灰盒子视角回答三个问题：“系统相关的问题域中有哪些业务数据？”“它们之间是什么样的数据关系？”“每个业务数据的具体构成是怎样的？”

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

1.4.4 非功能需求主线

由于系统部署、应用的环境不同，因此会带来不同的约束、不同的质量要求；而如果没有有效的分析，就会使得系统无法满足实际应用的需要。

对于非功能需求主线需求分析而言，简单来说，就是从灰盒子视角回答一个问题：“系统相关的外部环境会带来什么样的约束和质量要求？”

非功能需求主线需求分析在很多实践中存在很大的缺陷，最典型的情况有三种，具体如下。

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

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

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

对于非功能需求而言，是不是要做到面面俱到地进行分析呢？这是一个值得思考的问题。实际上，我们可以根据系统的特点决定非功能需求的分析深度，也就是通过识别并排序关键质量属性的任务，找出最为重要的质量属性，并以一张《关键质量属性列表》呈现。

对于非功能需求的分析工作，最核心的是逆向思维，从威胁入手。基于《关键质量属性列表》中的每种质量属性，识别出业务环境中可能产生的破坏力大、出现概率高的威胁场景，使用《目标—场景—决策表》描述出来。

也就是说，非功能需求主线需求分析的核心任务就是识别并排序关键质量属性、识别质量场景两项，如图1-8所示。通过这两项任务，把握关键的质量属性，用场景传达具体需求。

1.4.5 补充性内容

通过价值需求、详细需求（包括功能需求、数据需求、非功能需求三条主线）的梳理，识别并描述业务功能、业务报表、业务数据、质量场景、业务接口五类最小需求单元，基本覆盖了需求分析的所有内容。此外，还要补充两方面内容：一是业务规则，二是约束，有时需要单独进行更加详细的分析，如图1-9所示。

当系统中有大量的约束时，需要强化约束分析。当系统的规则量大、规则很复杂时，就可以考虑将其单独作为一个主题来进行分析，否则在业务流程分析、业务场景分析、领域建模时附带对业务规则进行分析即可。

1.5 组织应用类软件系统需求分析任务小结

为了帮助大家形成整体的认识，在此把前面提到的一些在组织应用类软件系统需求分析中需要回答的关键问题，以及17项需求分析关键任务汇总在一张图中，如图1-10所示。

在需求分析实践中，应该根据实际的产品、项目特点，明确关键的需求主线，以对其进行合理的剪裁。