About us 情シスのじかんとは？
About us 情シスのじかんとは？
INDEX
「非機能要件ってなに？」
「非機能要件と機能要件の違いってなに？」
上記のような疑問をお持ちの方がいるのではないでしょうか。
非機能要件とは、システムの主軸となる機能以外の要件を指します。よって、機能要件との違いとしては主軸となる機能か否かになります。
本記事では、システムの主たる機能以外である非機能要件の定義するべき項目や、非機能要求ガイドラインにて定義されている項目を紹介しています。
非機能要件定義書を作成する際のポイントや定義する際の手順も解説しているので、非機能要件の知見を深めたい方はぜひ参考にして下さい。
非機能要件とは、システムの主たる機能以外の要件を指します。ユーザビリティ、性能、拡張性、セキュリティなど、システムの「質」に関わる重要な要素です。
例えば、使い勝手が悪く利用者から不満が出る、パフォーマンスが低下して作業効率が悪くなる、セキュリティに問題があり情報漏洩が起きる、システムが不安定で頻繁に落ちる、拡張性が不足して使い勝手が悪いなど、これらの問題は非機能要件が満たされていないために生じます。
非機能要件の定義は多岐にわたり、何を定義すべきかが明確でないため、適切に定義せずにシステムを構築すると、稼働後に大きなトラブルが発生する可能性があります。
システムの品質を確保するためには、機能要件と非機能要件の両方をバランスよく備える必要があります。機能要件とは、企業や利用者が求める「必須の機能」のことです。比較的簡単に定義できます。
例えば、「現行システムで利用している機能は必ず盛り込んでほしい」とか、「今回は◯◯ができることが開発の目玉なので、できないと困る」といった基本的な要件が機能要件です。
そのため、システム開発プロジェクトでは、機能要件の実装は当然のことであり、最低限必要な機能です。ただし、機能要件を満たしているからといって、企業や利用者の満足度が大幅に向上するわけではありません。
一方、非機能要件は、企業や利用者から明確な要望があるわけではなく、開発者が利用者の視点で考える要件です。これらはシステムにとって重要な「品質」の要素となるので、非機能要件が高品質であれば、顧客満足度が向上します。このような違いから、システム開発では機能要件と同様に、非機能要件も重要視し、検討すべき事項と理解していただければと思います。
非機能要件で定義するべき項目を6つ紹介します。
それぞれ解説します。
可用性は、システムが連続して利用可能な状態を維持する能力を指します。例えば、システムの停止時間が稼働時間に比べて少ない場合、可用性が高いです。
可用性には、システムの稼働率だけでなく、運用スケジュールや業務継続性、業務復旧なども含まれます。さらに、バックアップの頻度や復旧までの時間、非常時の障害耐性なども可用性に影響します。
性能と拡張性には、それぞれ性能要件と拡張性要件があります。性能要件はシステムの処理能力やレスポンスタイム、スループットなどを指し、拡張性要件はシステムがどれだけ拡張可能かを示します。
性能と拡張性の要件を明確にすると、システムの性能や将来の拡張性を定義できます。具体的な目標値を設定し、処理速度を向上させるために必要なハードウェアの配置を決定します。
運用・保守性とは、システムの運用や保守に必要な要件のことを指します。システムに何か異常が起きた場合の対応や、障害監視システムやメンテナンスに関する事項などが含まれます。
運用・保守性に関する要件は、非常時の対応と密接に関わっているため、システムの構成に大きな影響を与えます。また、運用マニュアルや手順書にも要件の内容を含める必要があります。
移行性とは、現在のシステムから新しいシステムへの移行がスムーズに行えるかどうかを示す要件です。具体的には、移行方法やスケジュールの設定だけでなく、システムの停止時間や移行データの種類、作業の分担なども関係します。
移行性を確保するためには、予定の調整や企業への情報提供だけでなく、移行対象の資産の提示やリハーサルも行われます。
セキュリティとは、システムを利用する際に考慮すべきリスクを管理するための要件です。具体的には、リスクの分析やセキュリティ診断、セキュリティパッチの導入などが含まれます。
また、不正アクセス対策としての認証機能やデータ暗号化、アクセス制限などもセキュリティの要件として検討されます。
環境とエコロジーは、システムの設計や運用で考慮すべき制約条件や消費エネルギーに関する項目を指します。
この中には、システムが環境に与える影響を考慮した内容や下記にも検討する必要があります。
これらの内容にはコンプライアンスに関連するものも含まれるため、慎重な定義が必要です。
「非機能要求仕様ガイドライン」は、一般社団法人日本情報システム・利用者協会(JUAS)が出版しています。この書籍では、10種類の要件を分類し、それぞれの定義や検証方法が詳しく説明されているので、下記にて簡易的にまとめています。
|
分類 |
要点 |
非機能グレード |
非機能要件ガイドライン |
|
可用性 |
・バックアップ体制 ・障害発生時の回復方法 |
⚪︎ |
|
|
性能・拡張性 |
・レスポンス ・スループット ・改善の容易さ |
⚪︎ |
|
|
運用・保守性 |
運用、保守の容易さ |
⚪︎ |
⚪︎ |
|
移行性 |
多環境への移行の容易さ |
⚪︎ |
⚪︎ |
|
セキュリティ |
・アクセス制限 ・不正利用者の監視 ・社員への情報セキュリティの教育 |
⚪︎ |
|
|
システム環境 |
・システムの設置環境 ・消費エネルギー |
⚪︎ |
|
|
機能性 |
必要な機能の実装度 |
⚪︎ |
|
|
信頼性 |
システムの安定供給 |
⚪︎ |
|
|
使用性 |
ユーザビリティ |
⚪︎ |
|
|
効率性 |
リソースの効率利用 |
⚪︎ |
|
|
障害抑制性 |
障害発生や問題拡大のしにくさ |
⚪︎ |
|
|
効果性 |
・投資対効果 ・費用対効果 |
⚪︎ |
|
|
技術要件 |
・技術に関する要件 |
⚪︎ |
出典：非機能要求仕様定義ガイドライン（UVCプロジェクトⅡ 2008報告書）より加工・編集_（編著：社団法人 日本情報システム・利用者協会）
上記により、代表的な要件の例を通じて、それぞれの重要性やポイントの異なることが理解できます。ただし、システムによってはこれらの要件が該当しない場合もありますし、必ずしもすべてを明確に定義する必要はありません。
要件を明示的に記述しなくても、一定の水準を満たしたシステムが完成する場合もあるでしょう。しかし、重要な非機能要件が見落とされることで、システムの完成後に大きな問題が発生するのも少なくありません。
そのため、システム開発を行う際には、システムの特性に合わせて適切な非機能要件を明確に定義するのを強くおすすめします。
本章では非機能要件定義書を作成する際のポイントを5つ紹介します。
順に見ていきましょう。
非機能要件を定義する際には、まず機能要件を明確に定めておく必要があります。なぜなら、システム構築では機能要件が必須の項目となるため、機能要件を基に非機能要件を作る方法が一般的だからです。
機能要件を中心に配置し、非機能要件を組み立てることで、目標や必要な機能が明確になり、要件の優先順位を定めやすくなります。その結果、人員配置や予算の割り当てをスムーズに行うことができるようになります。
機能要件には顧客が必要とする具体的な機能や要望が示されます。そのため、非機能要件を後から定義することで、機能要件と非機能要件のバランスを保てます。
要件は開発側からの提案であり、最終決定権は顧客にあります。顧客の満足度を高めるためには、顧客にとってメリットのある提案を複数用意するのが効果的です。
複数の提案を提示すれば、顧客は項目ごとの内容を比較検討し、それぞれのメリット・デメリットを事前に把握できます。また、顧客の隠れたニーズを提案に反映させることで信頼が深まり、良好な関係性を築くこともできます。
非機能要件は、顧客からの明確な要望がなく、利用者の視点から考える必要があります。開発チームはシステムの知識を持っているため、定義すべき項目やその内容に責任を持ち、積極的に推進していく必要があります。この前提のもと、プロジェクトを進めてください。
非機能要件を顧客にわかりやすく伝えるためには、単に文章でまとめるだけでなく、図や表を使って視覚的に示すことが有効です。「非機能要件」自体が少し難解な言葉であるため、さらに難しい専門用語を並べると、顧客の理解が難しくなってしまいます。
そのため、顧客に選択してもらいたい非機能要件がある場合は、メリットとデメリットがわかりやすい図や表を作成し、それを見ながら言葉で補足する程度に留めましょう。また、訴求の方法はさまざまですが、強引な話し方は避け、意図が伝わる訴求を心がけることが重要です。
顧客の要望をすべて実現しようとすると、工数やコストが増えることがよくあります。ですから、要望をそのまま採用するのではなく、目的や必要な要件を考慮して選びましょう。また、顧客の要望には優先順位をつけ、必須の要件だけを選択する方法も効果的です。その際には、丁寧なヒアリングを行うことで、他の要件で代替できるものも見つかることがあります。
前章では非機能要件定義書を作成する際のポイントを紹介しましたが、本章では実際に非機能要件を提起する際の手順を解説します。定義する際には下記の3STEPで進めてみてください。
それでは見ていきましょう。
対象システムの方向性によって、非機能要件も大きく変わります。例えば、企業にとって重要な基幹システムの場合、性能や可用性の要求は高くなります。
一方、小規模で影響の少ないシステムでは、要件にはある程度の許容範囲があります。
※引用:IPA「システム構築の上流工程強化（非機能要求グレード）」
IPAの非機能要求グレードでは、各項目ごとに推奨される要求レベルが定義されています。顧客の要望に合わせて推奨値を調整できれば、非機能要件を整理できます。
これらを参考にして、非機能要件の草案を作成していきましょう。作成したら、実現可能な内容であることを確認しましょう。
システムや顧客の要件に合わせて推奨値を設定し、その草案を顧客に提示して合意を得ます。この草案を提示すると、顧客から細かい要件が出ることも。
顧客からの細かな要件を取り入れながら、少しずつ要件を定義していきます。顧客から出された要件には、その理由も確認しましょう。代替案を提示するためには、理解が必要です。
非機能要件を決めたら、それを要件定義書に記載します。要件定義書は設計の基となるため、誰が見てもわかりやすく、曖昧な表現は避けましょう。図を使っても効果的です。
本章まで、非機能要件の概要や重要な項目を紹介しましたが、本章では具体的に各項目の評価方法を紹介します。具体的に下記のような設計指標/評価基準で解説します。
順に紹介します。
「RASIS」とは、非機能要件に特化した指標ではなく、コンピュータシステムのサービス全般に関する指標基準のひとつです。RASISのアルファベットは下記の5項目のイニシャルを表しています。
上記のような指標基準を持っていると押さえておきましょう。
「SLA」とは、「サービスレベル契約」のことです。サービスを提供する事業者と契約者の間で交わされる契約であり、事業者が提供するサービスの内容や性能基準を、どの程度のレベルまで保証するか、明文化したものとなります。
この契約は、サービス提供にて守るべき約束事であり、違反すればペナルティが課せられる場合もあります。そのため、ペナルティの条件や内容にも、両者合意の上で「SLA」に明記する必要があります。
サービスを提供する事業者は、「SLA」の策定によって、顧客の期待を明確に管理できるとともに、サービス障害や性能低下に関する免責事項も明示できます。一方、契約者である顧客も、サービス障害発生時の損害賠償などを契約として明確化できるメリットがあります。
「SLO」とは、「サービスレベル項目(目標)」の略です。この「サービスレベル項目(目標)」は、顧客と合意した契約内容である「SLA」を達成するための具体的な評価基準や指標値、そして目標を示します。
非機能要件の定義や判断基準、定義時のポイントを説明してきました。非機能要件は専門的であり、評価指標も曖昧になりがちです。
しかし、適切な非機能要件を設定できれば、他社との競争力を示し、企業や利用者の満足度を向上できます。システム開発では、非機能要件への関心と重要度は高まっています。
本コラムを参考に、上質な非機能要件の定義を実現して下さい。
30秒で理解！フォローして『1日1記事』インプットしよう！
