システムに求める性能や信頼性、保守運用のしやすさといった非機能要件を要求定義書にどう記述すべきかや、記述内容が達成できたかを評価する手法をまとめた。こうした試みは日本初。「世界でも類がないだろう」とJUASの細川泰秀専務理事はみる。

 ユーザー企業やITベンダーに広く利用を呼びかける。システムの高度化・大規模化に伴って非機能要件の重要性が改めて注目されているが、業界標準と言える記述・評価方法はこれまでなかった。

 完成したシステムの信頼性を測定するために、「稼動品質率」という指標を導入した。システムの利用者に“迷惑”をかけた回数、もしくはシステム停止が業務停止につながった回数を、システムの資産規模で割って算出する。資産規模には総ステップ数や運用費用などを使う。「この値がゼロに近づくようシステム部門は障害拡大防止策を講じていくべき」と細川専務理事は説く。

 システムの信頼性を測る指標には、これまでシステムの稼働時間を示す「稼働率」を使うのが一般的だった。JUASの調査ではユーザー企業の基幹システムの平均稼働率は99.3%(年間で2日半のダウン)だった。

 だが、「停止時間を単純に示す稼働率は、システム部門の正当な評価につながらない」と細川専務理事は指摘する。「稼働率にはダウンが業務に及ぼした影響が反映されない」というのがその理由である。

 稼動品質率を含めて9分類195項目の記述・評価手法をまとめた()。ソフトウエア品質特性についての国際規格「ISO9126」を、企業システムでの利用を前提に整理・追記した。

図●JUASは非機能要件の記述と評価手法をまとめた
図●JUASは非機能要件の記述と評価手法をまとめた

 レスポンスタイム(応答時間)を記述するときは、「明細照会画面から1秒間にN個のデータを入力したときに、X秒で結果を表示する確立がZ%」とする。これまで一般的だった「明細照会画面が表示されるのがX秒」といった記述に比べると、性能目標や必要なシステム構成がより明確になる。

 非機能要件の評価手法は、開発工程ごとに決めた。ユーザーから要求を提示したとき、ベンダーと要件を合意したとき、設計書に記述したとき、単体/結合/総合テストが完了したとき、運用段階などだ。レスポンスタイムの例では、要求仕様を出す段階では業務の必要性と投資対効果を満たすか、要件定義の段階では想定するシステム構成で達成できるか、などから目標値を評価する。ユーザーとベンダーで理解がずれないよう「レスポンスタイムとは何か」も定義した。

 195項目すべてを記述/評価すると、「開発と運用のコストが上がるのは確か」(細川専務理事)。JUASは重要システムからの適用を勧める。

 まずは各分類で1項目ずつ、記述と評価の手法を詳細に決めた。JUASは今年度以降、残りの項目も詳細を詰める方針だ。