物流管理系統需求分析與建模

前言

我自己本科是非科班出身，自己利用課余時間學習了前端。然后一直覺得自己的代碼能力還不錯，平時找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

流程圖模型