すべての要件は重要ですが、最大かつ即時のビジネス上の利益を早期に実現するために優先順位が付けられます。 開発者は最初、Must have、Should have、Could have のすべての要件を提供しようとしますが、Should および Could の要件は、提供期間が危うくなった場合、最初に削除されます。
優先順位付けカテゴリのわかりやすい意味は、高、中、低のような代替案と比較して、優先順位を設定することの影響を顧客によく理解してもらう上で価値があります。
カテゴリは通常次のように理解されます。 1 つでも Must have の要件が含まれていない場合、プロジェクト デリバリーは失敗と見なされます (注: 新しい要件がより重要であると考えられる場合など、関連するすべての利害関係者との合意により、要件を Must have から格下げすることができます)。 MUSTは、Minimum Usable Subsetの頭文字をとったものとも考えられます。 Should have Should haveと表示された要件は、重要ではあるが、現在の納期に間に合わせるためには必要ではない。 Should haveの要件はMust haveと同様に重要な場合がありますが、多くの場合、タイムクリティカルではないか、または要件を満たす別の方法があるかもしれないので、将来の配信タイムボックスまで保留にすることができます。 可能性がある（Could have） 「可能性がある（Could have）」と表示された要件は、望ましいが必要ではなく、わずかな開発コストでユーザーエクスペリエンスや顧客満足度を向上させることができる。 これらは通常、時間とリソースが許せば含まれます。 Won’t have (for this time) Won’t haveとラベル付けされた要件は、利害関係者によって、最も重要度が低く、最も費用対効果の低い項目として合意されたか、またはその時点では適切ではない。 その結果、Won’t haveの要件は、次の配信タイムボックスのスケジュールに計画されません。 Won’t haveの要件は、削除されるか、後のタイムボックスに含めるために再検討されます。 注：時折、Would like to haveという言葉が使われることがありますが、この最後の優先順位は、何かが納入範囲外であることを明確に示しているので、その使い方は正しくありません）。 (BCS は Business Analysis Book の第 3 版 & 4 で、「W」を「Want to have but not this time around」と表現しています)
VariantsEdit
Wish (または Would)、つまり、まだ可能性はあるが含まれる可能性は低い (Could より可能性が低い)、という意味で W が使用されることがあります。 これは、明確に含まれていない項目を表す X for Excluded と区別されます。