非機能要求を決める難しさの一つは漏れをなくすことだ。

 システムの停止や応答時間といった非機能要求項目は、業務利用時間に直接影響したり直感的に利用時を想像しやすいために比較的定義しやすい。とはいえ、細かく見れば漏れも多く、システム完成後に多くのトラブルを引き起しやすいのも事実だ。

 例えば、ピーク時や縮退運転時の性能が足りなかったり、システム利用者の8割しか目標のレスポンスが得られなかったりするトラブルだ。性能不足を解消するためにスケールアウトしようにも、基盤から作り直さなければならないようなトラブルもあるだろう。

 これらのトラブルを防ぐためにも非機能要求を漏らさずにきちんと決めておかなければならない。特に、移行時や運用時の準備に関する非機能要求は、要求定義時に「まだ先のことだから」と考慮の優先度を落とし、結局決めずにそのまま要求から漏らしてしまいがちだ。

項目一覧で漏れをなくす

 「漏れ」を防ぐためには、あらかじめ体系化された要求のチェックリストがあるとよい。

 検討会はシステム基盤の構築に欠かせない非機能要求項目を245項目とし、大きく六つに分類している(図6)。具体的には可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、環境・エコロジーである。前述の利用ガイドのモデルシステムとグレード表はこの分類に基づいて、一部の非機能要求項目の設定例を記述している。

図6●検討会が導き出した決めるべき非機能要求項目
図6●検討会が導き出した決めるべき非機能要求項目
六つの大項目と35個の中項目を示した。最小単位である確認項目(小項目)は245個ある

 245項目すべてを記載しているのが項目一覧と樹系図だ。どちらを利用しても良いが両方ともチェックリストの役割を果たす。例えば開発契約に至る前に最終確認で利用できるだろう。

 また樹系図は245項目をどの順番で決めていくか悩んだときの助けになる。樹系図は245項目の全体を俯瞰できる図だが、その並び方は検討会が勧める検討順に整理してあるからだ(図7)。

図7●樹系図は非機能要求項目の検討順序を示す
図7●樹系図は非機能要求項目の検討順序を示す
六つの大項目のうち、可用性を例に示した

 例えば、可用性を検討する場合は、まずシステムの稼働条件を決定する運用スケジュールや業務継続性などを検討する。その後にシステム構成要素の障害対策方針や、システムの信頼性品質といった項目を順に検討する。

 樹系図があることで、グレード表で定義した重要項目の値を基に詳細項目を決めるときに、順序の前後関係の調整が必要かを確認できる。

 検討会は6社のノウハウを終結して245項目を整理したが、裏を返せばシステム基盤を構築するのはそれほどの非機能要求項目が必要だということだ。ただし、245項目を「漏らさずに」決めるということは245項目すべてに値を設定することではない。

 大事なことは「検討していない項目」をなくすことだ。「項目があることは知っている。だが今回はシステムに求める信頼性が低いため、この項目は定義しない」などと、「決めないことを決めること」が必要になる。

 以上、「非機能要求グレード」の四つのツールと使い方を紹介した。

 このツールは検討会に参加する6社がノウハウとして蓄積してきた品質管理項目や要求定義チェックリストなどを公開しあってまとめたものである。同時に 2008年末に経済産業省が主催する非機能要求グレード「ユーザビュー検討委員会」にて、委員の発注側企業7社から300件以上の意見と提案をいただき、それを踏まえて改善している。

 ツールは無償なので、ぜひ検討会の公式Webサイトからダウンロードして試してほしい。


山下 武志
NTTデータ
技術開発本部 ソフトウェア工学推進センタ