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

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