---
tags:
- Rails Develoepr Foundation
- 開發必學的需求分析法
---
# 2023-12-10 - 開發必學的需求分析法

## 事前準備

本次課程實作的部分會以協作的形式進行，需確認可以正常使用 Hackmd 以及 FigJam 即可。

### 工具

上課過程會使用以下工具

| 名稱 | 說明 |
|------------------|---------------------------------|
| FigJam | 需求分析練習，請確認瀏覽器可以正常開啟 |

## 課後問卷

麻煩大家協助填寫改善課程品質，以及了解大家對哪些類型的內容更有興趣

[➡️ 問卷連結](https://www.surveycake.com/s/lyNa3)

## 講師資訊

課程內容無法涵蓋的部分，可以追蹤網誌、YouTube 會以小單元或者系列連載的方式分享出來。

| 網站 | 介紹 |
|-----------------|------|
| [個人網誌](https://blog.aotoki.me) | 系列文章連載、主題式討論
| [Facebook 粉絲專頁](https://fb.me/aotoki.me) | 主題式討論
| [YouTube 頻道](https://www.youtube.com/channel/UCcABbJfCL0DfNh3wDk_-7lg) | 技術講解
| [Discord 社群](https://discord.com/invite/t2Kd6PNvvA) | 技術討論，上課的問題也可以在此發問
| [訂閱電子報](https://mailchi.mp/aotoki/rails-developer-foundation) | 即時收到網誌通知

## 實作練習

隨著人工智慧的發展，我們已經開發好 AI 功能的 API。然而，我們需要對這個 API 基於運算時間計價，並且以帳號為計算。

### 需求分析

> 將上述的需求轉換為使用者故事（User Story）以及規格（Specification）根據需要可以向產品負責人（Product Owner，講師）提問

#### User Story
- User Application Client 發送 API 請求至 Server，API 請求紀錄、AI 功能的執行紀錄及運算時間，會在系統端儲存下來
- User 透過 API 請求使用 AI 功能之後，User 進入個人後台，可查詢 API 叫用紀錄、單次運算時間
- User Application Client，可叫用特定 API 查詢指定時間區間內的使用紀錄
- 使用者開啟 App/Web 頁面，點擊「使用紀錄」進入頁面，指定「查詢日期區間」(日期 A to B) ，按下「確認」，取得指定區間 (date A to B)的使用紀錄
- 使用者使用 AI 功能，AI 功能花了 10 秒回應，該玩家被收 1000 台幣。

#### Specification
- 每個 api request 都可以透過 token 來辨識 User
- 每個 api request time 與 response time 都有被記錄
- 不同 api 運算時間的單位價格需要可以被動態設定
- 用戶的使用紀錄可以被依照時間區間做彙總，以及透過 api 查詢相關資料
- API 紀錄包含的資料欄位有:
- User ID
- Token value
- Request time
- Response time
- AI function ID
- AI function Runtime

### 功能分析

> 根據需求分析的結果，在 FigJam 白板上協力將系統模型繪製出來

[➡️ FigJam 連結](https://www.figma.com/file/0jiBk4Z986BBcopneApVxb/2023-12-10---%E9%96%8B%E7%99%BC%E5%BF%85%E5%AD%B8%E7%9A%84%E9%9C%80%E6%B1%82%E5%88%86%E6%9E%90%E6%B3%95?type=whiteboard&node-id=0%3A1&t=AYwypoh54S4o3KkO-1)

### 驗收文件

> 根據練習的成果，嘗試以 Gherkin 格式（或者其他格式）將驗收用的文件撰寫出來

#### Feature: 對 AI 功能 API 基於運算時間計價，並且以帳號為計算
<!-- 對這份規格書更多的介紹 (非必要，不影響自動測試) -->
<!-- 介紹.... -->
<!-- 介紹.... -->
#### Scenario: 使用者使用 AI 功能，AI 功能花了 10 秒回應，該玩家被收 1000 台幣
Given 每秒100元
When 執行了10秒
Then 得到1000 台幣
#### Scenario:
Given 前提條件是....
When 我做了某件事....
Then 結果應該得到...

## 共筆區域

> 歡迎在這裡撰寫筆記跟其他同學協力紀錄
> [name=蒼時弦や]

### Keys
- 什麼是資料(data)？什麼是資訊(information)？
- 什麼是脈絡(context)？
- 模型(Model) 是什麼樣的概念？
- 應用程式 (Application) 是什麼？
- Requirement - 使用者提出一個需求時，你會怎麼做？
- User Story - 跟需求相比的差異是什麼？
- Specification - 規格跟需求的差異是什麼？
- Key Examples - 關鍵案例在軟體開發中發揮了什麼效益？
- Analysis - 為什麼要做功能分析？
- Boundary - 什麼是邊界？
- Bounded Context - 脈絡的邊界在哪裡？
- Domain Model - 領域模型是什麼？
- Entity - 實體是什麼？
- Value Object - 數值是什麼？
- Aggregate Root - 聚合根是什麼？
- Query - 領域模型能處理好讀取嗎？
- Check - 如何確認功能完成？
- Gherkin
- Feature - 一個測試該測什麼？
- 為什麼養成習慣寫測試，可以讓你的寫程式開發速度變快？

### Points
- MVC 其實最初是 front-end 的理論
- Model -> 模擬真實世界的一個物件
- 情境：身為玩家，我想知道儲值的寶石剩下多少
- User Story -> 脈絡 (context) -> 人、事、時、地、物
- Requirement -> User Story -> Specification
- User Story 應該儘可能地涵蓋到關鍵案例
- 關鍵案例 + 關鍵案例 + 關鍵案例 + ... -> 完整功能
- 同樣是「錢包」在手遊、電商等不同領域，概念是不同的
- Boundary -> 事物的「邊緣」或「限制」
- 在軟體開發當中，會有「指責邊界」和「脈絡邊界」的存在
- 脈絡的邊界是一個「功能」或者「操作單位」
- 領域的概念模型 (domain model)，包含資料和行為 (例如: 桌遊)
- 透過邊界劃分出領域，那麼領域模型反映出系統中的某個概念
- 模型驅動(model-driven)是先思考模型可以做什麼事情
- 資料驅動(data-driven)則是先思考要保存怎樣的資料
- Entity - 具備唯一識別的物件 (例如擁有 ID 的個體)
- 我們通常會將行為和狀態一起定義在實體中
- Value Object - 抽象無法以「個體」表示的概念
- Aggregate Root 也是 Entity，是一個操作單位
- 要改變餘額或者紀錄交易，都是以 Wallet 為操作單位
- 有 Aggregate Root 概念之後，對資料處理的職責回明確很多
- Check - 當有可見的輸出時，才能夠被檢查
- User Story 描述的就是測試的脈絡和結果，可以直接寫測試
- 耗時間的都不是真正寫程式的過程，而是過度依賴 PM、QA、PO 幫你驗收和手動測試，所以最好培養起寫測試的能力和習慣 (5分鐘 vs. 5秒鐘)
- 當每個功能都有一條對應的驗收成果，實作就會相對流暢

### Retrospect
- Aggregate Root -> 區分出工作單位
- 驗收驅動測試的開發流程 -> 讓成果能被看見
- Cucumber -> 測試的同時產出文件