■ 本文適合對象

• 剛被分派到開發團隊，常常聽到「需求定義」這個詞
• 不知道需求定義是什麼、為什麼重要
• 想知道在開始實作前應該先做什麼
• 想理解在團隊內與委託方討論時的流程

■ 本文可獲得的內容

• 3 分鐘就能理解「需求定義」的本質
• 了解委託方與開發團隊之間正在發生什麼
• 理解為什麼需求定義做得好壞，會影響專案成敗
• 明確掌握實際進行需求定義時的步驟

■ 參考書籍

• 開始吧！需求定義 ～從初學者到資深者

1. 結論：需求定義就是「滿足讓委託方點頭的條件」

需求定義聽起來可能很難，但本質其實非常單純。

「滿足讓委託方覺得『這樣就 OK』的條件」

在開始實作之前，讓開發團隊與委託方共享「同一個願景」的過程，就是需求定義。

如果在沒有需求定義的情況下就開始實作，會發生以下情況：

• ❌ 做出來的東西被說「跟想像的不一樣」
• ❌ 不斷冒出追加功能
• ❌ 時程與預算大幅超支
• ❌ 最後只能重做實作

如果需求定義做得好：

• ✅ 團隊所有人都能朝同一個目標前進
• ✅ 能清楚知道「為什麼需要這個功能」
• ✅ 實作效率會大幅提升
• ✅ 後續「還是想改」的情況會減少

2. 需求定義會面臨的現實限制

在抵達「委託方覺得 OK 的規格」之前，總會遇到以下限制。

制約說明例實作者的技能團隊內的技術能力無法實現的需求「使用 AI 的自動分類功能」→ 沒有機器學習專家現代技術現有技術無法對應的新需求「即時 10 萬人同時連線」→ 沒有成熟解法期間無法在排程內完成的需求「3 個月內實作 100 個功能」→ 物理上不可能預算在預算內無法實作的需求「在雲端實現高可用性」→ 基礎架構費用龐大人力無法確保所需資源的需求「iOS 與 Android 版並行開發」→ 人力不足

重要觀念

不存在完美無缺的需求。理解限制之後，判斷要優先什麼才是重點。

3. 需求定義的基本流程：來回反覆的過程

需求定義不是一次就完成，而是反覆來回很多次的過程。

需求(C) → 要求(C) → 檢討(M) → 提案(M) → 檢討(C)
  ↑                              ↓
  ←─────── 重複這個迴圈 ←────

• C = Client（委託方）

  • 提出「想做這樣的事」的需求
  • 接收提案後進行檢討，並回饋意見

• M = Me（實作團隊）

  • 將需求轉換成「可實現的要求」
  • 根據限制提出提案
  • 將委託方的回饋反映到下一次檢討中

這個循環本身就是需求定義。 不是一次就能做出完美規格書，而是透過多次來回逐步整理成形。

例：實作團隊與委託方的來回

❌ 壞例子（沒有來回）

委託方：「我想要好用的 UI」
開發團隊：「了解，那我們就開始實作」
   ↓
實作完成後...
委託方：「這不是我要的！跟想像不一樣」

✅ 好例子（有來回）

委託方：「我想要好用的 UI」
開發團隊：「具體來說，您希望是什麼樣的操作方式？」
委託方：「希望就算是新手也能直覺操作，並且在 3 分鐘內了解基本功能」
開發團隊：「那我們提案將畫面縮減為 3 個選單，請您確認」
委託方：「這個版面還需要再調整一下」
開發團隊：「了解，那麼這樣改如何呢」
   ↓
最後做出雙方都滿意的規格

4. 需求可分成 3 類

所有需求都可歸類為以下其中之一。

■ 1. UI（使用者介面）

「使用者會看到什麼，以及怎麼操作」

• 畫面版面配置（各元件放在哪裡）
• 輸入表單（文字框、按鈕等）
• 顯示內容（要顯示什麼）
• 導覽流程（從哪個畫面移到哪個畫面）

具體例子

商品列表畫面要配置以下元件：
- 搜尋表單（上方）
- 商品清單（中央）
- 分頁器（下方）

■ 2. 功能（Function）

「使用者操作時，系統要做什麼」

• 資料處理（計算、轉換、格式化）
• 商業邏輯（訂單處理、付款處理等）
• 外部串接（與其他系統進行資料交換）
• 通知與警示（通知使用者）

具體例子

對於「點擊商品搜尋按鈕」這個操作，
系統提供「用輸入的關鍵字搜尋資料庫，
並回傳符合條件的商品」這個功能

■ 3. 資料（Data）

「系統要保存什麼，以及如何管理」

• 資料表設計（要儲存哪些資料）
• 關聯關係（資料彼此的關係）
• 資料保存期限（資料要保留多久）
• 歸檔／刪除規則（舊資料如何處理）

具體例子

商品資訊資料表：商品 ID、商品名稱、價格、庫存數量
庫存鎖定：下單時暫時鎖定庫存

5. 需求定義的準備階段：6 個步驟

在實作前，為了統一團隊內的理解，依序整理以下 6 件事。

■ ①企劃（Planning）

目的：「要實現什麼」要先明確化

委託方：「希望新增功能」
↓
開發團隊：「那麼，這會實現什麼成果呢？」

檢查清單

• 為什麼要做這個（背景／問題）
• 實現後會有什麼改變（效益）
• 誰會使用（目標對象）
• 什麼時候需要（期限）

具體例子

❌ 不好的企劃案
「做一套新的庫存管理系統」

✅ 好的企劃案
「讓店員在每天早會時，能在 5 分鐘內確認庫存不足狀況，
 進而減少下單失誤，並將每月銷售損失降低 3%」

■ ②整體概觀（System Overview）

目的：共享大方向的理解

簡單畫成圖來看。

外部系統 A
    ↓（資料串接）
[我們的系統] ← 使用者操作
    ↓（結果通知）
外部系統 B

開發所需資訊

• API 規格（如何與其他系統通訊）
• 資料格式（以何種格式交換）
• 錯誤處理（通訊失敗時怎麼辦）
• 串接觸發條件（何時與其他系統串接）

■ ③範圍界定（Scope Definition）

目的：劃清「要做什麼」與「不做什麼」

如果這點不明確，後面就會一直出現「不然再加這個吧……」，最後導致時程超過。

要決定的項目

• 第一階段（一定要做）： 最小必要功能
• 第二階段以後： 優先度較低的功能
• 外部處理： 系統不處理的工作（改由人工處理）
• 未來再做： 受限於條件，現階段不實作

具體例子

【線上商店系統】

◎ 第一階段實作：
- 商品搜尋與顯示
- 購物車功能
- 訂單處理

△ 第二階段評估：
- 評論功能
- 願望清單
- 點數系統

✗ 不實作：
- 庫存自動補貨（以人工處理）
- SNS 串接（初期不需要）

■ ④實作技術（Technology Stack）

目的：確認技術上是否可行

依團隊內的技術程度來選擇很重要。太先進的技術，如果沒有人會做，就會變成負債。

要決定的項目

系統架構

• 整體架構：單體式 vs 微服務
• 執行環境：地端部署 vs 雲端
• 擴充性：可承受多大的負載

各部分的實作技術

• 前端：React / Vue / 其他
• 後端：Node.js / Python / Java / 其他
• 資料庫：PostgreSQL / MongoDB / 其他
• 基礎架構：AWS / GCP / Azure / 其他

具體例子

❌ 危險的選擇
「因為想用最新技術棧，所以用 Rust + GraphQL + Kubernetes 來做」
→ 如果團隊裡沒有人有經驗，開發效率會下降，最後變成負債

✅ 適當的選擇
「因為團隊內很多人有 React 與 Node.js 經驗，所以採用這個技術棧」

■ ⑤整理想實現的內容（Requirements Refinement）

目的：從「看得見的想做事項」中，抽出「真正應該實現的內容」

委託方的「需求」與「本質需求」有時不一樣。

流程

1. 先把委託方提出的需求原封不動列出來
2. 對每一項需求重新追問「為什麼需要？」
3. 只保留本質性的需求

具體例子

需求：「想要從範本一鍵大量建立」
  ↓ 為什麼需要？
本質：「節省手動作業時間」「降低人為錯誤」

結論：
不只是單純的「大量建立功能」
→ 真正目的其實是「提升效率」與「確保品質」
→ 也可能用其他方法達成

例如：
- 自動輸入功能（不使用範本功能）
- 顯示檢查清單（避免錯誤）
等，也都可以列為候選方案

■ ⑥使用者行為情境（User Scenarios）

目的：想像系統實際會怎麼被使用

具體寫出「什麼時候、誰、要做什麼」。

情境中要包含的要素

要素說明例時機什麼時候使用每天早上 8:30、每月初等理由為什麼使用銷售記錄、庫存確認等具體工作要達成什麼「決定明天的備料數量」情境範例

【早會時的庫存確認】

時間：每天早上 8:30
使用者：店鋪經理

流程：
1. 登入系統
2. 確認前一天的銷售
3. 確認庫存不足的商品
4. 通知總部追加下單

應實現的功能：
- 登入功能
- 銷售顯示（含篩選功能）
- 庫存警示（將不足項目醒目顯示）
- 訂單範本（郵件草稿功能）

透過準備多個情境，可以找出原本沒注意到的需求。

6. UI 設計階段：將概念落實成具體畫面

概念確立後，就把使用者介面具體化。

■ 步驟 1：整理草圖項目

先大致決定各畫面要顯示的主要元件。

【商品列表畫面】
- 搜尋表單
- 商品清單
- 分頁器
- 詳細資訊按鈕

■ 步驟 2：思考導覽流程

用圖示表示「使用者會怎麼切換畫面」。

登入畫面
    ↓
選單畫面
    ├→ 商品列表 → 商品詳細 → 購買畫面 → 完成畫面
    ├→ 訂單歷史 → 訂單詳細
    └→ 設定畫面

■ 步驟 3：補上草圖細節

針對各元件明確寫出「這是什麼」與「會顯示什麼」。

要素說明輸入／顯示補充搜尋表單用關鍵字搜尋商品輸入可用多個關鍵字 AND 搜尋商品清單顯示符合條件的商品顯示每 10 筆分頁器詳細按鈕前往所選商品的詳細頁動作點擊後進入詳細畫面---

7. 功能設計階段：從畫面設計功能

UI 整理完成後，再將各功能具體化。

■ 步驟 1：從畫面切換圖挑出功能

分析「從哪個畫面到哪個畫面」，抽出必要功能。

例如：如果有「商品列表 → 詳細 → 購買」這種流程

需要的功能：
- 商品搜尋功能
- 商品取得功能
- 購買處理功能

■ 步驟 2：從顯示項目決定「輸出」

畫面要顯示什麼，就決定功能應該輸出什麼。

【商品詳細畫面顯示的資訊】
  ↓
輸出：商品 ID、商品名稱、說明、價格、庫存狀態、評論

■ 步驟 3：從遷移來源畫面決定「輸入」

使用者在前一個畫面輸入的內容，就是這個功能的輸入。

【搜尋表單中使用者輸入】
輸入：關鍵字、分類篩選、排序方式

【接收這些內容的功能被決定】
功能：商品搜尋（根據關鍵字、分類篩選、排序方式回傳結果）

■ 步驟 4：用樹狀結構整理處理流程

複雜的處理，透過樹狀結構整理後，實作會更明確。

【訂單處理】
├─ 訂單資訊輸入
│  ├─ 選擇送貨地址
│  └─ 選擇付款方式
├─ 保留庫存
│  ├─ 確認庫存
│  ├─ 扣減庫存數量
│  └─ 保留鎖定
└─ 付款處理
   ├─ 傳送至付款閘道
   ├─ 確認結果
   └─ 發生錯誤時回復

這個樹狀圖可以直接用於實作時的模組切分。

■ 步驟 5：拆分功能

大型功能要拆成數個小功能。

【大型功能】
「訂單處理」

【拆分後的功能】
① 訂單資訊驗證
② 確認庫存
③ 執行付款
④ 記錄訂單
⑤ 寄送完成通知信

拆分的優點：

• 比較容易測試
• 比較容易重複利用
• 錯誤處理更清楚
• 可分工並行開發

8. 資料設計階段：決定要保存什麼

功能整理完成後，再詳細設計資料結構。

■ 步驟 1：從前面成果整理出必要欄位

把企劃、UI、功能各階段出現的「資料」全部彙整。

從 UI 得到的資訊：商品名稱、價格、庫存數量
從功能得到的資訊：商品 ID、說明、評論、庫存鎖定
從情境得到的資訊：銷售日期時間、銷售數量

■ 步驟 2：進行資料庫設計

設計有效率的資料表。這個階段不需要完整正規化，實作時再最佳化即可。

【products 資料表】
- product_id（主鍵）
- product_name
- description
- unit_price

【inventory 資料表】
- inventory_id（主鍵）
- product_id（參照 products 資料表）
- stock_quantity
- updated_at

【sales 資料表】
- sales_id（主鍵）
- product_id（參照 products 資料表）
- quantity_sold
- sales_date

9. 常見陷阱（不要做的事）

以下介紹在進行需求定義時很常犯的錯誤。

■ 陷阱 1：把需求與實作規格混在一起

❌ 壞例子

「要用 AWS RDS 實作 PostgreSQL 資料庫」

✅ 好例子

「需要一個可支援多使用者同時存取的
 可擴充資料庫」

重點

• 需求是「想達成什麼」
• 實作規格是「要怎麼做」

在需求定義階段，要聚焦在「要什麼」。至於「怎麼做」，留到實作階段決定。

■ 陷阱 2：模糊的表達

❌ 壞例子

「需要好用的 UI」
「動作要快」
「操作要簡單」

✅ 好例子

「從搜尋到顯示結果需在 3 秒內完成」
「新手可在 3 分鐘內完成基本操作」
「100 筆資料可在 1 秒內載入」

重點

• 用數值或具體例子讓需求可被衡量
• 避免使用「簡單」「很快」這類抽象詞

■ 陷阱 3：缺少使用者視角

❌ 壞例子

「在庫存資料表中新增庫存數量欄位」

✅ 好例子

「店員能在早上的短時間內
 快速確認庫存不足的商品」

重點

• 先想「誰」想做「什麼」
• 優先考慮使用者行為，而不是系統技術細節

10. 需求定義完成時的確認清單

請確認需求定義是否足夠，以下項目都檢查過了嗎。

■ 企劃確認

• 是否清楚記載背景與目的
• 實現後的效益是否具體可量化
• 是否定義了目標使用者

■ UI 確認

• 是否將所有畫面都畫出來
• 畫面切換是否沒有矛盾
• 是否說明了各元件的意圖

■ 功能確認

• 是否定義了所有對應畫面的功能
• 輸入與輸出是否明確
• 是否考慮錯誤情境（通訊失敗、資料不正確等）
• 是否確定外部串接規格

■ 資料確認

• 是否定義了所有必要資料表
• 關聯關係是否適當
• 是否決定資料保存期限

■ 整體

• 委託方是否理解並認同內容（最重要）
• 團隊內是否已共享實作想像
• 無法實作的需求是否已記錄

11. 實作前的最終確認

需求定義結束、準備進入開發前，請做以下最終確認。

■ 願景共享

委託方與開發團隊是否擁有相同願景
是否確認過沒有認知落差？

■ 範圍明確化

要做什麼、不做什麼，界線是否不模糊
階段切分是否清楚？

■ 實作可行性驗證

技術上的課題是否都已列出
預算上的課題是否都已列出
時間上的課題是否都已列出

■ 優先順序決定

在有限制的情況下，優先要做什麼是否已決定
第一階段的最小功能是否已決定

如果以上都確認完成，就表示已經準備好進入開發階段。

總結

重點整理（3 分鐘可讀完）

1. 需求定義就是「滿足讓委託方點頭的條件」

   • 在開始實作前，讓團隊所有人共享同一個願景的過程

2. 認知限制是必要的

   • 技能、技術、期間、預算、人力都有其限制
   • 不存在完美需求，重點是判斷優先順序

3. 要不斷來回反覆

   • 不可能一次就完成完美規格書
   • 在委託方與開發團隊的對話中，需求會逐漸被磨練得更清楚

4. 從 UI、功能、資料三個觀點檢討

   • 所有需求都可以歸到這三類之一
   • 做到無遺漏地檢討，實作會更順利

5. 別忘了使用者視角

   • 一開始就要想「誰」要做「什麼」
   • 優先考慮想實現的價值，而非技術細節

那到底該做什麼❓

現在就能實踐的行動清單

這一週（Day 1-2）

1. 向委託方確認專案的背景與目的
2. 用文字說清楚「能實現什麼」
3. 定義目標使用者

下週（Day 3-5）

1. 簡單畫出整體系統圖
2. 劃定範圍（要做／不做）
3. 寫出多種使用者情境

第二週（Day 6-10）

1. 把主要畫面畫成圖
2. 整理畫面切換流程
3. 明確各功能的輸入與輸出

第三週以後

1. 設計資料表
2. 完成需求定義書
3. 與委託方進行最終確認

優先順序

• 一定要做：願景共享、範圍劃分、使用者情境
• 能做就做：UI 設計、功能設計、資料設計
• 可以晚點做：細部實作規格、最佳化

以上就是給開發成員初學者的需求定義指南。

需求定義不是「做出完美的規格書」，而是「建立團隊所有人朝向同一目標前進的狀態」，這才是最重要的。

透過委託方與開發團隊的對話，需求才會真正被磨練成形。不要害怕提問、確認，然後一起往前進。

株式会社シンシア

株式会社xincere 正在招募沒有實務經驗的工程師與學生工程師實習生，並與他們一起工作。
※ 關於シンシア的工作樣貌，請見這裡

在シンシア，每年大約會有 100 位沒有實務經驗的人申請並接受技術面試。
透過這些經驗，這裡會介紹希望實務未經驗者一定要具備的技術能力（語法）。

原文出處：https://qiita.com/Nao52/items/996735e9b8ff4b3b1255