Requirement Engineering for FDE（FDE 需求工程）

知识库位置：FDE Knowledge Base/02 Business/09-Requirement-Engineering.md

Core Principle（核心原则）

客户的：

Request（要求）

不等于：

Requirement（需求）。

例如：

我们要一个 Chatbot（聊天机器人）。

是 Request。

真正 Requirement 可能是：

用户必须能在 30 秒内找到适用的 HR Policy（人力资源政策），并查看来源。

---

Requirement Layers（需求分层）

建议分四层。

Business Requirement（业务需求）

回答：

为什么做？

例如：

Reduce employee time spent searching policies.
（减少员工搜索政策花费的时间。）

User Requirement（用户需求）

回答：

用户需要完成什么？

例如：

Employee needs to ask natural language questions.
（员工需要能用自然语言提问。）

Functional Requirement（功能性需求）

回答：

系统具体需要做什么？

例如：

System retrieves relevant policy documents.（系统检索相关政策文档。）
System displays citation.（系统展示引用来源。）

Non-functional Requirement（非功能性需求）

回答：

系统需要达到什么质量？

例如：

• Latency（延迟）
• Security（安全）
• Availability（可用性）
• Scalability（可扩展性）
• Auditability（可审计性）
• Compliance（合规）

---

Requirement Traceability（需求追溯）

推荐：

Business Goal（业务目标）
↓
User Requirement（用户需求）
↓
Functional Requirement（功能性需求）
↓
Architecture（架构）
↓
Test（测试）
↓
Metric（指标）

例如：

Reduce search time（缩短搜索时间）
↓
Ask natural language questions（自然语言提问）
↓
Retrieve relevant policy（检索相关政策）
↓
Enterprise RAG（企业级 RAG 架构）
↓
Retrieval evaluation（检索评估）
↓
Task time reduction（任务耗时下降）

---

Acceptance Criteria（验收标准）

Requirement 必须可验收。

不够好：

System should be fast.（系统应该快。）

更好：

P95 response latency should meet the agreed service target under expected pilot load. （在预期试点负载下，P95 响应延迟应满足约定的服务目标。）

具体数值根据项目实际确定。

---

Requirement Categories（需求分级）

Must Have（必须有）

没有就无法交付价值。

Should Have（应该有）

重要，但可延后。

Could Have（可以有）

有价值，但不影响核心目标。

Won’t Have Now（本次不做）

明确暂不做。

也就是 MoSCoW（Must/Should/Could/Won’t，需求四级优先法）。

---

Common Mistakes（常见错误）

• 把 Solution（解决方案）当 Requirement（需求）
• Requirement 无法测试
• 所有人对术语理解不同
• Non-functional Requirements（非功能性需求）太晚才定义
• Scope（范围）中没有明确 Out of Scope（范围外）

---

FDE Principle（FDE 原则）

Requirement 应尽可能描述：

必须满足的结果和约束。

而不是过早规定：

必须用哪一个技术实现。

---

Related Topics（关联知识）

• Problem Framing（问题定义）
• Use Case Definition（用例定义）
• Business Knowledge Map（业务知识地图）