你好，这里是工行架构，我是任长清。

课程学习到这里，我想你已经了解了如何运用业务架构去构想业务创新，开展需求设计和分析整合机会，那么这一讲，我将带你继续了解如何运用业务架构，编写出一份标准化、结构化、以用例为基础单元的业务需求书。

在业务研发全生命周期流程中，业务需求书作为业务需求的载体，是贯穿业务与技术、连接需求、开发和验收测试的重要纽带。具体来说是这样的：

• 在需求设计阶段，结合对需求内容的逐步澄清确认，完成业务需求书中用例的详细逻辑设计；
• 在需求实现阶段，以业务需求书作为程序设计蓝本，依照其中具体的用例内容开展开发设计；
• 在需求验证阶段，以业务需求书中的用例为依据开展验收测试，验证需求开发的落地实施情况。

我们可以看出，用例方式的业务需求是业务需求书的主要组成部分，在业务需求书起到纽带作用的各个阶段中，用例都承担了关键职责。

正因如此，用例作为贯穿业务研发生命周期的重要信息要素，其划分依据的标准化、编写工艺的标准化、内容的资产化，都将是提升组织级效能的关键因素。粒度的标准化有助于组织级需求资产的管理与积累；编写的工艺提升有助于需求质量提升；内容的资产化有助于业务资产的沉淀与复用。所以，今天这讲，我要向你介绍一种基于业务架构的业务需求书的标准化编写方法。

基于业务架构的业务需求书的标准化编写有什么用？

基于业务架构的业务需求书的标准化编写方法，是一种业务需求的标准化设计和操作方法。这种方法主要是基于业务架构资产来指导需求用例标准化划分，辅助需求用例结构化编写，资产化管理用例内容，从而实现用例划分标准化、编写工艺化和内容资产化，提升组织级业务资产的数字化管理与积累、提升业务需求书的专业化水平质量，最终实现业务研发效能的提升。

你可能会有疑问，为什么业务架构资产可以起到上面所说的关键作用？

一方面，企业级业务架构资产是经过高度抽象的标准化资产，涵盖全领域、全渠道、全产品、全流程，可以从全局视角展示全行能力和资源分布，不论从用例的划分视图、编写工艺还是IT落地指导都可以作为用例标准化准绳的良好选择。

另一方面，用例作为业务架构动态指导IT架构落地的主要媒介，负责将业务架构的变动信息传导至IT架构并最终在系统中开发落地。因此在基于业务架构的业务研发体系中，用例与架构资产是相互依托、相互促进的。

如何实践这套方法？

基于业务架构资产标准化地编写需求用例，可以从用例划分标准化、用例设计工艺化和用例内容资产化三个方面进行实践，接下来我就针对这三个步骤进行详细的介绍。

步骤一：用例划分标准化

如何标准划分用例，识别出的用例还可以保持常态稳定，覆盖企业全部业务场景且不存在重复呢？你需要做两件事，一是确定需求用例的种类，二是确定与之匹配的划分依据。

首先，我们要根据用例编写内容的特征。用例可划分为四个类型，包括业务处理类、查询报表类、接口参数类和其他类。大体如下：

• 业务处理类用例，主要描述银行创造收入的内外部业务办理流程的业务需求，从业务流程、业务规则、输入输出和风险控制等方面全面描述业务需求；
• 查询报表类用例，主要描述查询功能和报表功能相关全流程的业务需求，包括功能入口、查询或导出条件、结果生成方式、输出的内容以及打印等内容，从业务规则、输入输出和风险控制等方面全面描述业务需求；
• 接口参数类用例，主要描述内部系统间交互接口或对外API以及参数设置相关全流程的业务需求，包括调用方式、生效机制、送入参数等内容，需从输入输出和风险控制等方面全面描述业务需求；
• 其他类用例即未包含在上述分类中的业务需求，结合实际情况，包括新增客户触点、控件优化、产品低效退出、数据入湖、数据移行、技术安全优化等内容。

确定了需求用例的种类之后，我们就可以依据业务架构资产开展进一步划分。下面我逐一介绍下这四种用例的标准划分思路和依据。

业务处理类用例通常是能满足某一业务目的的端到端完整业务流程，这与流程模型的三级活动颗粒度正好相当。因此这类用例主要依照流程模型三级活动来划分。同时，在业务需求用例按照物理业务场景进行需求阐述的情况下，用例的划分在三级活动的基础上可以考虑物理场景因客户、产品、渠道、合作方等带来的差异化处理，即按照“活动+客户/产品/渠道/合作方”的原则划分用例。

其次是查询报表类用例，其中的查询类用例主要依照业务架构流程模型的查询类三级活动来划分，同时也可以在三级活动的基础上可以考虑物理场景因客户、产品、渠道、合作方等带来的差异化处理；报表类用例由于在业务上灵活化定制的趋势越加明显，因此建议按照“一事一议”的方式划分用例，例如“一张报表”为一个用例。

接口参数类用例和其他类用例根据企业对参数、接口和其他业务的管理需要，进行用例划分，例如按照“一个接口”“一个参数表”和“一个渠道功能菜单”等原则划分用例。

在标准地划分完需求用例后，就可以开始第二步，用例设计工艺化。

这一步中，我们需要对用例所涵盖的内容进行结构化处理。按照业务架构思维建立用例工艺结构，并在用例相应部分引用架构资产。

具体来说，在创建用例时，用例需要与业务架构资产中的业务领域、活动、客户、产品、渠道、合作方等信息进行关联。在编写用例时，按照四级任务和五级步骤描述用例内部运行的基本流和备选流。对于业务规则，按照四级任务和五级步骤描述，分条编制或引用修订业务规则。同时，如果涉及产品模型，以产品条件为依据分条编制或引用修订业务规则。对于输入和输出，按照业务架构思维，按照实体属性粒度，描述输入和输出。具体引用如下图所示：

在结构化、工艺化地实现用例设计与编写后，就可以进行第三步，用例内容资产化。

基于业务架构进行需求用例标准化划分和用例内容结构化、工艺化编写后，用例便不再只是一张包含人机交互步骤和业务规则的表格，其内容之间也产生了清晰的层次性与逻辑关系。因此，我们可以结合用例与业务架构的映射关系对用例内容进行拆解，将拆解后的内容分别存储于业务架构资产视图下对应的位置，便于用例编写时精准引用存量用例资产，同时也便于伴随业务研发的不断演进，持续完善和积累用例资产。

在用例资产初始积累阶段，需要用户自行创建用例内容，当用例资产积累到一定程度以后就可以实现引用并修订存量来提高效率，在同一个用例中逐步呈现完整的业务处理和变迁过程，将原业务不可见、不易懂的代码级资产转变为业务可见、可懂的用例级资产。

在用例资产积累相对完善阶段，在创建用例时，我们就可以依据用例所关联的用例种类、业务领域、活动、客户、产品、渠道、合作方等信息，检索用例库中的存量用例，将信息匹配一致的存量用例作为底稿，以此为基础开展用例内容设计。

实际案例分享

好了，介绍了详细的步骤方法，我再给你分享一个跨产品、跨版本复用存量用例资产的实际案例，让你体会下这套方法带来的实际效能。

针对相同渠道下的公共规则改造，相关产品逐步迭代推进优化，在业务需求设计和编写过程中，基于业务架构资产定位并引用存量用例资产中已沉淀的公共业务规则描述，可以极大降低对于生产现状业务规则的研究成本。

我们以手机银行渠道上的无障碍类公共规则改造为例，这个改造需要在个人账户和信用卡等业务领域中逐步推广实施。现在的背景是我们已经往期版本中实现了个人存款领域在手机银行渠道签订产品协议流程中的系统读屏功能，相关需求完成移交并实施开发，相关用例也已入库存储。

那么，现在我们要在信用卡领域推广实施手机银行渠道的无障碍功能，要在信用卡还款流程中新增相同功能，需求工作人员在编写用例时就可以通过业务架构资产中的跨领域复用任务，定位库中已有的用例资产，进而直接引用存量用例资产，准确描述功能的实现方式，保证各产品在相同渠道下的业务规则一致，提升研发效率。

课程小结

讲到这里，本节课也就接近尾声了，我再对本节课的要点做一个简单的回顾。

基于业务架构的业务需求书的标准化编写方法是基于业务架构资产来指导需求用例颗粒度划分，辅助需求用例的编写，结构化存储用例资产信息，从而实现用例划分标准化、编写工艺化和内容资产化。

用例划分标准化，一是确定需求用例的种类，二是依据用例的不同种类，结合业务架构资产确定与之匹配的划分。

用例编写工艺化，对用例所涵盖的内容进行结构化处理。按照业务架构思维建立用例工艺结构，在用例相应部分引用架构资产。

用例内容资产化，结合用例与业务架构的对照关系对用例内容进行拆解，将拆解后的内容分别存储于与业务架构资产视图下对应的位置，以便于用例编写时精准引用存量用例资产，同时也便于伴随业务研发的不断演进，持续完善和积累用例资产。

思考题

请结合你的实际工作想一想，如何更高效高质量地完成业务需求书编写呢？使用这套方法试试吧。

如果有什么问题，欢迎在评论区留言，今天的内容就到这里，咱们下期再见。