Five Requirements That Cannot All Be True

Do not pick a winner unilaterally, and do not average the two. Conflict between requirements is usually a sign that an underlying business rule hasn't been decided.

Method:

1. Trace each requirement to its business need or goal. If "self-schedule any open slot" traces to a patient-satisfaction objective and "clinician approval" traces to clinical-safety or regulatory policy, they are not equal - the safety rule likely constrains the convenience rule.
2. Identify the real decision owner. This is a policy decision about patient intake, so the sponsor (or clinical governance) decides, not the BA and not the loudest stakeholder.
3. Frame the decision as options with consequences: full self-scheduling with a rule-based exception list, approval only for new patients, approval by exception, etc. - each with effect on schedule, interface design, and the fixed-scope contract.
4. Document the decision, the rationale, and the rejected alternatives in the requirements repository.
5. Re-run traceability and test coverage on whichever version is chosen.

Why this order: Requirements conflicts that get resolved by whoever is in the room become change requests later, during build, at the highest cost.

Risk: An unlinked requirement is an unverifiable requirement. No one can demonstrate it was built, so:

• It may be silently omitted, or built to an interpretation no one agreed to.
• Acceptance becomes opinion-based at UAT - the most expensive moment to discover a gap.
• Coverage cannot be reported, so "90% complete" may exclude exactly the requirements with the most ambiguity.

Verification vs. validation:

• Verification asks "did we build it right?" - is the product consistent with the documented requirement and its acceptance criteria? This needs a test case per requirement, or an explicit, justified exception (e.g., a requirement satisfied by a vendor product out of the box, evidenced by vendor test results).
• Validation asks "did we build the right thing?" - does it meet the actual business need? The schedulers' undocumented workarounds are a validation red flag: if the real workflow differs from the documented one, passing all 47 verification tests still delivers a system people route around.

Action: Write acceptance criteria and link test cases for all 12 before build starts; and spend time observing actual scheduling work to reconcile the documented process with the workarounds. Requirements that describe a process nobody follows should be challenged, not tested.

Assess what evidence actually exists before arguing.

• Minutes recording a verbal agreement are not approval. They evidence that a discussion happened and what was said; they do not evidence stakeholder sign-off. Daniel should not treat them as a signed baseline.
• Check whether the requirement is in the approved requirements baseline and whether it appears among the vendor's 40 contracted requirements. This determines whether it is in scope at all.

Then separate two questions:

1. Is it needed? If it is a regulatory/audit obligation, the answer is likely yes regardless of sign-off history - the compliance officer's concern is substantive, not procedural. Confirm the actual regulatory driver in writing.
2. Who pays for it? If it is outside the 40 contracted requirements, adding it is a scope change against a fixed-price contract and requires a formal change request with cost and schedule impact, negotiated with the vendor.

Process: Log the issue, document the evidence trail, escalate the scope decision to the sponsor, and record the outcome. Do not quietly build it (unfunded scope) or quietly drop it (compliance exposure).

Process lesson: Requirements need recorded approval, not just consensus in a meeting - verbal agreement decays exactly like this.