UML概要基础知识(待完善)
记录—UML
Written by guppy.version: 0.3
1. 概述
OOA（面向对象分析）为上世纪七十年代末期面向对象运动兴起所诞生，在最初面向对象进入的领域是编程领域，面向对象语言Smalltalk诞生，但软件分析与设计还是以结构化的面向过程方法为主。后面许多面向对象大师创建了自己的面向对象分析方法，随方法不同但理念相通。
有三位面向对象大师决定将其他们各自的方法统一起来，在1995年10月推出了第一个版本，称为“统一方法”（Unified Method 0.8），随后又以“统一建模语言”（Unified Modeling Language）UML 1.0的正式名称提交到OMG（对象管理组织）。
2. 基础元素
2.1 用例
2.1.1 概述
用例（Use Case），由参与者（actor）驱动的，并且给参与者提供可供观察的 有意义的结果的一系列活动的集合。它是一种把现实世界的需求捕获下来的方法。
官方定义：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观察的值。
换句话说，一个用例就是与参与者（actor）交互的，并且给参与者提供可供观察的有意义的结果的一系列活动的集合。而做一件事可以有很多不同的办法和步骤，也可能会遇到各种各样的意外情况，因此这种事情是由很多不同情况的集合构成的，在UML中称之为用例场景，一个场景就是一个用例的实例。
比如说你想做饭，你需要完成煮饭和炒菜两件事情，这两件事情就是两个用例。而煮饭可以有不同的做法，你可以用电饭煲煲饭，也可以用蒸笼做，这就是两个不同的场景，也就是两个实例。而同样用电饭煲做饭，如果是糙米你可能需要先淘米，也是精米你可以省掉淘米的步骤直接下锅，这是用例在不同条件下的不同处理场景。
综上，一个完整的用例由参与者、前置条件、场景、后置条件构成。如下图图2-1：
2.1.2 特征
用例有一系列的特征，这些特征保证用例能够正确地捕捉功能性需求，同时也是判断用例是否正确的依据。
- 用例是相互独立的
这就是说它不需要与其它用例进行交互就能直接完成参与者的目的。
- 用例的执行结果对参与者来说是有意义的和可观察的
比如说，登陆系统是一个有效的用例，但输入密码却不是。登陆系统对参与者来说是有意义的，可以获取身份认证和授权，单纯输入密码却没有任何意义。还有如下图2-2、图2-3，转账是一个有效的用例，而填写收款人账户却不是。
又比如说，有一个后台进程监控系统操作，并在参与者删除数据之前进行备份操作，虽它是系统的一个必须的组成成分，但是在需求阶段它不应该作为用例出现，它是后台进程，对参与者来说是不可观察的。
- 一件事必须由一个参与者发起，不存在没有参与者的用例，也不能主动启动另外的用例
用例是由参与者的愿望所诞生，是希望系统能够为参与者完成某些业务或事情，那么系统的必定需要参与者来驱动。例如从ATM机中取钱是有效的用例，ATM机吐钞票却不是。
高中的时候，我们学过，没有外力影响下，一个物体保持匀速直线运动和静止不动，一个独立无外力影响的系统要么静待命令，要么一直做相同的事，哪怕是定时发送邮件，也需要参与者先为定时模块设定发送时间。因此一个用例不能主动驱动或启动另一个用例。
- 用例必然是由动宾短语的形式组成的
用例必须有一个动作和动作的受体。比如，喝水是一个有效的用例，而“喝”和“水”却不是
- 一个用例就是一个需求单元、分析单元、设计单元、开发单元、测试单元，甚至部署单元
一旦决定了用例，软件开发工作的其他活动都以这个用例为基础，围绕它进行。分析、设计、组织、开发、测试、部署都需要围绕需求单元来进行活动开展。
2.1.3 业务用例
业务用例（business use case）是用例版型中的一种，专门用于需求阶段的业务建模。形状如下图“图213-1 业务用例图”。
本还有两个业务用例的版型，业务用例实现和概念用例，但在EA中没有，就不做绘制了，用处其实都可以用最基本的椭圆来替代，整这么版型倒还需要记概念，不需要这么复杂。
2.1.4 用例粒度
用例的粒度是令人困扰的，比如在ATM机取钱的场景下，取钱、读卡、验证账号、打印回执单，都是可能有的用例，但是取钱这一用例明显包含了后续的这些用例，取钱这一用例明显粒度大于后面这些，其它用例要小一些，那到底是一个大的用例好些还是拆解成几个小用例好些呢？
这里有一些建议，在不同阶段使用不同粒度的用例。
-
在业务建模阶段，用例以每个用例能够说明一件完整的事情为宜，既一个用例描述一项完整的业务流程。
-
在用例分析阶段（概念建模阶段），用例的粒度能够完整的描述一件事情为宜。既一个用例描述一项完整业务的一个步骤。
-
在系统建模阶段，用例视角是面向计算机的，因此用例的粒度以一个用例能够完整描述操作者与计算机的一次完整交互为宜。例如，填写申请单、审核申请单、取消申请单等等。
这些也只是一些建议，可实际根据自身实际情况划分粒度，只要是以该用例是否完成了参与者的某个完整目的为依据的。一切从实际目的（需求）出发。
2.1.5 用例获取
Ⅰ.准备
我们知道用例的来源就是[参与者](# 3.1 参与者)对系统的期望。所以发现用例的前提是发现参与者，而确定参与者的同时就确定了系统边界。因此在捕获用例之前，我们需要涉众分析。涉众具体概念在[3.4小节 涉众](# 3.4 涉众)。
为了便于理解，强调与[业务工人](# 3.3 业务工人)（business worker）的区别，这里将参与者改称”主角“，主角主要有以下几个要求：
- 主角是位于系统边界之外的。
电影中其它配角是为服务主角的。业务工人处于系统之内，是为主角服务的。
- 主角对系统有明确的期望和明确的回报要求。
需求明确，不要东扯西扯有的没得都加上去，要有核心的需求。
- 主角的期望和回报要求在系统边界之外。
期望及回报要求在系统边界之外，这个就是说，原有系统已经能够完整实现了，不需要多此一举再次获取需求。
接下来就可以进行涉众分析了。
Ⅱ.涉众分析
涉众分析大体流程如下图图2-4。
① 初始涉众
首先根据所做项目，发掘出比较容易发现的涉众也就是初始涉众，通常包括客户、管理者和相关投资方。
② 涉众识别
在涉众识别阶段，可以将初始涉众集中在一起，来进行一次头脑风暴，尽可能地列出一个涉众类别列表。列举类别时，要使用能够代表它们特征的名称，便于涉众细分。在得到涉众类别列表后，考虑及判断他们与系统的相关性，找出关键涉众类别。再根据新得出的关键涉众类别，来一次头脑风暴，持续几次，尽可能找出系统所需要的涉众类别。
③ 涉众描述
在上一步的关键涉众类别之上，进行涉众描述，主要描述其特征，这些描述可以帮助我们对涉众类别的理解。在下方一个例子，是自助餐厅在线订餐系统的涉众特征描述：
| 涉众 | 主要目标 | 态度 | 主要关注点 | 约束条件 |
|---|---|---|---|---|
| 公司管理层 | 提高员工生产率；节约自助餐厅的费用 | 强烈承诺完成版本2；如果有条件尽早完成版本3 | 使用该系统所节约的费用必须超过开发和使用此系统的费用 | 无 |
| 自助餐厅工作人员 | 更高效地利用工作人员的工作时间；提高客户满意度 | 担心与工会的关系和可能的裁员，否则很愿意接受新系统 | 保证工作 | 培训工作人员使用订餐系统的技能；需要有外卖员和交通工具 |
| 顾客 | 可以更好地选择食物；节约时间；更加方便 | 因为在自助餐厅和饭店有社交作用，所以积极支持新系统，但使用次数可能没有期望中的那么多 | 使用简单；送货可靠；食物选择要有效 | 需要访问网络 |
| 薪资管理部门 | 得不到什么益处；需要建立从工资中扣除餐费的登记方案 | 不愿意采用该系统，但能够认识到该系统对公司和员工的价值所在 | 尽量减少对当前薪资核算软件所做的变更 | 还没有得到资源来实现薪资软件的变更 |
| 饭店经理 | 增加销售额；扩大市场 | 能够接受，但比较谨慎 | 尽量少用新技术；关注送餐所需的资源和费用 | 可能没有足够的人手和能力来处理订单；需要得到连接网络 |
也可以查看后面的附件关于“类三国杀网游”的粗略的[涉众分析报告](# 4.1 涉众分析报告)，但是由于当时初学还有很多的细节做不到位，也有错误，因此仅供参考。
④ 涉众评估
在经过涉众描述之后，我们可以得到大量关于涉众的信息，这些信息分别描述了涉众某些方面的特征。涉众评估是将这些孤立的描述信息联合起来进行分析，以得到更深层次信息的过程。常见的涉众评估包括，优先级评估、风险评估和共赢评估。
优先级评估：
软件系统的涉众并不是完全平等的，有些涉众比其他涉众更为重要，因此就需要根据涉众的重要性进行优先级评估。
在评估涉众优先级时，可建立如下表格 医务软件的User/Task矩阵来评估：
| 用户群体 | 任务 | 群体数量 | 优先级 |
|---|---|---|---|
| 入院秘书 | 收集病人数据 | 25 | 2 |
| 护士 | 查看体检信息 | 490 | 3 |
| 管理员 | 软件安装与维护 | 12 | 1 |
每个涉众类别都按照自身权重及意向的高低放在一个合适的位置，如下图图2-5，并最终分为四种类型中的一种：
- 参与者
通常是系统的实际使用者，对系统最终成功有比较大的影响力量。
- 环境设定者
很少是系统的直接使用者，受系统影响较小，对系统保持较低关注度，但他们会因为政治、经济或权力等因素而对系统有较大的影响力。如政府力量和管理层是最常见的环境设定者。
- 被影响者
他们有可能是系统的直接使用者，但更有可能是因为系统的出现而被剥夺了部分利益的输家，受系统较大的影响，却没有足够的力量影响系统的决策。
- 观众
不会受系统较大的影响，也没有足够的力量影响系统的决策，所以他们更多以观众的身份参与软件开发。领域砖家和市场力量便是常见的观众。
风险评估：
如果有些涉众在项目中的表现和开发者所预期的不太一致，那么就可能会给项目带来风险，进而导致项目失败。所以为了保证项目成功需要在涉众分析时进行风险评估工作，以控制涉众因素给项目带来的风险。
风险评估需要先分析涉众的态度，建立如下Power/Attitude分布图 图2-6，处于强反对者区域的涉众是需要进行仔细分析的高风险因素。
对于高风险的涉众类别，要尽可能澄清各个涉众类别的角色及职责，分析实际情况与预期不一致时可能出现的风险因素，制定风险的提前化解策略和事后处置措施。
尽可能提高“环境设定者”对系统的关注，将其转化为参与者，另一方面消除反对者的反对原因，将其变为强支持者，此外给予被影响者一些充分发表和实现自身意愿的权力，化解弱反对者的忧虑，也会有利于控制项目因涉众而可能产生的风险。化解涉众风险策略图如下：
共赢评估：
软件系统的不同涉众有不同的立场和利益，因此他们之间对系统的期望难免会发生冲突。为了保证软件系统的最终成功，应该尽可能地解决这些冲突，而且最好是在冲突发生之前能够消除于无形，这就是在涉众分析中进行共赢分析工作的主要目的。
除了涉众之间的需求冲突之外，还会有涉众自身期望与项目整体目标相存在背离和不一致的现象，所以这也是我们将要解决的问题，如何消除涉众期望与项目业务需求之间的冲突。
想要消除冲突，首先就需要找到冲突所在。可以建立Stakeholder/Issue关系图。如下图所示：
需求工程师可以在仔细分析项目的Issue，得出可选方案及约束，并提供给冲突方来进行权衡，促进他们协商解决，并尽可能形成一个共赢的局面。
⑤ 涉众选择
一个成功的项目不仅要很好地发现和理解关键涉众类别，而且还要能够让这些涉众类别在项目中确实起到关键的作用。筛选出合适的涉众类别这里暂时略过，不作过多描述，能够保证在项目中确事起作用便可，如要验证，可采取代表采样。
⑥ 项目参与者
在经过这些步骤后，得出的项目参与者便是最终我们的结果。
Ⅲ.需求获取
当到这个时候，需求获取人员就可以开始对筛选出来的涉众，进行一系列活动来获取用例了，可以以访谈、问卷或者其它形式来进行获取项目需求。
在进行访谈客户时，可选取一名业务代表来进行访问，访谈过程中需要把握节奏，时刻提醒喜欢一谈事情就深入到细节的客户，可以通过制定一些问题来进行引导。这里举一些例子：
- 您对这个系统有什么期望？
- 您打算在这个系统中做什么事情？
- 您做这件事的目的是什么？
- 您希望做完这件事有一个什么样的结果？
记录下该业务代表的访谈结果，从结果中找出用例。
注意：用例不是功能；
在描述事物时常有三种观点描述：
- 这个事物是什么？ 结构
- 这个事物能够做什么？ 功能
- 人们能够用这个事物做什么？ 用例
2.2 边界
边界（Boundary）在上述用例板块中出现过，本质上是面向对象方法的一个重要的概念，和封装的概念同源。面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象打交道，而对象内部则是一个禁区。
边界有以下一些特征：
- 边界决定视界
边界是可大可小的，由建模者主观决定。比方说我们观察并描述一栋建筑物，在正前方观察到的是大门、招牌、楼层等等事物，而在大楼顶上观察却是围栏、烟道、水管等等，当我们处于大厅之中又会观察到凳子、沙发、吊灯之类的事物。
- 边界决定抽象层次
要选择合适的抽象层次来描述事物，比如我们要描述一辆车，一辆车几十万个零部件，如果直接从零件上来描述，那绝对可以把人逼疯的，而如果选择从高抽象层次出发，动力模块、安全模块到方向盘、仪表盘、刹车，再到最后的几十万个零件这样来描述会有一种循序渐进的感觉，也更容易让人接受。因此在合适的地方选择合适的抽象层次，而在UML中，边界控制抽象层次，因此灵活的使用边界对我们理解项目很有帮助。
2.3 包
包（Package）是一种容器，如同文件夹一样，它将某些信息分类，形成逻辑单元。使用包的目的主要是为了整合复杂的信息，某些语义上相关或者某方面具有共同点的信息都可以分包。包的形状如下图图2-3-1所示：
包可以容纳其它UML元素，并为它们分类，如，用例、类图、业务实体、子包等等。
包图举例如下图 图2-3-2用于描述组织架构：
也可以用于描述软件架构层次，如下图 图2-3-3：
2.4 业务实体
业务实体是类的一种版型，特别用于在业务建模阶段建立领域模型。（就不细说了，后面再绘制例子，就是其代表业务角色执行业务用例时所处理或使用的“物”，类似于对象图）
2.5 分析类
分析类是从业务需求向系统设计转变过程中最为主要的元素，官方定义为是用于获取系统中主要的“职责簇”，它们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。常用于时序图，协作图等动态图
2.5.1 边界类
边界类是一种用于描述对系统外部环境与其内部运作之间的交互进行建模的类，这种交互包括转换事件，并记录系统表示方式中的变更。
2.5.2 控制类
控制类用于对一个或几个用例所特有的控制行为进行建模。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kn8crRCf-1616145890027)(C:%5CUsers%5Cgu-ppy%5CAppData%5CRoaming%5CTypora%5Ctypora-user-images%5Cimage-20210123202216637.png)]
2.5.3 实体类
实体类是用于对必须存储的信息和相关行为建模的类。
这三种分析类在此处可以简单理解为MVC，model实体类、view边界类、controller控制类。后面动态图再细讲用法。
2.6 设计类
3. 名词解释
3.1 参与者
参与者（actor）在UML官方文档中对参与者的定义为：actor 是在系统之外与系统交互的某人或某事物。
note：参与者位于系统边界之外，参与者可以非人！
参与者这个叫法很可能迎来歧义，会觉得但凡在业务的或者在业务流程中做事情的都叫参与者。这是一个误解，如果换一个叫法“主角”，可能就好很多。电影中的剧情走向都是围绕主角，配角就类似于业务工人，他们的出现就是为了让主角完成业务目标。
3.2 业务主角
业务主角（business actor）是参与者的一个版型，特别用于定义业务的参与者，在需求阶段使用。
note：业务主角的特殊性在于，他针对的是业务人员而非计算机用户。在查找业务主角时必须抛开计算机，没有计算机系统这些业务人员也客观存在。
其常用于建立业务模型、查找业务用例。很多需求分析人员是由程序员或设计师担任，由于有开发计算机系统的背景，使得他们建立的业务模型时常容易犯一个错误，喜欢从计算机系统的角度来思考问题，在向客户收集需求的时候总第一时间想到如何实现，常常津津乐道与客户谈论计算机系统将如何实现客户的需求，并指望客户能够用这种方式来确定需求。这会导致如下后果：
客户不理解将来计算机实现是个什么样子，但出于信任，将信将疑的回答：Yes，就是这样做。而结果在计算机系统真正展现在客户面前时，客户大声说：No，这不是我想的。
需求分析人员一开始就加入了自己的主观判断，假设了业务在计算机系统里的实现方式，而没有去理解客户实际业务。其结果是当计算机系统完成之后，客户抱怨：No，流程不对；开发人员：我是按照需求来做的啊。
3.3 业务工人
业务工人（business worker），在下图图3-1中，人工坐席处于机票预订系统这个系统边界之内，则此时为业务工人。当然这个没有绝对，当观察视角转换，人工座席处于Web子系统的外面时，人工座席则又可以处于业务主角，这跟你自己设定的抽象层次有关。
3.4 涉众
涉众（stakeholder），也称干系人。涉众是与要建设的这个系统有利益相关的一切人和事，涉众的利益要求会影响系统的建设。比如，投资方，系统使用用户，假如一个系统的建设是由一家风险投资机构投资的，有时系统必须满足投资方的一些特殊要求，作为涉众，投资方的意见或许会构成一些约束。但投资方并不参与系统建设，它只是从资本上拥有这个系统从将来的收入中获得回报。
3.5 用户及角色
用户（user）：是指系统的使用者，俗话说就是系统的操作员。
角色（role）：其是参与者的职责。角色是一个抽象的概念，从众多参与者的指责中抽象出相同的那一部分，将其形成一个叫角色。如商城系统中买家与卖家就属于两个就角色，卖家有相应的上架商品的职责（权限），买家可以购买商品的职责（权限）。
4. 附件
4.1 涉众分析报告
一、业务目标：
-
本游戏是基于原三国kill单机版所开发的现代网络卡牌游戏，在游戏有着与传统纸牌游戏的基本功能，也有着当代网络游戏的交友，自由交易等功能，是一款极易入手的卡牌网游，当然本游戏旨于为现代社会日益操劳的人们而带来娱乐，而且让人们感受到纸牌游戏无穷魅力。
-
为了方便游戏活动的开展，吸引玩家消费，对以往游戏流水查阅、分析，由此需要为财务部开发相应的流水查询板块。
-
为了解答玩家的一系列疑问及查询，由此引入了客服系统，同时相应的玩家享受不同的客服服务。
二、涉众概要
| 编号 | 涉众名称 | 涉众说明 | 期望 |
|---|---|---|---|
| SG001 | VIP玩家 | 普通玩家在充值一定数额CNY后，自动升级为VIP玩家，VIP玩家可以获得普通玩家没有的经验/金币加成及道具奖励 | ① 享受专属账号申述服务（每天可免费获取稀有道具，经验/金币加成） ② 体验三国杀的所有游戏功能 |
| SG002 | 普通玩家 | 没有对游戏进行充值的玩家 | ① 体验三国杀的大部分游戏功能 |
| SG003 | 运维部门 | 在游戏发布后，对游戏进行运行维护升级的部门 | ① 原软件代码可读性强，易于 ② 软件鲁棒性强，不易出错 ③ |
| SG004 | 财务部门 | 设定充值通道，管理资金流水，并对资金进行汇报总结的部门 | ① 通过计算机自动统计各类财务并打印财务报表 ② 并有良好的图形界面易于观察盈亏 |
| SG005 | 客服部门 | 对玩家的要求、问题及咨询提供解答和解决服务 | ① 界面操作简单 ② 有详细的游戏文档给客服了解，以便解决玩家问题 |
三、涉众简档
| 涉众 | SG001用户 |
|---|---|
| 涉众代表 | XXX普通中学生用户小明 |
| 特点 | 系统的预期使用者，不可预计计算机应用水平使用者，及使用者的年龄 |
| 职责 | ① 向游戏运营商注册账号 ② 在游戏中可以选择充值方式并充值虚拟币或购买其它服务 ③ 向游戏运营商申请查询充值记录，业务办理，虚拟币消费情况等要求 |
| 成功标准 | ① 按要求准确填写注册信息 ② 符合服务要求用户 |
| 参与 | 不参与系统建设 |
| 可交付工件 | 无 |
| 意见/问题 | ① 充值兑换比例大一些 ② 服务更多一些 |
| 涉众 | SG003用户 |
|---|---|
| 涉众代表 | XXX运维组常组长、 |
| 特点 | 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 |
| 职责 | ① 处理系统运行时发生的错误并记录 ② 更新系统并更改bug |
| 成功标准 | ① 按要求完成系统建设任务 ② 系统能完成需求文档的要求 |
| 参与 | 参与系统后期运维 |
| 可交付工件 | ① 《维护纪录》 ② 《版本更新内容》 ③ 《缺陷报告》 |
| 意见/问题 | ① 望开发组的程序能具有鲁棒性 |
| 涉众 | SG004用户 |
|---|---|
| 涉众代表 | XXX财务处刘处长、 |
| 特点 | 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 |
| 职责 | ① 负责财务分析及报告 ② 通过财务报告来为运维组提供运营思路 ③ 汇报盈亏 |
| 成功标准 | ① 按要求使用系统 ② 仔细分析财务 ③ 定期汇报财务 |
| 参与 | 系统使用者；参与运营活动可行性分析 |
| 可交付工件 | ① 《财务报告》 ② 《财务分析》 |
| 意见/问题 | 望操作界面良好，易于分析 |
| 涉众 | SG005用户 |
|---|---|
| 涉众代表 | 客服组组长小林 |
| 特点 | 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄，可培训 |
| 职责 | ① 给玩家提供解决问题，同时提供咨询服务 ② 撰写玩家问题总集 |
| 成功标准 | ① 根据讲解，玩家能清晰了解问题 |
| 参与 | 不参与系统建设 |
| 可交付工件 | 《FAQ》 |
| 意见/问题 | ① 操作界面待改良 ② 减轻工作量 |
四、用户概要
| 编号 | 用户名称 | 用户概况和特点 | 使用系统方式 | 代表涉众 |
|---|---|---|---|---|
| US001 | VIP用户 | 在游戏中进行充值到相应金额的游戏玩家 | 在自己的手机上运行三国杀客户端 | SG001 |
| US002 | VIP用户客服· | 在游戏对VIP用户进行对点服务的人员 | 远行与游戏相应的内部管理版本 | SG005 |
| US003 | 普通玩家 | 在游戏中进行未充值到相应金额的游戏玩家 | 在自己的手机上运行三国杀客户端。 | SG002 |
| US004 | 普通玩家客服 | 在游戏中对不是VIP玩家群体进行·服务的人员 | 远行与游戏相应的内部管理版本 | SG005 |
| US005 | 财务人员 | 管理游戏收益的人员 | 运行相应的游戏充值管理系统 | SG004 |
| US006 | 运维人员 | 管理游戏系统正常运行与耿欣维护的人员 | 远行游戏的开发板 | SG003 |
五、用户简档
| 用户 | US001VIP用户 |
|---|---|
| 用户代表 | 大学生皮XX |
| 特点 | 系统的预期使用者，不参与系统建设 |
| 说明 | 在游戏中进行相应充值的少量游戏玩家 |
| 职责 | 1.注册账号，登录游戏 2.遵守相应的法律法规 |
| 成功标准 | 正确注册账号并登录游戏 |
| 参与 | 需求获取 |
| 可交付工件 | 略· |
| 意见/问题 | 在游戏中需要有非常大的亮点 |
| 用户 | US002 VIP用户客服 |
|---|---|
| 用户代表 | 专用客服皮XX |
| 特点 | 对游戏进行相应金额的充值的玩家进行点对点的游戏服务· |
| 说明 | 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 |
| 职责 | 1.使游戏中高充值群体享受到高级服务 2…正确维护游戏秩序 |
| 成功标准 | 让VIP玩家获得高级服务 |
| 参与 | 需求获取，需求分析 |
| 可交付工件 | 《工作汇报》 |
| 意见/问题 | 略 |
| 用户 | US003普通用户 |
|---|---|
| 用户代表 | 大学生皮XX |
| 特点 | 在游戏未充值到相应金额的玩家，但数量庞大 |
| 说明 | 系统的预期使用者，不参与系统建设 |
| 职责 | 1.注册账号，登录游戏 2.遵守相应的法律法规 |
| 成功标准 | 正确注册账号并登录游戏 |
| 参与 | 需求获取 |
| 可交付工件 | 略· |
| 意见/问题 | 游戏尽量有比较好玩创新的玩法 |
| 用户 | US004普通玩家客服 |
|---|---|
| 用户代表 | 客服皮XX |
| 特点 | 对游戏中充值金额未到一定数量的玩家进行游戏服务 |
| 说明 | 系统的预期使用者，可预计计算机应用水平使用者，及使用者的年龄 |
| 职责 | 1.保证游戏内大多玩家的体验感， 2.及时把大部分玩家对游戏的期待反馈于项目组，并维护游戏秩序 |
| 成功标准 | 使多数玩家感受到游戏的可玩性及对游戏玩家的诚意 |
| 参与 | 需求获取、需求分析 |
| 可交付工件 | 《工作汇报》 |
| 意见/问题 | 略 |
六、消费者统计
| 消费者名称 | 消费者概况和特点 | 应用环境 | 使用频率 | 特殊要求 |
|---|---|---|---|---|
| 游戏玩家 | 游戏面向群体广泛，无法衡量其计算机水平，无法培训，在年龄段15-30之间用户占大部分，且男性玩家多，潜在玩家估计共100万，预计有15万人玩家。 | Android手机 iPhone手机 | 账号注册频率初始预计较高，在用户数量趋于稳定后注册频率显著降低， 登录服务，高峰期按10万用户计算，瞬时在线及登录人数达3万。 | 由于玩家的消费水平不同，应将不同玩家能体验功能详细描述给玩家， |
| 财务处 | 面向运营公司的财务人员，应对财务人员进行培训使用该系统 | 财务处使用该系统时，预计在周一到周五，一般为一周几十次； | 若有良好的图形界面供财务分析人员分析，可大幅提高分析效率及准确性 | |
| 客服 | 面对玩家的咨询问题，进行相应的解决和讲解 | 电话及网站 | 根据以往经验得出，每日咨询人次为200；一般咨询的高峰期为下午，傍晚及中午，瞬时峰值大约15人次，可根据常见问题解答分流出一部分玩家，剩余玩家再让客服介入，其瞬时峰值大约3-5人。 | 让客服提供优质的服务，所以客服的操作方式应有快捷操作方式，提高客服解决玩家的速率 |
家估计共100万，预计有15万人玩家。 | Android手机 iPhone手机 | 账号注册频率初始预计较高，在用户数量趋于稳定后注册频率显著降低， 登录服务，高峰期按10万用户计算，瞬时在线及登录人数达3万。 | 由于玩家的消费水平不同，应将不同玩家能体验功能详细描述给玩家， |
| 财务处 | 面向运营公司的财务人员，应对财务人员进行培训使用该系统 | | 财务处使用该系统时，预计在周一到周五，一般为一周几十次； | 若有良好的图形界面供财务分析人员分析，可大幅提高分析效率及准确性 |
| 客服 | 面对玩家的咨询问题，进行相应的解决和讲解 | 电话及网站 | 根据以往经验得出，每日咨询人次为200；一般咨询的高峰期为下午，傍晚及中午，瞬时峰值大约15人次，可根据常见问题解答分流出一部分玩家，剩余玩家再让客服介入，其瞬时峰值大约3-5人。 | 让客服提供优质的服务，所以客服的操作方式应有快捷操作方式，提高客服解决玩家的速率 |