要求の優先度が役立つ場面には次がある．
- 利害関係者が望む全ての特性を開発するには，用意した予算・人員・納期では，制約があるとき
- （例えば，スパイラル型の開発において）次のサイクルやリリースを計画する，或いは不測の事態（開発の遅れ・予算の制限・人員不足・納期短縮の圧力）のために再計画を行うとき．
- 優先度の低い要求を後回しにする，或いはあきらめることによって，衝突回避が可能になるとき
優先度があることは意義深いことだとして，どうしたら効果的に優先度を付加することができるか．以下が条件としている．
- レベル分けされていた方が良い．レベル内では，各要求は同一の優先度を持つ．容易に優先度付けできるように，レベルを示す数値は，小さい方が良い
- レベルは，量的というよりは質的な区分の方が良い．また，絶対的レベルというよりは，相対的なレベル分けが良い（例：「高い」ではなく，「〜より高い」）
- 要求は，比較可能であること．そのためには，粒度や抽象度が同じくらいであること．
- 比較される要求は，他から独立であること．少なくとも，相互に依存していないこと．相互依存があると，ある要求をあきらめたときに，残るべき要求も成立しなくなる
- 優先度レベルによる要求のクラス分けは，同意のために利害関係者同士で調整済みである必要がある
前回の寄与度と同様に，優先度を如何に体系立てて付加するかが，ここでの議論である．対象が単純であれば，えいやっと優先度をつけて，合意をとるのも容易かもしれない．しかし，レベル分けが必要なほど複雑になってくると，合意をとるのはなかなか難しくなる．
一般的な合意形成の手法として有名なAHPを，次回扱う．上記のうち，a-dは，ヴァリエーションが多くあるAHP（Analytic Hierarchy Process）のうち，最も基本的なAHPの条件でもある．
ソフトウエアを作る側は，常に合理性を求められるが，要求者はどうか．共に，体系立てて合理的に考えることは，（特に二者間取引においては）重要である．
（nil）