数字化转型之需求分析的正确打开方式

需求是业务和技术的桥梁，是行业知识向数字化转换的过程，业务是需求的输入，需求是设计的输入。即需求的关键元素必须从业务分析的元素演化而来，后续的高阶设计需要从需求一脉相承，一以贯之，每个元素需要有完整的生命周期和演化链，这是一个有机的整体。以业务对象为例，在业务分析阶段，业务客体是业务对象，在需求阶段，业务客体演化为对象实体，在设计阶段，对象演化成为数据库物理模型中的表或者视图。

需求内涵包括业务需求、管理需求、运维需求、外部服务需求四部分。

需求分析师的职责是依据业务分析输出，根据业务边界，界定需求边界，根据业务参与者厘清用户，根据业务用例深化使用用例，并衍生出管理用例、运维用例、系统用例、外部服务用例，根据业务规则，规定需求的约束和限制，根据业务流程，确定工作流程、页面流、数据流，根据业务对象，定义对象实体和界面元素。

需求分析的目标已清晰，那我们如何正确打开需求分析这个迷宫呢？需要一个好的方法论指导，我们采用的是Rational提出的基于面向对象的软件工程RUP方法论，基于RUP方法论，对业务需求、管理需求、运维需求、外部服务需求和约束进行提取、组织、文档化，从而定义一份完美的需求。下面我们就像庖丁解牛一样，朝着目标，沿着正确的路径昂首前行。

在进入正题前，我们先解个惑，那就是业务和需求的差异究竟是什么，为何资深需求分析师也会将二者混淆？

首先，内涵不同，业务是政府或者企业的运营内容，比如石油勘探开发业务，普查->详查->精查->勘探钻井->开发钻井->输油->炼化的全流程的业务通过全手工的方式同样可以完成。而需求是信息化领域概念，特指业务中能够数字化、需要数字化的用户要求，再比如勘探钻井需要用钻井平台去实现，这个动作，信息化是无法完成的，因此这个动作是无法进入信息化需求的列表的。

其次，外延不同，业务的外延涵盖组织的全部社会活动，但是需求的外延是可以数字化的组织工作。

最后，主体不同，业务分析的主体是甲方或者乙方组织的行业专家或者业务专家，可以完全没有信息化的知识背景。但是需求分析的主体是甲方或者乙方具备信息化知识背景而且具备需求转化能力的分析师。

一、如何界定需求边界？

需求分析师是天才的转换器和过滤器，依据业务边界，将能够数字化同时需要数字化的业务转换为需求，而过滤掉不能数字化或者不需要数字化的线下过程。同时，无论在业务支撑还是业务重构、业务创新场景下，需求都肩负着对业务过程进行自动化和标准化的责任。

二、如何厘清用户？

用户是数字化系统的访问主体，用户分为使用用户、运营管理用户、运维用户、系统内置用户。

最佳实践是，从业务分析中的业务参与者出发，参与业务执行、业务运营管理、业务决策的人员，将成为使用用户，他们使用系统的服务功能，完成业务工作。

运营管理用户、运维用户是业务数字化过程中衍生的信息系统的管理和运维人员，运营管理用户负责管理、配置系统后端功能，涵盖了应用系统管理人员。运维用户负责定期巡查、应急处置系统故障、数据备份、安全管理等，涵盖了IT运维人员。

系统内置用户是根据业务自动化和外部服务的诉求从业务数字化过程中衍生出来的用户，它负责系统自动执行的动作。

这里需要强调的是，所谓用户，是针对数字化系统而言的概念，不是针对业务而言的，即使用用户指的是使用数字化系统的人，运营管理用户指的是运营管理数字化系统的人。所以业务的运营管理和决策人员是使用用户，不是运营管理用户。

以保险系统为例，保险客户、保险产品销售、保险产品审核人员、保险理赔人员、保险公司管理人员、保险公司领导等是保险系统的使用用户，保险系统管理员是保险系统的管理用户，保险系统的运维人员是运维用户，保险系统的内置用户是系统用户。

顺便说一句，厘清用户的一项重要工作是对用户进行分类，合理、精确的用户分类是系统切分子系统以及系统安全控制的一项基础工作，需要科学的划分。

三、如何抽取用例？

用例定义的方法是范围+级别+主体+前置条件+动作（场景）+触发事件，用例是分层次的，高阶用例允许包含多个低阶用例。

范围的核心是空间范围、组织范围和时间范围。空间范围是指网络空间和地理空间，组织范围是指用例在哪些组织机构内执行，时间范围是指用例的生命周期。比如中国人寿的产险产品，在北京、新疆的不同地域可能会存在不同的业务规则，在不同时间段保费可能存在不同的优惠价格，北京分公司和新疆分公司可能推出不同的特色地区小险种产品等。

级别主要针对用例的树形层级，比如一级用例、二级用例等。高阶用例通常抽像级别更好、更宏观。

主体是用例的执行者，前置条件是用例执行需要具备的条件或者状态，是用例的必要前提。

动作是用例的行为，触发条件则是用例的触发时间或者触发事件。

最佳实践是，依据业务用例，深化出使用用例，它是使用用户访问数字化系统执行的业务工作，比如录入保险订单、审核保险订单、签订保险合同等。

为支撑和保障使用用例的执行，数字化系统衍生出管理用例、运维用例和系统用例、外部服务用例。

管理用例是数字化系统建成后，管理员对数字化系统的管理工作，比如，身份管理、组织管理等。

运维用例是数字化系统建成后，运维人员对数字化系统进行的运行维护工作，比如模拟登录、数据备份等。

系统用例是自动执行的动作，由系统内置用户作为用例的使用者。比如自动审批流转、自动预警等。

外部服务用例通常从需求边界衍生而来，是系统与外部系统集成的服务接口，将系统与外部系统在业务流程或者数据层面集成为一个整体。

用例定义的难点是，业务用例是闭环的，需求用例同样要求闭环。但是，由于业务用例中的手工动作或者线下动作不包含在需求用例中，那么需求用例如何保证业务的闭环呢？最佳实践是，将由于手工或者线下中断的不同业务环节封装在不同的子系统中，子系统间通过集成实现完整的业务闭环。或者在系统内，将上个环节的执行结果作为下个环节的输入信息，延续业务流程。

强调一点，需求分析中必须包含运维需求。因为，数字化系统的价值体现在系统运行产生的效益，那么前提是系统能稳定运行并在故障时能快速恢复，所以，系统是否能良好运维，直接关系到系统的价值是否能充分体现。比如，如果系统中的业务链复杂，系统运行故障时，需要跟踪整个业务链才能定位系统故障点，那么为了快速解决故障，运维需求需要包括在业务链中每个业务动作包含一个唯一的traceID，通过traceID能够跟踪业务链中每个业务动作执行的结果，通过日志确定哪个业务动作结果是失败，即可快速定位故障的程序点，从而快速排障。

四、如何抽取约束和限制？

约束和限制是用例执行的过程规则，包括业务主体、客体的空间和时限限制、性能和可靠性指标约束、环境限制、安全保密约束、用户体验约束等。

业务主体、客体、时限限制是指特定类型的主体在特定的空间和特定时限能对特定客体进行特定操作。

指标约束包含（用户量、数据量、性能指标、可靠性指标）等，以保险业务为例，要求用户访问保险订单时响应时间2ms，系统24*7稳定运行等。

环境限制包括系统空间限制、行政区划限制等。安全保密约束包括用户访问采用加密方式，系统数据必须加密存储等。用户体验约束包括用户访问3次点击即可完成等类似需求。

最佳实践是细化和分解业务规则，作为需求的约束和限制。以保险业务为例，产险的代理机构领导在公司内网中上班时间才允许审核本代理机构的产险经纪人销售的产险订单。这个约束，要求特定主体（保险代理机构领导）在特定环境（公司内网）在特定时限（上班时间）对特定客体（产险订单）进行审核。

五、如何定义流程？

流程是具有确定的开始节点、确定的环节、确定的环节转换逻辑、确定的结束节点的一个时间或者逻辑序列。

流程图需要包括用户、活动、次序、输入、输出等关键元素。那么定义流程需要先定义业务任务，分解业务任务为多个过程，将过程定位为环节，明确环节输入和输出，并确定环节间的并行或者串行次序，即可完成流程定义。

最佳实践是，从业务流程细化业务执行的工作流程。然后，依据工作流程结合功能设计，确定页面流和数据流向，定义数据流。

需要强调的是，流程定义需要涵盖正向流程、反向流程、异常流程。正向流程是业务正常开展的走向，而反向流程是环节出现逆向动作，比如A提交申请，B审核通过，C审核通过，此时，A撤销申请，或者C审核驳回，流程需要逆向返回A。异常流程是在流程运行过程中，在某环节出现异常结果，流程如何提供异常出口，而不是让流程停滞在该环节等。

更重要的是，流程定义，需要从高层流程向细化流程层层深入，先抓树干，再抓枝叶，最后深入毛细。

六、如何定义对象？

对象是数字化系统中的信息载体，对象的内涵包含了业务主体、业务客体、事件、过程等。

如何表达对象呢？ER图。ER图即对象关系图是指以对象实体、关系、属性三个基本概念概括对象实体的数据基本结构，从而描述静态数据结构的概念模式。

最佳实践是，根据业务对象抽象出对象实体和对象元素，作为系统的数据概念模型。根据对象元素，设计界面上的属性。

对象定义中的关键点是分析对象关系，对象间的依赖、继承、扩展等关系是对象定义中保证系统数据的完整性和可用性的根本保证。

简单而言，需求分析是说明谁（用户）对谁（对象）按照什么样的规则（约束和限制）在数字化系统中以什么样的顺序（流程）做什么事（用例）。如果以正确的方式打开需求分析，需求分析将是一个令人愉悦的过程，前提是，您一定要上接业务，下衔设计，让需求分析成为一个业务到技术的完美转身。

*此为数字化转型系列文章的第二篇，第一篇《设计数字化转型业务顶层的九个疑问》，后续将推出第三篇《数字化转型的产品设计正确打开方式》，敬请持续关注EAWorld~