# NTOUber 軟體需求文件(SRD)

## 專案資訊
- **專案名稱**：<span style="color:orange">海大機車共乘系統</span>
- **撰寫日期**：<span style="color:orange">2025/10/11</span>
- **發展者**：<span style="color:orange">王鈞宇、劉長諺、郭家齊、郭晉佑、翁世華</span>

---

## 版次變更記錄

| 版次 | 變更項目 | 變更日期 |
| ---- |:------------------------:| ---------- |
| 0.1 | 初版 | 2025/10/11 |
| 0.2 | 操作概念修改 | 2025/10/16 |
| 0.3 | 軟體工程需求文件回饋修改 | 2025/11/12 |
| 0.4 | 微調需求描述 | 2025/12/22 |
| 0.5 | 修正需求顆粒 | 2025/12/29 |

---

## 目錄
1. [接受準則 (Acceptance Criteria)](#section1)
2. [系統概述 (System Description)](#section2)
3. [操作概念 (Operational Concepts)](#section3)
4. [使用者故事地圖 (User Story Map)](#section4)
5. [使用者介面分析 (User Interface Analysis)](#section5)
6. [功能需求 (Functional Requirements)](#section6)
7. [非功能需求 (Non-functional Requirements)](#section7)

---

## <span id="section1">接受準則 (Acceptance Criteria of this document)</span>
- Clearly and properly stated（需求需清楚且適當的陳述）
- Complete（需求需完整）
- Consistent with each other（需求之間需維持一致性）
- Uniquely identified（每項需求有明確之識別）
- Appropriate to implement（需求需可被實作）
- Verifiable（需求需可被驗證）

---

## 系統概述 (System Description)

### 系統目標
設計一個**安全、高效且高度客製化**的機車共乘平台，讓使用者能即時且準確地找到合適的共乘夥伴（無論是提供共乘或尋求共乘）以抵達共同目的地。

### 系統特色
我們的平台不同於傳統社團，專為機車共乘設計：

#### 強化共乘安全
* **身分驗證與把關：** 實施車主身分驗證流程，確保乘客共乘安全性。
* **違規處理機制：** 針對不當行為或惡意取消等，可向系統管理員舉發且以評分系統發表評論。

#### 優秀的共乘體驗
<!-- * **即時地圖顯示與匹配：** 利用地圖顯示共乘貼文資訊。 -->
* **高度客製化的使用體驗：** 平台專為機車共乘需求設計。
* **現代化與直覺的介面設計：** 提供流暢且現代化的使用者介面，讓操作更簡單直觀。

### 預計的實作方案：
前端語言/框架：HTML、CSS、JavaScript / React、Tailwind CSS
後端語言/框架：Python / FastAPI
資料庫系統 ： MySQL
部署方式 ： Zeabur




---
## <span id="section3">操作概念 (Operational Concepts)</span>
- ### 系統管理員
華華曾經在FB經營機車共乘粉絲專頁，因為FB的詐騙帳號太多、系統AI又有著一堆問題，加上沒有開啟審查機制，導致社團詐騙廣告、廢文滿天飛。這次他決定一切重來，寫一個網站並擔任管理員，在必要時對平台貼文進行刪除或調整
- #### A. 登入
華華打開機車共乘系統，點擊登入並選擇管理員登入，接著輸入帳密登入系統。
- #### B. 管理員主頁
可以如同一般使用者一樣查看所有使用者的貼文，也可以查看到各貼文申請狀態並刪除異常貼文，也可對指定帳號進行警告與停權。
- ### 車主
諺諺打算騎機車下去高雄，因為他不想讓他寶貝的<span style="color:orange">小橘</span>(FZX檔車)獨自在基隆淋雨，所以想要尋找可以陪他回高雄的好夥伴，但朋友都要坐火車回去，於是他找到了NTOUber這個平台。
- #### A. 註冊/登入
諺諺想找到一個夥伴一起回高雄，他碰巧發現了NTOUber並打開註冊了自己的帳號並登入，再申請成為車主。
- #### B. 發布貼文
諺諺點下新增貼文、輸入起點與目的地、集合時間、備註，並且允許中途下車。
- #### C. 拒絕請求
一開始阿瓜請求加入這趟返鄉行程，但諺諺發現這位仁兄家在南投深山中的部落中，他實在是一點都不想繞超長山路過去，瓜瓜的評分又超低，感覺超難搞，只好拒絕了他的請求。
- #### D. 接受請求
後來佑佑也發送了請求，希望可以在鹿港中途下車，諺諺看到了很高興，因為它可以順路去彰化看當地人狩獵肉圓，於是乎他同意了這項請求。
<!-- - #### E. 評分
在約好的日子到來後，諺諺載著佑佑騎著他寶貝的小橘一路往南，在彰化佑佑表演了拿手的狩獵肉圓，諺諺十分享受這趟回家之旅，給佑佑一個五星好評。 -->

- ### 乘客
佑佑好窮，火車漲價之後又好貴好貴，想要蹭一下好心人的車回家，於是上網搜尋共乘平台。

- #### A. 註冊/登入
佑佑上網找到了NTOUber，進入首頁後發現就是他們在找的共乘app，於是註冊了帳號。
- #### B. 尋找貼文
佑佑打開搜尋欄，輸入起點與目的地、找到了幾個符合需求的行程並發送請求。
- #### C. 收取通知
佑佑打開網頁後，看到諺諺同意了他的請求，準備和諺諺一起共乘回家。
<!-- - #### D. 評分
和諺諺的旅程相當有趣，佑佑決定給他一個五星好評。 -->

| 圖片 | 功能 |
| --------------------------------------------------- | ------------ |
|  | 未登入使用者：可以查看貼文|
| | 已登入使用者：可以查看貼文跟紀錄|
||登入畫面：|
| |SideBar：|
| | 管理員主頁：|
| | 管理員管理貼文：|

---

## <span id="section4">使用者故事地圖 (User Story Map)</span>

- 管理員故事 ： 瓜齊為網站管理員，他會定期管理線上的貼文
- **代號**：NU-Adm-01 Administrator check web
- **故事**：身為網站管理員 (瓜齊)，我想要定期審查使用者發布的貼文，讓我維護平台的內容健康與安全。
- **註記**：
- 管理員瓜齊能夠刪除出現在網站上的貼文
- 管理員瓜齊如果審查到不適當的貼文(例如 : 廣告文章、釣魚文章...)出現在網站上要將其刪除。
- 管理員瓜齊審查到的貼文為正常貼文，則保留。
- **測試方法**：
- 確認網站上的貼文是屬於正常貼文。
- 確認網站上的貼文不是不適當的貼文。
- 確認系統能成功刪除貼文。

- 管理員故事 ： 瓜齊為網站管理員，他會幫忙驗證車主身分
- **代號**：NU-Adm-02 Administrator verify identity
- **故事**：身為網站管理員 (瓜齊)，我想要接收並審核使用者成為車主的身份驗證請求，讓我確保所有車主都符合資格與安全標準。
- **註記**：
- 管理員瓜齊能夠接收到申請成為車主的請求。
- 管理員瓜齊需要允許或拒絕申請成為車主的要求。
- 若管理員瓜齊拒絕請求，需提供拒絕原因，並通知使用者。系統需驗證駕照、車型、車牌等資料的有效性。
- **測試方法**：
- 確認有成功接收到申請成為車主的要求。
- 確認管理員是否能夠允許升級成為車主的要求。
- 確認管理員是否能夠拒絕升級成為車主的要求。

- 使用者故事 ： 喜華為尚未登錄使用者，他想先查看貼文
- **代號**：NU-Usr-01 User check web
- **故事**：身為潛在乘客 (喜華)，我想要在未登入狀態下查看所有公開的行程貼文，讓我快速了解平台提供的共乘服務與行程選擇。
- **註記**：
- 喜華一進入網站，就看到目前能參加的行程貼文。
- 確保喜華看到貼文後，能查看貼文詳細資料。
- 點擊貼文可查看詳細資料，但若想發起共乘請求，系統需提示其先進行登入/註冊。
- **測試方法**：
- 確認「行程貼文」明顯可見。
- 驗證系統是否正確顯示行程至網站上並清楚顯示。
- 確認系統能顯示貼文詳細資料。

- 使用者故事 ： 喜華想要尋求司機載他一起去目的地
- **代號**：NU-Usr-02 Client finding driver
- **故事**：身為已登入乘客 (喜華)，我想要發布徵求共乘的貼文，讓我讓車主主動發現我的需求並發送邀請。
- **註記**：
- 乘客能輕鬆將徵求貼文，上傳到網站，或在網站上請求車主一起共乘去目的地。
- 確保徵求貼文能讓車主發現且乘客請求車主接受時能知道車主是否接受。 (見 NU-PG-02)
- **測試方法**：
- 確認「發送請求」按鈕明顯可見跟「上傳行程」按鈕明顯可見。
- 驗證請求、徵求貼文是否正確發送至司機的介面。
- 確認系統有提示請求、徵求貼文成功訊息。

- 乘客故事 ： 鈞宇想找是否有符合需求的貼文
- **代號**：NU-PG-01 Search post
- **故事**：身為乘客 (鈞宇)，我想要根據目的地、時間等條件來篩選和搜尋行程貼文，讓我快速找到符合我需求的共乘選擇。
- **註記**：
- 頁面只顯示符合搜尋條件的貼文。
- 若搜尋結果為空，系統需提示「查無符合條件的行程」。
- **測試方法**：
- 篩選後貼文必須符合搜尋限制。

- 乘客故事 ： 喜華想發送共乘請求給車主
- **代號**：NU-PG-02 Send request
- **故事**：身為乘客 (喜華)，我想要向有興趣的車主發送共乘請求，讓我預約共乘。
- **註記**：
- 請求成功送達車主後，喜華能在網站上看到明顯的請求已發送通知。
- 確保喜華能在一定時間內得到共乘請求結果。
- 若請求被接受，乘客會收到「請求已接受」的即時通知。
- 若請求被拒絕，乘客收到「請求被拒絕」的即時通知，並顯示車主提供的拒絕原因。
- **測試方法**：
- 驗證系統是否顯示有提示框讓喜華看到。
- 確認系統有回復共乘請求結果。

- 使用者故事 ： 鈞宇想登入為車主

- **代號**：NU-DV-01 Driver login
- **故事**：身為潛在車主 (鈞宇)，我想要註冊帳號並提交身份驗證資料，讓我成為平台認證的車主，以發布行程並賺取點數。
- **註記**：
- 使用者可以透過google登入或密碼登錄來註冊系統。
- 使用者須通過身分驗證才可以變為車主，驗證結果會在平台發送通知。
- **測試方法**：
- 確認為新帳號時，會建立新的使用者資料。
- 驗證請求可以正確地傳送到那位使用者的信箱。

- 使用者故事 ： 諺諺作為一位車主想發布貼文

- **代號**：NU-DV-02 Driver Pose route
- **故事**：身為車主 (諺諺)，我想要發布包含時間、地點、目的地和費用等資訊的行程貼文，讓我向潛在乘客宣傳我的共乘服務。
- **註記**：
- 諺諺能輕鬆將行程貼文，上傳到網站。
- 確保後續能被潛在顧客搜尋到。
- **測試方法**：
- 確認「上傳行程」按鈕明顯可見。
- 驗證系統是否正確新增行程至網站上並清楚顯示。
- 確認系統有提示新增行程成功訊息。

- 使用者故事 ： 諺諺作為一位車主想回應請求

- **代號**：NU-DV-03 Driver response to request
- **故事**：身為車主 (諺諺)，我想要接收並決定是否同意乘客的共乘請求。
- **註記**：
- 諺諺能在網站上接收到明顯的共乘request。
- 確保諺諺能在一定時間內回覆。
- 若接受，要將請求狀態更新為「已接受」，並讓乘客收到通知。
- 若拒絕，必須提供拒絕原因，且乘客收到通知。
- **測試方法**：
- 確認「同意或是拒絕請求」提示框明顯可見。
- 驗證系統是否顯示提示框讓諺諺看到。
- 確認系統有提示新增回覆成功訊息。
- 確認乘客有收到共乘回應

---

## <span id="section5">使用者介面分析 (User Interface Analysis)</span>

- 首頁
- 登入
- 註冊
- 忘記密碼
- 主畫面
- 更新/新增行程
- 檢視歷史紀錄

---

## <span id="section6">功能需求 (Functional Requirements)</span>

### 基本使用者需求
1. 系統使用者分為車主與乘客兩種。
2. 註冊需提供基本資料、聯絡方式
3. 申請成為車主需進行身分驗證、提供駕照、車型、車牌。
4. 車主可設定共乘邀請（包含時間、地點、目的地等）。
5. 乘客可搜尋符合條件的車主。
6. 乘客可向車主發送搭乘請求。
7. 車主可接受或拒絕乘客請求，並提供原因。
8. 當乘客請求被接受/拒絕，乘客會收到通知
9. 系統提供即時通知功能，更新請求狀態。

### 進階使用者需求
1. 提供乘客查看請求狀態。
2. 提供乘客查看歷史共乘紀錄。
3. 提供車主查看歷史載客紀錄。

### 系統應提供：

#### **帳號與身份管理**

| 代號 | 具體功能描述
| :--- | :--- |
| **CM-FC-RG** | 系統應提供 **Google 帳戶或電子郵件/密碼** 方式註冊使用者帳號，並收集基本資料 (姓名、聯絡方式)。 |
| **CM-FC-LG** | 系統應提供 **Google 帳戶或電子郵件/密碼** 方式登入使用者帳號。 |
| **USR-FC-LO** | 系統應提供 登入使用者登出帳號。 |
| **CM-FC-DT** | 系統應根據使用者身份 (乘客/車主) **切換介面與功能權限**。 |
| **DV-FC-VFY** | 系統應提供車主身份驗證流程，要求上傳**有效的**駕照、車型、車牌照片，並由管理員進行審核。 |
| **USR-FC-POF-VW** | 系統應提供**檢視個人檔案**，讓登入使用者能檢視自己的名稱與詳細資訊。 |
| **USR-FC-POF-ED** | 系統應提供**個人檔案編輯**，讓登入使用者能更改自己的名稱與詳細資訊。 |

#### **行程、請求與紀錄管理**

| 代號 | 具體功能描述 | 備註 |
| :--- | :--- | :--- |
| **DV-FC-POS-UP** | 車主應能發布行程貼文，欄位需包含：**出發時間、上車地點、目的地**。 | |
| **CM-FC-POS-VW** | 使用者應能檢視詳細貼文 | |
| **DV-FC-POS-ED** | 車主應能編輯詳細貼文 | |
| **CM-FC-POS-SR** | 系統應提供**模糊搜尋**功能，允許使用者依據目的地、出發時間區間等進行查詢。 | |
| **USR-FC-POS-REQ** | 乘客應能向特定行程**發送共乘請求**，並在請求發出後，系統應**凍結該行程**。 | |
| **DV-FC-RES** | 系統應提供車主**接收、同意或拒絕**乘客請求的功能，拒絕時需輸入拒絕原因。 | |
| **USR-FC-ST** | 乘客應能查看所有已發送共乘請求的**即時狀態** (例如：待回覆、已接受、已拒絕)。 | |
| **USR-FC-POS-HS** | 使用者應提供查看**歷史共乘紀錄** (包含已完成與已取消行程) 的功能。 | 適用於車主 (載客紀錄) 和乘客 (搭乘紀錄)。 ||
| **NU-FC-NOT** | 系統應提供**即時通知**功能，更新請求狀態 (接受/拒絕) 和重要訊息 (如：行程取消)。 | |

#### **管理員管理功能**

| 代號 | 具體功能描述 | 備註 |
| :--- | :--- | :--- |
| **AM-FC-BLK-ADD** | 管理員要能新增用戶黑名單 | |
| **AM-FC-BLK-DEL** | 管理員要能刪除用戶黑名單 | |
| **AM-FC-MAG-USR** | 管理員要能管理用戶 | |
| **AM-FC-MAG-DV** | 管理員要能管理車主 | |
| **AM-FC-DRV** | 管理員要能同意/拒絕車主申請 | |
| **AM-FC-JP** | 登入自動跳轉進管理員區域 | 管理員不能離開管理員區域 |

---

## 非功能需求 (Non-functional Requirements)

### 系統須滿足：

| 代號 | 類型 | 具體非功能需求描述 | 標準/指標 |
| :--- | :--- | :--- | :--- |
| **NU-NFR-T1** | **效能** | **搜尋貼文** (依目的地篩選) **預期回應時間**，從使用者點擊搜尋到結果顯示完成。 | $\le 2.0$ 秒 |
| **NU-NFR-T2** | **效能** | **核心操作** (如：登入、發送請求、接受/拒絕請求) 的**預期回應時間**。 | $\le 2.0$ 秒 |
| **NU-NFR-C1** | **並發性** | 伺服器能穩定承載的**最大同時使用人數** (進行高互動操作，如：發布貼文、發送請求)。 | $\ge 100$ 人 |
| **NU-NFR-P1** | **相容性** | 系統介面需支援的最低硬體與作業系統環境。 | 手機： $\ge$ IPhone 6 或 Android OS 8.0；電腦： $\ge$ Windows 10 或 macOS 10.14；支援主流瀏覽器最新兩版。 |
| **NU-NFR-U1** | **易用性** | **首次使用者** (無車主身份) 應能在無人指導下，從註冊到發送第一個共乘請求所需時間。 | $\le 10$ 分鐘 |
| **NU-NFR-T3** | **效能/可用性** | **即時操作防呆**：在重要交易或提交操作 (如：發送請求) 時，系統應避免使用者在單一請求未完成前重複點擊發送。 | $\le 0.5$ 秒內鎖定按鈕直到伺服器回覆。 |
| **NU-NFR-P2** | **即時性** | 貼文狀態 (如：可載人數、請求狀態) 需在發生變動後，在其他使用者介面上進行**即時反映**。 | 貼文狀態變動後 $\le 1.0$ 秒內更新。 |

## <span id="section8">軟工課程相關連結 (Course-related links)</span>

- 連結：
- [Trello](https://trello.com/b/OE5I8L02/ntouber)
- [Github](https://github.com/SE-develop-ntou-G9)
- [Miro](https://miro.com/app/board/uXjVJ_NxF-k=/?share_link_id=781838203611)
- [軟體設計文件SDD](https://hackmd.io/qHDQ8d40QWqx8XdJxhFVog?both)
- [部屬網頁](https://ntouber.zeabur.app/)

---

<!-- ## <span id="section9">todo </span>

- ✅各組可幫自己的系統取一個獨特的系統名稱 (不用跟使用者需求的用詞一樣)
- ✅操作概念可適度搭配重要的Wireframe說明
- ✅在使用者故事地圖上層可以標上User類型或特定的人物代表(Persona)，以更容易思考故事
- ✅請盡量補上MVP內所有的故事對應的User Story Card(請留意每張User Story Card應該要能在User Story Map看到)
- ✅故事卡片建議盡量遵循Story Voice格式：身為...，我可以...，讓我... (&#34;As a..., I want..., So that...&#34;)
- ✅使用者故事請多思考分支與例外情況(例如請求被拒絕、共乘取消、評分與電子點數結算等)
- ✅功能需求請再確認是否有比使用者需求(給定的需求)和使用者故事更具體、更明確
- ✅非功能需求請至少包含最大同時使用人數、預期回應時間兩項
- ✅功能需求/非功能需求之敘述方式可參考：https://kenming.gitlab.io/software-requirement-analysis/ch1/functional-vs-nonfunctional-requirement.html
- ✅請再檢查錯字，以提升文件品質
- ✅請多參考提供的需求文件範例，請確保各章節內容都有適當的涵蓋
- ✅Trello之運用可參考https://trello.com/b/sswSYsuU/scrum-demo，有效運用checklist，並能與使用者故事地圖有一定的對應，且能清楚制定task與DoD (Definition of Done)
- ✅Story Map目前只具體展開少數重要故事(且故事名稱沒有對應)，建議補齊MVP內主要故事卡，並為每張卡片補上註記與測試方法，讓Story Map、故事卡與操作概念互相對應。
- ✅功能需求多半仍停在「可註冊／可發布貼文」層級，尚未細化為輸入條件、狀態轉換與例外處理(例如請求被拒絕、共乘取消、評分與電子點數結算等)。也請留意此部分為「系統功能需求」。
- ✅非功能需求中「NU-NFR-U1 IQ &gt; 0 的人都能使用」「NU-NFR-P1 是台電腦都要能用」等敘述過於口語，也無法驗證，請再做修改。
- ✅錯字：部屬 → 部署。 -->