Handling Conflicting Requirements
Updated: 2 days ago
Requirements rarely conflict on paper. They conflict on a specific user, on a specific screen, on a specific day, and that is where you have to look for them.
A small invoicing product went into its signup redesign with three requirements, each from a different owner, each reviewed and signed off.
Product: "A new user can create an account and send their first invoice in one session."
Security: "All accounts must verify their email address before activation."
UX: "Signup takes under 30 seconds."
Nobody objected in review, because nothing on the page objected. In sprint four a developer wired up the verification email and asked the question the review hadn't: what does the user see between clicking "create account" and clicking the link in their inbox? Under the security requirement, nothing; the account isn't active. Under the product requirement, they should already be writing an invoice. And the 30-second clock was running out while the user switched to their email app. The team spent the next two sprints on rework and a week of meetings on whose requirement should give. (Composite example drawn from patterns across several teams; the product and numbers are illustrative.)
The conflict had been there since week one. It was invisible because each requirement was written about its own concern, and none of them described the same moment.
Why conflicts hide until someone builds
Read the three requirements separately and each is reasonable. Read them together and they still look compatible, because "verified", "one session" and "30 seconds" don't refer to a shared situation. They only collide when someone traces one user through all three in order, and on most teams the first person to do that is the developer, in sprint four.
The architecture community has a precise name for what happened. The Software Engineering Institute's Architecture Tradeoff Analysis Method (ATAM) defines a tradeoff point as a property that affects more than one quality attribute in opposite directions; its example is encryption strength, which raises security and costs processing time. ATAM's authors call tradeoff points the most critical decisions in an architecture, and the method finds them by writing concrete scenarios, not by reading requirements one at a time. In the signup case the tradeoff point was when verification happens. Move it earlier and security improves while time-to-first-invoice gets worse. Move it later and the reverse.
The mechanism is simple once named: a conflict only becomes visible when both requirements are measured on the same scenario. Adjectives like "secure", "fast" and "simple" coexist happily in a document. Numbers on a shared scenario don't.
The test you can run: open your current requirements and mark every quality requirement that has no number and no scenario attached (anything that says "fast", "secure", "intuitive" or "reliable" and stops). Each one is a conflict you can't see yet.
The shared-scenario pass
The discovery move that would have caught the signup conflict takes about an hour at requirements review, and it is the core of this article.
Write one concrete scenario per critical journey, in the user's terms: a freelancer signs up on their phone between client calls and wants to invoice a client before the next call.
Attach a number to every quality requirement that touches it: signup completes in under 30 seconds at the 95th percentile; first invoice sent within 10 minutes of starting; no outbound email from an unverified address.
Walk the scenario step by step and at each step ask which requirements apply and whether any design could satisfy all of them at once.
Record every collision in a conflict list: the two requirements, the step where they collide, and the decision that would settle it.
In the signup case, step three stalls at the moment the user taps "create account". Under the security requirement the next screen is "check your inbox"; under the product requirement it's the invoice editor. No design can show both, and that shows up on a whiteboard in week one instead of in a pull request in sprint four.
This is also where many apparent conflicts disappear. When you attach a number, it often turns out the two owners meant different scenarios: "fast" meant the signup form, "secure" meant payment. Those were never conflicts, only requirements written too vaguely to tell.
The test: count the collisions your pass finds per journey. Zero on a journey that crosses security, onboarding and payment usually means the numbers weren't attached, not that the requirements agree.
Diagnose the conflict before you resolve it
Conflicts that look the same in a meeting need different fixes. Five types cover almost all of them, and each has a test that tells you which you're facing.
Type | How to tell | What resolves it | Who decides |
Real trade-off | Both requirements are measurable on the same scenario and no design meets both numbers | Choose, tier or sequence (see the options below) | Whoever owns the outcome both sides serve |
Scenario mismatch | Ask each owner to name the scenario they meant; the scenarios differ | Rewrite both against named scenarios; the conflict goes away | The requirement owners, together |
Stale requirement | One side has no current owner, or its reason no longer applies | Retire or rewrite it, through traceability back to its source | The owner of the source document |
Commitment conflict | One side is written into a contract or a sales promise | A configuration boundary, a price for the exception, or a renegotiation | Product lead and sales lead, together |
Organisational conflict | Resolving it moves one team's budget or target | Escalate; it isn't a requirements problem | The person whose authority covers both teams |
Most teams treat every conflict as a real trade-off and go straight to a weighting matrix. Scenario mismatches are the commonest type in practice, and a matrix applied to them produces a confident answer to the wrong question.
The test: for each conflict on your list, write down its type and the evidence for it. If you can't name the evidence, run the scenario question with both owners before anyone scores options.
Walking the signup conflict to a decision
Back to the invoicing team, rerunning the decision as they should have the first time.
The type. A real trade-off: on the same scenario, "verified before activation" and "first invoice in one session" can't both hold as written. The tradeoff point is when verification happens.
The options, with the numbers each one would produce (illustrative):
Option | Signup time (p95) | First invoice possible | Risk accepted |
A. Verify before any access | 30 seconds, plus however long the inbox round-trip takes | After verification, often a different session | Lowest; highest drop-off between signup and first use |
B. No verification | Under 20 seconds | Immediately | Unverified addresses can send invoices, i.e. outbound email the product hasn't confirmed: a spam and fraud path |
C. Tiered: verify before sending to third parties | Under 20 seconds | Drafted immediately; sent after verification | Unverified users can explore and draft, but can't send |
D. Verify within 24 hours or lose access | Under 20 seconds | Immediately | Spam window of up to 24 hours per account |
The deciding question wasn't "which matters more, security or UX?" It was narrower and answerable: which action actually needs a verified address? The security requirement existed to stop the product sending email on behalf of an address nobody had confirmed. Creating an account and drafting an invoice send nothing. Sending the invoice does. That turns option C from a split-the-difference compromise into a precise boundary.
The rewritten requirements (each now testable against the scenario):
Account creation completes in under 30 seconds at the 95th percentile, with no email step.
A new user can create and preview an invoice without a verified address.
Any action that sends email to a third party, takes payment or issues an API key requires a verified address.
The verification prompt appears at the moment of the first such action, with the draft saved.
The decision record:
Conflict: email verification before activation vs first invoice in one session. Type: real trade-off; tradeoff point is when verification happens. Options: A–D above. Decision: C. Verification gates outbound actions, not account creation. Why: the risk the security requirement addresses comes from outbound email, not account creation. Decided by: head of product, with the security lead's sign-off. Revisit if: the share of drafted invoices never sent rises above the level agreed with product, or abuse appears from unverified accounts.
The last line is the one most decision records leave out. A trade-off is chosen under assumptions, and the record should say what evidence would reopen it, so the next stakeholder who disagrees can point to data instead of restarting the argument. Store it where architectural decisions live; the ADR template works for requirement decisions too.
The test: for your last resolved conflict, find the written record and its "revisit if" line. If there isn't one, the conflict will be reopened by the next person who joins.
The fudge test
The most common false resolution is a sentence that both sides can sign because it commits to nothing: "The system shall be highly secure and easy to use." Everyone agrees, the meeting ends, and the conflict moves into the code, where a developer settles it alone, usually without knowing that's what they're doing.
Sounding vague doesn't make a requirement fudged; you can only see it when people try to verify it. Give the "resolved" requirement to two people (one from each side of the conflict) and ask each to write the acceptance tests independently. If their tests disagree about what should happen on the scenario, the conflict hasn't been resolved; it has been deferred to whoever writes the code.
Run on the original three signup requirements, this exercise fails in about five minutes: the security author writes "unverified user cannot reach the dashboard" and the product author writes "user reaches the invoice editor without leaving the session". Run on the rewritten four, both people write the same tests.
The test: apply it to your most recent "resolved" conflict. Disagreeing tests mean it's still open.
Escalating without handing over the homework
Some conflicts can't be settled by the people who own the requirements. Commitment and organisational conflicts usually can't, and a real trade-off can't when the requirement owners have equal standing. The escalation then needs to reach the person whose authority covers both sides: the owner of the outcome both requirements serve, not simply the next manager up.
An escalation that says "we disagree, please decide" hands the decider the analysis as well as the decision. A useful one fits on a page: the two requirements as written, the scenario where they collide, the conflict type and its evidence, the options table with numbers, a recommendation and why, and the date by which a decision is needed and what slips if it's late. Escalations prepared that way tend to come back quickly, because the decider is choosing between laid-out consequences rather than reconstructing them.
The test: before escalating, name the person whose authority covers both sides. If you can't, that gap is the real finding, and it is worth raising on its own.
Choosing how to resolve a real trade-off
Option | Gains | Costs | Best suited for | Warning signs |
Choose one side | Clear, simple to build and test | The losing side's risk or cost is fully accepted | One requirement serves a clearly larger outcome | The losing owner wasn't in the decision |
Tier by risk or user type | Each user gets the side that matters for them | More states to build, test and explain | Risk is concentrated in specific actions or roles (the signup case) | Tiers multiply; nobody can list them all |
Sequence in time | Both met eventually; ship one side first | An interim period where one side is unmet | The deferred side's risk is low for a bounded period | The "later" has no date or trigger |
Make it configurable | Customers choose their own trade-off | Every configuration needs testing; defaults still decide for most users | Customer contexts really do differ (regulated vs not) | Configuration is used to avoid deciding the default |
Split the scope | Each requirement gets a product or tier where it fits | Two things to maintain | Two distinct customer segments with opposite needs | The split is one large customer's requirement |
Weighted scoring methods, such as a Pugh matrix or a decision matrix, help when there are several options and several criteria, but they only rank the options you bring. Make sure the scenario pass has produced the options and their numbers first. Scores applied to adjectives give a precise-looking answer to a vague question.
When to leave a conflict open
Not every conflict needs settling in discovery. A conflict over something cheap to change later, such as a default setting or a piece of copy, can be left open with a trigger: decide after the first two weeks of usage data. That's often better than deciding blind. The test is the cost of reversal: if changing the decision after launch costs a configuration change, defer it; if it costs a data migration or a contract change, settle it now.
And some conflicts are not about requirements at all. When the same pair of teams collides on every project, the requirements are where an organisational problem shows up, not where it can be fixed. Name it in the escalation, and stop expecting better requirement wording to solve it. The Five Whys for requirements discovery is a quick way to check whether a conflict's root cause is in the requirements or above them.
What to do this week
Pick your next feature that crosses two owners: security and onboarding, sales and product, compliance and speed. Before the requirements review, write the one scenario that goes through both owners' concerns, attach a number to every quality requirement on it, and walk it in the review. Record each collision with its type. Then run the fudge test on whatever the meeting decides.
Before the next build starts, the Requirements Readiness Checklist runs twenty checks on whether the requirements are ready to build from, and its first section is a gate.
Final takeaway
Conflicting requirements aren't a failure of the people who wrote them; they're what happens when several valid concerns meet one product. What fails is finding them late. Put the requirements on a shared scenario with numbers, and the conflicts show up in week one as specific collisions with a type, a decision owner and a record. Leave them as adjectives, and the first person to resolve them will be a developer in sprint four.
Sources
Kazman, R., Klein, M. and Clements, P., ATAM: Method for Architecture Evaluation, CMU/SEI-2000-TR-004, Software Engineering Institute (August 2000), section 7.2: "A tradeoff point is a property that affects more than one attribute and is a sensitivity point for more than one attribute"; tradeoff points are "the most critical decisions that one can make in an architecture". https://www.sei.cmu.edu/library/atam-method-for-architecture-evaluation/
ISO/IEC 25010:2023, Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model: nine product quality characteristics, including security, interaction capability and performance efficiency, the attributes most often traded against each other. https://www.iso.org/standard/78176.html
Related reading
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.
