在进行系统需求分析之前对当前项目进行清晰的定义是十分必要的，也就是需要对项目范围作进一步的描述。
为此，我与部门内的另外一位同事及业务部门的负责人进行了简短了沟通，参与此次讨论的人员有：
我 作为系统分析人员；
阿清 部门内的另外一位同事，他将主要负责对项目的相关需求的细化工作及相关资源的协调工作；
阿平 业务部门具体业务的负责人，将由她提出系统的个体业务需求。
此处我将企业决策者给忽略了，首先，从前期我提到的项目范围我们可以了解到系统的主要功能将是集中在业务的处理上面，而不是对相关工作的反映上，如果在后期需要对系统的运行情况或工作执行情况进行反映，可以创建一份报表来完成此工作；另外，作为企业领导的话，我认为只要其充分了解项目能够达到的目的（在本项目中只要让其知道利用此系统可以打出、打入电话，能够把以前由人工需要半个月甚至1个月才能完成的工作在3～5天就可以完成）。在此基础上能够为项目的持续推进提供资源上的保证就可以了。
在我们的讨论中阿平指出目前我们的呼出程序只能打出固定的电话号码，催缴的范围相对于业务来说不够灵活，比如说在每月银行扣款后对于那些扣款不成功的客户就需要及时通知其进行处理（视帐户余额不足、帐户有误、挂失、冻结等情况不同）；在某个时候可能需要就公司的相关服务或政策征询客户的意见，此时需要能够从系统中选取部分有代表性的客户，通知其前往公司开会讨论并对客户在接到电话后是否前来进行统计；对于已经进行一定次数催缴且其又没有前来缴费的客户需要通知他公司对此会作停水或拆表处理等。
像许多这样的场景如何进行记录呢？首先我想到的是需求卡片，但是发现使用需求用于与业务人员进行交流时存在一些问题。如对于同一问题的描述可能由于出发点不同可能会有不同的结果，容易引起歧义。我想到了用例图（Use Case），用例是在应用软件开发中获取用户高层次功能需求的一种方法，用例方法最早是由Iva Jackboson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。在使用用例进行需求获取之前，我有必要对进行进行简单的了解J。经过一番讨论后我们确定了以下用例：
1、 用户设置需要呼出的电话号码列表，时间和接通后需要播放的文本（我们在前期准备通过TTS来播放相关内容，而不采用录音文件），并启动此任务；
2、 用户为打入的电话设置IVR流程菜单及每组按键的应答信息；
3、 用户修改一项任务的电话列表或呼出时间设置；
4、 用户暂停一项任务的执行；
5、 用户希望获取一项任务的执行情况的详细报告；
6、 系统拨出电话，被叫无人接听、忙或号码不存在；
7、 系统拨出电话，被叫接听电话后播放指定的文本/录音；
8、 系统拨出电话，被叫接听录音后输入IVR进行查询或直接转人工服务；
9、 用户拨入电话，系统空闲的话接通用户并转入IVR流程或直接转人工服务；
10、用户拨入电话，系统无空闲提示用户等待并播放音乐；
经过整理我们得到了如上10个简单的用例，它可能并不能够完全覆盖系统将要完成的所有功能，但是我已经很满足了通过用例我能够更清晰的了解到系统将要完成的工作。在用例中只是描述外部参加者与系统的交互或要求系统完成的工作，而并不会阐述系统内部之间的交互过程，这是大多数初使用用例进行需求收集工作人员容易犯的一个错误，当然，我也一样。在进行用例分析的时候我总是要努力克服自己想进行系统结构、对象之间交互设计的诱惑，尽管我是多少的想提前进入到下一个阶段，以往的经验告诉我这是一个不好的习惯。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。