非機能要件とは？機能要件との違いや6大項目をわかりやすく解説

非機能要件とは、システム開発における「機能以外のすべての要件」を指します。具体的には、可用性や拡張性、セキュリティといった項目です。本記事では、非機能要件の意味や機能要件との違い、IPAの6大項目や非機能要件を決める際のポイントなどについて詳しく解説します。

目次

開く

閉じる

1. 非機能要件とは
2. 非機能要件の6大項目
3. その他の非機能要件一覧
4. 非機能要件の評価指標
5. 非機能要件を決める際のポイント
6. ERPの開発にも非機能要件は重要
7. まとめ

非機能要件とは

システム開発における要件は、機能要件と非機能要件に分けられます。このうち、機能要件は、システムによって実現できる具体的な機能を意味します。例えば、システムによって処理が可能なデータの種類や処理内容に加え、アクセス制御なども機能要件に該当します。

対して、非機能要件とは、機能要件以外の全ての要件を意味します。非機能要件は具体的な機能ではなく、品質や性能といった抽象的な要件であり、拡張性・移行性・セキュリティなどが該当します。

機能要件との違い

機能要件と非機能要件を、わかりやすく言い換えると、機能要件とは、そのシステムによって何ができるかを意味する具体的な要件です。一方、非機能要件は、システムがどのように働くかを示す抽象的な要件であると言えます。

つまり、機能要件は顧客から求められている標準搭載すべき機能を指し、非機能要件は開発側が説明して初めて認識するような機能です。ただし、この非機能要件を高品質で届けることができれば、大きな顧客満足度の向上に繋がるため、決して見逃せないポイントです。

非機能要件の6大項目

非機能要件に該当するものは多数存在しますが、ここではIPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」の6大項目を非機能要件の6大項目とし、それぞれの概要について詳しく解説します。

参考：システム構築の上流工程強化（非機能要求グレード）紹介ページ｜独立行政法人 情報処理推進機構

＼気になる項目をクリックで詳細へジャンプ／

可用性

可用性は稼働率とも呼ばれ、システムが利用可能な状態を継続させる能力のことを指します。例えば、システムが連続稼働している時間に対し、システム障害やメンテナンスなどで動作が停止している時間の割合が低い場合は可用性が高いと言えます。

可用性には、システムの稼働率に加え、運用スケジュール・業務継続性・業務復旧などの項目が含まれます。また、システムの停止が必要となるバックアップの頻度・停止してから復旧にかかるまでの時間・非常時における障害耐性なども可用性の範囲です。

性能・拡張性

性能・拡張性には、性能要件と拡張性要件が含まれます。性能要件とはシステムの処理能力・レスポンスタイム・スループットなどを指します。また、拡張性要件によってシステムがどの程度の拡張に対応できるかどうかを表します。

そして、性能・拡張性の要件により、システムに備わっている性能や将来的な拡張性を定義します。これらを定める場合は具体的な目標値を設定し、処理速度の向上のために必要なハードウェアなどの配置を行います。

運用・保守性

運用・保守性とは、システムの運用や保守を行う上で必要となる要件を指します。システムに異常が発生した場合の対応に加え、障害監視システムやメンテナンスに関する事項などが該当します。

運用・保守性における要件定義は非常時の対応と密接な関わりがあるため、システムの構成に大きな影響を及ぼします。また、運用マニュアルや手順書に要件の内容を組み込む必要があります。

移行性

移行性とは現状のシステムから新しいシステムへの移行がしやすいかどうかを表す要件です。移行性には、移行方式やスケジュールの設定に加え、移行にかかるシステムの停止期間・移行データの種類・移行時の作業分担などが該当します。

移行性では、移行にかかる予定調整やクライアントへの周知に加え、移行の対象となる資産の提示やリハーサルの実施なども行われます。

セキュリティ

セキュリティとは、システムを使用する上でのセキュリティリスクを管理する要件です。リスクの分析・セキュリティ診断・セキュリティパッチなどの内容が含まれます。

また、不正アクセス対策としての認証機能やデータ暗号化、アクセス制限などについてもセキュリティの要件において検討が行われます。

環境・エコロジー 

環境・エコロジーとは、システムの構築や運用を行う際の制約条件、消費エネルギーについて定める項目です。システムが環境に及ぼす影響を考慮した内容が含まれており、消費電力・CO2排出量・耐震性能・騒音性についても検討する必要があります。

これらの内容にはコンプライアンスに関わるものも含まれるため、慎重な定義が必要となります。

その他の非機能要件一覧

前の章ではIPAによる「非機能要求グレード」の6大項目について取り上げましたが、日本情報システム・ユーザー協会がまとめた「非機能要求仕様定義ガイドライン」も非機能要件を把握する際の参考になります。

日本情報システム・ユーザー協会による項目は、以下の通り10項目です。

1. 機能性
2. 信頼性
3. 使用性
4. 効率性
5. 保守性
6. 移植性
7. 障害抑制性
8. 効果性
9. 運用性
10. 技術要件

参考：JUASライブラリー｜一般社団法人 日本情報システム・ユーザー協会

非機能要件の評価指標

非機能要件には、設計指標となる「RASIS」や、評価基準である「SLA」などの評価指標があります。抽象的な非機能要件においては、これらの指標に則った要件定義が求められます。ここでは、RASISとSLAについて解説します。

＼気になる項目をクリックで詳細へジャンプ／

RASIS

RASISとはコンピュータシステムに関する指標基準の一種です。RASISのアルファベットはそれぞれ以下の5つの項目の頭文字を示しており、各項目に指標が定められています。

1. Reliability：信頼性
2. Availability：可用性
3. Serviceability：保守性
4. Integrity：保全性
5. Security：安全性

SLA

SLAとは「Service Level Agreement」の頭文字を取った言葉で、サービスレベル契約という意味があります。これは、システムやサービスを提供するベンダーと顧客の間で締結される契約を指し、サービスレベルや保証の基準について明確に定めたものです。

SLAは、契約内容を明確化した条文のような役割を果たすため、可用性・応答時間・セキュリティの要件などに加え、免責事項やサービス障害発生時の損害賠償に関する内容も記載されます。

また、SLAを達成するための具体的な目標値として「SLO」という指標が用いられます。SLOは「Service Level Objects」の頭文字を取った言葉で、サービスレベル目標という意味を持つ用語です。

非機能要件を決める際のポイント

非機能要件は機能要件と同様に重要な要件定義です。非機能要件を決める際は、機能要件を明確に定め、開発側からの提案を行うことが重要です。

また、必要に応じて要件の取捨選択を行い、代替案を含めた複数の提案を用意することが望ましいでしょう。ここでは、これらのポイントを取り上げ、それぞれについて詳しく解説していきます。

＼気になる項目をクリックで詳細へジャンプ／

機能要件を明確にする

非機能要件を定義する際は、まず機能要件を明確に定めておかなければなりません。なぜなら、システム構築においては機能要件が必須項目となるため、機能要件を基に非機能要件のたたき台を作る方法が一般的だからです。

機能要件を中心に配置して非機能要件を組み立てることで、目標や必要な機能が明確になり、要件の優先順位を定めやすくなります。これにより、人員配置や予算などの割り当てを設定する作業がスムーズになる効果も見込めます。

機能要件には顧客が必要とする機能や要望が具体的に示されます。そのため、非機能要件を後から定義することによって、機能要件と非機能要件とのバランスを保つことができます。

開発側から提案する 

顧客がシステム開発について一定以上の知識を持っていない場合、非機能要件について意識しているケースは少ないです。また、非機能要件には潜在的・抽象的なニーズが多く含まれるため、顧客からの要望から非機能要件を汲み取ることは困難な場合があります。

このような背景から、非機能要件については開発側で情報を取りまとめ、提案という形で顧客に提示することが望ましいです。これによって、顧客が非機能要件に対して意識を向けるきっかけとなり、要件定義がスムーズになります。

複数の提案を用意する 

開発側から提示する要件はあくまで提案であり、最終決定権は顧客側にあります。その際、顧客の満足度を高めるためには、顧客にとってメリットのある提案を複数用意しておくことが効果的です。

提案を複数提示することによって、顧客は項目ごとの内容を比較検討し、それぞれのメリット・デメリットを事前に把握することができます。顧客の隠れたニーズを提案に反映させることで信頼が深まり、良好な関係性を構築する効果も見込めます。

要件は取捨選択する 

顧客からの要望を全て要件に反映させた場合、工数やコストが膨らんでしまう場合が多いです。よって、顧客要望の全てをそのまま取り入れるのではなく、要望によって叶えたい目的や、そのために必要となる要件の取捨選択を行いましょう。

さらに、顧客の要望に優先順位をつけ、どうしても外せない要件だけを選択してもらう方法も有効です。また、その際には丁寧なヒアリングを行うことで、別の要件で代替可能であることが判明する場合もあります。

視覚的に伝わりやすくする

非機能要件を顧客に伝えやすくするには、ただ文章でまとめるだけでなく、図や表を使って視覚的に伝わりやすくするのがおすすめです。非機能要件という言葉だけでも少し難しいため、さらに難しい用語を並べると、視聴者の頭に入りにくくなってしまいます。

そのため、非機能要件の中から顧客に選択して欲しい場合は、メリット・デメリットがわかりやすい図や表を作成し、それを見せながら言葉で補足する程度にしましょう。

また、訴求の方法はさまざまですが、高圧的な話し方は避け、正確な熱意が伝わりやすい訴求を心掛けることが大切です。

ERPの開発にも非機能要件は重要

ERPとは、経営資源であるヒト・モノ・カネの有効活用を支援するためのツールや考え方のことです。一般的には、ERPシステムのことを指す場合が多く、ERPによって基幹情報の一元管理が可能になり、これらの配分を適切に行うことができます。

ERPの開発においても、非機能要件は重要な役割を果たします。その理由は、ERPは企業全体の基幹業務に関わるシステムであり、不具合やシステム停止によって大きな損害が発生する場合があるからです。

つまり、ERP開発においては、システムの安定稼働や障害復旧に関わる非機能要件が非常に重要です。また、ERPは機能が多様で複雑な構造のものも多いため、機能要件と非機能要件のバランスを取りながら慎重に定義を行わなければなりません。

まとめ

システム開発における要件は、具体的な機能を定める機能要件と、品質や性能などを示す非機能要件とに分類されます。非機能要件はIPAによって6大項目が定められており、可用性・拡張性・保守性・移行性・エコロジーなどの項目に分類されます。

非機能要件は抽象的であることから、評価基準が曖昧になりやすいため、評価指標によって明確な要件を定めることが重要です。また、多くの顧客は機能要件に比べて非機能要件に対する意識が薄いため、顧客のニーズを汲み取り、積極的な提案を行うことが望ましいです。

顧客には複数の提案を提示し、費用対効果のバランスについても意識しましょう。特に、社内において重要な役割を担うERPの開発を行う際は、重要度の高い災害復旧やシステムの安定稼働といった項目に注意を払いながら、適切な非機能要件の定義を行いましょう。