引言

之前在看一些需求建模的文章或者书籍时，常常看到用例分析法，根据用例里的主谓宾来构建模型、模型的方法以及模型之间的关系等。但是在工作中遇到的一个问题是拿到的需求往往只有一份PRD，只是对于需求的功能进行了简单的描叙，那如何才能对PRD或者需求进行分解，得到用例或者模型与业务规则呢？之前参加一个培训里，谈到了一些需求分析的常用方法，例如事件风暴、实例化需求、用例分析、用户故事地图、影响地图、用户旅程地图。在网上简单了解了一下几个方法，发现实例化需求的可实践价值挺高的，于是对实例化需求做个简单梳理。

实例化需求简介

顾名思义，实例化需求就是通过一个个业务的实例case来对需求进行澄清与说明，这些业务实例case也就是业务的规则，可以被用来作为自动化测试的用例，对系统进行自动化的验证以及活文档进行使用。

之所以认为实例化需求可实践价值高主要基于以下两点：

1. 事件风暴、用户故事地图等方法更加适合团队协作来对需求进行分析与拆解，实例化需求当然也是团队分析方法，但是也可以用来个人对于需求进行分析，并且日常会议（例如电话会议）来使用也比较方便。

2. 实例化需求可以作为活文档来使用，系统功能的显示化对于系统的维护与交接非常重要，而在团队中又很难实现。

实例化需求步骤

实例化需求的步骤重要分为目标、流程、规则三步。

目标：目标是对于业务目标达成一致，可以通过质疑目标的价值（不做会怎样）与可替代方法来进行。

操作流程：最关键的操作流程，MECE中最难的是如何做到不遗漏，个人认为这需要一些经验的积累，例如之前在工作中会把支付相关的业务流程与特殊点都整理成xmind，当有新需求来时会去对照之前的xmind去看看有没有一些场景遗漏的。不过对于没有积累过的场景可以通过PRD描述出发，通过梳理流程图来思考与完善，以及与业务方进行讨论，来逐步完善操作流程。通过流程就可以大致得到系统的用例（可以通过UML用例图或者xmind来标识），以及通过时序图或者流程图来描述业务流程。

业务规则：业务规则是对于操作流程中的节点进行业务规则的描述，最终形成的一条条描述准确的，无歧义的业务case。

在实施过程中流程基本为：了解/介绍背景 => 理清目标 => 列用户操作 => 画流程图 => 列业务规则

对于个人使用来说，经过了这些步骤后，基本就可以理清一个需求中的用例，至少有了可以进行需求建模的原材料，可以帮助梳理领域模型。