risk = nil;

要求のカテゴリ

品質要求

品質要求は，ソフトウェアの機能によって生じる，付加的でかつ品質に関連する特性のことである．(p.24)

前回の図において，非機能ゴールからブレークダウンした左側に，その要素が示されている．安全性・セキュリティ・信頼性・性能・インターフェイスである．再掲する．

この分類は，納得しやすい．

ところで， SQuaRE (Systems and software Quality Requirements and Evaluation ) ¹で挙がっているのは，Lamsweerdeさんとは，異なる選択と並びになる．ちなみに，SQuaREは，ここではISO/IEC 25010:2011を指している．また，以前も触れている．

この中で，「システム／ソフトウェアの製品品質」として挙がっているのは，以下になる（日本語は，JIS X25010:2013 のもの）

• 性能効率性
• 互換性
• 使用性
• 信頼性
• セキュリティ
• 保守性
• 移植性

Lamsweerdeさんが最初に挙げていた安全性は，副特性を含めてここにはない．

もう一つのユーザ視点での「利用時の品質」は次の通り．

• 有効性
• 効率性
• 満足性
• リスク回避性
• 利用状況網羅性

安全性は，リスク回避性のなかの副特性の一つ「健康・安全リスク緩和性」の中に埋もれている．ふむ．セキュリティが，立派に特性として挙がっているのに，安全性は，副特性の一部でしかない．とても興味深い．構造上，類似している安全性とセキュリティの間で，ここまで違いがある理由のはなぜだろう．

訓詁学的に比較・検査するのはおもしろいが，今は余り有益でもなく，先に進む．

図に挙がっている品質要求のそれぞれについて，例が挙がっている．

安全要求

列車の加速制御において，後続列車との最悪ケースでの停止時の距離は，常に維持されること．

隠匿性要求（Confidentiality requirements）

スタッフではないユーザは，自己以外のユーザが何の本を借りているかを，知ることができないこと．

以下，全ての例が挙げられているが，残りは原書を参照いただければと思う．

品質特性というのは，網羅的なものではなく，その時点で重点を置くアスペクトを示しているに過ぎない．大事なのは，どの品質特性を重視するかと云うことをあらかじめ示しておくことかと思う．

（nil）