---
name: requirement-quality-review
type: review_rule
when: '需求分析, 需求审查, requirement review'
scope:
  - backend
  - frontend
products:
  - '*'
id: ka-review-rule-需求质量审查规则
asset_kind: review_rule
lifecycle_status: active
authority: supporting
routes: ['code_change', 'planning']
primary_triggers:
  - 需求质量审查规则
secondary_triggers:
  - 需求审查
  - 需求质量
negative_triggers: []
priority: P1
specificity: 5
version: 1.1.0
last_reviewed: '2026-06-01'
stages: ["编码与单元测试", "联调验证"]
owner_mechanism_id: mc-intent-router
---

# 需求质量审查规则

## REQ-01: 需求可测试性

pattern: 需求描述必须包含可量化的验收标准
severity: warning
scope: [backend, frontend]
description: 每个需求点必须至少有一条可验证的验收标准，避免模糊表述（如"性能好"应改为"响应时间<200ms"）

## REQ-02: 功能/非功能/约束三维度覆盖

pattern: 需求分析必须覆盖功能需求、非功能需求和约束条件
severity: warning
scope: [backend, frontend]
description: 需求文档必须明确区分功能需求（做什么）、非功能需求（性能、安全、可用性等）和约束条件（技术栈、时间、资源等）

## REQ-03: 需求无歧义表达

pattern: 需求描述不得使用模糊量词或条件
severity: warning
scope: [backend, frontend]
description: 禁止使用"等"、"相关"、"适当的"、"必要时"等模糊表述；每个需求点必须有一个明确的动作和对象

## REQ-04: 需求间无矛盾

pattern: 需求文档中不得存在相互矛盾的描述
severity: warning
scope: [backend, frontend]
description: 检查需求间是否存在矛盾（如"支持离线使用"与"实时同步数据"），发现矛盾必须标注并请求澄清

## REQ-05: 需求完整性

pattern: 每个功能需求必须包含触发条件、处理逻辑和预期结果
severity: warning
scope: [backend, frontend]
description: 缺少触发条件、处理逻辑或预期结果的需求必须标注为"待补充"，不得留空
