risk = nil;

（…）様々な貢献型がある．”マイナス”の貢献をするものからプラスの大きな貢献をするものまで．プラスから順番に並べると次のようになる．実現する（MAKE,++），助けになる（HELP,+），不明(UNKNOWN,?），邪魔をする（HURT,-），阻害する（BREAK,–）．(NFR本 ¹，p. 63)

ここでは，代替手段の選択に関する評価を取りあげている．代替手段の利点は，そもそも何か．

• 副目的・機能・前提に関する代替となる組合せの中に，適切なものがあれば，目的を達成できる可能性がある
• システムコンポーネントとソフトウェア−環境の境界との間で，代替となる責任を割当できる可能性がある
• 代替となる解決策によって，要求文の間の衝突を解消できる可能性がある
• 代替となる対抗手段の組合せによって，リスクを減らすことができるかもしれない

KAOS的用語が使われているので，少し説明が必要かもしれない．

2番目は，KAOSにおいて，仕様ノードには，操作とエンティティが割り当てられることを思い出す（思い出すといっても，この議論は，第二部に入ってからである．まだ説明がない）．或いは，仕様は「誰か」が実行する必要がある．人が実行する場合もあるし，システム化の目的からは，システムの構成品である何かのコンポーネント（即ちソフトウェア）である．もし，ソフトウェアが受け持つ範囲が変化すれば（即ち，境界が変わるので），対応するコンポーネントが新たに必要になる，不要になる，或いは変更が必要になるということである．

もし，不要になれば，（例えば開発労力が減り）プロジェクト視点での要求を充足できるかもしれない．

上記は，当たり前のことのようにも思う．しかし，KAOSを初めとする要求分析手法のメリットは，体系的に実施することにある．体系立てることによって，間違いを減らす．思い込みに基づく争いを防ぐことが可能となる（これは，ひとつの信念かもしれない）．

 冒頭のように，これまで何度も登場している NFR本では，プラスやマイナスの記号を用いて，代替手段の貢献を示すことができる．以下は，単純な例である．

NFRにおける貢献度の図的記述法の例

この図の例では，正確さに対して，柔軟なユーザインターフェイスというソフトゴールは，マイナスである．即ち，目的達成の邪魔をしている．優先度の付加はプラスの効果である．正しいかの「確認」を行うことは，まさに正確さの実現ということになる（NFRの図式の説明は，いずれ行いたい．！は，重要なソフトゴールであることを示している）．

質的な代替手段の評価においては，KAOSでもこの方式を勧めている．

(nil)