Back to Details

requirement-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Requirement Review

需求评审

Systematically review requirements to validate quality and identify issues before design and development begins. Ensure requirements are complete, clear, consistent, testable, and traceable.
在设计和开发开始前，系统性地评审需求以验证质量并识别问题。确保需求具备完整性、清晰度、一致性、可测试性和可追溯性。

Review Workflow

评审工作流程

1. Preparation

1. 准备阶段

Gather all relevant documentation:
  • Requirements documents (BRD, SRS, user stories)
  • Non-functional requirements and constraints
  • Requirements Traceability Matrix (if available)
  • Project context (charter, goals)
  • Existing acceptance criteria
收集所有相关文档：
  • 需求文档（BRD、SRS、用户故事）
  • 非功能性需求与约束条件
  • 需求追溯矩阵（若有）
  • 项目背景（项目章程、目标）
  • 现有验收标准

2. Quality Assessment

2. 质量评估

Evaluate each requirement using six quality attributes:
  1. Completeness: All needs captured, no missing details or TBDs, dependencies identified
  2. Clarity: Unambiguous, specific, no vague terms ("user-friendly", "fast", "easy")
  3. Consistency: No conflicts, consistent terminology and priorities
  4. Testability: Verifiable with measurable acceptance criteria and clear pass/fail
  5. Traceability: Links to business goals, design, and tests
  6. Feasibility: Technically achievable within constraints (budget, timeline, capability)
See quality-checklists.md for detailed assessment criteria and document-specific checklists
使用六项质量属性评估每一项需求：
  1. 完整性：涵盖所有需求，无缺失细节或待确定项（TBD），已识别依赖关系
  2. 清晰度：表述明确、具体，无模糊术语（如「用户友好」「快速」「易用」）
  3. 一致性：无冲突，术语和优先级保持一致
  4. 可测试性：可通过可衡量的验收标准明确判定通过/失败
  5. 可追溯性：与业务目标、设计和测试环节相关联
  6. 可行性：在约束条件（预算、时间线、能力范围内）具备技术可实现性
参考quality-checklists.md 获取详细评估标准和针对不同文档的检查清单

3. Issue Identification

3. 问题识别

Identify common requirement problems:
Ambiguous: "system shall be fast" → Specify measurable criteria: "< 2s response for 95% of requests"
Untestable: "system shall be secure" → Define specific controls: password complexity, encryption standards, audit logging
Incomplete: "system shall send notifications" → Specify channel, timing, content, recipients
Conflicting: REQ-012 "phone required" vs REQ-089 "phone optional" → Flag for stakeholder resolution
See examples.md for extensive before/after examples
识别常见的需求问题：
模糊表述：「系统应快速响应」→ 替换为可衡量标准：「95%的请求响应时间<2秒」
不可测试：「系统应具备安全性」→ 定义具体控制措施：密码复杂度、加密标准、审计日志
不完整：「系统应发送通知」→ 明确渠道、时机、内容、接收人
冲突：REQ-012「必须提供手机号」与REQ-089「手机号可选」→ 标记需涉众解决
参考examples.md 获取丰富的前后对比示例

4. Quality Scoring

4. 质量评分

Calculate scores for each quality attribute (0-100%):
  • 90-100%: Excellent - minimal issues
  • 75-89%: Good - minor improvements needed
  • 60-74%: Fair - notable gaps exist
  • Below 60%: Poor - major rework required
Overall Quality = Average of all six attributes
Target: ≥ 90% for production-readiness
为每项质量属性计算得分（0-100%）：
  • 90-100%：优秀 - 问题极少
  • 75-89%：良好 - 需小幅改进
  • 60-74%：一般 - 存在明显缺口
  • 低于60%：较差 - 需要大幅返工
整体质量 = 六项属性得分的平均值
目标：生产就绪状态需≥90%

5. Report Generation

5. 报告生成

Create structured review report with:
Executive Summary: Quality rating, recommendation, key strengths (2-3), critical issues (2-3), top actions
Detailed Findings: Quality scores, issues by severity (Critical/Major/Minor), specific examples with requirement IDs
Action Items: Prioritized list with owners, due dates, effort estimates, approval conditions
See report-templates.md for complete report structure and templates
创建结构化评审报告，包含：
执行摘要：质量评级、建议、核心优势（2-3项）、关键问题（2-3项）、首要行动项
详细发现：质量得分、按严重程度（关键/主要/次要）分类的问题、带需求ID的具体示例
行动项：按优先级排序的列表，包含负责人、截止日期、工作量估算、批准条件
参考report-templates.md 获取完整的报告结构和模板

6. Recommendations

6. 评审建议

Provide clear decision:
  • Approve: Requirements ≥ 90% quality threshold
  • Approve with Conditions: Critical issues must be resolved before design
  • Major Revision: 60-74% quality - substantial rework required
  • Reject: < 60% quality or fundamental issues - complete redesign needed
给出明确决策：
  • 批准：需求质量≥90%阈值
  • 有条件批准：关键问题必须在设计前解决
  • 重大修订：质量得分60-74% - 需要大量返工
  • 拒绝：质量得分<60%或存在根本性问题 - 需要重新设计

Document-Specific Focus

针对不同文档的评审重点

Business Requirements Documents (BRD)

业务需求文档（BRD）

Focus on business objectives, stakeholder needs, scope definition, business case, constraints
重点关注业务目标、涉众需求、范围定义、业务案例、约束条件

Software Requirements Specifications (SRS)

软件需求规格说明书（SRS）

Focus on functional requirements, non-functional requirements (performance, security, scalability), system behaviors, integration points, IEEE 830 compliance
重点关注功能性需求、非功能性需求（性能、安全性、可扩展性）、系统行为、集成点、IEEE 830合规性

User Story Backlogs

用户故事待办列表

Focus on INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable), acceptance criteria format (Given-When-Then), story format, prioritization
See quality-checklists.md for document-specific assessment criteria
重点关注INVEST准则（Independent、Negotiable、Valuable、Estimable、Small、Testable）、验收标准格式（Given-When-Then）、故事格式、优先级排序
参考quality-checklists.md 获取针对不同文档的评估标准

Severity Definitions

问题严重程度定义

  • Critical: Blocks progress, must fix immediately (security gaps, fundamental conflicts, missing scope)
  • Major: Significant quality impact, should fix before approval (ambiguous criteria, missing acceptance criteria)
  • Minor: Quality improvements, nice to have (formatting, examples, enhancements)
  • 关键：阻碍项目进展，必须立即修复（安全缺口、根本性冲突、缺失核心范围）
  • 主要：对质量有显著影响，应在批准前修复（模糊标准、缺失验收标准）
  • 次要：质量优化项，可选择性修复（格式问题、示例补充、细节增强）

Common Anti-Patterns to Flag

需要标记的常见反模式

  • Gold Plating: Adding unrequested features
  • Solution-Focused: Specifying "how" instead of "what" (requirements should be technology-agnostic)
  • Scope Creep: Accepting changes without change control
  • Analysis Paralysis: Over-perfecting requirements indefinitely
  • Weak Acceptance Criteria: Vague or missing test conditions
  • No Traceability: Requirements disconnected from business goals
  • 镀金：添加未被要求的功能
  • 聚焦解决方案：指定「如何实现」而非「需要什么」（需求应与技术无关）
  • 范围蔓延：未通过变更控制流程就接受需求变更
  • 分析瘫痪：无限期地过度完善需求
  • 薄弱的验收标准：模糊或缺失测试条件
  • 无追溯性：需求与业务目标脱节

Vague Terms to Replace

需要替换的模糊术语

Always replace with measurable criteria:
  • "user-friendly", "intuitive", "easy" → Define usability metrics
  • "fast", "quick", "responsive" → Specify response time targets
  • "secure" → Define specific security controls
  • "scalable" → Define capacity and load targets
  • "reliable" → Define uptime percentage and recovery time
始终用可衡量的标准替换：
  • 「用户友好」「直观」「易用」→ 定义可用性指标
  • 「快速」「迅速」「响应快」→ 明确响应时间目标
  • 「安全」→ 定义具体安全控制措施
  • 「可扩展」→ 明确容量和负载目标
  • 「可靠」→ 定义正常运行时间百分比和恢复时间

Standards Compliance

合规性标准

  • IEEE 830: SRS structure and content standards
  • INVEST: User story quality criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable)
  • ISO/IEC 25010: Systems and software quality models
  • Industry-Specific: HIPAA (healthcare), PCI-DSS (payments), SOC 2 (SaaS), FDA (medical devices)
See quality-checklists.md for standards compliance details
  • IEEE 830：SRS的结构和内容标准
  • INVEST：用户故事质量准则（Independent、Negotiable、Valuable、Estimable、Small、Testable）
  • ISO/IEC 25010：系统与软件质量模型
  • 行业特定标准：HIPAA（医疗健康）、PCI-DSS（支付）、SOC 2（SaaS）、FDA（医疗设备）
参考quality-checklists.md 获取合规性审查的详细信息

Report Format

报告格式

Generate review reports in this structure:
  1. Executive Summary (1 page): Overall assessment, key findings, recommendation
  2. Quality Metrics (0.5 page): Scores by attribute with targets
  3. Detailed Findings (2-5 pages): Issues grouped by attribute with examples and recommendations
  4. Action Items (1 page): Prioritized list with owners and due dates
  5. Approval Decision (0.5 page): Recommendation with rationale and next steps
Keep reports factual, specific, and actionable. Always cite specific requirement IDs when identifying issues.
See report-templates.md for complete report templates
按以下结构生成评审报告：
  1. 执行摘要（1页）：整体评估、关键发现、评审建议
  2. 质量指标（0.5页）：各项属性得分及目标值
  3. 详细发现（2-5页）：按属性分组的问题、示例及建议
  4. 行动项（1页）：按优先级排序的列表，包含负责人和截止日期
  5. 批准决策（0.5页）：建议内容、理由及后续步骤
报告需基于事实、具体明确且具备可操作性。识别问题时务必引用具体的需求ID。
参考report-templates.md 获取完整的报告模板