需求分析

BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員: 理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象: 新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式: 循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調: ...

BDD 行為驅動開發使用教學手冊 📘 手冊說明 本手冊專為系統分析師（SA）、業務分析師（BA）、開發人員與測試人員設計,旨在協助團隊成員: 理解 BDD 的核心概念與價值 掌握 Gherkin 語法與規格撰寫 學會將業務需求轉換為可執行的行為規格 建立 BDD 協作開發流程 實踐 BDD 自動化測試 適用對象: 新進系統分析師 想導入 BDD 的開發團隊 需要強化需求溝通的專案經理 負責驗收測試的 QA 人員 使用方式: 循序閱讀各章節,建立完整概念 參考實務案例,模擬實際場景 使用附錄的模板與檢查清單 在專案中逐步導入與實踐 📑 目錄 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD 1.2 BDD 與 TDD、ATDD 的差異 1.3 為什麼要導入 BDD 1.4 BDD 的價值與應用場景 1.5 BDD 在軟體開發生命週期(SDLC)中的位置 第二章　BDD 的三大支柱 2.1 Discovery(需求探索) 2.2 Formulation(範例定義) 2.3 Automation(自動化驗證) 第三章　BDD 的核心語法:Gherkin 3.1 Gherkin 語法結構與規則 3.2 Feature、Scenario、Scenario Outline 進階應用 3.3 範例:從需求敘述轉為 Gherkin 規格 3.4 常見錯誤與最佳實務 第四章　BDD 與系統分析的整合應用 4.1 如何將業務需求轉化為可執行行為 4.2 與利害關係人共創範例(Example Mapping) 4.3 User Story 與 BDD 的結合方式 4.4 Acceptance Criteria(驗收準則)的撰寫指引 4.5 從 BDD 到 Use Case 的對應關係 第五章　BDD 開發流程與角色分工 5.1 BDD 工作流(Workflow)全貌 5.2 三方會談(Three Amigos:BA/SA、Dev、QA) 5.3 SA 在 BDD 流程中的責任與產出 5.4 實務文件產出範例 5.5 維護與版本控管實務 第六章　BDD 自動化測試實作 6.1 常見 BDD 工具比較 6.2 環境安裝與專案結構 6.3 Feature 與 Step Definitions 的關聯 6.4 CI/CD 整合實務 6.5 測試報告與追蹤機制 第七章　BDD 實戰案例 7.1 案例一:Web 登入驗證流程 7.2 案例二:銀行轉帳業務流程 7.3 案例三:批次系統業務規則驗證 7.4 案例四:API 行為測試 7.5 案例回顧與行為重構 第八章　導入策略與組織落地 8.1 組織 BDD 成熟度評估 8.2 BDD 導入計畫範本 8.3 克服導入 BDD 的常見障礙 8.4 建立 BDD 協作文化 8.5 成功導入的關鍵因素 第九章　高階應用與延伸 9.1 AI 輔助 BDD 實踐 9.2 BDD 與 Specification by Example (SBE) 整合 9.3 微服務架構下的 BDD 挑戰 9.4 BDD 的未來趨勢 第十章　附錄 10.1 Gherkin 語法速查表 10.2 BDD 文件模板 10.3 常見 BDD 工具與插件 10.4 推薦學習資源 10.5 BDD 完整檢查清單 第一章　認識 BDD:行為驅動開發的核心理念 1.1 什麼是 BDD BDD (Behavior-Driven Development,行為驅動開發) 是一種軟體開發方法論,強調: ...

UI/UX 設計指引範本 Prompt 目標 指導 AI 進行用戶體驗和使用者介面設計，建立以使用者為中心的設計規範和原型。 角色設定 你是一位資深 UI/UX 設計師，具備豐富的使用者體驗設計經驗，熟悉設計思維、使用者研究方法和現代化介面設計原則。 任務描述 請協助我完成 {專案名稱} 的 UI/UX 設計工作。 專案設計背景 專案名稱: {填入專案名稱} 產品類型: {填入產品類型，如：Web應用、Mobile App、桌面應用} 目標使用者: {填入主要使用者群體} 使用情境: {填入主要使用場景} 設計風格偏好: {填入設計風格，如：簡約、現代、傳統} 品牌色彩: {填入品牌主色調} UI/UX 設計要求 請按照以下結構進行設計： 1. 使用者研究 使用者角色建立 使用者旅程地圖 痛點分析 需求優先級排序 2. 資訊架構設計 內容結構規劃 導航系統設計 資訊層級設計 搜尋和篩選機制 3. 互動設計 使用者流程設計 互動原型設計 微互動設計 回饋機制設計 4. 視覺設計 設計系統建立 色彩配置方案 字體系統設計 圖示和插圖風格 5. 響應式設計 多裝置適配策略 斷點設計規劃 彈性佈局設計 觸控優化設計 6. 無障礙設計 可及性標準遵循 色彩對比度檢查 鍵盤導航支援 螢幕閱讀器相容 輸出格式 # {專案名稱} UI/UX 設計規格 ## 1. 使用者研究 ### 1.1 使用者角色 (Personas) #### 主要使用者角色: [角色名稱] **基本資訊:** - 年齡: [年齡範圍] - 職業: [職業類型] - 技術熟悉度: [初級/中級/高級] - 使用裝置: [主要使用的裝置] **目標和需求:** - 主要目標: [使用者想要達成的目標] - 次要需求: [附加需求清單] - 成功指標: [如何衡量目標達成] **行為特徵:** - 使用習慣: [典型的使用模式] - 偏好: [介面和功能偏好] - 挫折點: [常見的困擾] **情境描述:** "[一段描述使用者在什麼情況下會使用這個產品的情境故事]" ### 1.2 使用者旅程地圖 #### 旅程階段1: 發現階段 **使用者行為:** [使用者在此階段的行為] **想法和感受:** [使用者的心理狀態] **觸點:** [與產品的接觸點] **痛點:** [遇到的問題] **機會點:** [改善的機會] #### 旅程階段2: 探索階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] #### 旅程階段3: 使用階段 **使用者行為:** [行為描述] **想法和感受:** [心理狀態] **觸點:** [接觸點] **痛點:** [問題點] **機會點:** [改善機會] ### 1.3 痛點分析矩陣 | 痛點 | 頻率 | 嚴重性 | 影響範圍 | 解決優先級 | |------|------|--------|----------|------------| | [痛點1] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | | [痛點2] | [高/中/低] | [高/中/低] | [影響的使用者比例] | [高/中/低] | ## 2. 資訊架構設計 ### 2.1 網站地圖 首頁 ├── 產品/服務 │ ├── 產品分類A │ ├── 產品分類B │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定 ...

使用者故事撰寫範本 Prompt 目標 指導 AI 撰寫高品質的使用者故事，包含完整的驗收標準和估算資訊。 角色設定 你是一位敏捷開發專家和產品負責人，具備豐富的使用者故事撰寫經驗，熟悉敏捷開發方法論和最佳實務。 任務描述 請協助我為 {專案名稱} 撰寫完整的使用者故事集合。 專案背景資訊 專案名稱: {填入專案名稱} 產品類型: {填入產品類型} 目標使用者: {填入主要使用者群體} 業務目標: {填入主要業務目標} Sprint 週期: {填入 Sprint 長度，如：2週} 故事撰寫要求 請按照以下標準撰寫使用者故事： 1. 故事結構 使用標準的「作為…我希望…以便…」格式 包含明確的角色定義 描述具體的功能需求 說明清楚的價值目標 2. 驗收標準 使用 Given-When-Then 格式 涵蓋正常流程和例外情況 包含可測試的條件 定義明確的完成標準 3. 故事估算 使用故事點數進行估算 考慮複雜度、工作量和風險 提供估算理由說明 建議任務分解方式 4. 優先級排序 定義業務價值優先級 考慮技術相依性 評估風險和不確定性 建議開發順序 輸出格式 # {專案名稱} 使用者故事清單 ## 產品願景 {產品願景陳述} ## 使用者角色 (Personas) ### 角色1: [角色名稱] **角色描述:** [詳細描述] **主要目標:** [目標列表] **技術能力:** [技術水平] **使用情境:** [典型使用場景] **痛點問題:** [主要困擾] ## Epic 史詩故事 ### Epic 1: [Epic 名稱] **Epic 描述:** [Epic 整體描述] **業務價值:** [價值說明] **成功指標:** [衡量標準] **相關使用者:** [涉及的使用者角色] ## 使用者故事清單 ### 故事 ID: US001 **故事標題:** [簡短描述性標題] **使用者故事:** 作為 [使用者角色] 我希望 [功能描述] 以便 [價值/目標] **商業價值:** [具體的商業價值描述] **驗收標準:** #### 場景1: [正常流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景2: [替代流程場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] #### 場景3: [例外處理場景] **Given** [前置條件] **When** [執行動作] **Then** [預期結果] **定義完成 (Definition of Done):** - [ ] [完成條件1] - [ ] [完成條件2] - [ ] [完成條件3] - [ ] 通過所有自動化測試 - [ ] 通過程式碼審查 - [ ] 更新相關文檔 **故事點數:** [點數] 點 **估算理由:** [估算考量因素] **優先級:** [高/中/低] **優先級理由:** [排序理由] **相依性:** - 前置需求: [相依的其他故事] - 阻擋因素: [可能的阻礙] **備註:** [額外的技術或業務考量] --- ### 故事 ID: US002 [重複上述格式...] ## 故事地圖 (Story Map) ### 使用者旅程階段1: [階段名稱] - US001: [故事標題] - US002: [故事標題] ### 使用者旅程階段2: [階段名稱] - US003: [故事標題] - US004: [故事標題] ## Release 規劃 ### Release 1.0 (MVP) **發布目標:** [MVP 目標] **包含故事:** US001, US002, US003 **預計時間:** [時間範圍] **風險評估:** [主要風險點] ### Release 2.0 **發布目標:** [下一版本目標] **包含故事:** US004, US005, US006 **預計時間:** [時間範圍] ## 故事估算總結 | 故事ID | 故事標題 | 故事點數 | 優先級 | Sprint | |--------|----------|----------|--------|--------| | US001 | [標題] | [點數] | [優先級] | [建議Sprint] | | US002 | [標題] | [點數] | [優先級] | [建議Sprint] | **總估算:** [總點數] 故事點數 **預估 Sprint 數:** [Sprint 數量] 故事撰寫最佳實務 INVEST 原則 Independent (獨立): 故事應該盡可能獨立 Negotiable (可協商): 細節可以協商調整 Valuable (有價值): 對使用者有明確價值 Estimable (可估算): 團隊能夠估算工作量 Small (小): 在一個 Sprint 內完成 Testable (可測試): 有明確的驗收標準 3C 模型 Card (卡片): 故事的簡短描述 Conversation (對話): 團隊間的討論 Confirmation (確認): 驗收標準 故事拆分技巧 按工作流程拆分: 將大故事按步驟分解 按資料變化拆分: 根據不同資料類型分解 按操作拆分: 增加、修改、刪除、查詢 按使用者角色拆分: 不同角色的需求 按介面拆分: Web、Mobile、API 品質檢查清單 使用標準的故事格式 包含明確的使用者角色 描述具體的功能需求 說明清楚的價值目標 提供完整的驗收標準 包含正常和例外流程 故事大小適中 (1-8 點) 具備可測試性 標示優先級和相依性 符合 INVEST 原則 使用範例 範例：線上書店購物車功能 使用者角色 角色: 線上購書者 描述: 25-45歲的上班族，喜歡閱讀，經常在線上購買書籍 目標: 方便快速地選購和購買書籍 技術能力: 中等，熟悉基本網路操作 ...

功能需求分析範本 Prompt 目標 指導 AI 進行系統化的功能需求分析，產生詳細的功能需求規格文檔。 角色設定 你是一位資深系統分析師，具備豐富的功能需求分析經驗，能夠將業務需求轉換為詳細的功能規格。 任務描述 請協助我完成 {專案名稱} 的功能需求分析工作。 專案背景資訊 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 主要使用者角色: {填入使用者角色列表} 核心業務流程: {填入核心業務流程} 分析要求 請按照以下結構進行功能需求分析： 1. 使用者故事分析 識別主要使用者角色 撰寫使用者故事 定義驗收標準 設定故事點數估算 2. 功能分解結構 系統功能模組劃分 子功能識別 功能相依關係分析 功能優先級排序 3. 介面需求定義 使用者介面需求 系統介面需求 外部整合介面 API 需求規格 4. 資料流程分析 輸入資料定義 處理邏輯描述 輸出結果規格 資料驗證規則 5. 效能需求 響應時間要求 吞吐量需求 並發使用者數 資源使用限制 6. 安全需求 身份驗證需求 授權控制要求 資料保護需求 稽核日誌需求 輸出格式 # {專案名稱} 功能需求規格文檔 ## 1. 使用者故事 ### 1.1 使用者角色定義 | 角色 | 描述 | 主要職責 | 技術能力 | |------|------|----------|----------| | [角色名稱] | [角色描述] | [主要職責] | [技術能力評估] | ### 1.2 使用者故事列表 #### 故事 ID: US001 **作為** [使用者角色] **我希望** [功能描述] **以便** [價值/目標] **驗收標準:** - [ ] [標準1] - [ ] [標準2] - [ ] [標準3] **故事點數:** [點數] **優先級:** [高/中/低] ## 2. 功能分解結構 ### 2.1 功能模組圖 系統名稱 ├── 模組A │ ├── 子功能A1 │ ├── 子功能A2 │ └── 子功能A3 ├── 模組B │ ├── 子功能B1 │ └── 子功能B2 └── 模組C ├── 子功能C1 └── 子功能C2 ...

安全需求識別範本 Prompt 目標 指導 AI 進行全面的安全需求分析，建立符合 SSDLC 標準的安全需求規格。 角色設定 你是一位資深資訊安全顧問，具備豐富的安全需求分析和威脅建模經驗，熟悉各種安全框架和標準。 任務描述 請協助我完成 {專案名稱} 的安全需求識別和分析工作。 專案安全背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型，如：Web應用、API服務、移動應用} 資料敏感度: {填入資料敏感度等級，如：公開、內部、機密、極機密} 合規要求: {填入相關法規或標準，如：GDPR、HIPAA、PCI-DSS} 威脅等級: {填入威脅等級評估，如：低、中、高、極高} 安全分析框架 請按照以下結構進行安全需求分析： 1. 威脅建模分析 資產識別與分類 威脅行為者分析 攻擊向量識別 威脅情境建模 2. 風險評估 威脅可能性評估 影響程度分析 風險等級計算 風險處理策略 3. 安全控制需求 預防性控制 偵測性控制 回應性控制 復原性控制 4. 合規性需求 法規要求分析 標準符合性檢查 稽核要求定義 報告需求規劃 5. 資料保護需求 資料分類要求 資料生命週期保護 隱私保護需求 資料銷毀要求 6. 基礎設施安全 網路安全要求 主機安全要求 應用程式安全 雲端安全要求 輸出格式 # {專案名稱} 安全需求規格文檔 ## 1. 威脅建模分析 ### 1.1 資產識別與分類 | 資產類型 | 資產名稱 | 機密性 | 完整性 | 可用性 | 業務影響 | |----------|----------|--------|--------|--------|----------| | 資料資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 系統資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | | 人員資產 | [資產名稱] | [高/中/低] | [高/中/低] | [高/中/低] | [影響描述] | ### 1.2 威脅行為者分析 #### 威脅行為者: [行為者類型] **動機:** [攻擊動機] **能力等級:** [初級/中級/高級/專家] **攻擊手法:** [常用攻擊方法] **目標資產:** [主要攻擊目標] ### 1.3 威脅情境 #### 威脅情境 ID: T001 **威脅名稱:** [威脅名稱] **威脅描述:** [詳細描述] **攻擊路徑:** [攻擊步驟] **影響資產:** [受影響的資產] **可能性:** [很低/低/中/高/很高] **影響程度:** [輕微/低/中/高/嚴重] ## 2. 風險評估 ### 2.1 風險矩陣 | 威脅ID | 威脅名稱 | 可能性 | 影響程度 | 風險等級 | 處理策略 | |--------|----------|--------|----------|----------|----------| | T001 | [威脅名稱] | [評分] | [評分] | [風險等級] | [接受/減輕/轉移/避免] | ### 2.2 高風險項目處理計畫 #### 風險ID: R001 **風險描述:** [風險說明] **處理策略:** [減輕措施] **負責人員:** [負責人] **預計完成時間:** [時間] **成功標準:** [衡量指標] ## 3. 安全控制需求 ### 3.1 身份驗證與授權 **需求ID:** AC001 **控制目標:** 確保只有經過驗證的使用者能夠存取系統 **實作要求:** - 多因子驗證 (MFA) - 強密碼政策 - 帳戶鎖定機制 - Session 管理 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.2 資料加密 **需求ID:** CR001 **控制目標:** 保護敏感資料的機密性 **實作要求:** - 傳輸中加密 (TLS 1.3) - 靜態資料加密 (AES-256) - 金鑰管理機制 - 加密強度要求 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ### 3.3 安全監控 **需求ID:** MN001 **控制目標:** 即時偵測安全事件 **實作要求:** - 安全事件記錄 - 異常行為偵測 - 即時告警機制 - 事件關聯分析 **測試方法:** [測試步驟] **符合標準:** [相關標準條款] ## 4. 合規性需求 ### 4.1 法規要求對照表 | 法規名稱 | 條款編號 | 要求內容 | 對應控制措施 | 實作狀態 | |----------|----------|----------|--------------|----------| | [法規名稱] | [條款] | [要求說明] | [控制措施] | [待實作/已實作] | ### 4.2 稽核要求 **稽核頻率:** [年度/季度/月度] **稽核範圍:** [稽核項目清單] **稽核標準:** [依據的標準或框架] **報告要求:** [報告格式和提交時間] ## 5. 資料保護需求 ### 5.1 資料分類標準 | 分類等級 | 標籤 | 存取控制 | 處理要求 | 保存期限 | |----------|------|----------|----------|----------| | 公開 | Public | [控制要求] | [處理方式] | [保存期限] | | 內部 | Internal | [控制要求] | [處理方式] | [保存期限] | | 機密 | Confidential | [控制要求] | [處理方式] | [保存期限] | | 極機密 | Top Secret | [控制要求] | [處理方式] | [保存期限] | ### 5.2 隱私保護要求 **個人資料處理原則:** - 合法性和透明度 - 目的限制原則 - 資料最小化原則 - 準確性維護 - 保存期限限制 - 完整性和機密性 ## 6. 基礎設施安全需求 ### 6.1 網路安全 - 網路分段和隔離 - 防火牆和入侵防護 - DDoS 防護機制 - 網路流量監控 ### 6.2 應用程式安全 - 安全編碼實務 - 輸入驗證機制 - 輸出編碼處理 - 錯誤處理機制 ### 6.3 雲端安全 (如適用) - 雲端服務安全配置 - 資料隔離要求 - 存取控制管理 - 雲端監控要求 威脅建模工具建議 STRIDE 分析框架 Spoofing (偽裝): 身份偽造威脅 Tampering (竄改): 資料完整性威脅 Repudiation (否認): 不可否認性威脅 Information Disclosure (資訊洩露): 機密性威脅 Denial of Service (拒絕服務): 可用性威脅 Elevation of Privilege (特權提升): 授權威脅 PASTA 方法論 定義目標 (Define Objectives) 技術範圍定義 (Define Technical Scope) 應用程式分解 (Application Decomposition) 威脅分析 (Threat Analysis) 弱點分析 (Vulnerability Analysis) 攻擊建模 (Attack Modeling) 風險影響分析 (Risk Impact Analysis) 品質檢查清單 完整的資產識別和分類 全面的威脅情境分析 定量化的風險評估 具體的安全控制措施 明確的合規性對照 詳細的資料保護要求 可測試的安全需求 可追溯的需求編號 使用範例 範例：電子商務平台安全需求 威脅情境範例 威脅ID: T001 威脅名稱: SQL 注入攻擊 威脅描述: 攻擊者透過惡意 SQL 語句存取資料庫 攻擊路徑: ...

客戶需求訪談與分析技巧指引 文件資訊 文件版本：1.0 建立日期：2025年8月13日 目標讀者：新進專案經理（0-2年經驗） 適用範圍：金融、IT與大型系統整合專案 目錄 前言 前置準備 訪談進行技巧 訪談紀錄與整理 需求分析方法 需求驗證與確認 跨文化與遠端訪談技巧 數位化工具應用 品質控制與持續改善 常見錯誤與避免方法 實際案例分析 附錄 參考資料 1. 前言 1.1 指引目的 本指引旨在協助新進專案經理掌握客戶需求訪談與分析的核心技巧，提升專案成功率並降低需求變更風險。 1.2 需求訪談的重要性 專案成功關鍵：85% 的專案失敗源於需求理解不足或溝通不良 成本控制：前期準確的需求分析可降低後期變更成本達 10-100 倍 客戶滿意度：清楚的需求理解是客戶滿意度的基礎 1.3 適用情境 新專案啟動階段的需求收集 現有系統功能擴充或改版 系統整合專案的介面需求確認 使用者體驗改善專案 2. 前置準備 2.1 訪談前資料蒐集 2.1.1 必要資料清單 組織架構資料 客戶組織圖與部門職掌 關鍵決策者與影響者清單 內部溝通流程與層級關係 業務背景資料 客戶業務模式與營運流程 現有系統架構與使用狀況 過去類似專案的經驗與學習 技術環境資料 現有 IT 基礎架構 技術標準與限制條件 資安與合規要求 實務案例：在銀行核心系統專案中，PM 提前了解該行的組織架構，發現風險管理部門在系統需求上有關鍵決策權，因此將其納入主要訪談對象，避免後期需求變更。 2.1.2 資料蒐集管道 正式管道 客戶提供的 RFP（Request for Proposal）文件 組織年報與公開資訊 官方網站與產品說明文件 非正式管道 ...

業務需求收集範本 Prompt 目標 協助 AI 理解如何進行系統性的業務需求收集，產生完整的業務需求文檔。 角色設定 你是一位資深業務分析師，具備豐富的需求收集經驗，能夠透過結構化的方法收集、分析和文檔化業務需求。 任務描述 請協助我完成 {專案名稱} 的業務需求收集工作。 專案背景資訊 專案名稱: {填入專案名稱} 專案類型: {填入專案類型，如：Web應用、移動應用、桌面應用等} 目標使用者: {填入目標使用者群體} 業務領域: {填入業務領域，如：電商、金融、教育等} 專案規模: {填入專案規模，如：小型、中型、大型} 具體要求 請按照以下結構產生業務需求文檔： 1. 專案概述 專案目標與願景 成功標準定義 專案範圍界定 主要限制條件 2. 利害關係人分析 識別所有利害關係人 分析各利害關係人的需求和期望 定義利害關係人的影響力和重要性 建立溝通策略 3. 業務流程分析 現有業務流程描述 問題點識別 改善機會分析 未來流程設計 4. 功能需求概述 核心功能列表 次要功能列表 可選功能列表 功能優先級排序 5. 業務規則 業務邏輯規則 驗證規則 計算規則 工作流程規則 6. 資料需求 主要資料實體 資料關係 資料品質要求 資料安全要求 輸出格式 請使用以下 Markdown 格式輸出： # {專案名稱} 業務需求文檔 ## 1. 專案概述 ### 1.1 專案目標與願景 [詳細描述] ### 1.2 成功標準 [具體的、可測量的成功標準] ### 1.3 專案範圍 [明確的範圍界定] ### 1.4 限制條件 [技術、時間、預算等限制] ## 2. 利害關係人分析 ### 2.1 利害關係人清單 | 角色 | 姓名/部門 | 需求/期望 | 影響力 | 重要性 | |------|----------|----------|--------|--------| | [角色] | [姓名] | [需求] | [高/中/低] | [高/中/低] | ### 2.2 溝通策略 [溝通方式和頻率] ## 3. 業務流程分析 ### 3.1 現有流程 [流程描述或流程圖] ### 3.2 問題分析 [問題點列表及影響分析] ### 3.3 改善建議 [具體改善方案] ## 4. 功能需求概述 ### 4.1 核心功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.2 次要功能 - [功能1]: [描述] - [功能2]: [描述] ### 4.3 功能優先級 | 功能 | 優先級 | 理由 | |------|--------|------| | [功能] | [高/中/低] | [理由] | ## 5. 業務規則 ### 5.1 業務邏輯規則 - [規則1]: [描述] - [規則2]: [描述] ### 5.2 驗證規則 - [規則1]: [描述] - [規則2]: [描述] ## 6. 資料需求 ### 6.1 資料實體 - [實體1]: [屬性列表] - [實體2]: [屬性列表] ### 6.2 資料品質要求 - 準確性: [要求] - 完整性: [要求] - 一致性: [要求] 品質檢查清單 請確保產生的文檔包含以下要素： ...

專案系統分析指引 目錄 系統分析階段目標與產出物 需求收集與分析流程 涉及角色與職責 系統分析方法與工具 4.1 UML 建模方法 4.2 資料流程圖 (DFD) 4.3 實體關係圖 (ERD) 4.4 物件導向分析方法 (OOA) 4.5 狀態圖 4.6 分析模型整合 跨系統整合分析 安全與合規考量 版本控管與審核流程 範例與模板 8.1 需求規格書模板 8.2 用例描述表模板 8.3 物件導向分析模板 8.4 系統功能列表模板 8.5 需求變更申請表模板 總結與最佳實踐 敏捷開發環境下的系統分析 數據驅動的需求分析 雲端架構考量 國際化與在地化需求 效能與容量規劃 災難恢復與營運連續性 附錄 文件資訊 文件名稱：專案系統分析指引 版本：2.0 建立日期：2025年8月11日 最後更新：2025年8月29日 適用專案：大型共用平台系統 技術架構：前後端分離 + Clean Architecture + 雲端原生 1. 系統分析階段目標與產出物 1.1 階段目標 系統分析階段是軟體開發生命週期中的關鍵環節，主要目標包括： 需求理解與定義：深入理解業務需求，並將其轉化為明確的系統需求 系統邊界確立：明確定義系統的範圍、功能邊界與非功能需求 風險識別與評估：識別技術風險、業務風險及安全風險 可行性分析：評估技術可行性、經濟可行性與時程可行性 架構規劃基礎：為後續的系統設計階段提供清晰的需求基礎 1.2 工作範圍 1.2.1 業務分析範圍 現有系統分析與問題識別 業務流程梳理與優化建議 利害關係人需求收集 業務規則定義與驗證 使用者體驗需求分析 1.2.2 技術分析範圍 系統功能需求分析 非功能需求定義（效能、安全、可用性等） 系統整合需求分析 資料流程與資料模型分析 介面需求定義 1.2.3 安全分析範圍 威脅建模與風險評估 安全需求定義 合規要求分析 資料保護需求 存取控制需求 1.3 主要產出物清單 1.3.1 需求文件 業務需求規格書 (Business Requirements Specification, BRS) 系統需求規格書 (System Requirements Specification, SRS) 功能需求規格書 (Functional Requirements Specification, FRS) 非功能需求規格書 (Non-Functional Requirements Specification, NFRS) 使用者需求文件 (User Requirements Document, URD) 1.3.2 分析模型與圖表 用例圖 (Use Case Diagrams) 用例描述表 (Use Case Specifications) 業務流程圖 (Business Process Diagrams) 資料流程圖 (Data Flow Diagrams, DFD) 實體關係圖 (Entity Relationship Diagrams, ERD) 狀態圖 (State Diagrams) 活動圖 (Activity Diagrams) 循序圖 (Sequence Diagrams) 1.3.3 整合與介面文件 系統整合需求規格書 (System Integration Requirements) API 需求規格書 (API Requirements Specification) 批次處理需求規格書 (Batch Processing Requirements) 資料交換格式定義 (Data Exchange Format Specification) 外部系統介面規格 (External System Interface Specification) 1.3.4 安全與合規文件 安全需求規格書 (Security Requirements Specification) 威脅模型文件 (Threat Model Document) 風險評估報告 (Risk Assessment Report) 合規檢查清單 (Compliance Checklist) 資料保護影響評估 (Data Protection Impact Assessment, DPIA) 1.3.5 測試相關文件 測試需求規格書 (Test Requirements Specification) 驗收標準定義 (Acceptance Criteria Definition) 測試案例大綱 (Test Case Outline) 1.3.6 專案管理文件 需求追蹤矩陣 (Requirements Traceability Matrix, RTM) 變更控制文件 (Change Control Document) 需求優先級矩陣 (Requirements Priority Matrix) 影響分析報告 (Impact Analysis Report) 2. 需求收集與分析流程 2.1 需求收集流程 2.1.1 準備階段 flowchart TD A[專案啟動] --> B[組建分析團隊] B --> C[制定分析計劃] C --> D[識別利害關係人] D --> E[準備訪談資料] E --> F[安排訪談時程] 主要活動： ...