非機能要件と聞くと皆さんどういったイメージを持ちますでしょうか？
私は非機能要件に関しては若干の苦手意識があり、自分が担当するプロジェクトでも非機能要件の決め方について随分と苦労しています。
そんな私も含め、非機能要件について何を検討し、どのように決めるべきか悩める人にうってつけなのがIPA情報処理推進機構が公開している非機能要求グレードです。
これを参考にすれば、誰でも非機能要件を定義することができるようになります。
今回は私が実際にプロジェクトで活用した時の経験も交えて、非機能要求グレードの活用方法、非機能定義書の作成方法について解説します。
スポンサーリンク
非機能要件の６大項目とは
非機能要件とは、次の６項目について定義することだと、IPA情報処理推進機構の非機能要求グレードでは定義されています。実際、私のプロジェクトでもこれら６つを定義しています。
- 可用性
- 性能・拡張性
- 運用・保守性
- 移行性
- セキュリティ
- システム環境・エコロジー
システム開発をする際は、これら６つの大項目に関して、今回のシステムではどうするかを決めていくこととなります。
それぞれの要件項目とその内容、そして具体的な検討内容は次のようになっています。
| 非機能要件項目 | 説明 | 具体例 |
|---|---|---|
| 可用性 | システムの継続性 | ・稼働時間 ・稼働目標 |
| 性能・拡張性 | システムの性能、将来に渡る拡張性 | ・業務量の増加見込み ・業務特性（ピーク時、通常時） |
| 運用・保守性 | システムの運用と保守性 | ・稼働レベル ・問題発生時の対応レベル |
| 移行性 | 現行システムからの移行性 | ・移行期間及び移行方法 ・移行の種類、移行量 |
| セキュリティ | 情報の安全性 | ・利用制限 ・不正アクセス防止 |
| システム環境・エコロジー | システム設置環境や規格 | ・耐震、免震、騒音 ・CO2排出量 |
(c)2010 2018 独立行政法人情報処理 推進機構
スポンサーリンク
非機能要求グレードの活用方法
非機能要件の６大項目はわかりましたが、もっと具体的に何を決めなければいけないのか不明瞭です。そこで出てくるのは非機能要求グレードです。ここには超具体的に、何を決めるべきかがリストアップされています。
したがって、非機能要求グレードに定義された内容に沿って定義さえすれば、非機能要件定義は完了できます。
実際、私もプロジェクトの中でIPA情報処理推進機構が提供してくれている非機能要求グレードを活用しましたが、非常に便利で、効果的でした。そこで、どのように活用すればよいか、IPA情報処理推進機構が推奨する方法をベースに実際に活用した際の事例と共にご紹介します。
基本的な使い方については、非機能要求グレード2018ダウンロード 02_利用ガイド利用編.pdf (c)2010 2018 独立行政法人情報処理 推進機構を参照したうえでこちらを見てもらうとより理解が深まると思います。
大きな流れ
大きな流れは次の通りです。
1.モデルシステムを選定
2.非機能要件項目のテーラリング
3.要求レベルを選定（重要項目）
4.重要項目に関する顧客合意
5.要求レベルを選定（その他項目）
6.その他項目に関する顧客合意
7.最終合意
それぞれ内容解説していきます。
スポンサーリンク
１．モデルシステムを選定
まずは、各要件検討項目のレベル決定のベースとなるモデルシステムを選定します。今回開発するシステムがどのIPA情報処理推進機構が定めるモデルのどれに当たるかを決めます。それにより、各検討項目の参考レベルを参考にすることができます。
モデルには、「社会的影響が殆ど無いシステム」「社会的影響が限定されるシステム」「社会的影響が極めて大きいシステム」の３つがあります。
| モデル | モデル内容 | 指標（例） |
|---|---|---|
| 社会的影響が殆ど無いシステム | 企業の特定部門が比較的限られた範囲で利用しているシステム。利用部門では大きな影響があるが、その他には影響しないもの。 | ・1年間で数日程度の停止まで許容できる ・移行の日程は十分に確保される。 |
| 社会的影響が限定されるシステム | 企業活動の基盤となるシステム。当該企業活動に多大の影響を及ぼすと共に取引先や顧客等の外部利用者にも影響を及ぼす | ・1年間で1時間程度の停止まで許容できる ・移行のためのシステム停止は可能である。 |
| 社会的影響が極めて大きいシステム | 国民生活・社会経済活動の基盤となるシステム。国民生活・社会経済活動に多大な影響を与えるもの。 | ・1年間で数分間程度の停止まで許容できる ・移行のための停止時間を最小限にする。 |
(c)2010 2018 独立行政法人情報処理 推進機構
それぞれのモデルに対して、目安となる稼働率、性能目標、運用時間、移行方式、情報セキュリティ、耐震などの情報が整理されているため、自身が開発するシステムと近しいモデルを採用します。
私はこれまで「社会的影響が殆ど無いシステム」「社会的影響が限定されるシステム」までの経験しかありません。目安としては、ある特定の事業部門でしか利用しないような企業内システムであれば「社会的影響が殆ど無いシステム」が該当し、会社の基幹システムや企業が取引先や顧客に対して公開しているようなシステム（例えば、問合せ受付システム等）は「社会的影響が限定されるシステム」に該当するとイメージすると良いと思います。「社会的影響が極めて大きいシステム」に関しては、金融系のシステムで多いです。
スポンサーリンク
２．非機能要件項目のテーラリング
IPA情報処理推進機構が提供する非機能要求グレードでは、非機能要件の６大項目を細分化し、118個の要件検討項目と、238個（重複除き230個）の指標が示されています。
勿論すべてを検討できれば申し分ないですが、プロジェクトの時間は有限であり、検討するための費用も人的リソースも限られています。また、そもそも今回のプロジェクトでは明らかに検討しなくて良い項目、指標もあります。
したがって、まずはすべての検討項目、指標を総なめして、その次に今回のプロジェクトで検討しなければいけない項目を選定します。これをテーラリングといいます。
選定レベルの中で、「規定なし」「契約はなし」といった選定レベル０に相当するような判定をする方法もあります。どちらでも問題ないと思います。ただ、まずは対象となる検討項目を浚う方が効率的だと思い、私はまずテーラリングから実施するようにしています。
最初のうちのテーラリング時のコツは、「迷ったら残しておく」です。ただし、不要と感じた時点で切り捨てることです。経験が浅いとテーラリングに時間がかかってしまいますが、最初のうちは判断がつかないことの方が多いと思います。したがって、まずは検討項目として残しておき、ゆくゆく削除していくというやり方で十分です。
スポンサーリンク
３．要求レベルを選定（重要項目）
いよいよ、テーラリングした要件項目に対して要求レベルを決定していきます。
要件項目の検討については、「重要項目」から優先的に対応します。
IPA情報処理推進機構の非機能グレードでは「重要項目」という印を付けてくれており、この重要項目から先に検討するように案内がされています。したがった、テーラリングした項目の中から更に重要項目に絞って先に検討をします。
検討する際は、１．モデルシステムを選定で選定したモデルと照らし合わせながら、今回のプロジェクトにおける指標を決めていきます。モデルはあくまでモデルですので、参考として捉えます。したがって、採用したモデルよりも緩いレベルにすることも、厳しいレベルに設定することもどちらもあります。
スポンサーリンク
４．重要項目に関する顧客合意
私のプロジェクトでは、重要項目の検討が済んだ段階で一度顧客との合意をはさみます。３．要求レベルを選定（重要項目）の中でももちろんこまめに顧客との意見交換はしていますが、重要項目のすべての検討が完了した段階で一度、合意・承認という手順を踏むようにしています。
この後、その他の項目についても検討をしますが、重要項目の内容がベースになってくるため、一度この段階で重要項目について合意しておくことは、この後の検討をよりスムーズにしてくれます。
スポンサーリンク
５．要求レベルを選定（その他項目）
続いて、テーラリングされ検討項目となっているその他の項目についての検討を行います。
検討する際は、重要項目と同様に、モデルシステムを参考にして選定レベルを決めていきます。
６．その他項目に関する顧客合意
その他項目の検討も完了したら、顧客合意を行います。
重要項目の合意をベースにしつつ、その他項目についても１つずつ合意形成を図っていきます。
７．最終合意
最後に、重要項目、その他項目を総なめして最終合意を行います。
ここでのポイントは、重要項目とその他項目とを比較し、矛盾している箇所がないかという観点で確認することです。
例えば、重要項目である「通常時レスポンス順守率」で選定レベルを「90%」としているにもかかわらず、その他項目である「縮退時レスポンス順守率」では「95%」としている場合、縮退時の方が厳格なレスポンスを求めていることになり、少々違和感があります。こちらは分かりやすい例になりますが、このように横ぐしで全体を確認し、最終合意を図ります。
ここで合意できた内容がそのまま非機能要件定義書となります。何か特筆すべき事項などがあれば別途、資料にまとめることもありますが、基本的にはこの非機能要求グレードに沿って決定した内容だけで非機能要件定義は完了といっても問題ありません。むしろ十分です。
スポンサーリンク
非機能要件定義書のサンプル
前述した内容に沿って検討をしていけば、自ずと非機能要件定義書の作成も完了することができます。最後の、私が非機能要求グレードを参考に、実際にプロジェクトにて活用した際の非機能要件定義書のサンプルをお見せしたいと思います。
非機能要件定義のサンプルダウンロード
本サンプルは、独立行政法人情報処理推進機構が提供する非機能要求グレード 2018 活用シート 2018年4月を参考に筆者にて加筆修正を実施。
使用条件は下記の通りであり、使用条件「２」に沿って、本資料を提供するものとする。
使用条件「２」：独立行政法人情報処理推進機構は、「本資料の全部又は一部を複製、改変、公衆送信、又は翻訳/翻案し、第三者に有償又は無償で再配布すること」を許諾します。なお、複製し再配布する場合は本使用条件を添付し、本使用条件に記載されている条件を配布先に遵守させて下さい。改変又は翻訳/翻案し再配布する場合は、新しく使用条件を設定することが可能ですが、本使用条件を必ず含めて下さい。
スポンサーリンク
IPA非機能要求グレードを活用しよう
はじめて非機能要件定義をするとなると、非常にハードルが高く感じてしまいます。しかも、インフラ領域を専門としておらず、アプリケーション畑出身のエンジニアにとってはとっつきにくいと思います。
今回の内容が非機能要件定義の必要性に迫られているシステムエンジニアの皆さんの助けになっていれば幸いです。
改めて今回本記事の参考とさせていただいており、日々のシステム開発でもお世話になっているIPA情報処理推進機の非機能要件定義に関するリンクを共有して終わりたいと思います。
他にもIPA情報処理推進機のサイトは参考になるものばかりですのでご覧になってみるとよいと思います。
スポンサーリンク
コメント