Any condition found which poses the possibility of causing injury or harm to, or otherwise endangering the business process of the end user of the product.

Must have requirements are critical to project success and have to be included in the current delivery in order for it to be a success. Unfortunately, if a Must have requirement is not included, the project delivery may be considered a failure. Please note however that a MUST have requirement can be downgraded if agreed with all relevant stakeholders.

Any condition found adversely affecting the product’s marketability and sale-ability or adversely affecting its required form, fit or function and which is likely to result in the end user returning it to the source from which is was purchased for replacement or refund.

Should have requirements are important to project success, but not necessary for delivery in the delivery time box. Should have requirements are often not as time-critical as Must haves. Should Have requirements may also allow for another way of satisfying the requirement, so can be held back until a future delivery time-box.

Any condition found which while possibly less than desirable to the end user of the product, does not adversely affect its required marketability, sale-ability, form, fit or function and is unlikely to result in its return to the source from which it was purchased.

Could have requirements are less critical and maybe often seen as nice to have. A few easily satisfied Could requirements in a delivery can increase customer satisfaction for little development cost.

Won't have but would like requirements are either the least-critical, lowest payback items, or perhaps not appropriate at that time. Won't have requirements are not always planned into the schedule for the delivery time-box. This can sometimes be described as Would have and leaves the option open to add these requirements to the scope and delivery if the scope, budget or time changes.