In almost every project all requirements are important at the start. The MoSCoW method forces them into four classes and thus lays the basis for a realistic first scope.
The four classes
Must have: without this requirement the solution cannot be used, for example because of a legal duty or a core process. Should have: important, but a workaround exists if it is missing. Could have: desirable if time and budget allow. Won’t have this time: deliberately excluded, not forgotten; this class stops requirements quietly reappearing.
Against inflated must-haves
The most common weakness is that everything becomes a must. A rule of thumb that must-haves may only take up part of the available effort, leaving room for the unexpected, works well. Another useful question: would we go live without this requirement? If yes, it is not a must.
Use in projects
MoSCoW suits defining an MVP, planning releases and negotiating under budget or schedule pressure. Classification is agreed with stakeholders, ideally based on the stakeholder analysis, and linked to the acceptance criteria of the must-haves. In requirements engineering following IREB, prioritisation is part of requirements management.