物流管理系统需求分析与建模

前言

我自己本科是非科班出身，自己利用课余时间学习了前端。然后一直觉得自己的代码能力还不错，平时找bug也挺快, 写个模块和功能都挺顺手，自认为不比科班学生差。但是每当自己从头搞一个项目时，就感觉毫无头绪，不知道从哪里开始。我一直搞不懂问题出在哪里。学了孟宁老师的需求分析与建模后，我突然发现这就是问题所在，感觉自己视野一下子被打开。科班学生的素养不仅仅是写代码的能力，还要有将现实问题抽象与建模的能力。通过系统需求分析与建模之后，接下来的代码工作自然就水到渠成了。不然就只能不断地发现新问题，不停地改自己的代码，陷入泥淖之中。

业务需求

抽象层次最高的需求称为业务需求是系统建立的战略出发点，表现为高层次的目标，它描述了组织为什么要开发系统。
为了满足用户的业务需求，需要描述系统高层次的解决方案，定义系统应该具备的特性。高层次解决方案与系统特性说明了系统为用户提供的各项功能，限定了系统的范围，帮助用户和开发者确定系统的边界。
对物流管理项目，结合用户日常工作，可以建立高层次的解决方案，其系统特性如如SF1~SF5所示：

• SF1: 用户信息管理。对各种类型的用户信息进行增删改查。
• SF2: 部门信息管理。对部门信息进行增删改查。
• SF3: 物流管理。管理物流的下单、分拣、核实、分类、发货、确认收货等过程，并将仓库里的物品进行分类显示。
• SF4: 绩效管理。对员工、部门的出勤等信息进行分析和展示。

用户需求

用户需求(user requirement)是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做什么。用户需求主要来自系统的使用者（用户），也可能来自间接的渠道（如销售人员、售后支持人员）
针对每一个系统需求，都可以建立一组用户需求。

用户信息管理

针对SF1用户信息管理, 可以建立如下用户需求：

• UR1.1: 系统应该允许管理员增加、修改或者删除用户、部门经理和部门员工的信息。
• UR1.2: 系统应该允许管理员授予或者取消部门经理的权限。
• UR1.3:系统应该允许客户经理增加、修改或者删除部门员工的信息。
• UR1.4: 系统应该允许客户经理授予或者取消部门员工的权限。

部门管理

针对SF2部门管理，可以建立如下用户需求：

• UR2.1: 系统应该允许管理员增加、修改或者删除部门信息。

物流管理

针对本项目的核心需求SF3物流管理，可以建立如下用户需求：

• UR3,1: 系统应该允许管理员修改货架信息(即有几个货架，每个货架有多少个货品)
• UR3.2: 系统应该允许客户(可能是顺丰等物流公司的门店)下订单，即给出货品信息、发货地、收货地等信息。
• UR3.3: 系统应该允许分拣员核实收到的产品是否与订单一致，如果一致，将产品入库，否则报告错误。
• UR3.4: 系统应该允许搬运员编辑产品在仓库中的位置信息。
• UR3.5:系统应该允许发货人员对产品进行发货。
• UR3.6: 系统应该允许客户确认收货。
• UR3.7: 系统应该允许用户进行投诉。

绩效管理

绩效管理准备对员工和部门的打卡、分拣商品数、搬运商品数、出错率等信息进行统计分析后展示。但由于此需求还在讨论之中，准备放在二期改进之中，暂时不进行相应的用户需求分析。

用例图

用例描述了在不同条件下系统对某一用户的请求的响应。根据用户的请求和请求时的系统条件，系统将执行不同的行为序列，每一个行为序列被称为一个场景。一个用例是多个场景的集合。
换句话说，每个用例是对相关场景的集合，这些场景是用户和系统之间的交互行为序列，帮助用户实现用户的目的。

管理员

客户

部门经理

员工

UML图

系统顺序图

数据表模型

user

id	username	password	role

department

id	username	password	role

user_department

id	departmentId	userId

product

id	name	quantity	detail	status	position

shipping订单

id	userId	productId	status	handler

cart货架

id	row	col

error_info

id	type	message	handler

流程图模型