需求分析

3-3需求分析案例

“Android点餐系统”项目案例需求获取资料介绍如下：

(1)目标和范围

本软件主要作用是为点餐者提供一套可以在移动设备(手机、平板)上运行的点餐软件。 系统分为前台和后台,前台是点餐者使用的，点餐者可以在移动设备上查看餐馆所有的菜目、价格、简单的菜品介绍以及餐馆的特色菜介绍，同时点餐者还可以查看、取消自己已经挑选的菜品，最后上传订单。后台是管理员使用的，管理员可以在后进行订单管理、用户管理、菜谱管理等。

(2)系统角色和职责

系统的使用人群包括两类管理员:系统的维护，订单管理、菜品的增删。

普通用户:注册账号，点餐、座位预订。

(3)系统处理功能要求

查询菜品
设置菜品
顾客下单
订单处理
数据处理

(4)系统其他要求

本系统客户端要求符合大众操作习惯，与网上其他的Android系统App操作方式保持基本一致。餐馆要求每笔订单交易误差不得超过工角，每天交易额的误差不得超过100元。5年内价位在500元以上的Android手机都可以流畅运行该系统。

第一阶段

工作的输入是需求定义阶段产生的业务事件列表和报表列表，输出的是领域模型和用例模型。

针对每个业务事件进行业务流程分析、业务实体分析和用例分析;

针对每类报表进行业务实体分析和用例分析。

业务流程分析

在分析过程中，要注意抓住核心业务和主要活动点、部门内以及部门之间的衔接，工作中的烦琐及反复的环节，成本高、效率低、时间长的环节以及任务转手次数较多的环节。

“Android点餐系统”中的主要业务就是点餐，我们要围绕点餐的主业务展开分析。

业务流程分析的过程中的三个关键的要点

一是理解流程的层次性，其中包含三大层次，有组织级，部门级
岗位级;

二是了解流程的类型，包括生产性流程，管理性流程和支持性流
程;

三是掌握以业务事件识别、寻找流程的技巧。

产物

跨职责流程图
活动图
数据流图

基于Android平台的点餐系统的总体流程包括的步骤有

(1)顾客在智能手机上登录点餐系统客户端后，自动进入
菜谱界面，查看菜谱;
(2)顾客选择菜品进行下单;
(3)顾客选择菜品数量，若需在餐厅用餐还需选择座位号;
(4)选择完成并确定后，提交订单;
(5)订单提交后，订单数据会上传到服务器;
(6)订单提交后，顾客可以在客户端查看自己的订单情况;
(7)在管理员未确认订单之前，顾客可以对订单进行修改或取消操作;
(8)管理员登录点餐系统服务器端，对用户订单进行确认;

跨职责流程图的应用

跨指责流程图绘制要点是在进行业务流程分析时，采用的关键入手点为部门级的业务流程，也就是从业务事件出发，分析该业务事件会触发的一系列活动。要真正保障绘制出来的跨职责流程图是真实、有效的，就必须强化用户的参与。

我们应先找到业务事件的负责人，然后通过设问的方式，让他描述响应该业务事件所进行的活动,说明活动的执行岗位以及它们之间的关系、数据传递。

(三)活动图
活动图是一种表述过程机理、业务过程以及工作流的技术。它可以用来对业务过程、工作流建模，也可以对用例实现甚至是程序实现来建模。
活动图的主要元素包含初始节点和活动终点、活动节点转换、分支与监护条件、分岔与汇合等。

数据流程图

点餐系统由客户端和服务器端两部分组成，客户端主要负责点菜，服务器端负责信息管理。

客户端的基本流程

(1)用户输入正确的登录信息进入系统，若登录信息不对，系统提示重新输入登录系统，直到用户成功登录系统，新用户要先进行注册并注册成功才可以登录系统。
(2)用户成功登录系统后，可先查看菜品信息，选择菜品及数量，若需在餐馆用餐还需选择座位，完成后进行下单操作。
(3)用户可以查看自己的订单，在订单未确定的情况下，可以修改或取消订单。

服务器端的基本流程

(1)管理员输入正确的登录信息进入系统，若登录信息不对，系统会提示重新输入登录信息，直到管理员成功登录系统。
(2)管理员成功进入系统后，可进行各类信息的管理，如菜品信息管理、用户信息管理、订单管理等，其实就是对上述信息进行添加、删除及修改操作。

业务实体分析

要了解这个问题域中有哪些业务实体，它们之间存在什么样的逻辑关系、数量关系，以及有什么相应的结构规则。

1.业务实体分析任务概述

“自底向上”

识别出业务实体
确定实体间关系
定义实体关健属性

业务实体分析的产物有两种可选的模型，包括类图和E/R模型也叫实体关系图。

2.类图

根据边界类、控制类、实体类帮助分析系统中的类

(1)领域建模方法

领域建模时，其工作主要就是识别标识类、明确类之间的逻辑关系和数量关系以及添加重要的结构规则三个方面。

(2)建立类之间的关联

(3)添加类的重要属性

分析模型中有3种十分有用的构造型即实体类、控制类和边界类。

实体类:即实体对象的抽象，通常来自域模型也就是现实世界，用来描述具体的实体，通常映射到数据库表格与文件中;

控制类:即控制对象的抽象，主要用来体现应用程序的执行逻辑，将其抽象出来，可以使得变化不影响用户界面和数据库中的表;

边界类:即边界对象的抽象，通常是用来完成参与者(用户、外部系统)与系统之间交互的对象，例如From、对话框、菜单、接口等。

3.E/R图应用基础

数据建模过程的优势体现在能够更好地与后续的数据库设计
结合;

缺点是语义相对于类图来说更弱一些，同时对面向对象开发的指导作用相对差- - .些。

概念模型是需求人员的视图，等价于现在出镜率很高的领域模型;

逻辑模型是开发人员(包括设计人员)的视图，它约等于面向对象分析与设计方法中提到的“分析模型”。

概念模型与逻辑模型具体区别在于两个方面

完整性:逻辑模型在完整性上要比概念模型更胜筹，通过在需求细化、设计的阶段会对类的属性进行细化，会补充-些新的类;

加工方式:概念模型的原则是忠于问题域，而逻辑模型则会从实现的便利性和需要的角度进行细化，具体来说可能会对一些类进行分拆、合并。