转载本文需注明出处：微信公众号EAWorld，违者必究。



需求分析是软件工程中的一个关键过程，也是一个复杂的过程。需求的管理与各个应用的特征密切相关，同时还涉及非功能性需求及其与功能性需求的错综复杂的关系。需求需要方方面面的人员参与，业务部门是需求的发出者，需求分析人员是需求的接受者，开发人员是需求的执行者，只有三方人员对需求的理解达成一致才能开发出成功的软件产品。但这三种人员由于背景知识不同、擅长的领域不同，通常不能完整、正确地了解对方领域的知识，再加上沟通的不充分，最终导致需求理解存在偏差。



举个简单的交易前检查的例子：



V1.0：必须是登录的用户才可以进行交易；必须是未惩罚、未冻结的用户才可以进行交易。

V1.1：海外登录的用户IP不能是“XX.XX.XX.XX”。

V2.0：金额大于1000元需要短信验证码确认，单日限额10000元。

V2.1：短信验证金额、单笔限额、单日限额可以由用户调整……。

V2.5：转账给曾经转账用户小于2000元无须短信认证……。

V3.0：购买行内理财产品仅需输入密码确认；购买三方理财产品需要短信验证……。

V4.0：久眠户交易必须增加实名认证和生物识别，且金额大于500元需要审批。



一般需求描述方法随着迭代周期的延伸，最终流程图复杂到我们无法一目了然地找到需求切入点。如果需求人员都不知道该在哪里加需求，谈何设计和开发呢?



因此，如何对业务需求进行准确的传递至关重要。用结构化的表达方式来描述需求，统一项目相关方对于需求的理解，是保证需求被正确理解的重要方式。为了更好地支撑业务中台的标准化、端到端、柔性的业务流程建设，我们需要一套需求结构化方法，从产品、架构、需求、设计、开发、测试等多角色的全链路视角，建立标准化的信息描述语言和可复用标准，打造跨越业务、需求、设计的需求结构化管理与沟通协作方法。



1. 目标：统一语言、建立标准、打通环节、展现全貌



为了更好地支撑业务的标准化、端到端、柔性的业务流程建设，通过实践我们总结出一套需求结构化方法，这是一个面向产品、架构、需求、设计、开发、测试等多角色的全链路视角，建立标准化的信息描述语言和可重用标准，打造跨越业务、需求、设计的需求结构化管理与沟通协作方法，如图所示。



从上图我们可以看出，需求结构化的目标体现在如下四点：

（1）实现需求的数字化，统一业务与技术的沟通语言：建立在需求结构化方法之上的统一的需求描述语言，沉淀了基于统一元模型的结构化需求数据。需求的管理与描述不再仅仅是文档形式，而是以结构化的形式呈现，同时这种结构化需求需要能够向前承接业务方案，向后能够准确地传递给设计、开发以及测试等角色，形成研发过程全链路的打通。从而基于共同的语言填平了业务需求到系统设计之间的鸿沟。

（2）减少软件研发的环节，提高协作效率：传统的研发过程从业务方案的制定到软件设计过程需要四个步骤：业务方案、业务需求、系统需求、软件设计。引入需求结构化方法之后，业务需求过程中的业务流程梳理，软件设计过程中的操作流程和交易流程梳理被需求结构化整合到一起，从而将原本的四个步骤缩短为三个步骤。看上去只是减少了一步，实际上我们将研发过程中最为重要的流程梳理整合到一起，产品、需求与设计多角色协同工作，原本需要多路沟通和反复确认的需求，将通过统一的语言，汇聚到一起的流程梳理方法，快速达成一致。这种基于多角色认同的需求结构化分析方法，降低了需求确认的周期与频次，有效提升了交付效率。

（3）建立业务可重用标准：重用不是目的而是手段，通过重用我们能够降低整个IT建设的复杂度，从而实现低成本、高效率、高质量、快速交付以及易维护的业务系统。以前我们都是在设计阶段考虑重用，这样的重用一般专注于技术上的可扩展性。对于业务上的潜在可变性关注不足，这也是导致需求反复确认以及重复造轮子的原因。我们认为一切的变化源于需求，那么在需求结构化中落地的重用对于IT建设将更具价值。通过需求结构化建立领域工程与应用工程之间的可重用标准，领域工程实现能力用以重用，应用工程通过可重用的标准复用已有业务流程实现个性化的业务，基础服务组件与业务实现真正隔离，针对业务的创新将无须考虑对于其他业务的影响，由此可以进一步缩减测试的范围以及周期，加速业务交付。

（4）形成可重用能力的全貌：需求结构化不仅仅是运用结构化的信息数据描述需求和设计，同时管理着层级关系、引用关系和扩展关系。“层级关系”实现对业务流程的解构，从流程的分解，服务的透出，呈现出平台的能力全貌；“引用关系”描述了业务流程作为组件或服务被系统内部或者外部使用的情况，从而获得业务流程的影响分析；“扩展关系”展示了业务流程透出的可变性，以及由什么业务重用了这些可变性，从而形成扩展影响关系。产品在做业务需求的分析时，可以随时查看平台提供的业务能力的三个维度关系的全貌，清楚地知道业务与能力的关系，而不需要委托设计与开发人员翻代码。

2. 需求结构化的要领

我们可以从四个方面发力，推进需求结构化建设，达成前面所述需求结构化的目标。

（1）数字化建模

从“需求结构化”这个名字我们就可以看出，结构化是建模应当具备的基本能力。它要能够把业务需求通过建模的方式，变成结构化的数据。有了结构化数据，推进数字化管理才能够成为可能，这为后续可视化以及面向结构化需求的运营打下基础。从这一点出发，需求结构化描述方法作为工具链的重要环节，必须是结构化、可分析、能展示、可运行的数据。

（2）可视化呈现

结构化的数据通常可以用结构数据表示，例如有向拓扑图、列表、树、以及集合等，这类数据都是比较容易可视化的，也是更加容易理解的。需求结构化的关键要领之一是“可视化”，通过对结构化需求可视化呈现使得我们对于业务的表达更加易于理解；通过呈现“业务能力地图”使得我们能够看到系统业务全貌，通过呈现“业务影响度分析”使得我们了解业务流转之间的依赖关系，等等。

（3）促进融合

融合性体现在两个方面：一方面是组织融合，结构化需求的描述方法需要适合业务人员学习与理解，易于表述业务需求；适合研发人员设计与实现业务；同时适合架构师进行架构管控。通过结构化需求的描述方法，让架构、需求和开发相互之间都走近了一大步；另一方面，在成果方面结构化需求以系统需求为基础，向前融合了部分业务需求，向后融合了部分系统设计，既可以满足业务需求的管理，又可以推动和支撑业务的设计与运行。

（4）实现贯通性

贯通性的最大价值是帮助软件研发过程的管理，结构化需求作为研发过程中的一部分，向前需要与业务方案打通，向后需要与设计、开发、测试、部署以及运维打通，这就是需求结构化的贯通性。通过贯通性，我们可以实现在研发全链路上的可追溯。

3. 描述需求要用“模型”说话

通过前述章节我们理解了需求结构化的意义，那么需求结构化具体包含些什么呢？业务的本质是围绕组织、目标、过程、事件、信息展开。“需求结构化”分成两个部分：偏向“业务需求”的概念模型覆盖了业务需求的关键组成；偏向结构化设计的元模型覆盖了结构化需求的重要组成；两类模型通过映射关系顺利打通，实现了前述关键目标：统一沟通术语，缩短研发沟通路径及成本。


 
4. 从结构化到可视化
 


流程可视化不能单纯地“拿来主义”

在实施流程可视化的过程中，任何一种可视化方式都不能单纯地“拿来主义”，也存在以下问题：

“一张图打天下”的做法要不得：以BPMN为例，BPMN的表述能力非常强大，以至于无论是需求、架构还是开发对此都青睐有加。然而BPMN仅仅约定流程片段或者子流程的规范，并没有定义流程层级划分的原则。这样的结果就是同一张图会混入不同层级的业务要素，不加约束，随着时间的推移，BPMN流程图本身变得臃肿而复杂，最终成为业务系统中看不懂、不能动、不敢动的技术债务。

图例不是越多越好：许多流程规范是用来适应更广泛的用户，逐步泛化而变得复杂。就如BPMN规范演进到2.0版本之后，为了适应更广泛的业务需要，图例越来越多，也越来越复杂，尤其是事件图元，一方面，许多图元意义相近、功能相似，为了细微的差别定义成不同的图元；另一方面，为了满足事务、异常等场景的需要，同一个图例也有相当多的表现形式。这是BPMN力求精细化表达的结果，但这也给业务人员带来了极大的学习成本，在实际运用过程中加大了沟通难度。

不要分心，流程可视化应做最擅长的事情：标准化的业务流程是企业的业务核心，是对企业有序的业务过程精确的表达。因此，流程可视化应当专注于标准业务流程的可视化呈现。许多流程工具把规则的决策流等都放到流程可视化当中，这是不可取的。我们建议与标准化流程可视化展示相背离的内容都应当具有专属的呈现方式，包括业务信息、业务规则、业务扩展，等等。

流程重用标示不清晰：流程的可视化是对企业标准化业务的沉淀，是对知识工作的总结，是企业IT工作的生产资料。因此，对于标准化流程的重用即是对生产资料的重复利用，可以极大地提升企业IT的生产效率。然而，众多的流程可视化标准中对流程重用并没有良好的可视化呈现。


流程可视化基本图例

运用四色模型建立结合流程的信息可视化

前面我们提到业务信息与业务流程紧密相连。业务信息发起和推动业务流程的流转，同时业务流程流转也产生业务信息。因此我们梳理业务流程就可以找到业务信息。

下面我们针对上述的信贷流程，利用四色原型法进行业务信息的分析与可视化描述，如图所示：


 
如上图所示，在业务流程流转过程中，不同的环节将会产生不同的MI模型：贷款申请活动产生“贷款申请单MI”，评价授信活动产生“信用评估记录MI”，签订合同活动产生“信贷合同MI”，办理放款活动产生“放款记录MI”……以此类推，我们便在时序轴上分析出了所必须的MI模型。这就是时刻-时段模型的实质，当我们把这些数据的足迹按照时间顺序排列起来，我们几乎可以清晰地推测出这个在过往的一段时间内到底发生了哪些事情。

当我们完成MI原型推断以后，每个场景中的Role以及PPT就显而易见了，例如“贷款申请用户（Role）” “签约用户（Role）”，虽然可以是同一个用户，但是在不同的场景下，体现为不同的角色原型。提供征信信息的是“个人征信（Role）”等。进一步分析，我们就清晰地获得了PPT原型，征信中心（Place）、业务员（Party）、信贷账户（Thing）、用户（Party）等，如图所示：


  
业务规则可视化



需求结构化是业务中台建设的开端，解决了需求的结构化描述，形成数字化的需求沉淀。如此以来后续的可变性分析以及领域工程设计和应用工程设计均可以与数字化需求模型一一映射，然后与编码、测试、资产、环境实现完整的映射关系，获得可重用能力的全貌，呈现从需求到部署的全链路跟踪。有了需求结构化，业务中台建设的方法还需要可变性业务的分析与设计，相关的内容将呈现在后续的推文当中，敬请期待。

关于作者：喻吉林 ，数字化金融研究院研究员，长期致力于SOA架构、微服务架构、业务中台架构的设计与实践，拥有多年金融行业IT规划、架构设计与研发经验。


关于EAWorld：微服务，DevOps，数据治理，移动架构原创技术分享。长按二维码关注！