How to prepare a system requirements table with the MoSCoW method
WHAT IS THE MOSCOW METHOD (MoSCoW Prioritization)? The MoSCoW method is a technique that helps categorize and prioritize all requirements that define a “future state”, that should be implemented. The method was developed by Dai Clegg in 1994, and dedicated to supporting software development projects (where the “future state” is the shape of an application that should be implemented). Despite the origin, the method is not only limited to software projects, and can include requirements necessary when implementing changes to physical products (cars, buildings, furniture) or organizational changes (eg. changes to the bonus systems, changes to the partnership agreement, etc.). Although this is a generic method, it is mainly used when implementing software systems and helps companies define the requested configuration of a future application that is planned to be implemented. The MoSCoW name explained The MoSCoW term is an acronym inherited from the statuses used in this method to prioritize requirements: Must have, Should have, Could have and Won’t have. Priorities used in the MoSCoW methodology The priorities used in the MoSCoW method sound self-descriptive, but in practice, they need some additional explanation to use them properly and in a consistent way: Must Have (MUST) – This is the most obvious priority that represents the critical requirements that must be delivered from day one. The software without these requirements simply can’t be used properly and the project goals will not be achieved without them. Should Have (SHOULD) – This priority represents the requirements that are almost as important as “Must haves”, but users can live without them. Although it sounds similar to “Could have”, they are closer to “Must haves”. The difference is, that while “Must haves” have to be implemented from day one (software can’t exist without it), software users can live without “Should haves” for some time. The “Should haves” have to be ultimately implemented, but the company can live without it and still benefit from the 1st version of the software solution; these missing requirements will not cause critical security problems or will not bring a lot of additional work – if that happens, it means that they should be classified as “Must haves”. The “Should have” priority is often used to divide a complex project scope into phases, where only “Must haves” are implemented in the current phase, and “Should haves” are planned for the next phases. Sometimes, companies use “Should have” to address the “readiness” for future requirements or improvements (e.g. currently the software is not implemented in the cloud, but it must use the technology that is ready for future cloud deployment). Could Have (COULD) – This is used to address all the “nice to have” features, that will have a positive impact on the final solution (and then on users’ satisfaction/efficiency), but are not necessary and might never be implemented. Their business value is smaller than “Should haves”. These requirements are useful when comparing software from various software vendors – assuming, that all “Must have” and “Should have” requirements must be identically fulfilled by all short-listed applications, “Could haves” help […]
learn more
