R — RequirementMandatory need arising from customer, contract, law, safety, regulation or technical necessity. The source should be identifiable.
C — ConstraintA genuine boundary within which the solution must operate, such as time, budget, interface or physical limitation.
E — EvidenceVerified information that informs the decision, such as test data, customer evidence, capability data or prior learning.
P — PreferenceA desired feature or approach that may be useful but is not mandatory. Preferences should not silently become requirements.
A — AssumptionSomething believed to be true but not yet evidenced. Assumptions should be validated before being allowed to reshape the solution.
Key challengeWhenever a stakeholder asks for a change, ask: R, C, E, P or A? Then ask what evidence demonstrates benefit to the whole.