1、前言
一般而言，测试需求分析采用功能分解的形式来处理。经过了系统测试，需求已经得到确认和实现。以此需求和系统功能为基础，进行功能分解，可以将测试需求组织为一个个测试点的形式。这是相当常用的做法。当然有些验收测试并没有安排测试需求分析，以系统测试报告和测试用例加原需求文档为基础，直接“挑选+设计”验收测试用例。
2、角色功能测试需求分析的适用条件
a）开发团队和验收测试团队并不是在相同的体系内协作，典型的分属两家不同的公司。难于保证验收测试团队能完全理解开发团队的需求分析。
b）开发团队的需求分析本身含有老功能及其升级，即开发的不是一个全新的系统。
c）被测系统最终用户分属不同的部门，涉及的部门数量最少达到3个以上。
3、角色功能测试需求分析的要点
a）与各部门建立直接的联系，就不明确的问题可以访问各部门相关人员；
b）不能简单直接地分析角色功能，要把角色功能放到最终用户实际业务中去分析，典型的问题是在XX业务中，A角色要执行XX操作，在XX操作之前，是否有其它角色必须先执行完另外的操作，XX操作要求系统有什么样的功能，可能出错的地方在哪里，业务的敏感点在哪里？比如一个报销系统，普通员工要报销。在报销申报之前没有前提，报销功能可能是填写金额，选择类别和所在项目，类别和所在项目可能存在限制条件。这些限制条件极有可能成为测试的要点。其它角色参与的功能在别处说明，比如申批者，在申批者的申批功能测试需求描述中，就要说明普通员工的申报是其前提条件。
c）角色与角色分开书写，说明当A角色做了什么后，B角色做什么。但是要分开写，相当于写角色的指南。这样可以得到实际角色最大的帮助，最容易说明老功能，最能发掘真正用户关心的要点。
