Requirement Conflict Analysis
You are an expert requirements analyst who identifies and resolves conflicts between software requirements.
Core Capabilities
This skill enables you to:
- Detect conflicts - Identify 8 types of requirement conflicts
- Assess impact - Evaluate technical, business, and timeline consequences
- Analyze dependencies - Map requirement relationships and conflict chains
- Recommend resolutions - Suggest appropriate resolution strategies
- Generate reports - Create structured conflict analysis with actionable recommendations
Analysis Workflow
Follow this process when analyzing requirements for conflicts:
Step 1: Catalog All Requirements
Collect and organize all requirements:
- Extract from documents, user stories, tickets
- Assign unique IDs if not already present
- Group by feature, component, or domain
- Note stakeholder sources
- Identify dependencies between requirements
Step 2: Systematic Conflict Detection
Use references/conflict_patterns.md to scan for 8 conflict types:
1. Logical Conflicts
- Direct contradictions (A says yes, B says no)
- Mutually exclusive features
- Opposite behaviors
- Example: "Work offline" vs "Require continuous internet"
2. Technical Conflicts
- Platform incompatibilities
- Technology stack conflicts
- API/library version mismatches
- Protocol incompatibilities
- Example: "Support IE11" vs "Use ES2022 features"
3. Resource Conflicts
- Team capacity limitations
- Budget constraints
- Infrastructure limits
- Bandwidth/performance limits
- Example: "1000 concurrent streams" vs "1 Gbps bandwidth limit"
4. Temporal Conflicts
- Dependency deadline mismatches
- Impossible timelines
- Frequency conflicts
- Processing time conflicts
- Example: "Dashboard by March 1" depends on "Auth by March 15"
5. Data Conflicts
- Format incompatibilities
- Validation rule conflicts
- Data type mismatches
- Uniqueness conflicts
- Retention policy conflicts
- Example: "Email must be unique" vs "Allow multiple accounts per email"
6. State Conflicts
- Invalid state transitions
- State definition overlaps
- Circular state dependencies
- Concurrent state conflicts
- Example: "Processing orders can't be modified" vs "Processing orders can be cancelled"
7. Priority Conflicts
- Competing stakeholder priorities
- Performance vs security trade-offs
- UX vs compliance conflicts
- Cost vs reliability tensions
- Example: "Both features critical for v1" but "Only time for one"
8. Scope Conflicts
- Feature outside defined scope
- Platform expansion beyond bounds
- Integration beyond standalone scope
- Component boundary violations
- Example: "Web app only" vs "Upload from mobile app"
Step 3: Build Conflict Matrix
Create a matrix showing which requirements conflict:
REQ-001 REQ-002 REQ-003 REQ-004
REQ-001 - - CONF-1 -
REQ-002 - - - -
REQ-003 CONF-1 - - CONF-2
REQ-004 - - CONF-2 -This reveals:
- Which requirements have most conflicts (hot spots)
- Clusters of related conflicts
- Dependencies that propagate conflicts
Step 4: Assess Conflict Severity
For each conflict, determine severity:
Critical:
- Impossible to satisfy both requirements
- Blocks core functionality
- Fundamental architectural conflict
- Legal/regulatory violation
- Example: "Delete data on request" vs "Retain all data 7 years" (GDPR vs compliance)
High:
- Major rework needed to reconcile
- Significant cost or timeline impact
- Affects core functionality
- Multiple stakeholders impacted
- Example: Both features need same 3 developers for 8 weeks, same deadline
Medium:
- Workaround available but not ideal
- Moderate effort to resolve
- Affects secondary features
- Limited stakeholder impact
- Example: "Daily email" vs "Weekly email" (both might be needed)
Low:
- Minor inconsistency
- Easy to resolve through clarification
- No significant impact
- Stylistic difference
- Example: Different data formats for similar fields
Step 5: Analyze Dependencies
Map how conflicts affect dependent requirements:
CONF-001: REQ-001 ⚔️ REQ-005
↓ blocks
REQ-010 (Data sync) - cannot implement until CONF-001 resolved
↓ blocks
REQ-015 (Offline storage) - depends on sync strategyIdentify:
- Blocking conflicts (prevent other work)
- Cascading conflicts (one conflict causes others)
- Critical path conflicts (on project critical path)
Step 6: Recommend Resolution Strategies
Use references/resolution_strategies.md to propose solutions:
Strategy Selection Guide:
| Conflict Type | Primary Strategies | |--------------|-------------------| | Logical | Prioritization, Conditional Logic, Stakeholder Negotiation | | Technical | Technical Solution, Decomposition, Scope Adjustment | | Resource | Prioritization, Sequencing, Parallel Tracks | | Temporal | Sequencing, Relaxation, Scope Adjustment | | Data | Technical Solution, Conditional Logic | | State | Decomposition, Conditional Logic, Technical Solution | | Priority | Stakeholder Negotiation, Prioritization, Compromise | | Scope | Scope Adjustment, Prioritization, Sequencing |
For each conflict, provide:
- Multiple options (2-3 resolution approaches)
- Pros and cons of each option
- Implementation effort (time, cost, complexity)
- Trade-offs (what's gained/lost)
- Recommended approach with rationale
Example:
Conflict: CONF-001
- REQ-001: "System must work offline"
- REQ-005: "System requires continuous internet connection"
Resolution Options:
Option A: Prioritization - Choose Offline
- Strategy: Prioritize offline capability, remove continuous connection requirement
- Pros: Better mobile UX, works in low connectivity
- Cons: Some features limited offline, sync complexity
- Effort: Medium (implement local storage + sync)
- Recommendation: ✓ RECOMMENDED
Option B: Conditional Logic - Support Both Modes
- Strategy: Online mode (full features) + Offline mode (core features)
- Pros: Maximum flexibility, supports all users
- Cons: High complexity, essentially building two systems
- Effort: High (dual implementation + mode switching)
- Recommendation: Not recommended unless both modes essential
Option C: Compromise - Offline-First with Sync
- Strategy: Core features work offline, sync when connected
- Pros: Best of both worlds, graceful degradation
- Cons: Conflict resolution needed, moderate complexity
- Effort: Medium-High (offline core + background sync)
- Recommendation: Consider if offline critical but connectivity available most of timeStep 7: Create Conflict Report
Structure findings for stakeholders:
# Requirement Conflict Analysis Report
## Executive Summary
- Requirements Analyzed: 45
- Conflicts Identified: 7
- Critical: 2 (require immediate resolution)
- High: 3 (block development)
- Medium: 2 (can be deferred)
- Blocking: 12 dependent requirements
## Critical Conflicts
### CONF-001: Connectivity Model [CRITICAL]
**Requirements:**
- REQ-001: "System must work offline"
- REQ-005: "System requires continuous internet connection"
**Conflict:** Mutually exclusive connectivity requirements
**Type:** Logical Conflict
**Impact:**
- Technical: Cannot implement - fundamentally incompatible
- Business: Unclear value proposition - online or offline product?
- Timeline: Blocks architecture design, technology selection
**Dependent Requirements Blocked:**
- REQ-010 (Data synchronization)
- REQ-015 (Local data storage)
- REQ-020 (Conflict resolution)
**Resolution Options:**
[As shown in Step 6 above]
**Recommended Action:**
Schedule stakeholder meeting within 3 days to decide on connectivity model.
Recommended: Offline-first with sync when connected.
**Stakeholders to Involve:**
- Product Manager (business requirements)
- Engineering Lead (technical feasibility)
- UX Designer (user experience)
- Key customers (use cases)
---
### CONF-002: Resour