让我们来看一个简单的用例图吧。
（图1.1 用户新增一个任务）
上面简单的用例图标识出了用户是如何运用系统增加一个新任务的，通过用例图能够将我们的关注点集中到外部参与者与系统的交互上。另外，用例图可以很好的描述用例发生的次序，能够为后期的需求分析提供一些重要的信息。
在本节中我将对系统如何工作进行简要的描述，为后面的系统分析提供清晰的图像。上一小节中例出了系统为实现根据业务人员（用户）指定的任务进行费用催缴工作及客户呼入查询或直接转人工服务而涉及到的10个简单用例。那么在上面的10个用例中系统是如何完成工作的呢？
创建呼出任务
业务人员希望能够通过系统快速的部署一项呼叫任务（对应用例1），要完成此工作用户必须登录到系统，然后新建一个呼叫任务并设置其：
l 要呼出的电话号码列表；
l 任务开始的时间，或许这个任务是周期性的，比如对于欠费客户的催缴任务可能每天都会发生，并需要指定任务呼出的时段。我觉得这个十分有必要，系统不可能为了催缴而在晚上12：00给客户打电话吧，如果这样的话将会引起客户的强烈不满；
l 为任务指定IVR（语音应答交互流程），我们可以考虑这样一个场景：当系统打出电话并接通时，系统可能会首先播放一段提示音“您好这里是……经核实您目前还尚部分费用未缴，按1键收听费用汇总情况，按2键收听本期费用发生情况，按3键收听上期欠费情况，按4键查询指定月份的费用发生情况，按0转人工服务”。
因此，创建呼出任务用例还包括了设置电话号码列表、设置任务调度信息及IVR流程等子任务。如下图所示：
（图1.2 创建呼出任务）
创建呼入IVR流程
有几种情况下客户可能需要拨打“热线”电话，其一、查询费用；其二、了解企业办事流程或相关用水政策；其三、查询申报的工程执行情况；其四、用水报修、报停；其五、水管报漏、报障等或者直接转人工服务。系统在接通客户的电话后将首先播放一段提示音，而后根据用户事先设置好的呼入流程转入相应的模块。为此必须为系统创建呼入的IVR流程。
（图1.3 创建呼入IVR流程）
在呼出的任务创建的用例图中也包括了对IVR流程的设置工作，为什么要单独创建呼入IVR流程的用例呢？可否将其合并为一个用例？！答案是肯定的，但是在此处我并不将其合并在一起，而是任由其存在，因为目前的工作只是让我们对系统有个清晰的了解，重点是识别出系统中的重要用例。
编辑存在的任务
在任务的执行期间，可能因为某种原因需要对存在的任务进行修改，如修改其执行的时间、IVR流程、调整任务优先级或干脆挂起任务。
（图1.4 编辑存在的任务）
当用户挂起一项任务后，应该可以通过类似的方式重新启动这项任务，我们在后面将详细讨论当挂起一项任务或重新启动它时系统是如何响应的。
获取任务报告
业务人员（用户）可能需要对某项任务或整个系统的执行情况进行了解，这时需要从系统中获取报告。
呼入呼出
呼入是由客户因查询、报障等原因发起的一个动作。而呼出则是由系统根据设置好的任务的外呼行为，当接通电话后客户可能会选择直接收听相关信息，那么此时一次外呼动作就此完成，客户只是作为被动信息接收者好像并没有参与到系统的交互，这又该如何用用例图来表示这个会话呢？而对于客户呼入的电话则可以像上面一样为其画出用例图来。
根据如上的分析我们可以了解到在系统运行的过程中将主要有几类参与者，他们分别是：
l 业务人员 根据业务的需要创建呼叫任务，并在随后的时间里需要了解其执行情况；
l 客户 呼出的接收者或呼入的发起者，系统的所有工作将以客户为最终对象，要么为其提供服务，要么发送信息给他们；
l 系统管理人员 这类参与者并不那么明显，主要通过系统状态报告了解系统的运行情况；
l 坐席人员 通过系统为客户提供人工服务。
为此，第一阶段的工作告以段落。主要完成了对系统的功能性方面的定义，粗略的描述了系统将要完成的工作，并对项目资源情况进行了简单的描述，重点对系统中涉及的关键用例进行了阐述。但是我总觉得有些东西在头脑中还是十分模糊，是对系统的功能理解得不够呢？还是对某些用例没有进行深入的分析。或许我们该进入到下一个阶段了吧！我真诚的邀请面向对象分析方面的大牛能够为我提出您宝贵的意见！好啦，欲知LightweightCTI究尽发展向何方，切听下回分解：）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。