Session 2.3 – Requirements Verification

Module 2: Verification & Validation | Duration: 1 hour

Learning Objectives
  • Judge requirement quality using SMART/FURPS+ heuristics.
  • Conduct requirement reviews, inspections, and traceability checks.
  • Capture defects, waivers, and coverage evidence for audits.

Requirement Quality Criteria

High-quality requirements follow two classic heuristics: SMART (Specific, Measurable, Achievable, Relevant, Time-bound) and FURPS+ (Functionality, Usability, Reliability, Performance, Supportability + constraints). Use these to evaluate every statement.

Specific
Describe exactly who/what/when. Example: “The system shall allow customer_support role to refund orders up to ₹10,000.”
Measurable
Include numbers or acceptance tests (response time < 150 ms, 99.9% availability).
Achievable
Feasible within existing architecture, budget, regulatory limits.
Relevant
Connect to business value; remove out-of-scope wishes.
Time-bound
Specify release/sprint or operational timeframe (e.g., “within 30 seconds of submission”).
Functionality (F)
Features, business rules, data transformations, integrations.
Usability (U)
UI, accessibility, localization cues.
Reliability (R)
Availability, error-handling, failover, data integrity.
Performance (P)
Latency, throughput, scalability targets.
Supportability (S+)
Maintainability, observability, deployment/operational constraints.
Ambiguity-buster checklist:
  • Highlight TBD/TBC items.
  • Clarify pronouns (“it”, “they”) with explicit references.
  • Replace “and/or”, “etc.” with explicit branching logic.
  • Tag each requirement with SMART + FURPS+ attribute to ensure coverage.
Steps to ensure requirement quality before inspection:
  1. Draft: Capture requirement, acceptance criteria, and business rationale in the backlog/document.
  2. Self-check: Author runs SMART/FURPS+ checklist; fills missing non-functional clauses.
  3. Peer sanity review: Quick asynchronous review for clarity (2 reviewers sign off).
  4. Trace seed: Link requirement ID to related epics, UX artifacts, or regulations.
  5. Ready for inspection: Moderator confirms prerequisites (roles, checklist, sample data) before formal verification session.

Review & Inspection Workflow

Use this step-by-step process for formal requirement inspections:

  1. Plan: Select a package (epics, BRD chapter). Assign moderator, author, reviewer roles.
  2. Preparation: Reviewers study the document individually using a checklist (coverage, quality, compliance).
  3. Meeting: Moderator walks through each requirement, recorder logs defects, questions, waivers.
  4. Rework & Follow-up: Author resolves findings; moderator verifies fixes; metrics captured.
  5. Closure: Update traceability matrix, share summary with stakeholders.

Verification Techniques

Peer Review Walkthrough
  • Great for early drafts or user stories.
  • Focus on clarifying intent and discovering missing scenarios.
  • Outcome: updated story, new acceptance criteria, risks flagged.
Formal Inspection
  • Time-boxed (60–90 min), metrics-driven.
  • Roles: moderator, reader, recorder, domain experts.
  • Outcome: defect log with severity, owner, due date.
Scenario/Use-case Walkthrough
  • Map personas to journeys, ensuring alternate flows are captured.
  • Validates completeness of requirements from user perspective.

Traceability & Coverage

Traceability proves each requirement is verified and validated. Maintain at least two views:

Forward Trace
Requirement → test cases → defects. Use spreadsheets or ALM tools (Jira XRay, Azure DevOps) to show coverage.
Backward Trace
Test case → requirement → business objective. Ensures no orphan tests and helps scope regression.
Requirement Test Case Defect / Evidence

Always be able to move left ↔ right along this chain.

Scenario: Refund Requirement Review

Requirement R-105: “A customer service agent shall refund a paid order within 30 days of shipment for amounts up to ₹10,000. Refunds above that amount require manager approval.”

Review / Inspection Findings
  • Ambiguity: “shipment” should reference carrier scan vs warehouse dispatch → clarified to “carrier pickup timestamp”.
  • Missing scenario: foreign currency orders → added conversion rule (use original FX rate).
  • Traceability gap: no story for manager override; created US-221 to capture interface.
Forward Trace (Requirement → Tests → Defects)
Requirement ID Acceptance Tests / Charters Defects Logged
R-105 Refund window
  • TC-105A: Refund within 30 days, amount ₹8k.
  • TC-105B: Attempt refund at day 31 → expect warning.
  • DEF-342: System allowed day 45 refund (severity High).
R-105 Manager approval
  • TC-105C: ₹15k refund prompts manager authentication.
  • TC-105D: Manager denies → audit entry created.
  • DEF-349: Audit entry missing currency field.
Backward Trace (Test → Requirement → Business Goal)
Test ID Requirement Business Objective
TC-105B R-105 Refund window Protect revenue leak beyond 30 days
TC-105C R-105 Manager approval Fraud prevention for high-value refunds
TC-105D R-105 Manager approval Compliance auditing for financial operations

Defect Logging & Follow-up

  • Log requirement defects with severity (critical ambiguity, missing constraint, conflicting rule).
  • Record waivers with justification, approver, expiry date.
  • Re-review high-risk requirements after fixes or scope changes.

Summary & Assignment

Requirement verification blends analytical checklists with collaborative reviews to ensure what you plan to build is precise, complete, and testable. Paired with traceability, it forms the foundation of the entire V&V stack.

Assignment: Select five user stories or BRD items. Run a mini review (walkthrough or inspection), log defects, and update a traceability table mapping each requirement to at least two test cases.
Course Home