Skill Hub — Decision & Validation
Requirements Review Checklist Working Skill
Catch gaps, contradictions, and untestable requirements before they enter implementation, so that rework and production failures are prevented at the source.
What this skill is for
Requirements that reach development with ambiguities or missing acceptance criteria become expensive defects later. This skill provides a structured checklist-based review process that reads drafted requirements, checks them against SMART criteria, verifies traceability to business sources, finds missing acceptance criteria, checks consistency with business rules, assesses technical feasibility, and documents review findings in a format that authors can act on. This is a gatekeeping activity: it happens after elicitation and before approval, not during discovery.
When to use this skill
- A requirements document is drafted and needs formal review before approval for implementation.
- A change request is proposed and the scope, impact, or testability is unclear.
- A user story is written but has no acceptance criteria, no owner, or no data source defined.
- Requirements from multiple stakeholders contradict each other or overlap.
- A previous requirement caused rework because it was ambiguous about system behavior or data needs.
- An audit or governance process requires evidence that requirements were reviewed before build.
Real work situations
SAP S/4 sales order incompletion procedure
A requirement states: "The system must block incomplete sales orders." On review, the requirement lacks: which fields trigger the block (customer reference, delivery date, incoterms), which order types are in scope, what "incomplete" means in terms of field population, and who receives the alert. Without review, developers build a generic block that either over-blocks standard orders or under-blocks rush orders, causing order entry delays or delivery failures.
Integration requirement: IDoc error handling
A requirement states: "IDoc errors must be handled automatically." On review, the requirement is missing: error types that trigger automatic retry versus manual intervention, retry count and interval, notification recipients, monitoring dashboard expectations, and SLA for resolution. Without review, operations receives a black box that retries indefinitely on data errors, flooding the queue with invalid IDocs.
Master data governance: business partner replication
A requirement states: "Business partner changes must replicate to all downstream systems in real time." On review, the requirement contradicts existing batch replication windows, assumes all systems can receive real-time events, omits conflict resolution rules for simultaneous updates, and has no acceptance criteria for latency measurement. Without review, the project launches a replication architecture that fails during peak hours because downstream systems cannot handle the event volume.
Inputs required
- Draft requirements document, user story, or change request with numbered requirement statements.
- Business rules catalog or documented decision logic that governs the process area.
- System documentation showing current behavior, available fields, and transaction codes involved.
- Previous review findings or post-implementation defect reports from similar requirements (if available).
- Stakeholder contact list with requirement owners and technical reviewers identified.
- Non-functional requirements: performance, availability, security, compliance constraints.
- Test environment summary showing what data, systems, and tools are available for verification.
Questions to ask
- Which requirement statements lack acceptance criteria, and what must be added?
- Which requirements contradict each other, existing business rules, or current system behavior?
- Which requirements cannot be tested with existing data, tools, or environments?
- Which requirements assume a system capability that does not exist?
- Which requirements are missing non-functional criteria: performance, availability, security, compliance?
- Which requirements have no traceable source: who asked for this, and what business outcome does it serve?
- Which requirements use vague terms like "fast," "easy," or "user-friendly" that prevent verification?
- What existing behavior must remain unchanged, and is that stated explicitly?
Working method
- Read the requirement statement. Read each requirement in isolation. Note its ID, author, and date. If it is longer than three sentences, flag it for decomposition.
- Check SMART criteria. For each requirement, verify it is Specific, Measurable, Achievable, Relevant, and Time-bound. If any criterion is missing, document the gap.
- Verify traceability to source. Confirm each requirement links to a business need, stakeholder request, regulation, or defect. If no source exists, flag the requirement as orphan.
- Identify missing acceptance criteria. Check that every requirement has at least one verifiable pass/fail criterion. If criteria are missing, note what must be added.
- Check consistency with business rules. Compare the requirement against documented business rules, process maps, and regulatory constraints. Flag contradictions.
- Assess technical feasibility. Verify the requirement can be met with current system capabilities, data, and resources. If feasibility is unclear, request a technical review.
- Check for ambiguity. Replace vague terms with measurable thresholds. Flag words like "appropriate," "sufficient," or "as needed."
- Document findings in a Review Report. For each requirement, list findings by severity: critical (blocks approval), major (requires revision), minor (suggested improvement). Link to the template below.
- Route for revision. Return the report to the requirement author with clear revision instructions and a deadline. Re-review after revision.
Decision rules
- If a requirement has no acceptance criteria, mark it incomplete and block approval until criteria are added.
- If two requirements contradict each other, escalate to the business owner with both statements and the conflict description.
- If a requirement is not testable with current data or tools, flag a test environment gap before approval.
- If a requirement assumes a system capability that does not exist, require a feasibility assessment or scope change.
- If a requirement uses vague language, reject it and request a rewrite with measurable thresholds.
- If a requirement duplicates an existing requirement, merge or remove the duplicate and update traceability.
- If non-functional criteria are missing, require them as a condition of approval.
- If a requirement changes existing behavior without stating what must remain unchanged, flag the omission.
Deliverables
- Requirements Review Report — Per requirement document. Contains findings classified by severity, with specific revision instructions and references to source documents.
- Defect Register — List of requirements that fail review, with reason, owner, and resolution deadline.
- Revision Plan — Ordered list of required changes, priority, and re-review schedule.
Templates
Requirements Review Checklist (compact)
---
artifact: Requirements Review Report
id: RR-001
requirement_doc: Link to requirement document
reviewer: Name
review_date: YYYY-MM-DD
status: draft | reviewed | approved
---
## Requirement ID: <REQ-001>
### SMART Check
- [ ] Specific: The requirement names a system, process, or field.
- [ ] Measurable: The requirement includes a metric or threshold.
- [ ] Achievable: The requirement can be met with current capabilities.
- [ ] Relevant: The requirement links to a business outcome or source.
- [ ] Time-bound: The requirement has a deadline or maintenance window.
### Acceptance Criteria Check
- [ ] At least one verifiable pass/fail criterion exists.
- [ ] Normal case is specified.
- [ ] Boundary case is specified.
- [ ] Error case is specified.
### Consistency Check
- [ ] No contradiction with business rules.
- [ ] No contradiction with existing system behavior.
- [ ] No duplication with other requirements.
### Feasibility Check
- [ ] Required data exists in the system.
- [ ] Required transactions or APIs are available.
- [ ] Test environment can verify the requirement.
### Findings
| Severity | Finding | Revision Required | Owner |
|----------|---------|-------------------|-------|
| critical | <description> | <yes/no> | <name> |
| major | <description> | <yes/no> | <name> |
| minor | <description> | <yes/no> | <name> |
### Sign-off
- Reviewer: _______________
- Date: _______________
Quality checklist
- Every requirement has at least one acceptance criterion.
- All contradictions with business rules or other requirements are flagged and assigned.
- Every requirement is traceable to a source document, stakeholder, or defect.
- No requirement contains vague terms without measurable thresholds.
- Non-functional criteria (performance, availability, security, compliance) are checked for every requirement.
- All findings are classified by severity and have an assigned owner.
- The review report is returned to the author with clear revision instructions.
Common mistakes
- Treating review as elicitation. Consequence: the review never ends because requirements are still being discovered. Reviews must be gatekeeping, not discovery sessions.
- Approving vague requirements with a comment to "clarify later." Consequence: ambiguity enters implementation, causing rework when the clarification contradicts what was built.
- Checking only functional requirements and ignoring non-functional criteria. Consequence: the solution passes functional tests but fails under load, lacks audit trails, or violates compliance.
- Reviewing without access to business rules or system documentation. Consequence: the reviewer cannot detect contradictions or feasibility issues, making the review a grammar check instead of a quality gate.
- Not documenting findings in a structured format the author can act on. Consequence: the author receives vague feedback like "make it clearer" and produces another unclear revision.
Weak output vs Strong output
Weak output
A generic summary with no actionable findings: "The requirements document looks mostly complete. A few items need clarification. Please review acceptance criteria and make sure everything is testable. Some requirements may conflict with existing rules, so check with the business owner. Overall, this is a good start but needs refinement before approval."
Why it fails: No specific requirement is named. No finding is classified by severity. The author has no clear instructions and no deadline. The review is indistinguishable from a polite rejection.
Strong output
---
artifact: Requirements Review Report
id: RR-2026-044
requirement_doc: REQ-S4-O2C-2026-044
reviewer: M. Chen
review_date: 2026-06-12
status: reviewed — revisions required
---
## Critical Findings (blocks approval)
### REQ-004: "Block incomplete sales orders"
- Missing: which fields trigger the block (customer reference, delivery date, incoterms).
- Missing: which order types are in scope (standard, rush, consignment).
- Missing: acceptance criteria for alert routing and escalation.
- Action: Decompose into 3 requirements. Add acceptance criteria for each field and order type. Assign to J. Schmidt by 2026-06-15.
### REQ-007: "IDoc errors must be handled automatically"
- Vague: "automatically" is not defined. No retry count, no interval, no error classification.
- Contradiction: assumes real-time processing but current system uses batch every 4 hours.
- Action: Rewrite with explicit error classification and retry rules. Request feasibility review from integration team. Assign to R. Patel by 2026-06-16.
## Major Findings (requires revision)
### REQ-002: "Migrate all active customers"
- Missing non-functional criteria: expected migration window, rollback procedure, data validation threshold.
- Action: Add performance and availability criteria. Reference atlas/diagnostics/sap-process-audit for validation checklist.
## Minor Findings (suggested improvements)
### REQ-001: "Enable credit limit check"
- Acceptable as written. Suggest adding edge case for emergency orders under 1,000 EUR.
Agent instructions
AI Prompt Pattern
Role: Requirements reviewer for an SAP enterprise project.
Context: You have a drafted requirements document with numbered requirements. You also have business rules, system documentation, and non-functional constraints.
Task: Review each requirement against the SMART criteria, check for acceptance criteria, verify consistency with business rules, assess feasibility, and produce a Requirements Review Report with classified findings.
Output format: Structured report with critical/major/minor findings, each containing: requirement ID, specific finding, reason, and clear revision instruction with owner and deadline.
- Never approve a requirement that lacks acceptance criteria. Flag it as incomplete with specific guidance on what criteria are missing.
- Use the template above. Produce structured output that the requirement author can act on without asking for clarification.
- Separate facts from assumptions. If feasibility is unclear, state the assumption and recommend a technical review rather than guessing.
- Check for contradictions. Compare requirements against each other and against documented business rules. Escalate conflicts.
- Do not rewrite requirements yourself. Identify the gap and instruct the author to revise. The author owns the requirement, not the reviewer.
- Do not skip non-functional criteria. Performance, availability, security, and compliance must be checked for every requirement.
- Link to Atlas diagnostics when requirements touch SAP processes. For example, incompletion procedure requirements should reference SAP Incompletion Procedure Diagnostics.
Related skills
- Requirements Elicitation Working Skill — Use before this skill; review happens after elicitation is complete.
- Acceptance Criteria Working Skill — Use to add the missing acceptance criteria that review discovers.
- Business Rules Discovery Working Skill — Use to obtain the business rules catalog needed for consistency checks.
Related Atlas pages
- SAP Process Audit — Diagnostic context for verifying that requirements align with actual process behavior.
- SAP Incompletion Procedure Diagnostics — Validation context for completeness requirements in order-to-cash processes.
Verification status and limitations
This skill is a public working interpretation of requirements review practices. It is not official BABOK, IIBA, or SAP documentation. It focuses on enterprise and SAP contexts where requirements must be verifiable by business owners and traceable to system behavior.
Known limitations: the skill assumes a requirements document exists and that business rules are documented. It does not cover elicitation techniques, stakeholder negotiation, or change control processes. It does not address agile-specific review ceremonies such as backlog refinement or sprint planning.