Handling Conflicting Requirements

Real requirements conflict. Marketing wants the signup flow simple; security wants two-factor on by default. Product wants fast launch; engineering wants reliability. Sales wants flexibility; support wants consistency. Pretending these conflicts don't exist leads to the worst kind of compromise — fudged requirements that don't satisfy anyone.

This guide is how to surface conflicts, structure the trade-off, and document the resolution.

The Sources of Conflict

Most conflicts have one of a few origins:

Different stakeholders' priorities. Each stakeholder weights different attributes differently.

Implicit assumptions clash. One requirement assumes A; another assumes the opposite.

Trade-offs not acknowledged. "Fast, cheap, reliable" — pick two. When all three are required, conflict is built in.

Inherited contradictions. Old requirements never removed; new requirements added without checking. The combination is incoherent.

Wishful thinking. Requirements that ignore physical or business reality.

Each has a different resolution approach. Diagnose before resolving.

Step 1: Surface the Conflict

Most conflicts are latent until someone tries to build the thing. Make them visible early.

Techniques:

• Cross-reading requirements. Look for pairs that constrain each other.

• Implementation thought experiment. "If I tried to build this, what would I do? Is that consistent with other requirements?"

• Stakeholder workshops. Get the differing perspectives in the same room.

• Edge case enumeration. Edge cases often reveal hidden conflicts.

Surfacing is half the work. A surfaced conflict can be resolved; a hidden one festers.

Step 2: Characterize the Conflict

Once visible, characterize it:

• What are the conflicting requirements? Specific text.

• What's the dimension of conflict? Cost vs. quality, security vs. usability, speed vs. completeness?

• Who cares about each side? Stakeholders.

• What's the impact if we choose each side?

The characterization makes the conflict discussable. Without it, the conversation slides into general values disagreements.

Step 3: Don't Force False Resolution

A common pattern: papering over with vague language.

"The system shall be both highly secure and very user-friendly."

This isn't a resolution. It's a wish. Both parties agree because the words sound right; the conflict resurfaces during implementation.

A real resolution makes the trade-off explicit. "We'll require 2FA for admin accounts but not standard users; we accept the security trade-off for usability of the broad user base."

Step 4: Use Trade-Off Frameworks

Several structures help with explicit trade-off:

Pugh matrix: options vs. criteria, weighted; structured comparison.

Decision matrix: options, criteria, weights, scores, totals.

ATAM (Architecture Tradeoff Analysis Method): identifies scenarios that exercise the trade-offs, evaluates how alternatives handle them.

Cost of delay: evaluates options on the cost of postponing benefit vs. accepting compromise.

The framework matters less than the discipline of explicit comparison.

Step 5: Escalate When Appropriate

Some conflicts can't be resolved at the working level. They need a decision-maker with authority over both sides.

When to escalate:

• Stakeholders can't agree

• The trade-off has business strategy implications

• The decision affects multiple teams beyond the original scope

• The conflict is symptomatic of a deeper organizational issue

Escalation isn't failure. It's recognizing that the decision rests at a different level.

Bad escalation: "We disagree. Decide for us." Doesn't give the decider information.

Good escalation: "We've identified that requirements X and Y conflict. Here's our analysis: option A means [trade-off], option B means [trade-off]. Our recommendation is A because [reason]. We need your decision because [stakes]."

Step 6: Document the Resolution

Once resolved, document:

• The conflict

• The options considered

• The decision

• The reasoning

• Who decided

Without documentation, the conflict re-emerges every time a new stakeholder joins or context shifts.

Often the resolution becomes an ADR (architecture decision record) or a similar artifact.

Common Conflicts and Patterns

Speed vs. quality: "Ship fast" conflicts with "ship well."

Resolution patterns:

• Define the quality bar explicitly (not "good," but specific properties)

• Time-box quality investment

• Accept honest "minimum viable" — not "minimum that passes."

Security vs. usability: "Highly secure" conflicts with "frictionless."

Resolution patterns:

• Tier the security based on risk (admin vs. standard user, high-risk action vs. low-risk)

• Make security defaults sensible but allow opt-in for more

• Distinguish "secure" from "secure-feeling"

Flexibility vs. consistency: "Customizable" conflicts with "predictable."

Resolution patterns:

• Define which dimensions are configurable, which aren't

• Provide presets that meet most needs

• Reserve customization for paid tiers or specific user types

Comprehensiveness vs. simplicity: "Has every feature" conflicts with "easy to use."

Resolution patterns:

• Tier the UI (basic by default, advanced on opt-in)

• Define the 80/20 path explicitly

• Move advanced features to expert workflows

The Sales Edge Case Pattern

A specific recurring conflict: sales agrees to a custom requirement for a specific customer; this conflicts with the product's default behavior.

Working approaches:

• Don't agree to product-level customizations during sales. Set scope upfront.

• Distinguish configuration from customization. What customers can set via config vs. what requires engineering work.

• Have a price for customization. When the customer wants something special, the cost reflects it.

• Decline gracefully. "We don't do that, but here's what we do" works better than yes-then-no.

The conflict surfaces post-sales; the resolution starts pre-sales.

When Conflicts Reveal Deeper Issues

Sometimes a conflict isn't really about the requirements. It's about:

• Misaligned org priorities

• Resource constraints not acknowledged

• Strategic ambiguity

• Power dynamics between stakeholders

When the conflict can't be resolved by tweaking requirements, the issue is upstream. Name it.

Iteration and Discovery

Some conflicts only become visible through implementation. The requirements seemed consistent until the team started building.

This is normal. Discovery-driven conflict is information.

Response:

• Don't blame anyone for the conflict not being predicted

• Surface and characterize as for any other conflict

• Adjust requirements based on learning

• Capture the lesson for future requirement gathering

A Worked Example

Initial requirements:

• "Users can sign up in under 30 seconds." (UX)

• "All accounts must verify email before activation." (Security)

• "Account is fully functional immediately upon signup." (Product)

These conflict. Verifying email takes longer than 30 seconds. Full functionality without verification undermines security.

Walking the resolution:

Conflict: signup speed vs. email verification vs. immediate functionality.

Dimensions: UX, security, business onboarding.

Options:

• A: skip verification (immediate functionality, fast signup, security risk)

• B: full verification before any access (slow signup)

• C: tiered access — basic features immediately, sensitive features after verification (compromise across all three)

• D: post-signup verification with limited functionality (similar to C)

Stakeholders agree on C: most features available immediately, sensitive actions (payment, email sending, API access) require verified email. The signup itself completes in 15 seconds; verification can complete later.

Resolution: requirements updated to reflect the tiered access. The conflict is documented as resolved with reasoning.

This is more productive than choosing "the system shall be both fast and secure" and discovering the conflict during implementation.

Key Takeaway

Conflicting requirements are normal. The mistake is pretending they don't exist or papering over them with vague language. Surface conflicts early; characterize them in terms of specific text, dimensions, stakeholders, and impact. Make trade-offs explicit; don't accept fudged resolutions. Escalate when stakeholders can't resolve at the working level. Document resolutions for future reference. Some conflicts reveal deeper organizational issues — name those. The discipline of explicit conflict resolution produces stronger requirements and better products.

Related reading

• Requirements Workshops That Don't Waste Time

• 'Requirements Traceability Matrix: A Practical Guide'

• The MoSCoW Method for Prioritizing Requirements

Keep learning. This article is part of the Requirements & Business Process Improvement path in the ShiftQuality Learning Center. Elicit, prioritize, and trace requirements that survive reality.