应用软件系统需求培训材料.ppt

边界决定描象层次，自项向下的方式把系统描述清楚。 灵活使用边界，边界是无形的，大到业务框架，小到一个
业务功能的需求
餐厅管理系统一些场景
顾客网站订餐场景 餐厅顾客就餐场景 仓库进货场景 财务日帐场景
• 引导顾客入座场景 • 吧台申请酒水场景 • 收银员结帐场景
餐厅顾客就餐场景
• 这是一个有效的完 整目标
•对
• 错，已经超出了边 界范围
• 错，同上
• 错 收银员没有找零 的愿望，只是过程 步骤
用例与功能的误区
通过用例来划分子系统、功能模块各功能点 用例是捕获功能性需求的，前提条件是从参与者角度出发
的，用例并不是功能。 功能实际描述的是输入—计算—输出 一、这个事物是什么？（结构） 二、这人事物能做什么？（功能） 三、人们能够用这个事物做什么？（使用）
上级部门或领导 业务负责人岗位 操作员岗位，数据收集
服 务对象 ….
调查
谁负责提供、使用或删除信息？ 谁使用此功能？ 谁对某个特定功能感兴趣？ 在组织中的什么地方使用系统？ 谁负责支持和维护系统？ 系统有哪些外部资源？ 其他还有哪些系统将需要与该系统进行交互？
分析事例
用要求。
功能是孤立，给一个输入，通过计算就可以有一 个固定的输出。
用例描述的是一个系统性的工作，这工作非常明 确地去达成一个特定的目标
用例可以解释为一系列完成一个特定目标的“功 能”的组合，针对不同的应用场景，这些“功能” 体现不同的组合方式
目标与步骤的误区
在实际应用中，对用例使用的另一个误区是混淆目标和完 成目标的步骤。
情况一：顾客通过酒店网站订餐
餐饮订餐系统
登陆网站
顾客
网站
情况二：假定顾客通过电话，由接线生操作订餐 系统订餐，那么接线生才是真正的参与者，而顾 客实际上是订餐电话服务中心的参与者.
订餐系统
电话
顾客
接线生
网站
情况三： 顾客通过酒店订餐电话的自动语音订餐。（参与 者是非人类）
酒店电话 服务中心
获取用例情景
张总，您做开发餐厅系统的目的是什么？ 张总：数据清楚，实时可查，如“红烧肉”买了多少份。
我还想省点人工。我想让系统给我多位来点顾客… 李大姐（财务），你希望系统可以解决什么事？ 李大姐：不要让我每天很晚还要一张一张的单记帐了吧, 我
每天坐在这里就可以看到营业额，材料成本就好
和自底向上两类方法。
业务目标、业务术语
业务目标，就是为什么要做，解决了哪一些 重要的问题，达到什么样的目标与结果
业务术语，就是到相关业务方面的专用名词
的解释，大方面的总体术语，参与者名称的 解释，业务对象与操作的解释，部门间的， 对外的术语等
要求术语表示要全面，准确、统一、唯一性。 需求内容要用术语进行沟通。有二义性或是 不同义的名称也要进行解释说明。一般名称
一个流程达到什么目标？ 流程节点抽象层次 名称表示的准确性、可理解性、一致性 开始、动作、状态、分支、判断、备注、错误提示、结束
房物品帐目不清;帐务算帐太慢了。系统需要解决这些问题 刘经理（大堂）：一到吃饭的时，大堂总是比较乱，没有
的菜也点、菜不能按顺序上等。系统可不可 解决这些问题
获取用例情景
张总，您打算在系统中做些什么事情？ 张总：我想到在睡觉前就看到今天的营业报表; 大厨：月底马上就要给我本月的成本及下个月的预算
• 参与命题 一、超市购物系统——购物者、 收银员、发票座席 二、办公物品管理——部门员工 、用品管理员 三、吧台管理子系统——吧台出 酒水用例
业务场景
用活动图描述如何达到某一个目标所做的事以及执 行的顺序。也就是业务场景，每个节点（活动）完 成一个工作单元
边界
边界决定视界,对有形的事物来说，就是大多数时候可以看 得见的(在什么位置看出什么)。
餐饮管理用例判断
支持信用卡接算业务吗？ 插入客户VIP金卡？ 输入菜名？ 选择做菜方法服务？ 结帐？
• 错,这是一个业务规则 ，限定业务的范围
• 错，这是一个过程步 骤，不是完整的目标
• 错， 同上
• 错，同上
• 对，这是一个有效的 完整目标
用例判断
催菜？ 挂失客户VIP卡？ 退菜？ 张贴出特价菜？ 吃到不卫生的饭菜免单 收银员找零
出给顾客打折，告知收银员或是直接对当前订单设定拆操“进行打拆” 就可以成为一个用例
业务用例的实现（订餐）
订餐
网上订餐
电话订餐
到吧台订餐
餐厅内的订单用例
点菜员
下单 退菜 加菜
收银员
结帐 查阅订单 查看餐厅状态
点菜单发出订单用例
在顾客就餐用例中点菜员只能是业务工人，那就是因为边 界抽象设定就是餐厅系统假设为顾客服务，即以顾客角度 看问题
顾客
点菜员
辅厨
吧台
收银台
要求点菜 要求催菜 要求加菜
餐桌上 要求结账
输单
收到菜单
收到酒水单
查询订单 结帐
练习二
继续练习定义一个边界，画出业务场景（活动图）
• 参考命题 一、购物过程、打印发票 二、员工获取办公品、办公品的采购 三、吧台申请酒水、结帐场景
需求的任务
一、业务目标、概念定义 二、功能性能与扩展要求 三、业务系统的数据要求 四、业务流程与特征要求 五、修正系统开发计划
描述自行车
一、自行车是一种交通工具，它由传动系统、刹车系统等 部分组成(结构)
二、自行车可以骑行、可以载物(功能) 三、人们可以用双脚蹬动踏板向前行进，可以用手捏合刹
车使自行车停下来(使用)
总结用例与功能的区别
功能是脱离使用者的愿望而存在的 用例是描述使用者的愿望，是使用者对系统的使
现在以点菜员的角度看问题，菜单我们改一下名称叫订单， 就是发送订单假设为一个子系统，也就是说边界就是点菜 员输入订单后要厨房照单做菜，再让菜做好传到大堂,也就 是说不考虑顾客的角度，就是为了工作环境的需要。那以 点菜员就成为了这个边界的业务主角，用例如下：
练习一
每人定义一个简单的业务系统名称写出所有的参 与者、业务工人画出二个主要角色用例
对某些调查中的问题，可以找专人询问。
常用的调查方法
⑸设计调查表请用户填写 如果调查表设计得合理，这种方法是很有效，
也很易于为用户接受的。 ⑹查阅工作记录 即查阅与原系统有关的数据记录，包括原始单
据、账簿、报表等。 通过调查了解了用户需求后，还需要进一步分
析和表达用户的需求。 分析和表达用户需求的方法主要包括自顶向下
订餐系统
顾客
自动语音
网站
情况四：扩大系统边界，让酒店电话服务中心成 为订餐管理系统的一个子系统，并且假设顾客户 订餐可以自主选择可通过接线生、自动语音还是 登录网站订餐系统，那么顾客是参与者，而接线 生则变成业务工人
酒店订餐管理系统
订餐电话服务子系统
顾客
电话 登陆网站
自动语音
接线生
WEB子系统
边界描述、业务框架
顾客
仓库
财务部门
酒水吧台
散客
单位顾客
收银台
厨房
大堂
服务中心
餐饮服务业务边界
明确业务目标是为谁服务 边界明确决定了哪些涉众（忽略业务工人）与这一业务目
标利益相关，这些涉众可以提出他们的期望 边界的划分指明了需求分析的起点，推导用例。 边界进一步的深入
写业务流程要注意什么
具体的准备工作
⑴首先调查组织机构情况 包括了解该组织的部门组成情况，各部门的职能等，
为分析信息流程作准备。 ⑵然后调查各部门的业务活动情况 包括了解各个部门输入和使用什么数据，如何加工处
理这些数据，输出什么信息，输出到什么部门，输出结果 的格式是什么。
具体的准备工作
⑶协助用户明确对新系统的各种要求 包括信息要求、处理要求、完全性与完整性要求。 ⑷确定新系统的边界 确定哪些功能由计算机完成或将来准备让计算机完成，
订餐子系统的业务目标
因为现有餐厅业务不够饱和，及顾客意见要求是否 可预订，需要开发网上预订及电话预订服务系统， 以达到提高餐厅销售业绩本系统与方便顾客订餐的 问题.
订单：这里指的是顾客就餐时的菜单（订单的数据 格式！）
电子菜谱：为方例顾客订餐而设定的餐厅服务的菜 名列表（名称分大类、小类两个层次、做法与加码）
用户与开发人员很难进行交流
• 用户的需求是动态变化的 • 系统变更的代价呈非线性增长 • 公司的平台需要向产品化的方向发展
讨论分析一下，个人看法与实现体会
需求分析的要素
参与者
用例
业务场景
查找参与者
参与者：涉众，就是找出那些直接对系统发 出动作，或者直接从系统中接收反馈的涉众； 先从岗位设置入手。
就是什么人可以做什么事（一个用例是参与者对目标系统 的一个愿望，一个完整的事件），通过用例图表现出来
获取用例的准备工作 系统边界
涉众
主角1 主角2
可能的用例
用例获取情景
您对系统有什么期望？ 您打算在系统中做些什么事情？ 您做这件事的目的是什么？ 您做完这件事希望有一个什么样的结果？
哪Fra Baidu bibliotek活动由人工完成。由计算机完成的功能就是新系统应 该实现的功能。
常用的调查方法
⑴跟班作业 通过亲身参加业务工作来了解业务活动的情况。这种方
法可以比较准确地理解用户的需求，但比较耗费时间。 ⑵开调查会
通过与用户座谈来了解业务活动情况及用户需求。座谈 时，参加者之间可以相互启发。 ⑶请专人介绍。 ⑷询问
登陆网站
网站
业务主角
是参与者的一个版型。 是与业务系统有着交互的人和事物，他们用来确认业务范
围。
我是主角 我是谁？
业务主角图示
如果你对获得的业务主角不是很自信，请回答以下问题： 1.业务主角的名称是否是客户的业务业语？ 2.其职责是否在客户的岗位手册里有对应的定义？ 3.其业务用例是否都是客户的业务术语？ 4.客户是否对业务主角能顺序理解？
讲师：贾伟东
适用人群
客户的系统策划、客户平台业务分析管理人员、平 台业务的管理者
开发部门管理者、系统分析师、软件系统设计师、 软件工程师
软件产品部门负责人 网站策划、美工 软件测试部门负责人等
课程内容 （全程案例－餐饮管理系统）
什么是需求？ 需求分析的要素 写需求说明的任务 需求说明书规范
边界决定了当前分析阶段的抽象层次，错误的暴露 会导致（程序）结构的混乱
粒度分析（餐饮中顾客用例）
顾客
订餐 就餐 打折结帐
大堂经理
订单打折 查看订单状态
进行打拆结帐超出边界，结帐包括在就餐用例中，只是一个过程，打 折也不是顾客想做就可以做的事
解决办法就是认定系统边界和抽象层次 如上以”大堂管理”做为边界，就可以是大堂经理为了业务需要主动提
不会也有 我的份吧？
业务工人
参与了业务，他是被动参与业务的，不好说他有什么具体 的目的，但又的确在业务过程中做了事情。
是一个可有可无的，不是参与者，三个原因： 一、不主动向系统发出动作 二、没有完整的业务目标 三、系统不是为他服务的
我不说 话
什么是用例？
用例的定义是由参与者驱动的，并且给参与者提供可观测 的有意义的结果的一系统的活动的集合，参与者对系统的 期望
就餐 顾客
以完整的目标作为用例
以步骤作为用例（不对）
点菜
使用VIP卡
结帐
打印单据
顾客
用例粒度的误区
分不清目标和步骤 粒度过于细小，使得系统分析没有抽象的余地 如果系统达到一定的规模面对几百上千的用例不知你该如
何处理？
用例粒度的误区
同一个需求阶段中用例粒度大小不一，原因是你心 目中没有一个清楚的边界，没有检查现阶级处于哪 个抽象层次而造成的
确保一个明确的有效目标才是一个用例的来源 确保一人真实的目标应当完备地表达主角的期望 一个有效的目标应当在系统边界内，由主角发动，
并具有明确的后果。
以下做一个情景演习
情景演习: 一个需求分析员 一个餐厅老板(财务) 一个大堂经理(大厨)
问题是什么？
看一下吧
获取用例情景
“张总”（餐厅老板）您对系统有什么期望？ 张总：我对收银员不放心，他们可能私拿了我的钱;吧吧库
什么是软件系统需求
就是用户想通过软件系统平台实现、辅助、简化其 工作范围内的业务的要求
一个需求是一个完整独立的规范，要有明确的业务 目标、流程、数据等
“需求分析”是一个过程：指对要解决的问题进行 详细的分析，弄清楚问题的要求，包括需要输入什 么数据，要得到什么结果，最后应输出什么。
为什么要进行需求分析