Requirement Review

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

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

2. Quality Assessment

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](references/quality-checklists.md) for detailed assessment criteria and document-specific checklists

3. Issue Identification

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](references/examples.md) for extensive before/after examples

4. Quality Scoring

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

5. Report Generation

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](references/report-templates.md) for complete report structure and templates

6. Recommendations

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

Document-Specific Focus

Business Requirements Documents (BRD)

Focus on business objectives, stakeholder needs, scope definition, business case, constraints

Software Requirements Specifications (SRS)

Focus on functional requirements, non-functional requirements (performance, security, scalability), system behaviors, integration points, IEEE 830 compliance

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](references/quality-checklists.md) for document-specific assessment criteria

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](references/quality-checklists.md) for standards compliance details

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](references/report-templates.md) for complete report templates

Requirements Review Examples

Practical examples showing common issues and their improvements.

Table of Contents

• Ambiguous Requirements Examples
• Untestable Requirements Examples
• Conflict Examples
• User Story Examples
• Non-Functional Requirements Examples
• Complete Review Examples

Ambiguous Requirements Examples

Example 1: Performance Requirements

❌ Poor (Ambiguous):

REQ-045: The system shall be fast and responsive.

Issues:

• "Fast" is subjective - what's fast for one user may be slow for another
• "Responsive" is vague - no measurable criteria
• No context - fast for which operations?
• No baseline - how fast is acceptable?

✅ Good (Clear):

REQ-045: The system shall respond to user search queries within 2 seconds for 95% of requests under normal load (up to 1,000 concurrent users).

Acceptance Criteria:
- Search results displayed within 2 seconds for 95th percentile
- Search results displayed within 5 seconds for 99th percentile
- Measured with 1,000 concurrent users performing searches
- Measured over 1-hour sustained load test
- Baseline test data: 1 million product records

Example 2: User Interface Requirements

❌ Poor (Ambiguous):

REQ-067: The application shall have a user-friendly interface that is intuitive and easy to use.

Issues:

• "User-friendly", "intuitive", "easy" are subjective
• No measurable success criteria
• Cannot be tested objectively
• Different users have different skill levels

✅ Good (Clear):

REQ-067: The application shall enable new users to complete core tasks without training.

Measurable Criteria:
- 80% of first-time users complete account registration within 5 minutes without assistance
- 70% of new users successfully place first order within 10 minutes without help documentation
- Task completion measured via usability testing with 20+ participants
- Users rate perceived ease-of-use ≥ 4.0/5.0 on post-task survey
- Critical workflows have a maximum of 3 steps from start to completion

Example 3: Security Requirements

❌ Poor (Ambiguous):

REQ-089: The system shall be secure and protect user data.

Issues:

• "Secure" is too broad - what aspects of security?
• "Protect" is vague - protect from what threats?
• No specific mechanisms defined
• Not testable as written

✅ Good (Clear):

REQ-089: The system shall protect user data through the following security controls:

1. Authentication:
   - Support OAuth 2.0 and SAML 2.0 authentication
   - Enforce password complexity: min 12 characters, 1 uppercase, 1 lowercase, 1 number, 1 special character
   - Lock account after 5 failed login attempts within 15 minutes
   - Require password change every 90 days

2. Data Protection:
   - Encrypt all data in transit using TLS 1.3
   - Encrypt sensitive PII at rest using AES-256
   - Hash passwords using bcrypt with work factor ≥ 12
   - Mask credit card numbers (show last 4 digits only)

3. Audit & Monitoring:
   - Log all authentication attempts (success and failure) with timestamp, username, IP
   - Log all data access for sensitive fields with user ID and timestamp
   - Retain audit logs for 2 years
   - Alert security team on > 10 failed logins from same IP within 5 minutes

Untestable Requirements Examples

Example 4: Scalability Requirements

❌ Poor (Untestable):

REQ-102: The system shall be highly scalable to support future growth.

Issues:

• "Highly scalable" has no measurable definition
• "Future growth" is undefined - how much growth?
• No clear test pass/fail criteria
• Cannot verify "shall be scalable"

✅ Good (Testable):

REQ-102: The system architecture shall support horizontal scaling to handle increased load.

Testable Criteria:
- System scales from 1,000 to 10,000 concurrent users by adding application servers without code changes
- Response time degrades < 10% when load increases from 1,000 to 5,000 concurrent users (with proportional infrastructure)
- Database supports read replicas with < 100ms replication lag
- Stateless application design allows adding/removing servers without session loss
- Load balancer distributes traffic across N application servers with < 5% variance

Verification Method:
- Load testing with JMeter: measure response times at 1K, 5K, 10K concurrent users
- Infrastructure test: add servers and verify auto-scaling triggers
- Database replication lag monitoring over 24-hour period

Example 5: Maintainability Requirements

❌ Poor (Untestable):

REQ-115: The application code shall be maintainable and follow best practices.

Issues:

• "Maintainable" is subjective
• "Best practices" vary by team/organization
• No objective measurement
• Cannot determine pass/fail

✅ Good (Testable):

REQ-115: The application code shall meet the following maintainability criteria:

Code Quality Metrics:
- Maintain ≥ 80% unit test coverage (measured by coverage tool)
- Cyclomatic complexity ≤ 10 per function (measured by SonarQube)
- No code duplication blocks exceeding 10 lines (detected by SonarQube)
- All functions/methods have JSDoc/XML documentation with parameter descriptions

Code Standards:
- Follow ESLint rules defined in .eslintrc (zero errors on production build)
- Pass Prettier formatting checks (automated in pre-commit hook)
- All public APIs documented in OpenAPI 3.0 specification
- Code review approval required before merge (min 1 approver)

Verification Method:
- Automated: SonarQube analysis on every commit, build fails if thresholds not met
- Automated: ESLint/Prettier checks in CI pipeline
- Manual: Code review checklist includes documentation review

Conflict Examples

Example 6: Priority Conflicts

❌ Conflicting Requirements:

REQ-125: Users shall provide a phone number during registration. [Priority: Critical]
REQ-187: Phone number shall be optional to reduce registration friction. [Priority: Critical]

Issues:

• Direct contradiction: mandatory vs optional
• Both marked Critical priority - cannot both be essential
• Different stakeholders likely have different objectives
• Developers cannot implement both

✅ Resolved Requirement:

REQ-125: Users shall provide an email address during registration (mandatory).

REQ-125a: Users may optionally provide a phone number during registration for:
- SMS notifications (opt-in)
- Two-factor authentication (opt-in)
- Order status updates via SMS (opt-in)

REQ-125b: System shall send verification email to confirm email address before account activation.

REQ-125c: If user provides phone number, system shall send SMS verification code before enabling SMS features.

Priority: Critical (email), Medium (phone number)
Rationale: Email is critical for account recovery and communication. Phone is value-add for users who want SMS features.
Resolution Date: 2024-01-15
Stakeholders Consulted: Product Owner (Sarah), UX Lead (Mike), Security (Tom)

Example 7: Technical Conflicts

❌ Conflicting Requirements:

REQ-145: System shall provide real-time synchronization across all devices with < 1 second delay.
REQ-167: System shall work offline and sync changes when connection is restored.

Issues:

• Real-time sync requires constant connection
• Offline mode means no connectivity
• Conflict in architectural approach
• Need to clarify expected behavior

✅ Resolved Requirements:

REQ-145: System shall provide near-real-time synchronization when devices are online.

Criteria:
- Changes sync across devices within 5 seconds when all devices have active internet connection
- WebSocket connection maintains sync state
- Users see "Syncing..." indicator during synchronization
- Users see "Synced" confirmation when complete

REQ-167: System shall support offline mode with deferred synchronization.

Criteria:
- Users can view and edit locally cached data when offline
- System queues changes locally while offline
- UI shows "Offline Mode" indicator clearly
- When connection restored, system syncs queued changes automatically
- Conflict resolution: Last Write Wins (LWW) with timestamp, user notified of conflicts
- User can view sync history showing which device made which changes

Priority: REQ-145 (High), REQ-167 (Medium)
Architecture: Event sourcing with local-first approach using CRDTs for conflict-free merges

User Story Examples

Example 8: User Story with Poor Acceptance Criteria

❌ Poor User Story:

US-045: As a user, I want to search for products so that I can find what I need.

Acceptance Criteria:
- Search works
- Results are displayed
- User can click on results

Issues:

• Criteria are vague ("search works" - how?)
• No specific scenarios defined
• No error cases handled
• No performance criteria
• No edge cases

✅ Good User Story:

US-045: As a customer, I want to search for products by keyword so that I can quickly find items I'm interested in purchasing.

Acceptance Criteria:

Given I am on any page of the website
When I enter "laptop" in the search box and press Enter or click Search
Then I should see a list of products matching "laptop" within 2 seconds

Given I search for "laptop"
When the search completes
Then results should be sorted by relevance (best match first)
And each result shows: product image, title, price, rating, availability
And I see the number of results found (e.g., "1,247 results for 'laptop'")

Given I search for "xyzabc123nonsense"
When no products match my search
Then I see "No results found for 'xyzabc123nonsense'" message
And I see search suggestions or popular categories

Given I search for a product
When I click on a search result
Then I am taken to that product's detail page

Given I am viewing search results
When there are more than 20 results
Then results are paginated (20 per page)
And I can navigate to next/previous pages
And I can see total pages (e.g., "Page 1 of 63")

Given I use the search feature
When I enter SQL injection attempt "'; DROP TABLE products--"
Then system sanitizes input and treats it as a normal search string
And no database errors occur

Non-Functional:
- Search response time: < 2 seconds for 95% of queries
- Search handles up to 1,000 concurrent search requests
- Search indexing updates within 5 minutes of product changes
- Search supports common misspellings (e.g., "labtop" → "laptop")

Definition of Done:
- Code reviewed and approved
- Unit tests: 80%+ coverage
- Integration tests pass
- Performance test: verified < 2s response
- Security test: SQL injection protection verified
- Deployed to staging and validated by PO

Example 9: User Story Following INVEST Principles

✅ Good User Story (INVEST):

US-078: As a returning customer, I want to reorder items from my order history with one click so that I can quickly purchase items I buy regularly.

Story Points: 5

Acceptance Criteria:

Given I am logged in and viewing my order history
When I click "Reorder" button on a previous order
Then all items from that order are added to my cart
And I am taken to the cart page
And I see a confirmation message "12 items added to cart"

Given I click "Reorder" on order #12345
When some items are no longer available
Then available items are added to cart
And I see a message listing unavailable items: "Note: 2 items no longer available: [Item A], [Item B]"
And I can proceed with available items

Given I click "Reorder" on order #12345
When my cart already contains items
Then reordered items are added to existing cart items
And cart shows updated total item count

Given I click "Reorder" on order #12345
When items have price changes since original order
Then items are added at current prices
And I see message "Prices may have changed since your original order"

Definition of Done:
- UI button displays on order history page
- Backend API endpoint: POST /api/orders/{orderId}/reorder
- Unit tests cover: available items, unavailable items, price changes
- E2E test: complete reorder workflow
- Analytics event fired: "reorder_clicked"
- Performance: reorder completes in < 1 second

Dependencies:
- Requires completed: US-034 (Order history page)
- Requires: Product availability API

Notes:
- Product team priority: High (top customer request)
- Analytics show 35% of customers reorder within 30 days
- Expected to increase conversion by 8% (based on A/B test)

INVEST Check:
✅ Independent: Can be developed without other stories
✅ Negotiable: Could simplify to "single item" reorder if needed
✅ Valuable: Directly improves customer convenience and conversion
✅ Estimable: Team can estimate at 5 points
✅ Small: Fits in one sprint
✅ Testable: Clear acceptance criteria with specific scenarios

Non-Functional Requirements Examples

Example 10: Performance Requirements

❌ Poor NFR:

NFR-001: The system shall have good performance.

✅ Good NFR:

NFR-001: Performance - Response Time

The system shall meet the following response time targets measured from user browser:

Page Load Times (Cold Load):
- Homepage: < 3 seconds for 95th percentile
- Product listing page: < 3 seconds for 95th percentile
- Product detail page: < 2 seconds for 95th percentile
- Checkout page: < 2 seconds for 95th percentile

API Response Times:
- Search API: < 500ms for 95th percentile
- Product API: < 300ms for 95th percentile
- Cart operations: < 200ms for 95th percentile
- Checkout API: < 1 second for 95th percentile

Measurement Conditions:
- User location: Within same geographic region as server (< 50ms network latency)
- Device: Desktop with modern browser (Chrome, Firefox, Safari latest versions)
- Network: Broadband connection (10+ Mbps)
- Load: Up to 5,000 concurrent users

Verification:
- Load testing with Apache JMeter simulating 5,000 concurrent users
- Real User Monitoring (RUM) tracking actual user experience
- Weekly performance reports from production RUM data
- Performance regression testing in CI/CD pipeline

Priority: Critical
Acceptance: All targets must be met before production release

Example 11: Availability Requirements

❌ Poor NFR:

NFR-015: The system should be highly available.

✅ Good NFR:

NFR-015: Availability & Uptime

The system shall maintain 99.9% uptime measured monthly (allows 43.2 minutes downtime per month).

Uptime Measurement:
- Measured via external monitoring service (e.g., Pingdom) from 3 geographic locations
- Service considered "down" if HTTP 200 response not received within 30 seconds
- Planned maintenance windows excluded from uptime calculation

Scheduled Maintenance:
- Maximum 4 hours per month for planned maintenance
- Scheduled maintenance must be announced 7 days in advance
- Maintenance window: Sundays 2:00 AM - 6:00 AM EST (lowest traffic period)
- During maintenance, display maintenance page with estimated restoration time

High Availability Architecture:
- Load balancer distributes across min 3 application servers
- Database: Primary-replica setup with automatic failover
- Database failover time: < 60 seconds
- Application servers: Auto-scaling based on CPU (add server when >70%)
- Health checks every 30 seconds, auto-replace unhealthy instances

Disaster Recovery:
- Recovery Time Objective (RTO): 4 hours
- Recovery Point Objective (RPO): 15 minutes
- Database backups: Every 15 minutes (incremental), daily (full)
- Backup stored in geographically separate region
- DR site can handle 100% of production load

Monitoring & Alerting:
- 24/7 monitoring via PagerDuty
- Alert when availability drops below 99.5% in rolling 24-hour window
- Alert on any service downtime > 5 minutes
- Escalation to on-call engineer within 5 minutes

Verification:
- Monthly uptime reports from monitoring service
- Quarterly DR drills (full failover test)
- Load balancer failover test (monthly)

Priority: Critical
Penalties: SLA credits if uptime < 99.9% (per contract terms)

Complete Review Examples

Example 12: BRD Section Review

Original BRD Section:

## 3.2 User Management

The system needs user management capabilities. Users should be able to register, login, and manage their profiles. The system should be secure and protect user information. Administrators need to be able to manage users.

Review Findings:

Issues Identified:

1. Completeness (Critical): Missing key requirements

• No password requirements specified
• No user role definitions (regular user vs admin)
• No account activation/verification process
• No password reset workflow
• No session management requirements
• No multi-factor authentication requirements

2. Clarity (Major): Vague statements

• "secure" is not defined - what security controls?
• "manage profiles" is vague - what can users edit?
• "manage users" is vague - what admin capabilities?

3. Testability (Major): Not testable as written

• No acceptance criteria for any requirement
• No measurable security criteria

Improved BRD Section:

## 3.2 User Management

### 3.2.1 User Registration

REQ-201: The system shall allow new users to register by providing:
- Email address (required, unique, validated format)
- Password (required, meets complexity requirements per REQ-202)
- First name (required, 2-50 characters)
- Last name (required, 2-50 characters)
- Phone number (optional, validated format if provided)

REQ-202: The system shall enforce password complexity requirements:
- Minimum 12 characters
- At least 1 uppercase letter
- At least 1 lowercase letter
- At least 1 number
- At least 1 special character (!@#$%^&*)
- Cannot be same as previous 5 passwords
- Cannot contain user's name or email

REQ-203: The system shall send email verification upon registration:
- Verification email sent immediately after registration
- Email contains secure verification link (expires in 24 hours)
- User cannot login until email is verified
- User can request resend of verification email

REQ-204: The system shall validate that email addresses are unique (prevent duplicate accounts)

### 3.2.2 User Authentication

REQ-210: The system shall support username/password authentication:
- Users login with email address and password
- Passwords transmitted over HTTPS only
- Passwords stored as bcrypt hash (work factor ≥ 12)

REQ-211: The system shall lock accounts after 5 failed login attempts within 15 minutes:
- Display message: "Account locked due to multiple failed login attempts. Try again in 15 minutes or reset your password."
- Account automatically unlocks after 15 minutes
- User can unlock by completing password reset

REQ-212: The system shall support "Remember Me" functionality:
- Optional checkbox on login page
- If checked, session lasts 30 days
- If unchecked, session expires after 30 minutes of inactivity
- User can logout manually at any time

REQ-213: The system shall support optional two-factor authentication (2FA):
- Users can enable 2FA in account settings
- Support TOTP-based 2FA (Google Authenticator, Authy compatible)
- 2FA required for admin users (mandatory)
- Backup codes provided when 2FA is enabled (10 single-use codes)

### 3.2.3 Password Reset

REQ-220: The system shall allow users to reset forgotten passwords:
- "Forgot Password" link on login page
- User enters email address
- System sends password reset email (if account exists)
- Reset link expires in 1 hour
- New password must meet complexity requirements (REQ-202)

REQ-221: The system shall not reveal whether an email exists in the system:
- Always display "If an account exists, reset email has been sent"
- Prevents account enumeration attacks

### 3.2.4 Profile Management

REQ-230: Users shall be able to view and edit their profile:
- Editable fields: First name, last name, phone number
- Cannot edit: Email address (must verify new email if changing)
- Profile picture upload (optional, max 5MB, JPG/PNG only)

REQ-231: Users shall be able to change their email address:
- Verify new email address before change takes effect
- Verification link sent to new email address
- Email change confirmed only after clicking verification link

REQ-232: Users shall be able to change their password:
- Must provide current password
- New password must meet complexity requirements (REQ-202)
- New password cannot match previous 5 passwords

REQ-233: Users shall be able to enable/disable 2FA in account settings

REQ-234: Users shall be able to view login history:
- Last 30 days of login activity
- Display: Date/time, IP address, location (city/country), device type

### 3.2.5 Admin User Management

REQ-240: Administrators shall be able to view all user accounts:
- Searchable list: by email, name, or user ID
- Filterable by: account status (active/locked/disabled), role, registration date
- Sortable by: name, email, registration date, last login

REQ-241: Administrators shall be able to disable/enable user accounts:
- Disabled users cannot login
- Reason for disabling must be recorded in audit log

REQ-242: Administrators shall be able to unlock locked accounts:
- Reset failed login counter
- Unlock reason recorded in audit log

REQ-243: Administrators shall be able to assign user roles:
- Roles: Regular User, Admin
- Role changes recorded in audit log with admin user ID and timestamp

REQ-244: Administrators cannot delete user accounts:
- Rationale: Preserve data integrity and audit trail
- Disabled accounts retain all data but prevent login

### 3.2.6 Session Management

REQ-250: The system shall manage user sessions securely:
- Session tokens stored as secure, HTTP-only cookies
- Session tokens are randomly generated (256-bit entropy)
- Sessions expire after 30 minutes of inactivity (unless "Remember Me" checked)
- User can have max 3 concurrent sessions (oldest automatically logged out)

REQ-251: The system shall support explicit logout:
- "Logout" button visible on all pages when logged in
- Logout invalidates current session token immediately
- Redirect to login page after logout

### 3.2.7 Audit & Compliance

REQ-260: The system shall log all authentication and authorization events:
- Login attempts (success and failure): timestamp, user, IP address
- Logout events: timestamp, user
- Password changes: timestamp, user
- Password resets: timestamp, user, IP address
- Profile updates: timestamp, user, fields changed
- Admin actions: timestamp, admin user, action, target user
- Logs retained for 2 years

REQ-261: The system shall comply with GDPR requirements:
- Users can download their data (JSON format)
- Users can request account deletion (admin processes request)
- Privacy policy acceptance required during registration

Review Summary:

• Original: 4 vague sentences
• Improved: 21 specific, testable requirements
• Added: Security controls, workflows, admin capabilities
• Quality improvement: 30% → 95% completeness

This example shows how a vague section transforms into comprehensive, implementable requirements.

---

Key Takeaways

When reviewing requirements, look for:

1. Specificity: Replace vague terms with measurable criteria 2. Testability: Every requirement should have clear pass/fail criteria 3. Completeness: All scenarios including happy path, errors, edge cases 4. Consistency: No conflicts between requirements 5. Traceability: Link to business goals and downstream artifacts

Quality requirements enable quality software!

Quality Checklists

Detailed checklists for assessing requirement quality across different attributes.

Table of Contents

• Individual Requirement Checklist
• Document-Specific Checklists
• User Story Quality (INVEST)

Individual Requirement Checklist

For each requirement, evaluate against these criteria:

Completeness

□ All necessary information included □ No missing details or TBD placeholders □ Context and rationale provided □ Dependencies identified and documented □ Constraints documented □ Assumptions stated explicitly

Clarity

□ Unambiguous language used □ No vague terms ("user-friendly", "fast", "easy", "intuitive") □ Clear subject and action □ Specific and concrete □ Understandable by all stakeholders □ No jargon without definition

Correctness

□ Technically accurate □ Aligned with business needs □ Reflects stakeholder intent □ No technical errors □ Factually correct □ Feasible to implement

Consistency

□ No conflicts with other requirements □ Consistent terminology throughout □ Consistent level of detail □ Compatible priorities □ Aligned with project scope □ Consistent formatting

Testability

□ Can be verified/tested □ Measurable acceptance criteria defined □ Clear pass/fail conditions □ Observable outcomes □ Defined test approach □ Quantifiable where needed

Traceability

□ Unique identifier assigned □ Source documented (stakeholder, regulation, etc.) □ Rationale provided □ Linked to business objectives □ Mapped to architecture/design elements □ Linked to test cases

Necessity

□ Directly supports business goals □ Adds clear value to users/business □ Not a duplicate of existing requirement □ Priority justified □ Cost justified against value

Feasibility

□ Technically feasible with available technology □ Achievable within constraints (time, budget, resources) □ Technology exists or is obtainable □ Team has or can acquire needed capability □ Within budget allocation □ Within project timeline

Document-Specific Checklists

Business Requirements Document (BRD)

Business Context

□ Business problem clearly stated □ Business objectives defined and measurable □ Success criteria quantified □ Stakeholders identified with roles □ Business case present with ROI/benefits analysis □ Strategic alignment documented

Scope Definition

□ In-scope items clearly listed □ Out-of-scope items explicitly stated □ Boundaries well-defined □ Assumptions documented □ Constraints identified □ Dependencies on external factors listed

Business Requirements

□ Requirements state "what" not "how" □ Business rules documented □ Process flows included □ Business metrics defined □ Regulatory requirements covered □ Compliance needs stated

Software Requirements Specification (SRS)

Document Structure

□ IEEE 830 compliant structure (if applicable) □ Version control information present □ Table of contents complete □ Glossary of terms included □ References section complete □ Appropriate sections present

Functional Requirements

□ All system features specified □ System behaviors defined □ Input/output specifications complete □ Business logic detailed □ Error handling scenarios covered □ Edge cases addressed

Non-Functional Requirements

Performance □ Response time requirements specified □ Throughput requirements defined □ Resource utilization limits set □ Capacity requirements stated

Security □ Authentication mechanisms defined □ Authorization rules specified □ Data protection requirements stated □ Audit logging needs documented

Reliability □ Availability targets specified (uptime %) □ MTBF/MTTR defined □ Backup requirements stated □ Disaster recovery needs addressed

Usability □ User experience goals defined □ Accessibility requirements stated (WCAG level) □ Internationalization needs documented □ Training requirements specified

Maintainability □ Code quality standards defined □ Documentation requirements stated □ Modularity requirements specified □ Update/patch strategy defined

Technical Details

□ Architecture constraints stated □ Technology stack requirements listed □ Integration points defined with APIs/protocols □ Data requirements specified with schemas □ Interface requirements clear

Verification

□ All requirements have verification method □ Acceptance criteria defined for each requirement □ Test approach specified □ Traceability matrix complete or referenced

User Story Backlog

Epic Level

□ Epics align with business goals □ Epics appropriately sized (decomposable into 5-10 stories) □ Epic dependencies mapped □ Epic-level acceptance criteria defined □ Value proposition clear for each epic

Story Level Format

□ Follows standard format: "As a [role], I want [feature], so that [benefit]" □ Role clearly identified (specific user type) □ Feature/capability specifically described □ Business value/benefit explicitly stated □ Story is self-contained and understandable

Story Completeness

□ UI/UX considerations noted where relevant □ Technical constraints documented □ Dependencies on other stories identified □ Size estimate provided (story points) □ Priority assigned (MoSCoW, numeric, etc.) □ Epic or feature area linked

User Story Quality (INVEST)

Evaluate each user story against INVEST criteria:

Independent

□ Story can be developed and tested separately from other stories □ No tight coupling with other stories □ Can be scheduled flexibly □ Dependencies are documented but minimal

Negotiable

□ Details can be discussed and refined □ Not an explicit contract or detailed specification □ Allows for collaboration between team and stakeholder □ Room for technical implementation choices

Valuable

□ Delivers clear value to end user or business □ Value statement is explicit in the "so that" clause □ Stakeholder can understand and prioritize the value □ Contributes to business goals or user needs

Estimable

□ Team has enough information to provide size estimate □ Complexity is understood □ No major unknowns that prevent estimation □ If not estimable, needs spike or research story first

Small

□ Can be completed within one sprint/iteration □ Fits within team's definition of "small" □ Large stories are broken down (epics → stories → tasks) □ Typically 1-5 days of effort

Testable

□ Clear acceptance criteria provided □ Can be verified/validated □ Pass/fail conditions are objective □ Testing approach is obvious

Common Quality Issues

Ambiguity Examples

❌ Bad: "The system shall be fast" ✅ Good: "The system shall respond to user search queries within 2 seconds for 95% of requests under normal load"

❌ Bad: "The interface shall be user-friendly" ✅ Good: "New users shall be able to complete their first purchase within 5 minutes without requiring help documentation"

❌ Bad: "The system shall handle many concurrent users" ✅ Good: "The system shall support 10,000 concurrent users with 99.9% uptime and response times under 3 seconds"

Incompleteness Examples

❌ Bad: "The system shall send notifications" ✅ Good: "The system shall send email notifications to users within 5 minutes when their order status changes to 'Shipped', including order number, new status, tracking link, and estimated delivery date"

❌ Bad: "Users shall be able to search products" ✅ Good: "Users shall be able to search products by keyword, category, price range ($-$$$$), and brand, with results displayed in relevance order and pagination (20 items per page) within 2 seconds"

Untestability Examples

❌ Bad: "The system shall be secure" ✅ Good: "The system shall: (1) enforce password complexity (min 8 chars, 1 uppercase, 1 number, 1 special char), (2) lock accounts after 5 failed login attempts for 15 minutes, (3) encrypt all data in transit using TLS 1.3, (4) encrypt sensitive data at rest using AES-256"

❌ Bad: "The application shall be maintainable" ✅ Good: "The application code shall maintain: (1) 80% unit test coverage, (2) cyclomatic complexity below 10 per function, (3) no duplicated code blocks over 10 lines, (4) JSDoc comments for all public APIs"

Inconsistency Examples

Conflicting Requirements ❌ Requirement A: "Users must provide phone number during registration" Requirement B: "Phone number is optional during account creation" → Conflict: Mandatory vs optional field

❌ Requirement A (Priority: High): "System must support real-time data synchronization" Requirement B (Priority: High): "System processes data in nightly batch jobs only" → Conflict: Real-time vs batch processing approach

Terminology Inconsistencies ❌ Using "User", "Customer", and "Client" interchangeably ✅ Use one consistent term throughout, defined in glossary

❌ Using "Order", "Purchase", and "Transaction" to mean the same thing ✅ Define precise meanings or use one term consistently

Over-Specification Examples

❌ Bad: "The primary action button shall be colored #0066CC with 12px Arial font, 5px padding, 2px border radius, and box-shadow: 0 2px 4px rgba(0,0,0,0.1)" ✅ Good: "Primary action buttons shall follow the design system style guide for primary CTAs"

❌ Bad: "Error messages shall be displayed in 14pt Helvetica Neue font, colored #D32F2F, with icon error_outline from Material Design icons" ✅ Good: "Error messages shall follow the design system error message pattern for visibility and accessibility"

Acceptance Criteria Formats

Given-When-Then (Behavior-Driven)

Given: User is logged in with a valid account
  And: User has items in shopping cart
When: User clicks "Place Order" button
Then: Order is created with unique order ID
  And: User receives confirmation email within 5 minutes
  And: Order appears in user's order history within 2 seconds
  And: Inventory is decremented immediately
  And: Payment is processed successfully

Checklist Format

**Acceptance Criteria for User Login**

□ User can enter email and password
□ System validates email format before submission
□ System displays error for invalid credentials
□ Successful login redirects to user dashboard
□ Session persists for 30 days with "Remember me"
□ Failed login shows clear error message
□ Account locks after 5 failed attempts
□ Password field masks characters
□ Forgot password link is visible and functional

Scenario-Based Format

**Scenario 1: Successful Product Search**
- User enters "laptop" in search box
- System returns results within 2 seconds
- Results show 10-50 relevant products
- Each result displays: image, name, price, rating
- User can filter by price range and brand

**Scenario 2: No Results Found**
- User enters "xyzabc12345" (non-existent)
- System displays "No results found" message
- System suggests: (1) Check spelling, (2) Try different keywords, (3) Browse categories
- Search took less than 2 seconds

**Scenario 3: Partial Match**
- User enters "lapto" (typo)
- System suggests "Did you mean: laptop?"
- Clicking suggestion performs correct search
- Alternative results still shown for "lapto"

Quality Scoring Guidelines

Scoring Scale (0-100%)

90-100% (Excellent)

• All criteria met or exceeded
• No critical or major issues
• Minor issues only (cosmetic, formatting)
• Requirements are production-ready

70-89% (Good)

• Most criteria met
• No critical issues
• Few major issues with clear resolution path
• Requirements ready with minor revisions

50-69% (Fair)

• Some criteria met
• Few critical issues OR multiple major issues
• Significant revision needed
• Requirements need substantial work

0-49% (Poor)

• Many criteria not met
• Multiple critical issues
• Major rework required
• Requirements not ready for next phase

Issue Severity Definitions

Critical (Must Fix)

• Blocks project progress
• Causes major business impact
• Prevents requirement from being implemented
• Creates legal/compliance risk
• Examples: Missing security requirements, fundamental conflicts, incomplete scope

Major (Should Fix)

• Significantly impacts quality or implementation
• Causes confusion or ambiguity
• Increases risk of rework
• Affects multiple stakeholders
• Examples: Ambiguous performance criteria, missing acceptance criteria, terminology inconsistencies

Minor (Nice to Fix)

• Does not block progress
• Has workarounds available
• Cosmetic or formatting issues
• Minimal impact on implementation
• Examples: Formatting inconsistencies, minor typos, missing diagrams (if content is clear)

Traceability Assessment

Backward Traceability

Each requirement should trace to: □ Business objective or strategic goal □ Stakeholder need (who requested and why) □ Business case element (ROI, benefit) □ Market requirement or competitive analysis □ Regulatory/compliance mandate (if applicable) □ User research finding or usability study

Forward Traceability

Each requirement should trace to: □ Design elements (architecture diagrams, UI mockups) □ Architecture components (services, modules, APIs) □ Implementation tasks or user stories □ Test cases (unit, integration, acceptance) □ Validation criteria and acceptance tests □ Documentation and help content (if user-facing)

Traceability Matrix Quality

□ Complete coverage - no orphan requirements □ Unique, consistent identifiers for all items □ Clear, documented relationships between items □ Version tracking for requirement changes □ Impact analysis capability (what breaks if requirement changes) □ Maintained throughout project lifecycle

Gap Analysis

Identify and document:

• Missing Requirements: Business needs without corresponding requirements
• Orphan Requirements: Requirements without business justification
• Untested Requirements: Requirements without mapped test cases
• Undesigned Requirements: Requirements without design coverage
• Unstakeholdered Needs: Potential stakeholder needs not yet captured

Standards Compliance

IEEE 830-1998 (SRS Standard)

Correct Requirements Characteristics

□ Unambiguous: Only one interpretation possible □ Complete: All needed information present □ Correct: Accurately represents stakeholder needs □ Understandable: Clear to all stakeholders □ Verifiable: Can objectively test if met □ Consistent: No internal contradictions □ Modifiable: Structure allows easy changes □ Traceable: Origin and forward path clear □ Ranked: Priority and stability indicated

Required SRS Document Structure

□ Introduction (purpose, scope, definitions, references, overview) □ Overall description (product perspective, functions, user characteristics, constraints) □ Specific requirements (functional, non-functional, interface) □ Supporting information (appendices, index)

Industry-Specific Standards

Healthcare □ HIPAA compliance for data privacy □ HL7 standards for health information exchange □ FDA requirements for medical devices □ ICD-10 coding standards

Finance □ PCI-DSS for payment card data □ SOX for financial reporting accuracy □ PSD2 for payment services □ AML/KYC requirements

Automotive □ ISO 26262 for functional safety □ AUTOSAR for software architecture □ ASPICE for process quality

Aerospace □ DO-178C for airborne software □ DO-254 for airborne hardware

General Quality/Security □ ISO 9001 for quality management □ ISO 27001 for information security □ GDPR for data protection (EU) □ CCPA for consumer privacy (California)

Agile Best Practices

□ User stories follow INVEST principles □ Acceptance criteria are specific and testable □ Definition of Done exists and is followed □ Stories appropriately sized for sprint □ Epics properly decomposed into stories □ Backlog is prioritized and groomed regularly □ Dependencies identified and managed □ Technical debt tracked and addressed

Review Report Templates

Templates for generating comprehensive requirements review reports.

Table of Contents

• Full Review Report Template
• Quick Review Summary Template
• Issue Tracking Template

Full Review Report Template

# Requirements Review Report

**Document**: [Document name and version number]
**Review Date**: [Date performed]
**Reviewers**: [Names and roles of review team]
**Review Scope**: [What was included in this review]
**Review Type**: [Initial / Update / Quality Gate / Pre-Design]

---

## Executive Summary

## Overall Assessment
- **Overall Quality Rating**: [Excellent / Good / Fair / Poor]
- **Recommendation**: [Approve / Approve with Conditions / Major Revision Needed / Reject]

**Key Strengths** (2-3 bullet points):
- ✅ [Strength 1 - be specific]
- ✅ [Strength 2 - be specific]
- ✅ [Strength 3 - be specific]

**Critical Issues** (2-3 bullet points):
- ⛔ [Critical issue 1 - be specific]
- ⛔ [Critical issue 2 - be specific]
- ⛔ [Critical issue 3 - be specific]

**Top Recommended Actions** (3-5 priority items):
1. [Action 1 - specific and actionable]
2. [Action 2 - specific and actionable]
3. [Action 3 - specific and actionable]
4. [Action 4 - specific and actionable]
5. [Action 5 - specific and actionable]

### Review Metrics
- **Total Requirements Reviewed**: [number]
- **Issues Found**:
  - Critical: [number]
  - Major: [number]
  - Minor: [number]
  - Total: [number]
- **Quality Scores**:
  - Completeness: [percentage]%
  - Clarity: [percentage]%
  - Consistency: [percentage]%
  - Testability: [percentage]%
  - Traceability: [percentage]%
  - **Overall Quality**: [percentage]% ([Excellent/Good/Fair/Poor])

---

## Detailed Findings

### 1. Completeness Assessment

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

**Strengths**:
- ✅ [Specific strength example with requirement IDs if applicable]
- ✅ [Specific strength example]

**Issues Found**:

#### Critical Issues
- ⛔ **[Issue ID e.g., COMP-001]**: [Issue description]
  - **Location**: [Section/Requirement ID]
  - **Impact**: [Explanation of business/technical impact]
  - **Recommendation**: [Specific fix needed]

#### Major Issues
- ⚠️ **[Issue ID]**: [Issue description]
  - **Location**: [Section/Requirement ID]
  - **Impact**: [Impact explanation]
  - **Recommendation**: [Specific fix]

#### Missing Requirements
- 📋 **[Gap ID]**: [Description of what's missing]
  - **Area**: [Module/Feature area]
  - **Impact**: [Business/technical impact if not addressed]
  - **Recommendation**: [What needs to be added]

### 2. Clarity & Understandability Assessment

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

**Strengths**:
- ✅ [Example of well-written requirements]

**Issues Found**:

#### Ambiguous Requirements
- ⚠️ **[REQ-ID]**: "[Original ambiguous requirement text]"
  - **Issue**: [Why it's ambiguous - multiple interpretations possible]
  - **Interpretation A**: [Possible meaning 1]
  - **Interpretation B**: [Possible meaning 2]
  - **Recommendation**: "[Suggested clearer requirement text]"

- ⚠️ **[REQ-ID]**: "[Another ambiguous requirement]"
  - **Issue**: [Explanation]
  - **Recommendation**: "[Clearer version]"

#### Vague Terms Found
Requirements using unclear language:
- "User-friendly" appears in: [REQ-023, REQ-034, REQ-056]
- "Fast performance" in: [REQ-045, REQ-078]
- "Easy to use" in: [REQ-067, REQ-089, REQ-091]
- "Intuitive" in: [REQ-102, REQ-115]

**Recommendation**: Replace with specific, measurable criteria. Examples:
- "User-friendly" → "New users complete first task in < 5 minutes without help"
- "Fast" → "Response time < 2 seconds for 95% of requests"

### 3. Consistency & Conflict Analysis

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

**Issues Found**:

#### Conflicting Requirements
- 🔴 **Conflict #1**: Requirements [REQ-012] vs [REQ-089]
  - **REQ-012**: "[Full requirement text]"
  - **REQ-089**: "[Conflicting requirement text]"
  - **Conflict Nature**: [Explanation of the conflict]
  - **Business Impact**: [Impact if not resolved]
  - **Recommended Resolution**: [Specific resolution approach]

- 🔴 **Conflict #2**: [Similar structure for other conflicts]

#### Terminology Inconsistencies
| Inconsistent Terms Used | Occurrences | Recommended Standard Term |
| ------------------------- | ------------- |---------------------------|
| User / Customer / Client / End-user | 45 / 23 / 12 / 8 | "User" (most common) |
| Login / Sign-in / Log-in / Sign in | 15 / 8 / 7 / 4 | "Login" (matches system) |
| Order / Purchase / Transaction | 34 / 12 / 8 | "Order" (business term) |

**Recommendation**: Create glossary defining standard terms and update all requirements.

#### Priority Conflicts
- [REQ-045] marked Critical but depends on [REQ-078] marked Medium
- Too many requirements (35 of 120) marked as "Critical" priority
- [REQ-089] and [REQ-091] both marked Priority 1 but mutually exclusive

### 4. Testability Assessment

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

**Issues Found**:

#### Untestable Requirements
- ❌ **[REQ-034]**: "The system shall be secure"
  - **Issue**: No measurable criteria for determining if "secure"
  - **Recommendation**: Break into testable requirements:
    - "System shall enforce password complexity (8+ chars, 1 uppercase, 1 number, 1 special char)"
    - "System shall lock accounts after 5 failed login attempts within 15 minutes"
    - "System shall encrypt all data in transit using TLS 1.3"
    - "System shall encrypt sensitive PII at rest using AES-256"
    - "System shall log all authentication attempts with timestamp and IP"

- ❌ **[REQ-067]**: "Application shall be maintainable"
  - **Issue**: Subjective, no objective pass/fail
  - **Recommendation**:
    - "Code shall maintain 80% unit test coverage"
    - "Cyclomatic complexity shall not exceed 10 per function"
    - "All public APIs shall have JSDoc/XML documentation"
    - "No code duplication blocks exceeding 10 lines"

#### Missing Acceptance Criteria
User stories lacking acceptance criteria:
- [US-045]: "As a user, I want to search products..."
- [US-056]: "As a customer, I want to track my order..."
- [US-078]: "As an admin, I want to manage users..."
- [US-089]: "As a user, I want to save favorites..."

**Total**: 23 user stories (of 87) lack acceptance criteria

**Recommendation**: Add Given-When-Then acceptance criteria for all stories before sprint planning.

#### Requirements Without Verification Method
- [REQ-023, REQ-034, REQ-056, REQ-078, REQ-091]: No test approach defined
- No verification method specified for non-functional requirements in Section 4.3

### 5. Traceability Assessment

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

**Issues Found**:

#### Missing Backward Traceability
**Orphan Requirements** (no business justification):
- [REQ-145]: Real-time dashboard feature (Who requested? Why needed?)
- [REQ-167]: Advanced reporting module (Business value unclear)
- [REQ-189]: Mobile app support (Not in original scope?)

**Recommendation**: Link each requirement to:
- Business objective or goal
- Stakeholder who requested it
- Business case element (ROI, cost savings, revenue)

#### Missing Forward Traceability
**Requirements Without Design Coverage**: [45 requirements]
- Section 3.2 (User Management): No architecture/design documented
- Section 3.5 (Reporting): No UI mockups or data model

**Requirements Without Test Cases**: [78 requirements]
- No test cases mapped for functional requirements in Sections 3.1-3.4
- Non-functional requirements (Section 4) have no test strategy

**Untraced Business Needs**:
Business objectives mentioned in charter but not in requirements:
- "Support mobile access for field workers" - No mobile requirements
- "Integrate with payment gateway" - No payment processing requirements
- "Provide analytics dashboard" - Basic reporting only, no analytics

**Recommendation**: Create or update Requirements Traceability Matrix linking:
- Business Need → Requirement → Design → Implementation → Test Case

### 6. Standards Compliance Assessment

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

**Issues Found**:

#### IEEE 830 Compliance (if applicable)
- ❌ Missing: Glossary of terms (Section 1.4)
- ❌ Missing: Assumptions and dependencies documented
- ⚠️ Incomplete: Version control information (no change history)
- ⚠️ Incomplete: Only 60% of requirements have verification methods

#### Industry Standards (if applicable)
- [List specific standard] requirement [X] not met: [explanation]
- [Standard] compliance requirement missing: [what's needed]

#### Agile Best Practices (if applicable)
- 23 user stories do not follow INVEST criteria (missing testability)
- Definition of Done not documented
- Stories not properly sized (12 stories estimated > 13 points)
- Epic decomposition incomplete for [Epic-005] and [Epic-007]

### 7. Feasibility & Risk Assessment

**Rating**: [Excellent / Good / Fair / Poor] ([score]%)

#### High-Risk Requirements

| Req ID | Requirement Summary | Risk Category | Risk Level | Impact | Mitigation Needed |
| -------- | ------------------- |---------------|------------|--------|-------------------|
| REQ-045 | Real-time sync across 100K concurrent users | Technical complexity, Performance | High | Project timeline, Budget | POC/spike required, architecture review |
| REQ-067 | AI-based product recommendations | Unproven technology, Resource | Medium | Feature delivery | Evaluate ML platforms, skill assessment |
| REQ-089 | Sub-second global search | Performance, Infrastructure | High | User satisfaction | Load testing, CDN strategy |

**Recommendations**:
- **REQ-045**: Conduct proof-of-concept for real-time architecture before committing
- **REQ-067**: Evaluate 3rd-party ML services vs build, assess team ML skills
- **REQ-089**: Performance testing with realistic data volumes, consider search service

#### Feasibility Concerns
- **Technical**: [List technical feasibility concerns]
- **Resource**: [List resource/skill availability concerns]
- **Timeline**: [List schedule risk concerns]
- **Budget**: [List cost concerns]

---

## Quality Metrics Summary

### Quality Scores by Attribute

| Quality Attribute | Score | Target | Status | Gap |
| ------------------- | ------- |--------|--------|-----|
| Completeness | 75% | 95% | ⚠️ Below | -20% |
| Clarity | 82% | 90% | ⚠️ Below | -8% |
| Consistency | 70% | 95% | ❌ Poor | -25% |
| Testability | 65% | 90% | ❌ Poor | -25% |
| Traceability | 68% | 95% | ❌ Poor | -27% |
| Feasibility | 85% | 90% | ⚠️ Below | -5% |
| **Overall Quality** | **74%** | **90%** | **⚠️ Below Target** | **-16%** |

### Issue Distribution

| Severity | Count | Percentage | Examples |
| ---------- | ------- |------------|----------|
| Critical | 5 | 4% | Missing security requirements, fundamental scope conflicts |
| Major | 18 | 15% | Ambiguous performance criteria, missing acceptance criteria, terminology inconsistencies |
| Minor | 32 | 27% | Formatting inconsistencies, minor typos, diagram improvements |
| **Total Issues** | **55** | **46% of requirements** | |

### Requirements Coverage

| Category | Count | Percentage | Status |
| ---------- | ------- |------------|--------|
| Requirements Reviewed | 120 | 100% | |
| Requirements with Issues | 55 | 46% | ⚠️ High |
| Requirements without Issues | 65 | 54% | ✅ Good |
| High-Risk Requirements | 8 | 7% | ⚠️ Needs attention |
| Untestable Requirements | 23 | 19% | ❌ Critical gap |
| Orphan Requirements (no traceability) | 15 | 13% | ⚠️ Needs justification |

---

## Recommendations

### Critical (Must Fix Before Approval)

1. **Add Missing Security Requirements (REQ-SEC-*)**
   - **Priority**: Critical
   - **Effort**: 2-3 days
   - **Actions**:
     - Define authentication mechanisms (OAuth2, JWT)
     - Specify authorization rules (RBAC model)
     - Document data protection requirements (encryption at rest/transit)
     - Define audit logging requirements (what, when, retention)
     - Specify session management (timeout, concurrent sessions)
   - **Owner**: [Security Architect + Business Analyst]
   - **Due**: [Date]

2. **Resolve Requirement Conflicts (Conflicts #1, #3, #5)**
   - **Priority**: Critical
   - **Effort**: 1 week
   - **Actions**:
     - Conflict #1 (REQ-012 vs REQ-089): Clarify whether phone number is mandatory
     - Conflict #3 (REQ-034 vs REQ-078): Align on real-time vs batch processing
     - Conflict #5 (REQ-091 vs REQ-102): Resolve mobile-first vs desktop-first priority
   - **Owner**: [Product Owner + Business Analyst]
   - **Due**: [Date]

3. **Add Acceptance Criteria to All User Stories (23 stories)**
   - **Priority**: Critical
   - **Effort**: 1-2 weeks
   - **Actions**:
     - Use Given-When-Then format for each story
     - Include positive scenarios (happy path)
     - Include negative scenarios (error cases)
     - Include edge cases
     - Define clear pass/fail criteria
   - **Owner**: [Business Analyst + Development Team]
   - **Due**: [Date]

### Major (Should Fix for Quality)

4. **Improve Clarity of Performance Requirements**
   - **Priority**: Major
   - **Effort**: 3-5 days
   - **Actions**:
     - Replace vague terms ("fast", "quick", "responsive") with specific targets
     - Specify response time targets with percentiles (e.g., "< 2s for 95% of requests")
     - Define load/concurrency requirements (concurrent users, transactions/second)
     - Document performance measurement approach
   - **Owner**: [Business Analyst + Performance Engineer]
   - **Due**: [Date]

5. **Enhance Requirements Traceability**
   - **Priority**: Major
   - **Effort**: 1 week
   - **Actions**:
     - Link all requirements to business objectives/goals
     - Create comprehensive Requirements Traceability Matrix
     - Map requirements to design elements
     - Map requirements to test cases
     - Document requirement sources (stakeholder, regulation, etc.)
   - **Owner**: [Business Analyst]
   - **Due**: [Date]

6. **Standardize Terminology**
   - **Priority**: Major
   - **Effort**: 2-3 days
   - **Actions**:
     - Create glossary of terms with definitions
     - Define standard terms for identified inconsistencies
     - Update all requirements to use standard terminology
     - Distribute glossary to all stakeholders
   - **Owner**: [Business Analyst]
   - **Due**: [Date]

### Minor (Nice to Have)

7. **Add More Diagrams for Complex Workflows**
   - **Priority**: Minor
   - **Effort**: 1-2 days
   - **Recommendation**: Add workflow diagrams for user registration, checkout, and order fulfillment processes

8. **Include More Usage Examples**
   - **Priority**: Minor
   - **Effort**: 1 day
   - **Recommendation**: Add concrete examples for complex requirements to improve understanding

9. **Improve Document Formatting Consistency**
   - **Priority**: Minor
   - **Effort**: 0.5 day
   - **Recommendation**: Consistent numbering, heading styles, and table formats throughout

---

## Action Items

| ID | Action | Owner | Priority | Effort | Due Date | Status | Dependencies |
| ---- | -------- |-------|----------|--------|----------|--------|--------------|
| A-001 | Add security requirements section | [Security Architect, BA] | Critical | 2-3 days | [Date] | Open | None |
| A-002 | Resolve conflict: REQ-012 vs REQ-089 | [PO, BA] | Critical | 0.5 day | [Date] | Open | A-001 |
| A-003 | Add acceptance criteria to US-045 through US-078 | [BA, Dev Team] | Critical | 1-2 weeks | [Date] | Open | None |
| A-004 | Create glossary of terms | [BA] | Major | 0.5 day | [Date] | Open | None |
| A-005 | Update Requirements Traceability Matrix | [BA] | Major | 3 days | [Date] | Open | A-004 |
| A-006 | Replace vague performance terms with targets | [BA, Perf Engineer] | Major | 3 days | [Date] | Open | None |
| A-007 | Add workflow diagrams | [BA, UX] | Minor | 1-2 days | [Date] | Backlog | A-005 |

---

## Approval Recommendation

### Decision
**[Approve with Conditions / Major Revision Needed / Reject]**

### Rationale
[Provide 2-3 sentences explaining the recommendation based on findings. Example:]

The requirements show a solid foundation with clear business objectives and well-structured functional requirements (65 of 120 requirements have no issues). However, critical gaps exist in security requirements, requirement conflicts need resolution, and 23 user stories lack acceptance criteria needed for development. The testability and traceability scores (65% and 68%) fall significantly below the 90% target, indicating substantial rework is needed before the requirements can serve as a reliable foundation for design and development.

### Conditions for Approval (if "Approve with Conditions")

1. **All critical issues (A-001 through A-003) must be resolved**
   - Security requirements section added and reviewed
   - All requirement conflicts resolved with stakeholder agreement
   - Acceptance criteria added to all user stories

2. **Major issues should be addressed or have mitigation plans**
   - Performance requirements clarified with specific targets
   - Traceability matrix completed and validated
   - Terminology standardized across all requirements

3. **Updated version to be re-reviewed**
   - Submit updated requirements document by [date]
   - Targeted review of previously identified issues
   - Final approval within 3 business days of submission

### Next Steps

1. **Immediate**: BA team addresses critical issues (A-001 through A-003)
2. **Week 1**: Resolve requirement conflicts with stakeholder meetings
3. **Week 2**: Complete major quality improvements (A-004 through A-006)
4. **Week 3**: Submit updated requirements for targeted re-review
5. **Week 4**: Final approval and handoff to design team

---

## Sign-Off

**Review Team**:
- Reviewer: _________________ Role: _________ Date: _______
- Reviewer: _________________ Role: _________ Date: _______
- Reviewer: _________________ Role: _________ Date: _______

**Approvals** (after conditions met):
- Business Owner: _________________ Date: _______
- Technical Lead: _________________ Date: _______
- Project Manager: _________________ Date: _______

**Document Version Control**:
- Review Report Version: [1.0]
- Requirements Document Version Reviewed: [Version number]
- Next Review Scheduled: [Date] (if conditional approval)

---

**End of Review Report**

Quick Review Summary Template

For rapid reviews or status checks:

# Quick Requirements Review Summary

**Document**: [Name] v[Version]
**Review Date**: [Date]
**Reviewer**: [Name]

## Quick Assessment

**Overall**: [🟢 Good / 🟡 Needs Work / 🔴 Major Issues]

**Key Findings**:
- Total Requirements: [number]
- Critical Issues: [number]
- Major Issues: [number]
- Overall Quality: [percentage]%

## Top 3 Issues

1. **[Issue]**: [Brief description] → [Quick fix]
2. **[Issue]**: [Brief description] → [Quick fix]
3. **[Issue]**: [Brief description] → [Quick fix]

## Recommendation

[Approve / Conditional Approve / Revise / Reject]

**Next Action**: [What needs to happen next]

Issue Tracking Template

For tracking individual requirement issues:

| Issue ID | Severity | Req ID | Issue Type | Description | Recommendation | Owner | Status | Due Date |
| ---------- | ---------- |--------|------------|-------------|----------------|-------|--------|----------|
| ISS-001 | Critical | REQ-045 | Ambiguity | "Fast" undefined | Specify: "< 2s for 95%" | [BA] | Open | [Date] |
| ISS-002 | Major | REQ-067 | Untestable | "Intuitive UI" subjective | Define usability metrics | [UX] | Open | [Date] |
| ISS-003 | Critical | REQ-012, REQ-089 | Conflict | Phone number mandatory/optional | Align with stakeholders | [PO] | Open | [Date] |
| ISS-004 | Major | US-045 | Missing AC | No acceptance criteria | Add Given-When-Then | [BA] | In Progress | [Date] |
| ISS-005 | Minor | Section 3.2 | Formatting | Inconsistent numbering | Fix numbering | [BA] | Closed | [Date] |