需求分析案例.pptx

上传人:p** 文档编号:273541 上传时间:2023-04-25 格式:PPTX 页数:55 大小:1.19MB
下载 相关 举报
需求分析案例.pptx_第1页
第1页 / 共55页
需求分析案例.pptx_第2页
第2页 / 共55页
需求分析案例.pptx_第3页
第3页 / 共55页
需求分析案例.pptx_第4页
第4页 / 共55页
需求分析案例.pptx_第5页
第5页 / 共55页
需求分析案例.pptx_第6页
第6页 / 共55页
需求分析案例.pptx_第7页
第7页 / 共55页
需求分析案例.pptx_第8页
第8页 / 共55页
需求分析案例.pptx_第9页
第9页 / 共55页
需求分析案例.pptx_第10页
第10页 / 共55页
亲,该文档总共55页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

《需求分析案例.pptx》由会员分享,可在线阅读,更多相关《需求分析案例.pptx(55页珍藏版)》请在第壹文秘上搜索。

1、3-3需求分析案例第一阶段:理清业务与流程需求分析案例第二阶段:确定需求细节“Android点餐系统”项目案例需求获取资料介绍如下:(1)目标和范围 本软件主要作用是为点餐者提供一套可以在移动设备(手机、平板)上运行的点餐软件。系统分为前台和后台,前台是点餐者使用的,点餐者可以在移动设备上查看餐馆所有的菜目、价格、简单的菜品介绍以及餐馆的特色菜介绍,同时点餐者还可以查看、取消自己已经挑选的菜品,最后上传订单。后台是管理员使用的,管理员可以在后进行订单管理、用户管理、菜谱管理等。 (2)系统角色和职责 系统的使用人群包括两类,一类是普通的用户,另一类是管理员(经过培训或是专业人员)。 管理员:系

2、统的维护,订单管理、菜品的增删。 普通用户:注册账号,点餐、座位预订。“Android点餐系统”项目案例需求获取资料介绍如下:序序号号功能要求功能要求需求说明需求说明1查询菜品用户可以查看菜品的基本介绍,包括简单的材料和烧制过程。户可以查看菜品的价格、剩余数量、图片等。户可以查看当日的特色菜和特价菜推荐。2设置菜品管理员可以不断更新维护菜品信息,修改菜品价格,删除不再供应的菜品, 菜品信息里包括菜名、菜的简单介绍、图片、价格、数量、分类等。3顾客下单用户可以查看所有菜品,选择菜品及数量后下单,如果选择在餐厅用餐,还可以提前预订座位。4订单处理管理员可以查看到用户的订单情况,通过修改订单状态对订

3、单进行处理,表示订单是否完成,对恶意订单或已经取消的订单可以进行删除。用户可以查看自己的订单,如果订单的状态是未完成,用户可以修改或取消自己的订单。5数据处理管理员可以定期将数据备份到本地,遇到数据库故障时可以恢复数据库,打印数据库相关数据。(3)系统处理功能要求见下表。“Android点餐系统”项目案例需求获取资料介绍如下:(4)系统其他要求 本系统客户端要求符合大众操作习惯,与网上其他的Android系统App操作方式保持基本一致。餐馆要求每笔订单交易误差不得超过1角,每天交易额的误差不得超过100元。5年内价位在500元以上的Android手机都可以流畅运行该系统。“Android点餐系

4、统”项目案例需求获取资料介绍如下:3-3需求分析案例以Android点餐系统为例。第一阶段:理清业务与流程一、业务流程分析1. 1. 业业务务流流程程分分析析一是理解流程的层次性;二是了解流程的类型;三是掌握以业务事件识别、寻找流程的技巧。基于Android平台的点餐系统的总体流程包括的步骤有:(1)顾客在智能手机上登录点餐系统客户端后,自动进入菜谱界面,查看菜谱; (2)顾客选择菜品进行下单;(3)顾客选择菜品数量,若需在餐厅用餐还需选择座位号;(4)选择完成并确定后,提交订单; (5)订单提交后,订单数据会上传到服务器;(6)订单提交后,顾客可以在客户端查看自己的订单情况;(7)在管理员未

5、确认订单之前,顾客可以对订单进行修改或取消操作;(8)管理员登录点餐系统服务器端,对用户订单进行确认;一、业务流程分析2. 跨跨职责职责流程流程图应图应用用具体来说,我们应该先找到业务事件的负责人,然后通过设问的方式,让他描述响应该业务事件所进行的活动,说明活动的执行岗位以及它们之间的关系、数据传递。一、业务流程分析3 3. . 活活动动图图应应用用 活动图是一种表述过程机理、业务过程以及工作流的技术。本系统的下单活动图可以参看右图。一、业务流程分析4.4.数数据据流流程程图图应应用用客户端数据流程图服务器端数据流程图二、业务实体分析1 1业务业务实体分析实体分析任务概述任务概述业务实体分析的

6、产物有两种可选的模型,包括类图和E/R模型也叫实体关系图。二、业务实体分析2 2. .类类图图1)领域建模方法领域建模时,其工作主要就是识别标识类、明确类之间的逻辑关系和数量关系以及添加重要的结构规则三个方面。二、业务实体分析2 2. .类类图图使用名词分析法发现类和对象。1用例描述:用例描述:1. 经理经理开始制定开始制定促销策略促销策略2. 经理经理制定制定促销策略促销策略3. 系统系统返回当前返回当前促销策略促销策略经理重复步骤经理重复步骤2-3,直至制定,直至制定所有促销策略所有促销策略4. 经理经理结束制定结束制定促销策略促销策略5. 系统系统返回当前返回当前促销策略促销策略确定对象

7、:确定对象:经理,促销策略经理,促销策略概念类:概念类:经理,促销策略经理,促销策略二、业务实体分析2 2. .类类图图2用例描述:用例描述:1. 经理经理查看查看预约预约2. 系统系统返回返回预约列预约列表表确定对象:确定对象:经理,预约,预约列表经理,预约,预约列表概念类:概念类:经理,预约,预约经理,预约,预约列表列表摒弃对象:3用例描述:1. 经理查看取号2. 系统返回取号列表确定对象:经理,取号,取号列表概念类:经理,取号,取号列表摒弃对象:4用例描述:1. 经理查看订单2. 系统返回订单列表确定对象:经理,订单,订单列表概念类:经理,订单,订单列表二、业务实体分析2 2. .类类图

8、图5用例描述:用例描述:1. 顾客顾客请求请求预约预约2. 系统系统向向经理经理发送发送预约预约请求请求3. 经理经理处理处理预约预约请求请求4. 系统系统提醒提醒经理经理处理成功处理成功5. 系统系统返回返回顾客预约顾客预约信息信息确定对象:确定对象:顾客,预约,顾客,预约,经理经理概念类:概念类:顾客,预约,顾客,预约,经理经理摒弃对象:6用例描述:1. 顾客请求取号2. 系统向经理发送取号请求3. 经理处理取号请求4. 系统提醒经理处理成功5. 系统返回顾客取号信息确定对象:顾客,取号,经理概念类:顾客,取号,经理二、业务实体分析2 2. .类类图图7用例描述:用例描述:1. 顾客顾客请

9、求请求下单下单2. 系统系统返回返回促销策略促销策略3. 顾客顾客填写填写订单订单4. 系统系统向向经理经理发送发送下单下单请求请求5. 经理经理处理处理下单下单请求请求6. 系统系统提醒提醒经理经理处理成功处理成功7. 系统系统返回返回顾客订单顾客订单信息信息确定对象:确定对象:顾客,下单,促销策略,顾客,下单,促销策略,订单,经理订单,经理概念类:概念类:顾客,下单,促顾客,下单,促销策略,订单,销策略,订单,经理经理摒弃对象:8用例描述:1. 顾客请求支付2. 系统向经理发送支付请求3. 经理处理支付请求4. 系统提示顾客可以支付5. 顾客支付6. 系统提示经理顾客支付7. 经理回应支付

10、8. 系统提示顾客支付结果9. 系统提示经理支付结果确定对象:顾客,支付,经理 概念类:顾客,支付,经理二、业务实体分析2 2. .类类图图9用例描述:用例描述:1. 顾客顾客发表发表评论评论2. 系统系统返回返回评论列表评论列表确定对象:确定对象:顾客,评论,顾客,评论,评论列表评论列表概念类:概念类:顾客,评论,顾客,评论,评论列表评论列表最终发现的所有概念类如下:经理,顾客,促销策略,预约,预约表,取号,取号表,支付,下单,订单,订单信息列表,评论,评论列表二、业务实体分析2 2. .类类图图2)建立类之间的关联二、业务实体分析2 2. .类类图图3)添加类的重要属性二、业务实体分析2

11、2. .类类图图分析模型中有3种十分有用的构造型即实体类、控制类和边界类。实体类即实体对象的抽象;控制类即控制对象的抽象;边界类即边界对象的抽象。二、业务实体分析3 3. . E/RE/R图图应应用用基基础础概念模型和逻辑模型有什么区别呢?它们实际上是对“需求视图”与“开发视图”的区分。换句话说,概念模型是需求人员的视图,等价于现在出镜率很高的领域模型;而逻辑模型是开发人员(包括设计人员)的视图,它约等于面向对象分析与设计方法中提到的“分析模型”。三、角色与使用场景分析在传统的结构化分析与设计方法中,整个分析视角是站在解决方案域的,很容易产生对问题域分析不足的结果。用例分析技术的关键是“发现使

12、用系统的角色(参与者),了解并梳理这些角色将如何使用系统(场景)”,从而更好地完成“人”的视角的需求梳理。三、角色与使用场景分析1. 参与者参与者是在系统之外,透过系统边界与系统进行有意义交互的任何事物。本例中参与者包括 :普通用户与管理员。三、角色与使用场景分析2. 用例实例与用例用例实例(即场景)是在系统中执行的一系列动作,这些动作将生成特定执行者可见的价值结果,一个用例定义一组用例实例。用例是对一组用例实例(场景)的抽象,也就是说,用例是有路径(基本事件流、扩展事件流、子事件流等)的。一个场景是一个具体的行为,一个用例是对一类相关行为的抽象。 三、角色与使用场景分析3. 参与者与用例之间

13、的关系、用例与用例之间的关系、参与者与参与者的关系参与者与用例的关系体现在一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。用例之间的关系有包含、扩展和泛化。参与者之间的关系只有一种,那就是泛化。三、角色与使用场景分析事半功倍的问题:你平时都做什么?(参与者目标)这件事是谁交办的 ?做完了你需要通知或传达给认证吗?做这件事情你都需要填写些什么表格吗?三、角色与使用场景分析示例:边界确定(去除非End User的职责带区)确定角色(对剩下的职责带区进行角色化) 确定用例三、角色与使用场景分析示例:边界确定确定角色确定用例主要参与者主要参与者用例用例普通用户普通用户1.普通用户注册普通

14、用户注册2.普通用户登录普通用户登录3.用户修改密码用户修改密码4.查看菜谱查看菜谱5.点餐下单点餐下单6.查看特色菜推荐信息查看特色菜推荐信息7.查看订单信息查看订单信息管理员管理员1.管理员登录管理员登录2.菜品信息管理菜品信息管理3.用户信息管理用户信息管理4.订单管理订单管理5.特色菜信息管理特色菜信息管理6.数据库维护数据库维护三、角色与使用场景分析 菜品信息管理用例,它的参与者是管理员,用例是菜品信息管理,菜品信息管理用例包含查看菜品信息、添加菜品、删除菜品、修改菜品信息四个子用例,菜品信息管理是抽象出的一个基用例,是为了简化用例的描述。三、角色与使用场景分析4用例分析技术应用要点

15、在上面用例分析的基础上,来讨论一下用例分析的几个技术应用要点。(1)用例真的有粒度吗?(2)用业务动词命名用例十分重要。(3)采用先事后人的方式分析是要点。四、第一阶段产物1工作任务说明以为某餐饮公司开发的Android点餐系统为例,详细介绍该项目的第一阶段分析情况。在需求分析的第一阶段,核心任务就是结合业务流程、报表的需求,梳理出结构框架和行为脉络,为第二阶段的需求分析工作建立基础,指出方向。四、第一阶段产物1工作任务说明领域模型和用例模型:管理员主要负责系统的维护,订单管理、菜品的增删。希望通过这样一个系统能够吸引顾客,同时希望减少人力成本,获得更高的效率和收益。普通用户主要使用这个系统来

16、实现注册账号,点餐、座位预订,节约时间。四、第一阶段产物2业务事件分析“Android点餐系统”的总体业务流程包括如下步骤:(1)顾客在智能手机上登录点餐系统客户端后,自动进入菜谱界面,查看菜谱; (2)顾客选择菜品进行下单;(3)顾客选择菜品数量,若需在餐厅用餐还需选择座位号;(4)选择完成并确定后,提交订单; (5)订单提交后,订单数据会上传到服务器;(6)订单提交后,顾客可以在客户端查看自己的订单情况;(7)在管理员未确认订单之前,顾客可以对订单进行修改或取消操作;(8)管理员登录点餐系统服务器端,对用户订单进行确认。 标识标识出了出了查看菜谱、点查看菜谱、点餐下单、菜品餐下单、菜品信息管理、用信息管理、用户信息管理、户信息管理、订单管理、特订单管理、特色菜信息管理、色菜信息管理、数据库维护等数据库维护等业务事件。业务事件。四、第一阶段产物2业务事件分析以“菜品信息管理”业务事件为例四、第一阶段产物2业务事件分析 服务器端的主要作用在于实现与数据库的交互,完成相应数据的增加、修改及删除,具体的操作流程如下:(1)管理员输入正确的登录名和密码来登录系统;(2)管理员成功登录系统后,

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 金融/证券 > 金融资料

copyright@ 2008-2023 1wenmi网站版权所有

经营许可证编号:宁ICP备2022001189号-1

本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。第壹文秘仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知第壹文秘网,我们立即给予删除!