Prompts

API 設計範本 Prompt 目標 指導 AI 進行RESTful API設計，產生完整的API規格文檔和設計指南。 角色設定 你是一位資深API架構師，具備豐富的API設計經驗，熟悉RESTful設計原則、OpenAPI規範和API最佳實務。 任務描述 請協助我完成 {專案名稱} 的API設計工作。 API 背景資訊 專案名稱: {填入專案名稱} API 類型: {填入API類型，如：RESTful、GraphQL、gRPC} 主要功能領域: {填入主要業務領域} 預期使用者: {填入API使用者類型，如：前端應用、第三方系統、移動應用} 安全等級: {填入安全要求等級} API 設計要求 請按照以下結構進行API設計： 1. API 概覽設計 API 目標和範圍定義 資源模型設計 URL 結構規劃 HTTP 方法對應 2. 資料模型設計 實體關係模型 JSON Schema 定義 資料驗證規則 錯誤回應格式 3. 端點詳細設計 CRUD 操作設計 查詢和篩選設計 分頁機制設計 排序機制設計 4. 安全性設計 身份驗證機制 授權控制設計 API 金鑰管理 速率限制設計 5. 版本控制策略 版本控制方法 向後相容性規劃 廢棄策略設計 遷移指南規劃 6. 文檔和測試 OpenAPI 規格撰寫 使用範例提供 測試案例設計 錯誤處理指南 輸出格式 # {專案名稱} API 設計規格 ## 1. API 概覽 ### 1.1 API 目標 **主要目標:** [API 的主要用途和目標] **次要目標:** [輔助功能和延伸應用] **成功標準:** [API 品質和使用量指標] ### 1.2 API 設計原則 - **RESTful 設計**: 遵循 REST 架構風格 - **一致性**: 統一的命名和回應格式 - **可預測性**: 直觀的 URL 結構和行為 - **可擴展性**: 支援未來功能擴展 - **安全性**: 內建安全機制 ### 1.3 基礎 URL 結構 **Base URL:** `https://api.{domain}.com/v1` **URL 模式:** `/{resource}/{id}/{sub-resource}` ### 1.4 HTTP 方法對應 | HTTP 方法 | 用途 | 冪等性 | 安全性 | |-----------|------|--------|--------| | GET | 查詢資源 | 是 | 是 | | POST | 建立資源 | 否 | 否 | | PUT | 更新/替換資源 | 是 | 否 | | PATCH | 部分更新資源 | 否 | 否 | | DELETE | 刪除資源 | 是 | 否 | ## 2. 資料模型設計 ### 2.1 核心實體模型 #### 實體: User (使用者) ```json { "id": "string (UUID)", "username": "string (3-50字元)", "email": "string (email格式)", "firstName": "string (1-50字元)", "lastName": "string (1-50字元)", "role": "string (enum: admin, user, guest)", "status": "string (enum: active, inactive, suspended)", "createdAt": "string (ISO 8601 datetime)", "updatedAt": "string (ISO 8601 datetime)" } 實體: Product (產品) { "id": "string (UUID)", "name": "string (1-200字元)", "description": "string (可選，最多1000字元)", "price": "number (正數，最多2位小數)", "category": "string", "sku": "string (產品編號)", "inventory": { "quantity": "integer (非負整數)", "reserved": "integer (非負整數)" }, "images": ["string (URL陣列)"], "attributes": { "color": "string", "size": "string", "weight": "number" }, "isActive": "boolean", "createdAt": "string (ISO 8601 datetime)", "updatedAt": "string (ISO 8601 datetime)" } 2.2 標準回應格式 成功回應格式 { "success": true, "data": { // 實際資料內容 }, "meta": { "timestamp": "ISO 8601 datetime", "requestId": "UUID", "pagination": { // 僅分頁查詢時包含 "page": 1, "limit": 20, "total": 100, "totalPages": 5 } } } 錯誤回應格式 { "success": false, "error": { "code": "ERROR_CODE", "message": "錯誤訊息", "details": "詳細錯誤說明", "field": "發生錯誤的欄位 (驗證錯誤時)" }, "meta": { "timestamp": "ISO 8601 datetime", "requestId": "UUID" } } 3. API 端點設計 3.1 使用者管理 API 取得使用者清單 端點: GET /users 描述: 取得使用者清單，支援分頁和篩選 ...

CI/CD 流程範本 Prompt 目標 指導 AI 建立完整的 CI/CD 流程，包含持續整合、持續部署和基礎設施即程式碼。 角色設定 你是一位資深 DevOps 工程師，具備豐富的 CI/CD 流程設計和實作經驗，熟悉各種自動化部署工具和雲端平台。 任務描述 請協助我為 {專案名稱} 建立完整的 CI/CD 流程。 專案 DevOps 背景 專案名稱: {填入專案名稱} 應用架構: {填入應用架構，如：微服務、單體應用} 技術棧: {填入技術棧} 部署平台: {填入目標平台，如：AWS、Azure、GCP、Kubernetes} 團隊規模: {填入團隊人數} 發布頻率: {填入預期發布頻率} CI/CD 設計要求 請按照以下結構設計 CI/CD 流程： 1. 持續整合設計 原始碼管理策略 建置流程設計 自動化測試整合 程式碼品質門檻 2. 持續部署設計 部署策略選擇 環境管理規劃 發布流程設計 回退機制設計 3. 基礎設施管理 基礎設施即程式碼 環境配置管理 監控和告警設置 安全性配置 4. 自動化工具整合 CI/CD 工具選擇 容器化策略 編排工具配置 工具鏈整合 5. 品質和安全 程式碼掃描整合 漏洞檢測流程 合規性檢查 稽核日誌管理 6. 監控和運維 應用程式監控 基礎設施監控 日誌聚合分析 事件響應流程 輸出格式 # {專案名稱} CI/CD 流程設計 ## 1. 流程概覽 ### 1.1 CI/CD 流程圖 開發者提交程式碼 ↓ 程式碼品質檢查 ↓ 自動化建置 ↓ 自動化測試 ↓ 安全掃描檢查 ↓ 部署到測試環境 ↓ 整合測試執行 ↓ 部署到預生產環境 ↓ 使用者驗收測試 ↓ 部署到生產環境 ↓ 監控和回饋 ...

SSDLC 專案範本指南 簡介 本指南提供安全軟體開發生命週期 (Secure Software Development Life Cycle, SSDLC) 的完整範本體系，旨在協助團隊透過 AI 輔助完成專案的各個階段開發任務。 SSDLC 階段概覽 1. 需求分析階段 (Requirements Analysis) 目標: 收集、分析並定義專案需求，建立安全需求規範 工作項目 業務需求收集 功能需求分析 非功能需求定義 安全需求識別 使用者故事撰寫 風險評估 技術細節和業務需求 需求追溯矩陣 安全威脅模型分析 合規性要求檢查 效能基準定義 2. 設計開發階段 (Design & Development) 目標: 進行系統架構設計和安全編碼實作 工作項目 系統架構設計 安全架構設計 資料庫設計 API 設計 編碼實作 程式碼審查 技術細節和業務需求 設計模式應用 安全編碼標準 程式碼品質標準 版本控制策略 3. 測試驗收階段 (Testing & Validation) 目標: 執行全面測試並進行安全驗證 工作項目 單元測試 整合測試 系統測試 效能測試 安全測試 使用者驗收測試 技術細節和業務需求 測試策略制定 自動化測試框架 安全測試工具 測試覆蓋率要求 4. 部署運維階段 (Deployment & Operations) 目標: 安全部署系統並建立持續監控機制 ...

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 │ └── 產品詳細頁 ├── 關於我們 │ ├── 公司介紹 │ ├── 團隊介紹 │ └── 聯絡我們 ├── 支援中心 │ ├── 常見問題 │ ├── 使用指南 │ └── 技術支援 └── 使用者帳戶 ├── 個人資料 ├── 訂單記錄 └── 設定 ...

SSDLC Prompt 範本使用指南 概述 本文檔提供完整的 SSDLC (Secure Software Development Life Cycle) Prompt 範本使用指南，協助團隊透過 AI 輔助完成各階段的開發任務。 範本結構說明 目錄組織 .github/prompts/ ├── SSDLC_專案範本指南.md # 主要指南文檔 ├── 需求分析/ │ ├── 業務需求收集範本.md │ ├── 功能需求分析範本.md │ ├── 安全需求識別範本.md │ └── 使用者故事撰寫範本.md ├── 設計開發/ │ ├── 系統架構設計範本.md │ ├── API設計範本.md │ └── [其他設計範本] ├── 測試驗收/ │ ├── 測試策略制定範本.md │ ├── 自動化測試範本.md │ └── [其他測試範本] └── 部署運維/ ├── CI_CD流程範本.md └── [其他運維範本] 快速開始指南 步驟 1: 選擇適當的範本 根據當前專案階段選擇對應的範本： 需求分析階段: 從業務需求收集開始 設計開發階段: 從系統架構設計開始 測試驗收階段: 從測試策略制定開始 部署運維階段: 從 CI/CD 流程設計開始 步驟 2: 填寫專案資訊 每個範本都包含專案背景資訊區塊，需要填入： ...

使用者故事撰寫範本 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 語句存取資料庫 攻擊路徑: ...

業務需求收集範本 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 資料品質要求 - 準確性: [要求] - 完整性: [要求] - 一致性: [要求] 品質檢查清單 請確保產生的文檔包含以下要素： ...

測試策略制定範本 Prompt 目標 指導 AI 制定全面的軟體測試策略，涵蓋各種測試類型和測試方法。 角色設定 你是一位資深測試架構師和品質保證專家，具備豐富的測試策略規劃經驗，熟悉各種測試方法論和自動化測試框架。 任務描述 請協助我為 {專案名稱} 制定完整的測試策略。 專案測試背景 專案名稱: {填入專案名稱} 系統類型: {填入系統類型} 技術棧: {填入主要技術棧} 團隊規模: {填入開發團隊人數} 專案時程: {填入專案開發週期} 品質要求: {填入品質標準要求} 測試策略要求 請按照以下結構制定測試策略： 1. 測試目標和範圍 測試目標定義 測試範圍界定 品質標準設定 風險評估分析 2. 測試類型規劃 功能測試策略 非功能測試策略 安全測試策略 相容性測試策略 3. 測試層級設計 單元測試策略 整合測試策略 系統測試策略 驗收測試策略 4. 自動化測試規劃 自動化測試範圍 工具選型評估 框架架構設計 CI/CD 整合規劃 5. 測試環境規劃 測試環境需求 資料管理策略 環境配置管理 監控和維護計畫 6. 測試執行計畫 測試階段規劃 資源分配計畫 時程安排規劃 風險應對計畫 輸出格式 # {專案名稱} 測試策略文檔 ## 1. 測試概覽 ### 1.1 測試目標 **主要目標:** - 確保系統功能符合需求規格 - 驗證系統效能達到預期標準 - 保證系統安全性和穩定性 - 提升產品品質和使用者體驗 **品質目標:** - 功能覆蓋率: ≥ 95% - 程式碼覆蓋率: ≥ 80% - 缺陷逃逸率: ≤ 5% - 自動化測試比例: ≥ 70% ### 1.2 測試範圍 #### 包含範圍 - 所有核心業務功能 - 使用者介面和用戶體驗 - API 介面和資料交換 - 系統整合和第三方服務 - 安全性和權限控制 - 效能和可擴展性 #### 排除範圍 - 第三方組件內部邏輯 - 作業系統層級功能 - 網路基礎設施 - 瀏覽器內建功能 ### 1.3 品質標準 | 品質特性 | 標準 | 測量方法 | |----------|------|----------| | 功能性 | 95% 需求符合度 | 測試案例通過率 | | 可靠性 | 99.9% 系統可用性 | 系統監控數據 | | 效能 | 響應時間 < 2秒 | 效能測試報告 | | 易用性 | 8/10 使用者滿意度 | 使用者測試回饋 | | 安全性 | 0 高風險漏洞 | 安全掃描報告 | ## 2. 測試類型策略 ### 2.1 功能測試 #### 2.1.1 單元測試 **目標:** 驗證個別程式碼單元的正確性 **覆蓋率要求:** ≥ 80% **工具:** JUnit 5, Mockito, AssertJ **責任歸屬:** 開發人員 **測試重點:** - 業務邏輯正確性 - 邊界值處理 - 異常情況處理 - 資料驗證邏輯 #### 2.1.2 整合測試 **目標:** 驗證模組間介面和資料流 **類型:** - API 整合測試 - 資料庫整合測試 - 第三方服務整合測試 **工具:** TestContainers, WireMock, REST Assured #### 2.1.3 系統測試 **目標:** 驗證完整系統功能 **測試類型:** - 端對端功能測試 - 業務流程測試 - 使用案例驗證 **工具:** Selenium WebDriver, Cucumber ### 2.2 非功能測試 #### 2.2.1 效能測試 **測試類型:** - 負載測試: 正常負載下的系統表現 - 壓力測試: 超過正常負載的系統表現 - 容量測試: 系統處理能力上限 - 耐久性測試: 長時間運行的穩定性 **效能指標:** - 響應時間: 95% 請求 < 2秒 - 吞吐量: > 1000 TPS - 並發使用者: > 5000 - 資源使用率: CPU < 80%, Memory < 85% **工具:** JMeter, Gatling, K6 #### 2.2.2 安全測試 **測試範疇:** - 身份驗證和授權測試 - 輸入驗證和 SQL 注入防護 - 跨站腳本攻擊 (XSS) 防護 - 跨站請求偽造 (CSRF) 防護 - 敏感資料保護 **工具:** OWASP ZAP, Burp Suite, SonarQube Security #### 2.2.3 相容性測試 **瀏覽器相容性:** - Chrome (最新版本及前2版) - Firefox (最新版本及前2版) - Safari (最新版本及前1版) - Edge (最新版本及前2版) **作業系統相容性:** - Windows 10/11 - macOS (最新版本及前2版) - Ubuntu LTS **裝置相容性:** - 桌面電腦 (1920x1080 以上) - 平板電腦 (768x1024) - 手機 (375x667 以上) ## 3. 測試自動化策略 ### 3.1 自動化測試金字塔 ┌─────────────────┐ │ UI Tests │ ← 少量 (10%) │ (E2E Tests) │ ├─────────────────┤ │ Integration │ ← 中等 (30%) │ Tests │ ├─────────────────┤ │ Unit Tests │ ← 大量 (60%) │ │ └─────────────────┘ ### 3.2 自動化工具選型 #### 單元測試框架 **選擇:** JUnit 5 + Mockito **理由:** - 成熟穩定的 Java 測試框架 - 豐富的斷言和模擬功能 - 良好的 IDE 整合支援 - 活躍的社群和文檔 #### 整合測試工具 **API 測試:** REST Assured **資料庫測試:** TestContainers **模擬服務:** WireMock #### UI 自動化工具 **選擇:** Selenium WebDriver + Page Object Model **輔助工具:** WebDriverManager, Extent Reports ### 3.3 CI/CD 整合 #### 持續整合流程 程式碼提交 → 靜態分析 → 單元測試 → 建置 → 整合測試 → 部署測試環境 → E2E測試 → 產生報告 ...