需求分析案例课件

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. 业务流程分析一是理解流程的层次性；二是了解流程的类型；三是掌握以业务事件识别、寻找流程的技巧。基于Android平台的点餐系统的总体流程包括的步骤有：（1）顾客在智能手机上登录点餐系统客户端后，自动进入菜谱界面，查看菜谱； （2）顾客选择菜品进行下单；（3）顾客选择菜品数量，若需在餐厅用餐还需选择座位号；（4）选择完成并确定后，提交订单； （5）订单提交后，订单数据会上传到服务器；（6）订单提交后，顾客可以在客户端查看自己的订单情况；（7）在管理员未确认订单之前，顾客可以对订单进行修改或

5、取消操作；（8）管理员登录点餐系统服务器端，对用户订单进行确认；一、业务流程分析2. 跨职责流程图应用具体来说，我们应该先找到业务事件的负责人，然后通过设问的方式，让他描述响应该业务事件所进行的活动，说明活动的执行岗位以及它们之间的关系、数据传递。一、业务流程分析3. 活动图应用 活动图是一种表述过程机理、业务过程以及工作流的技术。本系统的下单活动图可以参看右图。一、业务流程分析4.数据流程图应用客户端数据流程图服务器端数据流程图二、业务实体分析1业务实体分析任务概述业务实体分析的产物有两种可选的模型，包括类图和E/R模型也叫实体关系图。二、业务实体分析2.类图1）领域建模方法领域建模时，其工

6、作主要就是识别标识类、明确类之间的逻辑关系和数量关系以及添加重要的结构规则三个方面。二、业务实体分析2.类图使用名词分析法发现类和对象。1用例描述：1. 经理开始制定促销策略2. 经理制定促销策略3. 系统返回当前促销策略经理重复步骤2-3，直至制定所有促销策略4. 经理结束制定促销策略5. 系统返回当前促销策略确定对象：经理，促销策略概念类：经理，促销策略二、业务实体分析2.类图2用例描述：1. 经理查看预约2. 系统返回预约列表确定对象：经理，预约，预约列表概念类：经理，预约，预约列表摒弃对象：3用例描述：1. 经理查看取号2. 系统返回取号列表确定对象：经理，取号，取号列表概念类：经理，

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

8、促销策略3. 顾客填写订单4. 系统向经理发送下单请求5. 经理处理下单请求6. 系统提醒经理处理成功7. 系统返回顾客订单信息确定对象：顾客，下单，促销策略，订单，经理概念类：顾客，下单，促销策略，订单，经理摒弃对象：8用例描述：1. 顾客请求支付2. 系统向经理发送支付请求3. 经理处理支付请求4. 系统提示顾客可以支付5. 顾客支付6. 系统提示经理顾客支付7. 经理回应支付8. 系统提示顾客支付结果9. 系统提示经理支付结果确定对象：顾客，支付，经理 概念类：顾客，支付，经理二、业务实体分析2.类图9用例描述：1. 顾客发表评论2. 系统返回评论列表确定对象：顾客，评论，评论列表概念类

9、：顾客，评论，评论列表最终发现的所有概念类如下：经理，顾客，促销策略，预约，预约表，取号，取号表，支付，下单，订单，订单信息列表，评论，评论列表二、业务实体分析2.类图2）建立类之间的关联二、业务实体分析2.类图3）添加类的重要属性二、业务实体分析2.类图分析模型中有3种十分有用的构造型即实体类、控制类和边界类。实体类即实体对象的抽象；控制类即控制对象的抽象；边界类即边界对象的抽象。二、业务实体分析3. E/R图应用基础概念模型和逻辑模型有什么区别呢？它们实际上是对“需求视图”与“开发视图”的区分。换句话说，概念模型是需求人员的视图，等价于现在出镜率很高的领域模型；而逻辑模型是开发人员(包括设

10、计人员)的视图，它约等于面向对象分析与设计方法中提到的“分析模型”。三、角色与使用场景分析在传统的结构化分析与设计方法中，整个分析视角是站在解决方案域的，很容易产生对问题域分析不足的结果。用例分析技术的关键是“发现使用系统的角色(参与者)，了解并梳理这些角色将如何使用系统(场景)”，从而更好地完成“人”的视角的需求梳理。三、角色与使用场景分析1. 参与者参与者是在系统之外，透过系统边界与系统进行有意义交互的任何事物。本例中参与者包括 ：普通用户与管理员。三、角色与使用场景分析2. 用例实例与用例用例实例(即场景)是在系统中执行的一系列动作，这些动作将生成特定执行者可见的价值结果，一个用例定义一

11、组用例实例。用例是对一组用例实例(场景)的抽象，也就是说，用例是有路径(基本事件流、扩展事件流、子事件流等)的。一个场景是一个具体的行为，一个用例是对一类相关行为的抽象。 三、角色与使用场景分析3. 参与者与用例之间的关系、用例与用例之间的关系、参与者与参与者的关系参与者与用例的关系体现在一个参与者表示用例的使用者在与这些用例进行交互时所扮演的角色。用例之间的关系有包含、扩展和泛化。参与者之间的关系只有一种，那就是泛化。三、角色与使用场景分析事半功倍的问题：你平时都做什么？（参与者目标）这件事是谁交办的 ？做完了你需要通知或传达给认证吗？做这件事情你都需要填写些什么表格吗？三、角色与使用场景分

12、析示例：边界确定(去除非End User的职责带区)确定角色(对剩下的职责带区进行角色化) 确定用例三、角色与使用场景分析示例：边界确定确定角色确定用例主要参与者用例普通用户1.普通用户注册2.普通用户登录3.用户修改密码4.查看菜谱5.点餐下单6.查看特色菜推荐信息7.查看订单信息管理员1.管理员登录2.菜品信息管理3.用户信息管理4.订单管理5.特色菜信息管理6.数据库维护三、角色与使用场景分析 菜品信息管理用例，它的参与者是管理员，用例是菜品信息管理，菜品信息管理用例包含查看菜品信息、添加菜品、删除菜品、修改菜品信息四个子用例，菜品信息管理是抽象出的一个基用例，是为了简化用例的描述。三、

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

14、的效率和收益。普通用户主要使用这个系统来实现注册账号，点餐、座位预订，节约时间。四、第一阶段产物2业务事件分析“Android点餐系统”的总体业务流程包括如下步骤：（1）顾客在智能手机上登录点餐系统客户端后，自动进入菜谱界面，查看菜谱； （2）顾客选择菜品进行下单；（3）顾客选择菜品数量，若需在餐厅用餐还需选择座位号；（4）选择完成并确定后，提交订单； （5）订单提交后，订单数据会上传到服务器；（6）订单提交后，顾客可以在客户端查看自己的订单情况；（7）在管理员未确认订单之前，顾客可以对订单进行修改或取消操作；（8）管理员登录点餐系统服务器端，对用户订单进行确认。 标识出了查看菜谱、点餐下单、

15、菜品信息管理、用户信息管理、订单管理、特色菜信息管理、数据库维护等业务事件。四、第一阶段产物2业务事件分析以“菜品信息管理”业务事件为例四、第一阶段产物2业务事件分析 服务器端的主要作用在于实现与数据库的交互，完成相应数据的增加、修改及删除，具体的操作流程如下：（1）管理员输入正确的登录名和密码来登录系统；（2）管理员成功登录系统后，可对系统的相关信息进行管理。四、第一阶段产物2业务事件分析 基于Android平台的点餐系统采用C/S和B/S的混合模式结构，其中手机客户端的实现采用的是C/S模式，而服务器端基于B/S模式进行实现。四、第一阶段产物2业务事件分析参与该系统的类分别是用户、管理员、

16、订单、菜品、座位、菜品类别。四、第一阶段产物3报表分析对于报表而言，分析工作可以分成why(目标)、what(内容)与How(展现形式)三个层次。以“订单业务报表”为例其要解决的问题包括角色查询、目的、相关场景与查询频率等方面的内容。四、第一阶段产物4抽象与整理客户端:客户端包括的主要功能有注册功能、登录功能、查看菜品功能、下单功能、选座功能、查看订单功能等。服务器端：根据前文的分析可知道，服务器端包括的功能有登录功能、用户管理功能、菜谱管理、订单管理等。系统管理模块包含数据备份、数据恢复及数据打印功能四、第一阶段产物4抽象与整理四、第一阶段产物5填充需求规格说明框架通过以上分析，就可以完成结

17、构框架和行为脉络的填充，同时将其填充到软件需求规格说明书中。需求规格说明课后可以在网站下载参考。3-3需求分析案例以Android点餐系统为例。第二阶段：确定需求细节一、确定行为需求的细节1.用例的灵活应用根据行为需求的特点，可以将其分成“业务功能、报表功能、接口、技术支撑”4种类型。 统一封装成用例，但在具体细节描述方面，可以对其进行灵活处理。一、确定行为需求的细节2.用例描述模板 针对业务功能类的用例来说，其需要整理的内容主要包括事件流、相关需求与功能点、界面原型、规则与约束4个方面，描述的方法可以采用通用的用例描述模板来组织。 以“Android点餐系统”为例。一、确定行为需求的细节2.

18、用例描述模板以“Android点餐系统”查看菜品信息为例。一、确定行为需求的细节3.相关需求整理(1)用户原始需求 将需求捕获阶段获得的用户原始需求，通常每个原始需求是以一句话的形式整理到相应的用例中，它可以更好地建立用户原始需求和软件需求(即用例)之间的映射。 (2)相关功能点 在需求规格说明书中除了可以将用户原始需求归类整理进来，作为开发时的重要参考依据之外，有时可能还会涉及一些无法有效地表述在事件流中的小功能点。 一、确定行为需求的细节4.界面原型(1) 要点 (2) 交互不要忽略 (3) 别让界面掩盖本质一、确定行为需求的细节4.界面原型一、确定行为需求的细节5.规则与约束规则大致可以分为：行为规则：或称为功能规则、业务规则，它是指和业务逻辑、业务流程相关的规则。 结构规则：或称为数据规则，它是指和业务实体、属性、派生属性相关的规则。 界面规则：它是指和用户界面相关的规则。 一、确定行为需求的细节5.规则与约束约束分成以下几种类型： 性能指标等非功能要求 软、硬件环境限制 技术选择限制 用户特点及环境限制 二、确定结构需求的细节(1)领域模型的组织(2)数据窗口分析 (3)数据组成与格式三、第二阶段产物用例描