• 作成日 : 2024年9月20日

非機能要件とは?機能要件との違いや定義すべき6大項目などを解説

非機能要件とは、システムの開発における「機能」以外の要件を指します。
システム開発では、システムが実現すべき事項を「要件」として定義します。要件は「機能要件」と「非機能要件」に分けられますが、機能要件は「システムができること」にフォーカスしている一方で、非機能要件は性能やセキュリティなどにフォーカスしている点が特徴です。どれほど優れた機能を持つシステムであっても、性能に問題がある場合、そのシステムは実際に運用できません。

本記事では、非機能要件の概要をはじめ、定義すべき6大項目や検証方法について解説します。

非機能要件とは

はじめに、非機能要件の概要や重要性について解説します。

非機能要件の概要

システム開発では要件定義工程において、システムが実現すべき事項を「要件」としてまとめます。要件は「機能要件」と「非機能要件」の2つに分けられるのが特徴です。

機能要件とは、その名前のとおりシステムの「機能」に関するものであり、非機能要件とは「機能」以外の要件を指します。具体的には、システムの品質や性能に関する事項が中心です。

機能要件との違い

機能要件は「システムができること」にフォーカスしていますが、非機能要件は性能やセキュリティなどにフォーカスしている点が異なります。

例えば、情報の登録・更新・削除・参照などは機能要件に分類されますが「機能の有無」がはっきりしているため、クライアント側も比較的イメージしやすいでしょう。
一方で「画面表示を1秒未満で行えること」や、「障害発生時に1時間以内で再稼働できること」などは非機能要件に分類されますが、システム発注側としてはややイメージがしづらいものが多いのが特徴です。

非機能要件は、システムの特性や発注者の要望などによって大きく異なります。また、システム発注側で定義することが難しいため、ベンダー側が主体となって決定していくことが求められます。

非機能要件の重要性

どれほど優れた機能を持つシステムであっても性能が著しく悪い場合、そのシステムは実運用に耐えられません。また、セキュリティ面に問題があるシステムも同様です。

ところが、多くのシステム開発において非機能要件は後回しにされがちです。しかし、非機能要件を疎かにした状態で開発を進めると、テスト工程やリリース後に問題が発覚するため、大きな手戻りが発生してしまいます。場合によってはリリースができない事態にも陥りかねません。

一方で、あらかじめ非機能要件をしっかり定義しておけば、システムの品質向上はもちろん、顧客満足度向上も実現可能です。

非機能要件で定義すべき6大項目

非機能要件は、主に6つの項目で構成されます。ここでは非機能要件で定義すべき6大項目について解説します。

可用性

可用性とは、システムを継続的に利用可能とするための要件を指します。

  • システムの稼働時間
  • 計画停止
  • 業務停止時や大規模災害発生時の復旧水準(何を、どこまで、どの程度復旧できるか)
  • 稼働率

性能・拡張性

性能・拡張性とは、システムの処理性能や拡張しやすさに関する要件を指します。

  • 業務処理量 (ユーザー数、同時アクセス数、データ数、処理件数など)
  • ピーク時の増大率
  • 性能目標
  • リソース拡張性 (CPUやメモリなど)

運用・保守性

運用・保守性とは、システムリリース後の運用や保守に関する要件を指します。

  • システム運用時間
  • バックアップ計画 (対象範囲、自動化範囲、取得間隔、保存期間)
  • 運用監視 (監視情報、監視間隔)
  • 保守運用 (計画停止有無、保守作業自動化範囲)
  • 運用環境 (開発環境の構築有無、試験用環境の構築有無、マニュアル準備範囲)
  • サポート体制 (保守契約、ライフサイクル期間)
  • 内部統制対応
  • サービスデスク設置有無

移行性

移行性とは、現行システムから新システムへの移行に関する要件を指します。

  • 移行スケジュール (移行期間、システム停止可能日時、並行稼働有無)
  • 移行方式
  • 移行対象 (移行データ量、移行データ形式)

セキュリティ

セキュリティとは、システムのセキュリティに関する要件を指します。

  • 順守すべき情報セキュリティに関するガイドラインや社内規定の有無
  • セキュリティリスク分析
  • セキュリティ診断 (ネットワーク診断実施有無、Web診断実施有無)
  • データの秘匿 (伝送データの暗号化有無、蓄積データの暗号化有無)
  • 不正監視
  • マルウェア対策

システム環境・エコロジー

システム環境・エコロジーとは、システムを設置する環境や環境負荷などに関する要件を指します。

  • 構築および運用時の制約条件
  • 適合規格の取得有無

非機能要件の定義方法

ここでは非機能要件の定義方法について解説します。

ステップ1.システムの特性や機能を整理・決定する

非機能要件はシステム特性や機能によって大きく異なります。同様の機能を持つシステムであっても「社内でのみ利用されるシステム」と「社会的に広く利用されるシステム」の非機能要件は全く異なるのです。

一般的に非機能要件を高い基準に設定するほどコストがかかるため、まずはシステム特性や機能要件の整理が重要です。

ステップ2.ベンダー側で非機能要件の案を作成する

機能要件と異なり非機能要件はイメージしにくいため、発注側のみでは要件定義がうまく進まないことが多々あります。そのため、開発ベンダー側に素案を作成してもらい、素案をもとに個々の項目を議論したほうがスムーズに定義可能です。

また、非機能要件の検討はIPA(独立行政法人情報処理推進機構)やJUAS(一般社団法人日本情報システム・ユーザー協会)などが公開しているガイドラインなどをベースにすれば抜け漏れを防げるため、非機能要件を網羅的に定義できます。

参考: IPA「非機能要求グレード2018
    JUAS「非機能要求仕様定義ガイドライン

ステップ3.合意形成を図る

最後に開発ベンダーから提示された案を確認し、問題なければ合意となります。なお、合意した非機能要件は、要件定義書にまとめておくことが重要です。

非機能要件の評価指標

非機能要件は目に見えにくいものが多いですが、これを評価するための指標が存在します。ここでは主な評価指標を紹介します。

RASIS

RASISはシステム全般の評価指標であり、下記項目の頭文字をとった単語です。

項目名概要
Reliability:信頼性障害・不具合によるシステム停止・性能劣化の発生しにくさを表す。
Availability:可用性稼働率の高さや障害・保守による停止時間の短さを表す。
Serviceability:保守性障害からの復旧およびメンテナンスのしやすさを表す。
Integrity:保全性過負荷や障害をはじめ、データの壊れにくさを表す。
Security:安全性攻撃者やマルウェアなどに対する耐性を表す。

SLA/SLO

SLAは「Service Level Agreement」の略語であり、開発(サービス提供)ベンダーとクライアント間で締結される契約です。SLAでは、可用性やセキュリティなどをはじめ、障害発生時の損害賠償などを定義します。

また、SLOは「Service Level Objective」の略語であり、SLAを履行するためのパフォーマンス目標値をサーバーやネットワークごとに表したものです。

非機能要件のテスト方法

非機能要件を満たしているかを確認するためには、各種のテストを行う必要があります。主なテストの種類は次のとおりです。

テスト種類概要
性能テスト処理速度や処理量などを確認する。
負荷テスト大量アクセス/大量データなどが発生した場合の性能を確認する。
セキュリティテストシステムが攻撃や脅威に対する耐性を有しているかを確認する。
ユーザビリティテストユーザーの操作性に問題がないかを確認する。
保守性テストシステムの保守性に問題がないかを確認する。

まとめ

非機能要件とは、システムの品質や性能をはじめ、セキュリティなど「機能そのもの」以外に該当するものを指します。
機能要件と比較すると非機能要件は後回しにされがちですが、テストやリリース後に問題が発覚すると、大きな手戻りが発生したりユーザー満足度が著しく低下する恐れがあるため、注意が必要です。

非機能要件の対象範囲は広くイメージしづらいものが多いですが、前述のIPAやJUASが公開しているガイドラインなどを活用して漏れなく定義しましょう。


※ 掲載している情報は記事更新時点のものです。

※本サイトは、法律的またはその他のアドバイスの提供を目的としたものではありません。当社は本サイトの記載内容(テンプレートを含む)の正確性、妥当性の確保に努めておりますが、ご利用にあたっては、個別の事情を適宜専門家にご相談いただくなど、ご自身の判断でご利用ください。

お役立ち資料

関連記事