需求实例化五步法
包括： 定系统、找用户、问目的、画场景、设功能 这个过程是一步一步把需求进行细化，明确，完整，以及可测的一个过程。
定系统
在定系统时，需要先描述出需求背景。再根据需求背景，结合需求新旧系统的区别，确定系统边界。
这个过程的第一步就是背景描述，这个背景包括：
- 物理实体结构（关系，一对一还是一对多这个属性通常会对软件的非功能属性产生需求）
- 逻辑结构，逻辑部分之间的关系，此时不需要详细的交互。逻辑结构有时是可以省略的。
第二步就是描述出满足需求的新旧系统的区别
第三步就是定系统，定系统定的是承接需求团队的能力边界。在上面分析的需求背景系统中，团队的边界包括哪些。
在描述背景时，需要约束，描述的是问题，而不是解决方案。但是用户一般都是给的解决方案，所以在一开始就要识别出来哪些是用户给的方案，哪些是用户提的需求。例子：
做一套信息管理系统，这个系统中有一个采购流程，最后的审批人是仓库管理员。
仓库管理员提出： 希望在审批采购流程时，可以让采购单可编辑
软件业务员就说：你负责采购单审核，为什么要编辑这个采购单呢？
仓库管理员就提出：如果担心我修改这个采购单，那就提供编辑的同时，把保持按钮给灰掉，禁止保存修改就可以了。
然后业务就回去让开发，去做个需求了。那么这个需求就成了开发人员茶余饭后吐槽的白痴需求了。
为了说明第三点，例子：
作为餐饮行业，用户提出能够网上进行订餐（点单），客人在预定事件到酒店就餐消费。
作为一个餐饮门店，，它的系统边界和作为一个餐饮集团公司总部分析这个需求时系统边界是不一样的。
作为集团公司可能就要包含门店选择这些餐饮门店所不具备的内容。
找用户
这个过程需要通过描述软件未实现的流程，就是此时系统内的软件都没有实现，仅描述在系统中的交互过程。需要注意的是：
- 软件未实现流程
- 需求触发包括：基本都是外部的，或者是定时器（定时器也可以转化为配置触发）
- 交互对象收到交互内容需要明确：可以满足外部交互对象进行分解问题（关键字）
- 中间的等待、同步异步等要素需要体现出来
- 明确结束流程
问目的
需求分为三个层次：
- want: 用户要的是什么
- need: 用户的需要
- win: 满足用户的内在需求
通过一个例子，可以说明这三个层次：
一个小伙来到杂货店买电转，这个老板跟小伙的交流过程：
guy: 我要一个电钻
/上面是want/
—
boss: （店里没有电钻，所以就聊了起来）你要电钻做什么？
guy: 要在墙上打个洞
boss: 墙上打洞做什么？
guy: 要在墙上挂上画
/上面是need/
—
boss: 为什么要在墙上挂画？
guy: 因为墙光秃秃的，显得冷清。我一个人，呆在家里不想这么冷清。
/上面已经识别出了用户的内在需求 win/
上面的例子在真实场景中，存在一个问题，不能通过一直问“为什么”来挖掘用户的内在需求，因为“为什么”存在质疑的含义，所以跟用户打交道还是需要市场人员有技巧的交流。
另外目的分类：
- 业务目的
- 管理目的
- 维护目的 我们需要尽量把所有角度的用户目的都挖掘出来，一般都会包括多个业务目的。找目的需要考虑趋利避害两个方面：
- 趋利：就是希望得到的好处，需要实现的目的
- 避害：为了避免过程中出现的问题，损失，需要实现的目的
最终在问目的步骤需要输出的是每一个业务目的、管理目的或者维护目的的need和want两层，可以通用描述为：
为了达到
最后，问目的的时候，要足够细致，这样后面步骤的画场景才能画的完整。
画场景
在画场景中，我们通过模型图来把每一个需求的前置条件、交互流程、后置达成目标都明确出来。形成可验收的用例。 一般我们可以选择时序图来画场景。过程中，需要对整个流程、参数进行细化，包括完整的三个部分：
- 验收准则
- 接口
- 完整的交互过程
这个画场景的过程还需要把系统在特定场景下的非功能需求挖掘出来。每个非功能指标都是在具体的场景下的。
设功能
通过前面的画场景，得到了用户的不同使用场景，以及具体的使用用例集。现在需要把不同的场景从业务领域提供的功能角度进行一次聚合。 聚合后形成这次需求涉及的功能列表。功能列表可以写成：as-for-do形式，其中do可以是多个场景聚合的内容。 之所以要做这个动作原因目前考虑有两方面，一是，当前的需求可能是对原有功能的增改动作，所以需要维护之前的功能描述文档；二是， 通过聚合梳理出的功能，更能表现业务领域模型，利于后面的软件设计。因此对于列出的功能，需要排优先级进行深度开发，也就是先完成最大价值的功能。 此时还有一个角度是，在没有顺序约束时，我们也可以选择可以决定软件架构骨架的功能进行优先开发。
参考
- 中兴通讯教练组需求实例化教程 – 金泽锋