Flask 創建一個二手書籍線上購物平台-系統需求與分析

本系列文章是紀錄研究所軟體工程課程修課實作過程

系統需求

1. 專案目的與動機

現代教育體系中，學生每學期都需要購買大量教科書，然而，許多書籍僅在短時間內使用，之後就被束之高閣。為了解決這個問題，我們致力於建立一個二手書交流平台，讓學長姊能夠輕鬆販賣二手書，同時讓學生購書的負擔降低。這不僅有助於節省金錢，更能實現地球永續發展，減少資源浪費。

2. 系統特色

a. 公開的平台，價格透明化

我們的平台注重透明度，讓購買者能夠清晰了解市場價格，避免不合理的高價販售。這種公開的交易環境有助於建立信任，提高整個系統的效能。

b. 第三方平台管理

為了確保平台的公正性和安全性，我們引入第三方平台管理機制。這將有助於處理潛在的糾紛，確保交易的順利進行，同時為使用者提供更多保障。

3. 使用者定位

a. 不再需要用到該教科書的同學

透過平台，這些同學能夠迅速輕鬆地轉手自己不再需要的教科書，獲得一些額外的收入，同時也促進了書籍的再利用。

b. 需要教科書卻無法負擔高額費用的同學

平台使這些同學能夠以更經濟實惠的價格獲得需要的教材，減輕了他們的經濟負擔，提高了教育資源的可及性。

c. 想擁有學長姐精華筆記的同學

除了書籍，我們的平台還提供學長姐的筆記販售功能，這滿足了一部分同學對於高質量學習材料的需求。

系統分析

使用者案例圖找出誰是系統的參與人、歸納出領域、並劃分系統內的領域邊界

我們與同學深入討論後，整理出了這套系統可能的各種使用者案例，並繪製了相對應的 Use Case Diagram。系統的使用者案例主要分為四大模組，包括會員模組、商品模組、訂單模組、以及購物車模組。

1. 會員模組

會員模組涵蓋了所有使用者在系統中的身份認證和相關功能。註冊、登入、修改個人資料等功能均屬於會員模組的範疇。

2. 商品模組

商品模組提供了訪客和會員查詢、瀏覽商品的功能。即使在未登入的情況下，訪客可以方便地瀏覽並查詢系統中的商品。會員作為訪客的一種。

3. 訂單模組

訂單模組與購物車模組之間存在高度相依性。這是因為結帳購物車這個使用者案例會延伸到新增訂單，因此兩者之間有著密切的關係。這一模組負責處理使用者的訂單相關操作，包括查看歷史訂單、取消訂單等功能。

4. 購物車模組

購物車模組負責處理使用者在購物過程中的相關操作。這包括將商品加入購物車、管理購物車內商品、進行結帳等功能。購物車模組的操作直接影響到訂單模組的運作。

這套系統的構想是，訪客可以在不登入的情況下瀏覽、查詢商品，而會員則包含在訪客的範疇內，因此可以享有訪客使用的功能。特別值得一提的是，訂單模組與購物車模組之間存在相對高的相依性，這是因為結帳購物車的案例會直接連接到新增訂單的流程中。

資料建模分析

活動圖（泳道圖）可以拿來疏理各個使用者案例的動向，以及了解業務流程中參與人會是誰

我們透過活動圖以泳道的方式呈現了系統的業務流程。使用者以「訪客」或「會員」身份進入網站後，開始瀏覽並查詢商品。若在這過程中點擊網頁加入購物車，系統會先檢查會員是否已登入。若未登入，系統將引導至登入畫面；若已登入，則將商品成功加入購物車。

在查看購物車期間，會員擁有刪除商品或調整商品購買數量的權限。完成購物後，系統將自動生成訂單。會員隨後可在訂單列表中查看已下訂的訂單，並追蹤其進度。若欲取消訂單，會員需提交取消申請，經系統管理員審核後方可生效。

循序圖是用細部拆解使用者案例的流程

接著我們挑出比較核心的 Use case 來繪製成循序圖，方便我們梳理資料流、與業務流程，圖上的物件有會員、前端介面、後端模組、以及資料庫，整理流程為登入、瀏覽商品、加入購物，最後到結帳。

登入流程

1. 會員或訪客進入前端介面。
2. 前端介面發送登入請求給後端模組。
3. 後端模組驗證登入請求，若為會員，則檢查會員身份；若為訪客，則要求註冊。
4. 登入結果回傳給前端介面。

瀏覽商品流程

1. 會員或訪客透過前端介面發送瀏覽商品請求。
2. 後端模組從資料庫中搜尋商品資訊。
3. 商品資訊回傳給前端介面。

加入購物車流程

1. 會員或訪客透過前端介面發送加入購物車請求。
2. 後端模組驗證使用者身份，確認是否為登入狀態。
3. 若為登入狀態且有庫存狀態下，將商品加入購物車，並把加入結果回傳給前端介面。
4. 如果沒有庫存，回傳「暫無庫存」給前端介面。

結帳流程

1. 會員透過前端介面發送結帳請求。
2. 後端模組從購物車中搜尋預購買商品，在庫存數足夠狀態下，扣除購買商品的庫存數，若不足，回傳「暫無庫存」給前端介面。
3. 會員的購物車的商品移除，將購物商品的資訊儲存為訂單。
4. 訂單成立後，將訂單資訊儲存到資料庫。
5. 回傳訂單資訊給前端介面。

需求訪談（補充內容）

怎麼需求獲取？

在進行需求訪談之前，充分的事前準備是必要的。事前的準備包括深入了解相關背景知識。需求訪談通常應該針對真實的使用者進行，人數最好控制在 20 人以內。根據我們的案例，可以選擇不同系所的同學進行訪談，同時也應該尋求領域專家（例如老師或其他電商平台經營者）的意見。需要注意的是，並不是每位受訪者都能充分表達對於系統需求的看法，因此訪談者可能需要巧妙設計問題，引導受訪者表達他們對系統的需求。整體過程有點像摸象，透過了解需求來逐漸塑造系統的輪廓。

怎麼確認需求？

在需求訪談結束後，我們將收集到各種意見和功能需求。基於這些資料，我們可以進行資料建模，而 UML（統一建模語言）是一個強大的工具，用來繪製系統使用者案例、設計業務流程等。接著，我們可以再次召集使用者和領域專家來檢視繪製的 UML 圖，請他們確認這是否是他們期望的系統樣貌，這是為了確保我們所想的與使用者需求是否一致。

在實務操作中，需求訪談往往需要進行多輪，且顧客的時間寶貴。因此，在召開會議之前，確保準備工作充足至關重要。需求文件要等到顧客簽署後方能確認完畢，這樣的確認流程是為了保證最終的系統需求與使用者的期望保持一致。