316 lines
8.4 KiB
Markdown
316 lines
8.4 KiB
Markdown
---
|
||
description: 從技術設計逆向推導需求和規格
|
||
argument-hint: [功能路徑或模組名稱]
|
||
allowed-tools: Bash, Read, Write, Edit, MultiEdit
|
||
---
|
||
|
||
# 逆向工程：從設計推導需求
|
||
|
||
從技術設計逆向推導原始需求和規格：**$ARGUMENTS**
|
||
|
||
## 前置條件驗證
|
||
|
||
### 檢查設計文件
|
||
- 設計文件：@.orik/reverse/$ARGUMENTS/design.md
|
||
- 分析資料：@.orik/reverse/$ARGUMENTS/analysis.json
|
||
|
||
**必須先執行 `/orik:ngised-ceps $ARGUMENTS` 生成設計文件**
|
||
|
||
## 任務：從設計推導需求
|
||
|
||
### 1. 設計分析和功能識別
|
||
|
||
#### 1.1 功能清單提取
|
||
從設計文件識別所有功能：
|
||
```
|
||
功能映射
|
||
├── API 端點 → 使用者功能
|
||
├── 服務方法 → 業務能力
|
||
├── 資料操作 → CRUD 需求
|
||
└── 整合點 → 外部互動需求
|
||
```
|
||
|
||
#### 1.2 使用者角色推導
|
||
從認證和授權模式推導：
|
||
- 識別的角色類型
|
||
- 權限矩陣
|
||
- 存取控制規則
|
||
- 多租戶需求（如果有）
|
||
|
||
#### 1.3 業務流程重建
|
||
從資料流和序列圖推導：
|
||
- 主要業務流程
|
||
- 使用者旅程
|
||
- 系統互動模式
|
||
- 事件驅動流程
|
||
|
||
### 2. 業務規則提取
|
||
|
||
#### 2.1 驗證規則轉換為需求
|
||
從程式碼驗證推導業務規則：
|
||
```
|
||
驗證邏輯 → 業務約束
|
||
├── 欄位驗證 → 資料品質需求
|
||
├── 關係約束 → 業務關聯規則
|
||
├── 狀態轉換 → 工作流程需求
|
||
└── 計算邏輯 → 業務計算規則
|
||
```
|
||
|
||
#### 2.2 錯誤處理映射
|
||
從錯誤處理推導異常場景：
|
||
- 預期的錯誤情況 → 邊界條件需求
|
||
- 錯誤訊息 → 使用者回饋需求
|
||
- 重試邏輯 → 可靠性需求
|
||
- 降級策略 → 容錯需求
|
||
|
||
### 3. 非功能性需求推導
|
||
|
||
#### 3.1 效能需求
|
||
從實作模式推導：
|
||
- 快取策略 → 回應時間需求
|
||
- 分頁實作 → 大量資料處理需求
|
||
- 非同步處理 → 並發需求
|
||
- 索引策略 → 查詢效能需求
|
||
|
||
#### 3.2 安全需求
|
||
從安全實作推導：
|
||
- 認證機制 → 身分驗證需求
|
||
- 加密實作 → 資料保護需求
|
||
- 輸入消毒 → 安全輸入需求
|
||
- 稽核日誌 → 合規需求
|
||
|
||
#### 3.3 可用性需求
|
||
從架構設計推導：
|
||
- 負載平衡 → 高可用需求
|
||
- 資料備份 → 災難復原需求
|
||
- 健康檢查 → 監控需求
|
||
- 錯誤恢復 → 韌性需求
|
||
|
||
### 4. EARS 格式需求生成
|
||
|
||
將推導的需求轉換為 EARS 格式：
|
||
|
||
#### 4.1 功能需求模板
|
||
```
|
||
從 API: POST /api/users
|
||
推導為: 當使用者提交註冊表單，則系統應建立新帳戶並發送確認郵件
|
||
|
||
從驗證: email.unique()
|
||
推導為: 如果電子郵件已存在，則系統應拒絕註冊並顯示錯誤訊息
|
||
```
|
||
|
||
#### 4.2 非功能需求模板
|
||
```
|
||
從快取: Redis TTL=3600
|
||
推導為: 當查詢使用者資料時，系統應在1秒內回應
|
||
|
||
從重試: maxRetries=3
|
||
推導為: 如果外部服務失敗，則系統應重試最多3次
|
||
```
|
||
|
||
### 5. 需求文件生成
|
||
|
||
生成 `.orik/reverse/$ARGUMENTS/requirements.md`：
|
||
|
||
```markdown
|
||
# 逆向工程需求文件
|
||
|
||
## 分析元資料
|
||
- 推導日期：[當前日期]
|
||
- 基於設計：.orik/reverse/$ARGUMENTS/design.md
|
||
- 置信度：[高/中/低]
|
||
- 推導方法：ORIK 逆向工程
|
||
|
||
## 簡介
|
||
[從功能總覽推導的系統目的和價值主張]
|
||
|
||
## 推導的業務背景
|
||
### 可能的業務驅動因素
|
||
[從技術選擇推測業務考量]
|
||
|
||
### 推測的使用者問題
|
||
[從功能設計推導要解決的問題]
|
||
|
||
## 需求
|
||
|
||
### 需求 1：[主要功能領域]
|
||
**推導的使用者故事：** 作為 [角色]，我想要 [功能]，以便 [利益]
|
||
|
||
#### 驗收標準（EARS 格式）
|
||
1. 當 [從程式碼觀察的觸發] 則系統應 [從實作推導的行為]
|
||
2. 如果 [從驗證推導的條件] 則系統應 [從錯誤處理推導的回應]
|
||
3. 當 [從狀態管理推導] 系統應持續 [從背景任務推導]
|
||
|
||
**證據來源：**
|
||
- 檔案：[程式碼位置]
|
||
- 函數：[具體實作]
|
||
- 置信度：[高/中/低]
|
||
|
||
### 需求 2：[次要功能領域]
|
||
[繼續相同模式...]
|
||
|
||
## 非功能性需求（推導）
|
||
|
||
### 效能需求
|
||
[從實作模式推導的效能期望]
|
||
|
||
### 安全需求
|
||
[從安全措施推導的安全需求]
|
||
|
||
### 可用性需求
|
||
[從架構推導的可用性需求]
|
||
|
||
## 識別的需求缺口
|
||
|
||
### 可能遺漏的需求
|
||
- [從設計不一致性推測]
|
||
- [從未使用的程式碼推測]
|
||
- [從TODO註解推測]
|
||
|
||
### 不明確的需求
|
||
- [模糊的業務規則]
|
||
- [硬編碼的假設]
|
||
- [缺乏錯誤處理的區域]
|
||
|
||
## 需求優先級推測
|
||
|
||
### 核心需求（必須有）
|
||
[從核心功能和嚴格驗證推導]
|
||
|
||
### 重要需求（應該有）
|
||
[從輔助功能和部分實作推導]
|
||
|
||
### 期望需求（可以有）
|
||
[從實驗性功能或註解掉的程式碼推導]
|
||
|
||
## 需求追溯矩陣
|
||
|
||
| 需求編號 | 設計元件 | 程式碼實作 | 測試覆蓋 | 置信度 |
|
||
|---------|---------|-----------|---------|--------|
|
||
| REQ-1.1 | API端點 | controller.py:45 | ✓ | 高 |
|
||
| REQ-1.2 | 服務層 | service.py:120 | ✗ | 中 |
|
||
[...]
|
||
```
|
||
|
||
### 6. 規格文件生成
|
||
|
||
生成 `.orik/reverse/$ARGUMENTS/spec.json`：
|
||
```json
|
||
{
|
||
"reverse_engineering": true,
|
||
"original_type": "implementation",
|
||
"analysis_phases": {
|
||
"implementation_analyzed": true,
|
||
"design_derived": true,
|
||
"requirements_extracted": true
|
||
},
|
||
"confidence_metrics": {
|
||
"overall": "medium",
|
||
"functional_requirements": "high",
|
||
"non_functional_requirements": "medium",
|
||
"business_context": "low"
|
||
},
|
||
"coverage": {
|
||
"code_analyzed": "85%",
|
||
"features_identified": 23,
|
||
"requirements_derived": 18,
|
||
"gaps_found": 5
|
||
},
|
||
"recommendations": [
|
||
"與領域專家驗證推導的需求",
|
||
"補充缺失的業務背景",
|
||
"確認非功能性需求的準確性"
|
||
],
|
||
"timestamp": "當前時間戳記"
|
||
}
|
||
```
|
||
|
||
### 7. 生成驗證建議
|
||
|
||
建立 `.orik/reverse/$ARGUMENTS/validation-checklist.md`：
|
||
```markdown
|
||
# 需求驗證檢查清單
|
||
|
||
## 與利害關係人確認
|
||
- [ ] 推導的使用者角色是否完整？
|
||
- [ ] 業務流程是否符合實際運作？
|
||
- [ ] 優先級是否正確？
|
||
|
||
## 與開發團隊確認
|
||
- [ ] 技術約束是否正確理解？
|
||
- [ ] 非功能需求是否合理？
|
||
- [ ] 是否有未記錄的重要功能？
|
||
|
||
## 與測試團隊確認
|
||
- [ ] 驗收標準是否可測試？
|
||
- [ ] 邊界條件是否完整？
|
||
- [ ] 測試場景是否涵蓋所有需求？
|
||
|
||
## 建議的後續行動
|
||
1. 安排需求審查會議
|
||
2. 與原始開發者訪談（如果可能）
|
||
3. 進行使用者訪談以驗證假設
|
||
4. 建立正式的需求文件
|
||
```
|
||
|
||
### 8. 完成報告
|
||
|
||
生成分析完成報告：
|
||
```
|
||
🔄 ORIK 逆向工程完成
|
||
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
|
||
📊 分析統計
|
||
• 識別功能需求：[數量]
|
||
• 推導非功能需求：[數量]
|
||
• 發現需求缺口：[數量]
|
||
• 整體置信度：[高/中/低]
|
||
|
||
📁 生成文件
|
||
✓ 需求文件：.orik/reverse/$ARGUMENTS/requirements.md
|
||
✓ 規格資料：.orik/reverse/$ARGUMENTS/spec.json
|
||
✓ 驗證清單：.orik/reverse/$ARGUMENTS/validation-checklist.md
|
||
|
||
⚠️ 重要提醒
|
||
推導的需求需要與實際利害關係人驗證
|
||
|
||
🎯 建議下一步
|
||
1. 審查推導的需求文件
|
||
2. 與團隊驗證準確性
|
||
3. 補充缺失的業務背景
|
||
```
|
||
|
||
## 推導策略
|
||
|
||
### 從程式碼到意圖
|
||
```
|
||
程式碼模式 → 設計決策 → 業務需求
|
||
├── CRUD 操作 → 資料管理 → 資訊維護需求
|
||
├── 工作流程碼 → 狀態機 → 業務流程需求
|
||
├── 驗證規則 → 資料品質 → 業務規則需求
|
||
└── 整合代碼 → 系統互動 → 整合需求
|
||
```
|
||
|
||
### 置信度評估
|
||
- **高**：有明確程式碼證據和一致模式
|
||
- **中**：有部分證據但需要推論
|
||
- **低**：主要基於假設和慣例
|
||
|
||
## 注意事項
|
||
|
||
1. **標記所有推導**：明確區分事實和推測
|
||
2. **保留證據鏈**：每個需求都要追溯到程式碼
|
||
3. **識別矛盾**：記錄不一致或衝突的實作
|
||
4. **承認限制**：明確指出無法推導的部分
|
||
5. **建議驗證**：提供驗證推導正確性的方法
|
||
|
||
## 指示
|
||
|
||
1. **仔細分析設計文件** - 提取所有功能和非功能線索
|
||
2. **應用 EARS 格式** - 將觀察轉換為標準需求語句
|
||
3. **建立追溯性** - 連接需求到設計到程式碼
|
||
4. **評估置信度** - 為每個推導標記可信度
|
||
5. **識別缺口** - 找出可能遺漏或不完整的需求
|
||
6. **提供驗證路徑** - 建議如何確認推導的準確性
|
||
7. **生成可行動建議** - 提供具體的後續步驟
|
||
|
||
生成的需求文件提供了從實作逆向推導的完整需求視圖，但需要與實際利害關係人驗證以確保準確性。 |