1 、 熟悉需求背景及商业目标：

　　a)   了解清楚项目发起的原因，是为了解决用户的什么问题。

　　b)   当前的解决方案是不是最优的，为什么会这样做。

　　2 、业务模型法：

　　a)  考虑本项目与外部系统的交互，划分系统边界（除了本项目的需求中要求做的事情，其他的都可以是外部系统，本系统和外部系统之间的交互就是系统的边界），。可以参考系统分析说明书。

　　b)  确定测试范围和关注点。系统的边界是测试的重点，特别需要关注边界交互时的数据交互。

　　3 、业务场景法：

　　a) 考虑用例的调用者；考虑每一个用例提供的服务是供哪些外部用例或者系统调用，找出所有的调用者。调用的前提、约束都要考虑。每一个调用都可以考虑成一个大的业务流程。（一般和外部有交互的用例出错的概率比较大，需要重点关注。具体被哪些外部调用，每个产品线都需要自己整理添加。）

　　b) 考虑系统内部各个用例之间的交互（有可能 PD 划分用例的粒度不同，我们暂时考虑用户一次提交并且系统的状态及数据发生变化的功能是一个用例），形成内部业务流程图。需要分析每个用例之间的约束关系、执行条件，组织出各种业务流程图。

　　4 、功能分解法（对每一个 UC ）：

　　1). 业务功能：与用户实际业务直接相关的功能 或细节。

　　2). 辅助功能：辅助完成业务功能的一些功能或者是细节，比如，设置过滤条件。

　　3). 数据约束：功能的细节，主要是用于控制在执行功能时，数据的显示范围、数据之间的关系等。

　　4). 易用性需求：功能的细节，产品中必须提供了，便于功能操作使用的一些细节，比如快捷健就是典型的易用性需求。

　　5). 编辑约束：功能的细节，在功能执行时，对输入数据项目的一些约束性条件，比如只能输入数字。

　　6). 参数需求：功能的细节，在功能中，需要根据参数设置不同，进行不同处理的细节。

　　7). 权限需求：功能的细节，这里的权限是指在功能的执行过程，根据根据不同的权限进行不同处理的，不包括直接限制某个功能的权限。

　　性能约束：功能的细节，执行功能时，必须满足的性能要求，目前基本不涉及（因为无法量化）。