rm-analysis

Evaluate each requirement against IEEE 830 criteria: completeness, consistency, unambiguity, verifiability, feasibility, and traceability. Requirements failing verifiability or lacking a stakeholder owner should be returned to elicitation or flagged for removal.

Classify each requirement as Must Have, Should Have, Could Have, or Won't Have based on explicit assignment criteria. Must Have should stay under 60% of total requirements; if everything is Must Have, rerun prioritization with stricter criteria like budget-cut or survival tests.

MoSCoW categorizes requirements by necessity for the release, while Kano classifies them by impact on user satisfaction (must-be, performance, delighters, indifferent, reverse). Kano complements MoSCoW when user-perceived value is uncertain.

Return to elicitation when functional gaps are found, key stakeholders did not participate, Must Have requirements lack an owner, or more than 30% of requirements fail verifiability. Document the specific gaps so re-elicitation is focused.

Conflicts are classified as priority, scope, technical, or business conflicts. Priority conflicts use joint MoSCoW workshops, technical conflicts need engineering review, and business conflicts escalate to the sponsor for a documented decision.