オブジェクトの広場はオージス総研グループのエンジニアによる技術発表サイトです

技術講座

非機能要求とISO9126

非機能要求抽出のための Tips とパターン
正木威寛 PMP
2006年3月9日

本稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。

※本稿は、技術評論社刊『JAVA PRESS Vol.40』に掲載された記事「機能外要求と ISO9126」を加筆、修正したものです。JAVA PRESS 編集部の了承を得た上で転載しています。

※一切の転載をお断りします。


はじめに

私達がソフトウェアを開発するためには、ソフトウェアに対する要求 (ソフトウェア要求) が必要です。 ソフトウェア要求がなければ、そのソフトウェアには本当は必要のない機能を作ってしまったり、必要な機能を作っていなかったりするでしょうし、何よりもソフトウェアが完成したのかさえ評価できません。 そのためにも、私達ソフトウェアを開発する者は、ソフトウェア要求とは何なのかを正しく理解しておかなければなりません。 本稿では、ソフトウェア要求とは何なのかを理解し、非機能要求に焦点を当て、ISO9126、要求定義プロセス、事例と解説していきます。

1. 要求とは?

1.1 要求って何?

国際規格 (ISO2382-20) および日本工業規格 (JISX0020) では、

「要求とは、システムが満たさなければならない必須条件」

と定義しています。また米国国家規格 (IEEE610) では、

「要求とは、ユーザの問題解決や目的達成のために必要とされる能力」

と定義しています。両方ともシステム開発におけるシステム要求の定義ですが、ソフトウェア開発においても ”システム” を ”ソフトウェア” に置き換えることで、ソフトウェア要求が何か理解できると思います。

1.2 視点の異なる要求

ソフトウェア開発を始める場面で、要求はプロジェクトスポンサやユーザなど利害関係者から収集して定義されます。 けれども時として、とても抽象的であやふやな要求だと感じることがあります。 これは、その要求がソフトウェア要求ではなく、視点の異なる要求であるためです。 ここでは、まずソフトウェア開発にまつわる要求には、どのような視点のものがあるのかを理解していきたいと思います。

業務要求とシステム要求

図 1 では、 ISO15271 で示されている組織におけるコンピュータシステムの位置づけをもとに、ソフトウェア開発を始める場面で、どのような要求が存在するかを図示しています。

  1. ① 組織への要求
  2. ② ビジネスへの要求
  3. ③ ビジネスプロセスへの要求
  4. ④ システムへの要求

①は市場や他組織からプロジェクトスポンサやユーザの所属する組織への要求、②は組織が提供しているビジネスへの要求、③はそのビジネスプロセスへの要求で、これらをまとめて業務要求や業務要件と呼んだり、システム要求やソフトウェア要求に対してユーザニーズと呼んだりします。 これらの要求は、売り上げが××パーセント向上しなければならないなど、開発者がソフトウェア要求として理解しようとすると、とてもあやふやな要求に思えます。 これは、これらの要求が業務上の目標や問題などであり、その要求の実現 (目標の達成や問題の解決策) が、必ずしもソフトウェアを導入することではなく、直接的にソフトウェアがどうあるべきかを要求するものではないからです。

①組織への要求の実現方法によって、②ビジネスへの要求が生まれ、その実現方法によって、③ビジネスプロセスへの要求が生まれ、その実現方法にコンピュータシステムが係わることによって、④システムへの要求が生まれるという関係になります。 ですが、④システム要求がソフトウェア要求かというとそうではありません。

システム要求とソフトウェア要求

図 2 では、 ISO15271 で示されているシステムにおけるソフトウェアの位置づけをもとに、システム要求がどのようなシステム構成要素への要求へ展開されるかを図示しています。 システム全体に対するシステム要求の実現方法として構成されるシステムは、ソフトウェアの実行環境であるハードウェア、ユーザの手作業、硬化の選別機などの設備で構成されます。 このシステム要求の実現方法によって、ソフトウェアへ要求されることがソフトウェア要求です。

2. 非機能要求

ここまでで、ソフトウェア要求とそれ以外の要求がどのような関係になっているか、ご理解いただけたかと思います。 ここからはソフトウェア要求の中でも、やっかいな存在である非機能要求について理解していきたいと思います。

2.1 機能要求と非機能要求

ソフトウェア要求は、おおざっぱには機能要求 (Functional requirement) と非機能要求 (Nonfunctional requirement) に分けられます。

機能要求とは、ユーザがソフトウェアにどのような機能を必要としているかを表す要求です。 非機能要求は、機能外要求と呼ばれることもあり、ソフトウェアの提供する機能が達成すべき性能や制限を表す要求です。 たとえば、インターネットバンキングで「預金者が送金できること」は機能要求、「Web ブラウザで送金ボタンを押して10 秒以内に送金処理を終えること」や、「本人以外が勝手に預金者の口座を使って送金できないこと」は非機能要求です。

実際のソフトウェア開発の現場では、機能要求と比較して非機能要求は識別しにくいということをよく耳にします。 その反面、ほとんどの非機能要求はソフトウェアアーキテクチャに影響します。 ソフトウェアアーキテクチャは、アプリケーションの設計全体に影響し、ソフトウェアアーキテクチャ設計にはエンジニアの高い技術力が求められます。 このことから、非機能要求の定義に漏れや誤りがあると、ソフトウェアアーキテクチャへの追加や変更に大きなコストや時間がかかることになります。 そのような事態を避けるためにも、非機能要求を網羅的に確認し、プロジェクトが見逃してしまった暗黙の要求としてしまわないことが重要です。

2.2 非機能要求の定義に国際規格 ISO9126 を使おう

ISO9126 は、ソフトウェアの品質を表す特性を定めた国際規格です。 品質を表す特性を品質特性と呼び、6 つの品質特性に分類され、品質特性はさらに 27 の副特性に分類されています(図 3 )。 ISO9126 は作成されたソフトウェアの品質を評価する目的だけでなく、作成前にソフトウェアの機能要求や非機能要求を定義するのにも使えます (ISO9126-1 の序文にも記されています)。 この ISO9126 の分類を使って、ソフトウェアに要求されている非機能要求がないか照らし合わせていくと、漠然と探し当てるよりも格段に楽に非機能要求を網羅的に確認できる便利なものです。

図 3 ISO9126 ソフトウェアの品質
図 3 ISO9126 ソフトウェアの品質

注)今回紹介するのは、ISO9126 の外部品質に対する要求で、コンポーネントやクラスなどソフトウェア内部に対しても同様の分類で、内部品質として利用可能です。

Tips 1) 非機能要求がどこの分類に属するか悩まない

これから紹介する ISO9126 の品質特性や品質副特性は、「非機能要求を見つけるため」に使ってください。 非機能要求の中には、いくつかの品質副特性に属してもおかしくないものがありますので、見つけた非機能要求が、「果たしてこの品質副特性で良いのだろうか?」「あっちの品質副特性のほうが適当では?」と悩まないようにしてください。

品質特性:機能性

機能性 (Functionality) は、指定された条件下で、ソフトウェアがユーザニーズを満たすために提供する能力を表します。

品質副特性:適切性

適切性 (Suitability) は、ソフトウェアがユーザの目的に合致している機能を提供するかを表します。

例 1) 預金者が過去1年間の取引内容を照会できること。

Tips 2) 適切性は操作のしやすさとして定義されることがある

操作がしにくいために、ユーザがその機能に期待する目的を達成できない、適切な機能ではないと感じることがあります。 このことから適切性ではなく、操作のしやすさとして非機能要求が定義されることもあります。 たとえば「顧客が商品一覧の照会から注文できること」は「顧客が注文できること」の説明として記述されることもあれば、操作のしやすさとして定義されることもあります。

品質副特性:正確さ

正確さ (Accuracy) は、ソフトウェアが必要な正確さで結果をもたらす能力を表します。 画面や帳票でユーザに提供する計算結果が正しいだけでなく、必要とされる精度で計算されているかも含まれます。

例 2) 取引金額の計算は、1 円未満切り捨てで計算すること。

もしあなたの作った販売管理のソフトウェアが、金額を 100 円未満切り捨てて計算したら、いくら正しい計算式で結果を出していても、使いものにならないといったことになります。

品質副特性:相互運用性

相互運用性 (Interoperability) は、相互接続性や、そのままインターオペラビリティと呼ばれることもあり、ソフトウェアが指定された他のシステムとやりとりをできる能力を表します。 非機能要求としては、データ転送や処理の依頼など他システムとの必要なやりとりが示されます。 相互接続では、Web サービスなど取り決められた通信プロトコルで直接やりとりをするのから、DAT などのメディアを介してやりとりするのまで考えられますが、要求の実現方法が選択できる場合は要求では指定しません。

例 3) 外部の決済システムと Web サービスを介して、必要な決済ができること。

Tips 3) 既存システムとの相互運用性は、やりとりの方法が指定されることが多い

既存システムとの相互運用性は、新しくやりとりの方法が相手側に実装されることが少なく、非機能要求に既存の接続方法が指定されます。 たとえば 例 3 の場合は、Session Bean ではなく Web サービスでやりとりすることを指定されています。 この場合、詳細な接続仕様も相手側から提供されますので、接続仕様の存在もあわせて確認してください。

品質副特性:セキュリティ

セキュリティ (Security) は、ソフトウェアが関係のない人に使用されたり、機能を実行する権限のない人に実行されたりしない能力を表します。 非機能要求としては、必要なセキュリティポリシーやセキュリティ強度が示されます。 インターネットを使ったシステムが多くなり、最近は特に要求が厳しくなっています。

例 4) 預金者本人以外が、口座の情報や取引履歴を参照できないこと。

Tips 4) 保管する情報のセキュリティも検討する

ユーザ認証など機能を実行できる権限だけでなく、例 5 のように保管する情報に対しても非機能要求があることがあります。

例 5) 運用担当者が、DB に保管されている情報を参照して預金者を識別できないこと。

Tips 5) セキュリティは使用性に影響することがある

ユーザ認証のために長いパスワードを覚える必要があったり、いろいろと操作が必要なソフトウェアは、ユーザにとっては理解しにくかったり、操作がしにくいと感じることがあります。 このことからセキュリティ要求は、使用性を考慮して定義しなければいけません。

品質副特性:機能性関連適法性

機能性関連適法性 (Functionality compliance) は、機能性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。

Tips 6) 機能性には法律や業界標準がよくある

税の計算式や精度、業界のガイドラインなど、求められる機能性に関する適法性はよくあります。 特にセキュリティに関する適法性は、ソフトウェアだけでなく、システム全体として策定された業界標準が多くあります。

例 6) JIS Q15001「個人情報保護に関するコンプライアンスプログラムの要求事項」を満たすこと。
例 7) (社)全国学習塾協会「学習塾における電子計算機処理に係る個人情報の保護に関するガイドライン」に従っていること。
例 8) (社)日本ダイレクトメール協会「DM に関する個人情報保護ガイドライン」に従っていること。
例 9) (社)日本通信販売協会「通信販売における個人情報保護ガイドライン」に従っていること。
例 10) 日本証券業協会「インターネット取引において留意すべき事項について(ガイドライン)」に従っていること。
例 11) ISACA 情報システムコントロール協会「IS Auditing Guideline: Internet Banking」を満たすこと。

品質特性:信頼性

信頼性 (Reliability) は、指定される条件下でソフトウェアがパフォーマンスレベルを維持する能力を表します。 パフォーマンスレベルというのは、機能性で規定された機能に対する、効率性で規定されたレベルを指しています。 ソフトウェアが決められた時間に機能を提供できるかを表す特性として、可用性 (Availability) というのも使われることがありますが、 ISO9126 では可用性は信頼性の副特性の組み合わせで表されることから独立した副特性にしていません。

Tips 7) 信頼性がソフトウェアに要求されるケースは限られている

信頼性は、EJB コンテナや DBMS などのように、システムの信頼性をソフトウェアで向上する機能があるケース以外では、ハードウェアやその構成などシステムアーキテクチャのその他の要素で実現するほうが多いです。

品質副特性:成熟度

成熟度 (Maturity) は、障害が発生した時にソフトウェアが故障 (機能停止) しない能力を表します。 非機能要求では、単位として MTBF (平均故障間隔) が多く用いられます。 MTBF は、故障から次の故障までの時間を表します。

例 12) MTBF は、8000 時間以上であること。

品質副特性:フォールトトレランス

フォールトトレランス (Fault tolerance) は、障害が起きてもソフトウェアが機能を提供し続ける能力を表します。 フェールセーフ機能も含まれます。

例 13) 各コンポーネントは多重化され、いずれかのコンポーネントに障害が起きてもサービスを 24 時間提供できること。

品質副特性:復元力

復元力 (Recoverability) は、障害が発生した後にソフトウェアの機能が正常に復帰する能力を表します。 非機能要求では、MTTR (平均復旧時間) が多く用いられます。 MTTR は、1 回の修理にかかる平均時間です。

例 14) DB との接続エラーが発生した場合、再接続し 10 分以内に復帰すること。

品質副特性:信頼性関連適法性

信頼性関連適法性 (Reliability compliance) は、信頼性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 信頼性に関する適法性は、ソフトウェアだけでなく、システム全体としてセキュリティもあわせて策定された業界標準が多くあります。 例は、「品質副特性:セキュリティ」の例を参照してください。

品質特性:使用性

使用性 (Usability) は、ソフトウェアがユーザにとって使いやすいかを表します。 ユーザには、運用担当者も含まれます。

Tips 8) 使用性にはプログラム以外への要求が含まれる

使用性の要求には、理解を助ける操作マニュアルやオンラインヘルプなどソフトウェア一式 (ソフトウェア製品) として提供すべきものへの要求も含まれます。

品質副特性:理解のしやすさ

理解のしやすさ (Understandability) は、ソフトウェアの使用法をユーザが理解しやすいかを表します。

例 15) パソコンやインターネットの初心者である預金者が理解できること。
例 16) 社内標準ソフトである経費管理システムと同じ操作性であること。

品質副特性:学習のしやすさ

学習のしやすさ (Learnability) は、ユーザがソフトウェアの使い方を学習しやすいかを表します。

例 17) ユーザが学習しやすいように、チュートリアルを提供すること。

品質副特性:操作のしやすさ

操作のしやすさ (Operability) は、ユーザがソフトウェアを使う時のユーザインターフェイスの使いやすさを表します。

例 18) ユーザの作業の順序にあわせて、次に必要な機能が連続して実行できること。
例 19) ユーザが中止したい時にいつでも実行を中止できること。
例 20) すべてのメニューおよびツールバーに、ツールチップで短い説明を表示すること。

品質副特性:魅力

魅力 (Attractiveness) は、ソフトウェアがユーザにとって魅力があるかを表します。 ユーザを引きつけるような画面の色彩や特異なユーザインターフェイスなどの要求が含まれます。

例 21) ユーザインターフェイスのスキンが定義でき、ユーザが自由に取り替えられること。

品質副特性:使用性関連適法性

使用性関連適法性 (Usability compliance) は、使用性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 この非機能要求には、ウインドウシステムや GUI のスタイルガイドが含まれます。

例 22) GUI は、サン・マイクロシステムズの「Java Look and Feel Design Guidelines 2nd Edition」に準拠していること。

品質特性:効率性

効率性 (Efficiency) は、指定された条件下で、ソフトウェアがメモリやハードディスクなどのコンピュータ資源を適切に利用し、期待されるパフォーマンスを提供する能力を表します。

Tips 9) 効率の悪いソフトウェアは、操作のしやすさを悪くすることがある

ひどくのろのろしたソフトウェアは、ユーザにとっては操作がしにくいと感じます。このことから効率性ではなく、操作のしやすさとして非機能要求が定義されることもあります。

品質副特性:時間挙動

時間挙動 (Time behavior) は、指定された条件下で、ソフトウェアが適切な応答時間、処理時間、スループットで機能を実行する能力を表します。

例 23) 注文の確定は、ユーザが選択してから 10 秒以内で完了すること。
例 24) 外部の決済システムへのデータ転送は、20 分以内に終了すること。

品質副特性:資源の活用度

資源の活用度 (Resource utilization) は、指定された条件下で、ソフトウェアがメモリやハードディスクなどのコンピュータ資源を適切に利用しているかを表します。

例 25) 最大でもメモリ 32M バイト、HDD 128M バイトまで有効に使用すること。

Tips 10) 資源の活用度は、できるだけ資源を使わない要求ではない

以前関わったプロジェクトのシステムテストで、自分たちの作ったソフトウェアは、専用のサーバでメモリ 2G バイト搭載しているのに、ピーク時でも 500M バイトも使わずに動いていたことが判明したことがありました。 結局もっとメモリを有効活用して、より良い性能を引き出せることができたのですが、このようにシステムアーキテクチャで割り当てている資源、つまり資源の活用度の非機能要求は、それ以上使わないというだけでなく、最大限活用するように要求されることも少なくありません。

品質副特性:効率関連適法性

効率性関連適法性 (Efficiency compliance) は、効率性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。

品質特性:保守性

保守性 (Maintainability) は、障害の発生、実行環境の変更、機能変更などの必要が生じた時に、ソフトウェアの保守のやりやすさを表します。

Tips 11) 保守性は、適切性と関係することがある

保守性は、その名のとおり保守をする時の要求ですので、ユーザである保守担当者や運用担当者にソフトウェアが提供する機能、つまり「品質副特性:適切性」と強く関係します。 技術的な話題も多いので、収集にあたってはソフトウェアアーキテクトなどの識者が参加するのも良いでしょう。

品質副特性:分析のしやすさ

分析のしやすさ (Analyzability) は、ソフトウェアに障害が発生した時に、その原因を判別し、修正の必要な箇所を特定しやすいかを表します。

例 26) 運用者に対して障害監視機能を提供すること。
例 27) アプリケーションサーバや DBMS の障害エラー、プログラムの例外を稼働ログに残し、障害の内容や箇所が特定できること。

Tips 12) 過剰な分析のしやすさが、効率を悪くすることがある

以前参加した開発で、障害時に原因をすぐに判別できるように、メソッドを呼び出すたびにメソッド名とパラメータを稼働ログに記録することというのを要求されたことがありましたが、ひどくのろのろとし、ディスクも恐ろしいいきおいで消費してしまうソフトウェアになってしまい、この要求は現実的ではなかったということで後から取り消されました。

Tips 13) 分析のしやすさが、使用性を悪くすることがある

顧客から障害に対する問い合わせが起きた時に、分析がしやすいように顧客が使用する画面に Java のスタックトレースや DBMS のエラーコードを表示するようにしたことがあります。 ですが、このような実現方法は、顧客に意味不明なメッセージを見せることになりますので、使用性を悪くすることがあります。

品質副特性:変更のしやすさ

変更のしやすさ (Changeability) は、稼働後の変更要求など、やらなければならない修正をソフトウェアにできるかを表します。 修正内容は未知ですので、ソフトウェアが変更を受け入れられるようなプログラミング言語、構造、アーキテクチャになっていることが要求されます。

例 28) コンポーネントベースで実現され、修正にかかるコストおよび期間が現行システムの 70% 以下であること。
例 29) 技術者の多い Java で記述されること。

Tips 14) 変更のしやすさは、操作のしやすさとして定義されることがある

エンドユーザがソフトウェアを変更可能な場合、変更がしにくいソフトウェアは、ユーザにとっては操作がしにくいと感じます。 このことから変更のしやすさではなく、エディタの操作性など操作のしやすさとして非機能要求が定義されることもあります。

品質副特性:安定性

安定性 (Stability) は、ソフトウェアを修正した時に、影響が予想外の箇所に及ばないことを表します。

例 30) コンポーネントベースで実現され、コンポーネントの修正が他のコンポーネントに及ぼす影響が最小限であること。

品質副特性:テストのしやすさ

テストのしやすさ (Testability) は、ソフトウェアを修正した時にテストがしやすいかを表します。

例 31) 市販あるいはオープンソースのテスティングツールで、システムテストを自動化できること。

Tips 15) 具体的なテスト方法までは要求できないことが多い

まだテスト計画もソフトウェアアーキテクチャ設計もしていない段階では、具体的なテスティングツールを指定することは難しいので、例 31 のように自動化するとかテスト方針にあたるものが要求されることが多いです。

品質副特性:保守性関連適法性

保守性関連適法性 (Maintainability compliance) は、保守性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 保守性に関する適法性は、ベンダーからの開発者向けのガイドラインが要求されるケースが多いです。

例 32) マイクロソフト「ASP ガイドライン」の保守性に関するガイドラインに準拠していること。

品質特性:可搬性

可搬性 (Portability) は、ソフトウェアの異なる環境への移しやすさを表します。

Tips 16) 可搬性は、稼働環境がどこかで収集先も違う

可搬性は、稼働環境がエンドユーザの PC なのか、サーバなのかによって、エンドユーザから収集すべきか、運用担当者から収集すべき違ってきます。 可搬性も技術的な話題が多いので、収集にあたってはソフトウェアアーキテクトが参加するのも良いでしょう。

品質副特性:順応性

順応性 (Adaptability) は、ソフトウェアを別の環境へ移す時の手間を表します。

例 33) リコンパイル無しに Windows から Linux へ移行できること。

品質副特性:インストールのしやすさ

インストールのしやすさ (Installability) は、ソフトウェアを指定された環境へインストールする時のやりやすさを表します。

例 34) クライアントソフトウェアは、顧客自身がインストールできるように、専用の対話型インストーラを用意すること。
例 35) サーバソフトウェアは、運用担当者が 3 時間以内にインストールできること。

Tips 17) インストールのしやすさは、操作のしやすさとして定義されることがある

インストールのしやすさには、インストール時の操作のしやすさが含まれることもあります。 特に例 34 のような、エンドユーザにとってのインストールのしやすさは、インストールのしやすさではなく、操作のしやすさとして非機能要求が定義されることもあります。

品質副特性:共存力

共存力 (Co-existence) は、ソフトウェアを同じ環境で他のソフトウェアと共存できることを表します。 後から他のソフトをインストールしたために正常に動かないということは、みなさんもご経験があると思います。

例 36) MS Office2003 のインストールされた環境で、共に正常に稼働すること。

品質副特性:置換性

置換性 (Replaceability) は、互換性と呼ばれることもあり、同じ環境で、同じ目的を持った他のソフトウェアと置き換えられる能力を表します。 「品質副特性:インストールのしやすさ」とよく似ていますが、古いバージョンや他の製品とそのソフトウェアを置き換える場合の要求である点が異なります。

例 37) 古いバージョンをアンインストールせずに新しいバージョンをインストールできること。
例 38) A社の製品aと置き換えられ、製品aのデータファイルをそのまま読み書きできること。

Tips 18) 置換性は、適切性として定義されることがある

たとえば古いバージョンや他の製品のデータが、ユーザが意図するように完全にインポート機能で引き継げない時は、その機能は適切ではないとも言えます。 このことから置換性ではなく、適切性として非機能要求が定義されることもあります。

Tips 19) 置換性は、操作のしやすさとして定義されることがある

置換性には、ソフトウェアを置き換える時の操作のしやすさが含まれることもあります。 このことから置換性ではなく、操作のしやすさとして非機能要求が定義されることもあります。

品質副特性:可搬性関連適法性

可搬性関連適法性 (Portability compliance) は、可搬性に関する法規、業界標準、規格にソフトウェアが沿っているかを表します。 可搬性に関するガイドラインは、例 39例 40のように稼働環境である OS などのベンダーで用意されている場合があります。

例 39) マイクロソフトの「Windows Server 2003 アプリケーション仕様書」に準拠し、Certified for Windows ロゴを取得できること。
例 40) ソフトウェアは、サン・マイクロシステムズの「100% Pure Java Cookbook」に準拠し、100 % Pure Java ロゴを取得できること。

3. 非機能要求収集のプロセスと定義方法

ここからは、非機能要求に関する要求定義プロセスと定義内容や技法について述べたいと思います。

スタートラインを確認する

1.2で説明したように、ソフトウェア開発に関係してさまざまな視点の要求があります。 機能要求も非機能要求も基本的には、図 1図 2 に示した要求の関係を理解していて、今プロジェクトがシステム要求まで定義できていれば、これからソフトウェア要求を収集できる段階にあるといえるでしょう。 だれが、いつ、どこで、何をするためにソフトウェアを使うのかを決定づける業務要求やシステム要求が定義されていない状態では、ソフトウェア要求の収集は開始できません。 ソフトウェア開発が開始したら、まずこのスタートラインの確認をしてください。

機能要求を収集する

ソフトウェアの機能要求は、図 1図 2 の関係にある各要求で、システム要求とその実現方式であるシステムアーキテクチャが定義されていれば、そこからソフトウェアがだれを支援するのか、何を自動化するのか導き出せます。 UML を使ってモデリングし、ソフトウェアの機能要求を収集する方法を、Vol.36 から連載中[*]の「J2EE 開発に求められるモデリング手法」で紹介していますので、参考にしてください。

[*] オブジェクトの広場でも公開しております。こちら(「J2EE 開発に求められるモデリング手法」)からご覧いただけます。

非機能要求を収集する

非機能要求は、収集された機能要求に対して収集していきます。 ソフトウェア全体あるいは個々の機能について ISO9126 と照らし合わせて、要求が存在しないか確認していきます。 とても骨の折れる作業ですが、後々のユーザの受け入れで思わぬ事態にならないためには必要な作業です。 もし、この作業で見逃すと、その非機能要求は「暗黙の要求」となります。 「暗黙の要求」とは、潜在的には確かに要求として存在するが、進捗やでき映えなど要求の実現状況がプロジェクトマネジメントされていない要求であり、プロジェクト終盤で利害関係者に実現するべき要求が実現されていないと主張されたり、要求が最後まで実現されず使いものにならないソフトウェアという評価を受けたりするリスクを伴います。 ユーザから「画面が 1 秒以内に切り替わるのは常識でしょ?」とか後で言われてしまうことにならないように、収集した要求は必ずプロジェクトスポンサやユーザなど利害関係者に承認を得て、プロジェクト期間中は要求がどこまで実現できたのか管理するようにします。

定義すべきこと

ソフトウェアは、すべての要求を実現していれば完成です。 ですから後々ソフトウェアが要求を実現したか確認する時のために、要求は実現できたことを測定可能でなければいけません。 要求は、「〜に準拠していること」、「〜が○秒以内にできること」など適法性や定量的な要求はハッキリしていて良いのですが、「ユーザである〜に魅力的であること」のようにそうでないものもあります。 この場合は、ベータテストで数名のユーザのサンプルによる評価で測定する、1 名のユーザ代表やプロジェクトスポンサによる評価をするなど、測定方法を利害関係者と合意し必ず測定可能にします。 もし測定方法が見つからないのであれば、プロジェクトとして取り組む要求としては不適切です。 ソフトウェア要求の測定方法は、基本的に保守や運用も含めてソフトウェアを使用するユーザが測定可能でなければいけません。 ですが、Java のプロファイラや Web のストレスツールなどを用いて測定したほうが正確で効率が良い場合もありますので、テスト計画時に利害関係者の承認を受けた上で採用してもよいでしょう。

定義内容

  • 概要
  • 測定方法
  • 適合基準
衝突する要求を取り除く

複数の利害関係者から要求を収集すると、相反する要求がされていることがあります。 たとえば、例 22 のように Java ルックアンドフィールのガイドラインに従っていることが要求されているのに、メインフレームの既存システムを使っているユーザからは、メインフレームの操作性、たとえばカーソルが Tab キーで移動するのではなく Enter キーで移動するような操作性を要求されていることがあります。この場合同じユーザインターフェイス上で、どちらの要求も実現することはできませんので、利害関係者を交えてどちらかにすることが必要となります。

利害関係者に承認を得る

定義した要求は、必ず利害関係者の承認を得ます。 承認された要求は、「要求ベースライン」と呼ばれ、プロジェクトの作業範囲 (プロジェクトスコープ) を決定づけます。 要求ベースラインは、プロジェクトマネジメントの要求管理下におかれ、要求の変更手続きのもとでしか変更してはいけません。 通常、要求の変更手続きには、ユーザの代表やプロジェクトマネジャーで構成される変更管理委員会 (CCB : Change Control Board) の承認が含まれます。 このように、要求をきちんと管理することは、PMBOK(*) など最近のプロジェクトマネジメントでは、より一層求められています。

(*) Project Management Body of Knowledge
プロジェクトマネジメントの標準として日本でも認知されつつあり、米国国家規格 (ANSI) にもなっています。 11 月に第 3 版がリリースされました。

Tips 20) 要求を評価しながら開発する

非機能要求は、人の感性に関する要求や技術的な要求を含んでいますので、利害関係者からすべてをすぐに引き出すのは難しいものです。 このような非機能要求が「暗黙の要求」になってしまうのを避ける開発方法もあります。 XP、アジャイル、統一プロセスのような反復型の開発です。 小さく作って、それを評価して、要求と実現が合っているか、非機能要求に漏れがないか確認できます。 それでもソフトウェアアーキテクチャに大きな影響がある非機能要求は、対応が難しくなりがちです。 そのためにも ISO9126 と照らし合わせて効率よく収集していく必要があります。

4. パターンでわかる良い事例、悪い事例

パターン1:要求の衝突

悪い例:非機能要求をそのまま受け入れる
良い例:衝突する要求を利害関係者と協議し取り除く

Tips に示したとおり非機能要求には、互いに影響し合うものがあります。 場合によっては一方の実現方法によって、他方の満足する実現が困難になることもあります。 たとえば、Tips 5 のようにユーザ認証に関する要求の適合基準として適当だが、認証されるまでに操作しにくいとユーザが感じるようなものは、適合基準や指定している実現方法を見直す必要があります。

パターン2:ザ・ユーザ

悪い例:ユーザをユーザとしてしか識別していない
良い例:どのようなユーザが利用するのか識別されている

ユーザをユーザとしてしか識別していないプロジェクトでは、機能性、使用性、保守性の低いソフトウェアを作ってしまうことが多くあります。 顧客、事務員、運用担当者、保守担当者などユーザを目的別に識別し、それぞれがどのような知識があるのかなどプロファイルまで識別しておくと、機能性、使用性、保守性の高いソフトウェアを作ることができます。 たとえば普段コンピュータを使って業務をしている運用担当者と、パソコンを覚えたての顧客ではユーザインターフェイスのデザインや、メッセージに表示する用語も変わってきます。

パターン3:技術的な制約

悪い例:技術的な制約を含む非機能要求をそのまま受け入れる
良い例:技術的な制約が、本当に制約なのか利害関係者へ確認し不必要な制約を取り除く

ユーザ部門と情報システム部門で人材の交流を図っている組織で多く見られるのが、ユーザ部門から設計上の技術的な制約を含む非機能要求が不必要にあげられることです。 たとえば、例 4 を「預金者本人以外が、口座の情報や取引履歴を参照できないように、Web の基本認証をおこなうこと」とした場合、「Web の基本認証」という要求の実現方法を含んでいます。 つまり預金者の認証を実現するメカニズムとして、ソフトウェアアーキテクチャでは証明書や乱数カードなど基本認証以外の選択肢はなくなります。 このような要求は技術上の制約となりますが、実現方法を含んだ要求の定義が即だめだというわけではなく、たまたま知っていたので例として言ってみた場合も多くあるということです。

技術的な制約は、

  • その技術を使うことを含む法律や業界/企業のガイドラインへの準拠が要求されている
  • その技術を使うことがビジネス上のメリットになる

というような正当な理由があることを確認してください。

パターン4:適合基準

悪い例:おおざっぱに適合基準を設定する
良い例:機能ごとに適合基準を変えて設定する

開発者が、利害関係者に「画面が切り替わるまでのレスポンスタイムは何秒ぐらいですか?」こんな感じで質問すると「 2 秒以内でお願いします」といったように一意の測定値を要求されるでしょう。 開発者は、ピーク時の注文トランザクションが完了し次の画面を表示するまでそんなに早く終わるわけがないと思い、「 7 秒以内じゃだめですか?」といったことを話し出します。 利害関係者は、メニューを選んでから最初の画面が表示されるまでに 7 秒もかかるのはごめんだと思い拒否します。 このように適合基準が異なるものを無理やり同じにしようとすると、利害関係者と合意できる基準が見つけられず、思わぬ時間が取られてしまいます。 特にレスポンスタイムやスループットなど効率性に関しては、機能ごとに個々に基準値を設定したほうが良いです。

パターン5:フィージビリティスタディ

悪い例:必要以上に厳しい適合基準を設定する
良い例:目標値を設定する

適合基準は、適合しているといえるもっとも広い範囲 (緩い範囲) に設定します。 ですが、それ以上に厳しい範囲に設定してしまっているプロジェクトを時々見かけます。 この場合、技術的に実現可能かどうかわからないぐらい厳しいものが、非機能要求として多く要求されます。 このようなプロジェクトは、実現可能かどうかの予備検証 (フィージビリティスタディ) に必要以上に時間やコストをかけたり、開発者から要求を取り下げるための交渉が長々と行われたりします。 ですがこの状況は無駄にプロジェクトのスケジュールや予算を圧迫しているだけです。 このような厳しい適合基準は、本来あるべき適合基準とは別に目標値として設定し、ソフトウェアアーキテクチャの課題として取り組むようにするべきです。

パターン6:何でも現状担保

悪い例:すべて現行システムより劣らないことを要求され、受け入れる
良い例:どの要求か確認する

要求する責任があるはずの利害関係者が、興味のある要求以外はすべて現行システムを基準にするように要求して、要求定義をさっさと終わらせようとすることがあります。 「現状担保」という言葉がよく使われます。 ところが、この現行システムの要求を定義した要求仕様書が存在しないとか、要求仕様書がメンテされていない時は最悪です。 これを受け入れる場合、果たしてどの非機能要求が現行システムより劣っていてはいけないのか何も明示されていませんので、現行システムで測定できるあらゆる非機能要求が要求されていることになります。 このようなケースは、実はソフトウェアへの要求を定義しているのではなく、依頼する側から依頼される側への要求を定義しているにすぎないのです。

パターン7:現行システムが適合基準

悪い例:現行システムの実測値より劣らないことを要求され受け入れる
良い例:適合基準として妥当か確認する

ある非機能要求について、現行システムが本来必要な適合基準を大幅に上回っていることがよくあります。 すべての非機能要求について、現行システムの実測値を適合基準とすることを求められた場合、必要以上に厳しい適合基準をクリアすることに開発者は努力しなければならなくなり、プロジェクトのお金も時間も費やされることになってしまいます。 現行システムの実測値を適合基準の参考にするのは良いことですが、必ず妥当かどうか、必要以上に厳しくないか利害関係者と確認すべきです。

パターン8:トレーサビリティ疲れ

悪い例:要求管理ソフトウェアを導入し、その入力作業に追われる
良い例:開発プロセスでトレーサビリティを確保している

最近では、要求の実現状況や要求の変更があった場合の影響範囲をすばやく追跡 (トレース) できる要求管理ソフトウェアも数社から発売されています。 ですが、すばやく追跡ができることと引き替えに、入力作業に思わぬ作業工数が取られ開発が進まないというプロジェクトもあります。 基本的にトレーサビリティは、ツールに頼る前に開発ライフサイクルでの段階的詳細化と成果物を定義している開発プロセスで確保し、要求管理ソフトは開発プロセスを実行する上での作業を軽減するためにだけ使うべきです。 ですがこのようなプロジェクトでは、開発プロセスについてあまり考えのないまま要求管理ソフトを導入してしまい、要求管理ソフトが持っている機能すべてを使おうとして、このような状態に陥ってしまっているようです。 導入にあたっては、自分たちの開発プロセスのどこを軽減できるのか、要求管理ソフトをよく評価してください。

パターン9:要求の放置

悪い例:承認された要求仕様書がプロジェクトで忘れ去られている
良い例:プロジェクトは要求に適合するか要求仕様書で確認している

公式に承認されたはずの要求仕様書 (SRS : Software Requirement Specification) が、プロジェクト終盤ではユーザにも開発者にもまったく参照されていないプロジェクトを目にすることがあります。 このようなプロジェクトではしばしば「言った、言わない」がやりとりされます。 3.の「利害関係者に承認を得る」で説明したような要求管理が行われておらず、要求の最初のベースラインである要求仕様書第 1 版ができたら放置され、後は口頭で要求の変更が行われています。 このような状況は、せっかく定義した「形式化された要求」を「暗黙の要求」に戻してしまっているといえます。 要求仕様書は、ソフトウェアが実現するべき要求であり、ソフトウェア開発やプロジェクト完了の根拠となります。 ユーザに引き渡す前に、開発側は要求仕様書に沿ってテストが行われているべきですし、ユーザは要求仕様書に沿ってソフトウェアが適合していることを確認し、開発の完了を承認すべきです。

パターン10:要求のバージョン

悪い例:開発者が担当する要求のバージョンを認識せずに開発している
良い例:開発者が担当する要求のバージョンを認識して開発している

一見するとプロジェクトで要求管理がされているが、開発者はこれから自分が実現する要求のバージョンを認識せずに開発しているケースがあります。 このようなケースでは、開発者はきちんと要求仕様に基づいて自分は実現したつもりで、要求仕様に基づくテストも完了し、進捗が報告されます。 ところが、その開発者が参照している要求仕様が古い版だったり、逆に変更中で未承認の版だったりしたらどうでしょう。 このようなプロジェクトは、ちゃんとした変更管理の仕組みがあるのにプロジェクトが大混乱します。 特に反復型の開発では、同じ要求が同じ反復中に、一方では開発者によって実現され、一方では次のバージョンが定義されることも少なくありませんので注意してください。

パターン11:非機能要求の適法化

悪い例:いつも非機能要求を苦労して収集している
良い例:類似したシステムのために非機能要求を標準化している

非機能要求は、業界やベンダーのガイドラインが多くあるように、機能要求よりも業界、企業、業務、利用者、システムアーキテクチャによって類似することが多いです。 このことから一度収集した非機能要求は、このようなカテゴリで整理しておくと、次の開発でも大いに再利用できます。 できれば、開発チームや社内標準などにして、 ISO9126 の各適法性として「社内標準×××に従っていること」と定義できるようにしましょう。

まとめ

前半では、ソフトウェア開発を取り巻くいろいろな視点の要求を整理し、非機能要求を収集する便利なツールとなる ISO9126 を重点的に紹介しました。 後半では非機能要求を中心とした要求収集プロセスと、私が経験したプロジェクトでの非機能要求にまつわる良い事例、悪い事例を紹介しました。 開発プロジェクトにとって、非機能要求の定義作業は開発ライフサイクルの一部分ですので、もっと開発ライフサイクルの全体感をつかみたい方は、Vol.36 から連載中[*]の「J2EE 開発に求められるモデリング手法」もぜひご一読ください。 本稿が、みなさんのソフトウェア開発プロジェクトで、要求定義の一助になれば幸いです。

[*] オブジェクトの広場でも公開しております。こちら(「J2EE 開発に求められるモデリング手法」)からご覧いただけます。

参考文献・Web サイト