はじめに

非機能要件とは、ソフトウェア開発の分野で働く人々の間では非常によく知られている言葉です。そこで、この記事では非機能要件とは何か、そして、システムを構築する上でなぜ重要なのかについて、その定義やシステム要件などと合わせてご説明します。

定義と分類

① 非機能要件とは

非機能要件は機能要件とは異なり、ソフトウェアシステムの品質を向上させるために役に立つ一連の属性です。動作（ソリューションの機能）に直接関係するものではありませんが、システムがスムーズかつ安定的に稼働するために欠かせない品質を支える要件であると言えます。製品は運用に移る前に使用目的を満たしているだけではなく、ユーザーエクスペリエンスの点でも優れている必要がありますが、これらを裏で支えているのが非機能要件なのです。

② 非機能要件の重要性

ユーザーは応答性、使いやすさ、システムセキュリティ、移植性、データの整合性などの要素を通じてソフトウェアの品質を評価するため、非機能要件は近年ますます重要になりつつあります。なぜなら、現在のソフトウェア開発プロセスにおいては、現在そして将来にわたって使用可能なソフトウェアを開発するだけではユーザーを満足させることは難しくなっているからです。

実際の開発では動くソフトウェアを開発することに加え、さまざまなユーザーの期待（ページの読み込み時間の短縮、使いやすい機能、セキュリティへの対応など）に応じた要件が求められています。つまり、顧客から高い評価を獲得するためには、顧客が望む非機能要件を正しく理解し、それらに適切に配慮した開発を行うことが欠かせません。これにより、顧客の当初の期待どおりの（さらには顧客の期待値を上回る）ソリューションを開発することが可能になります。

③ 非機能要件の分類

ソフトウェア開発分析において一般的に見られる非機能要件の種類を以下にいくつかご紹介します。

l セキュリティ (Security）

セキュリティはシステムを使用する（システムへのアクセスから、操作、ログアウトまで）際に関係する保守性要件です。セキュリティが保証できないシステムはユーザーに深刻な影響を及ぼします。

例：ユーザーが間違ったパスワードを5回続けて入力すると、システムは30分間非アクティブになる。

l パフォーマンス (Performance）

パフォーマンスの問題は、最初は表面化しにくいものの、顧客が実際に製品使用時のパフォーマンス低下を体験した場合、不満として表れやすくなります。パフォーマンスは次の基準で測定されます。

•トランザクションの応答時間

•1秒あたりに実行されたトランザクション数

•容量（システムが各オブジェクトに対して保存/実行できるトランザクション数）

•RAM、DB容量など使用リソースに関する要素

l ユーザビリティ (Usability）

ユーザビリティは最も重要な非機能要件の1つです。要するに、システムの「使いやすさ」に該当し、次の5つの要素が含まれています。

•有効性（Effectiveness）

•能率性（Efficiency）

•エンゲージメント（Engagement）

•エラー耐性（Error Tolerance）

•習得しやすさ（Easy to learn）

ユーザビリティ要件を明確にすることで、ユーザーはソフトウェアによりアクセスしやすくなります。

l インテグリティ (Integrity）

インテグリティはデータの正確性と信頼性を指します。多くのソースから収集したデータを組み合わせた複雑な数式の場合には、システムが誤って計算を実行する可能性があります。しかし、顧客にとっては、データが常に正しく計算されることが最も重要な要件であることは言うまでもありません。

たとえば、システムに入力されたデータAから結果A'、A"→B、C、D、D'→最終結果Fという順序で出力されるとします。このとき、データAを処理して最終的な「F」データを生成するプロセスでは、システムが同期および非同期なバッチを実行しています。

インテグリティ（整合性）があるということは、データが常に正しく計算されることを意味します。今回は正しくても、次回のデータ出力において間違いが発生するということは、インテグリティが無いと言えます。

l アベイラビリティ (Availability）

アベイラビリティ（可用性）はシステムの使用可能性の要件であり、次の2つの要素で構成されます。

•システム使用可能時間

例：システムは24時間年中無休の運用を保証する必要があります。アップグレードは最大で3か月以内に1回、1年あたりのダウンタイムは1時間を超えてはなりません。

•システム操作の依存要因

例：システムが第三者によって構築された「Add-on」またはアプリケーションをインストールしている場合、当システムは24時間年中無休で運用を保証し、第三者の製品のダウンタイムに依存しないようにする必要があります。

l 監査 (Audit）

監査はシステムで実行されたタスクを記録する機能の要件です。その目的は統計・レポートではなく、データが正しく実行されているかを検査することにあります。

監査されたデータはシステムのメインデータベースとは別のデータベースに保存され、毎日バックアップされ、30日間有効にする必要があります。

監査対象のデータは読み取り専用で、ユーザーインターフェイスから編集することはできません。

l 外部インターフェース (External Interface）

外部インターフェースは構築中のシステムのコンポーネントを他のシステムのコンポーネントと統合する方法に関する要件です。

統合はどのプロジェクトでも非常に重要であるため、統合要件の説明はドキュメント内の別のセクションによく分けられます。このセクションではシステム間のデータ交換（交換対象コンポーネント、目的、変更の頻度、操作ユーザーの数などが含み）の概要について説明します。

l ユーザーインターフェイス (User Interface）

ユーザーインターフェイスはユーザビリティと名前が似ているため、混同しやすいかもしれません。

しかし、ユーザビリティには、「使いやすさ」という広い意味があります。これは、UIの改善、データ構造の変更、さらにはシステム内のデータの流れの変更を意味する場合があります。

一方ユーザーインターフェイスはユーザーが必要とするUIの要件を指し、次のものが含まれます。

•UI構造

•警告とエラーメッセージ

•その他の要件

例：システムのデータ削除操作に対しては確認モーダルが必ず表示される。

l データ移行 (Migration）

データ移行は旧システムから新システム（または旧環境から新環境）へのデータの移行を規制する非機能要件です。

通常、データ移行は次の場合で展開されます。

•サーバーまたはデータストレージデバイスを交換またはアップグレードする。

•ウェブサイトを統合します。

•サーバーのメンテナンス。

•データセンター移転。

l サポート性 (Supportability）

サポート性はシステムが正常に動作する環境/プラットフォームの要件です。

プラットフォーム (Windows、iOS、Android)、バージョン、Ram に関する情報など、システムが適切に動作する環境に関する情報を明確にする必要があります。

システムをサポートしていない環境では、レイアウトが崩れたり、プロセスが正しく実行されなかったりする可能性があります。

l コンプライアンス (Compliance）

コンプライアンスは法律、規制、会社法、金融法、土地法、環境法、児童保護法、希少動物などの規定を確実に遵守するための要件です。

このコンプライアンスでは、通常として国際決済機関の規制、海事規制、海上輸送など、最も一般的な規制について説明します。

l 柔軟性 (Flexibility）

柔軟性はシステムの適応性の要件であり、あらゆる環境（組織、領域、業界など）に適応できることを指します。

例：ERP製品を利用しよう顧客が世界中に5つの拠点 (日本、ベトナム、ラオス、カンボジア、モンゴル) を持っています。このERP製品は日本で適応できれば、他の拠点でもスムーズに利用できることです。

l スケーラビリティ (Scalability）

スケーラビリティはシステムにおける拡張可能性を指し、システムが将来的にどれだけ柔軟にスケールアップ可能かどうかを表した詳細な要件です。

例：既存のEコマースサイトでは、システムが一度に500件の注文を処理できるようにバックエンドを設計する方法は多数あります。ただし、顧客が2年間の運用後にスケールアップする機能を必要とする場合には、バックエンドを別の方法で設計する必要があります。

この非機能要件では、将来のスケールアップに関する詳細な要件を書き留めます。

具体的な例:

-サーバーの構成アップグレード機能。

-別のサーバーにDBを分離し、別のサーバーにバックエンドを分離する機能。

- HA Proxyを使用して実行されるロードバランサーを適用する機能。

- DBマスターをサブDBに分割して同期する機能。

l 拡張性 (Extensibility）

拡張性はソリューションの拡張性を意味します。つまり、旧機能に悪影響を与えることなく新機能を開発することを可能にした要件となります。下記が代表な例です。

•旧データ構造を変更せずに小売チャネル向けのマーケティングコスト管理モジュールをさらに開発する機能。

•旧データ構造を変更せずに在庫管理機能を開発する機能。

l ローカリゼーション (Localization）

ローカリゼーションはソリューションのローカリティについての要件です。具体的には以下に関連した要件が該当します。

•現地の言語

•地域の法律

•現地通貨

•文化

•エンドユーザーの特性　など

その中に、法律の要件が一番大切なことです。例としては、法律および会計に関連する文書・会計帳簿がまったく同じではないため、ベトナムでの企業向け会計モジュールの導入は、日本での企業向けの実装とはまったく異なります。

l 購入コンポーネント (Purchased Component）

購入コンポーネントは、使用時に支払いが必要となるシステムのコンポーネント（機能と制限含み）に関する要件です。この非機能要件についてはコンポーネントの機能、制限、既存のバージョンへの適応性、アップグレード方法などに注意することが必要です。

l 保守性 (Maintainability）

保守性はシステムの保守性についての要件です。つまり、バグが発生した場合、管理者がその理由を簡単に知ることができ、すぐに修正する方法を理解できるかなどの要件が含まれます。

そのためには、コーディング、モジュール・機能ごとに明確な規則やドキュメント化が必要になります。

保守性要件のいくつかの例：

•四半期ごとのシステムアップグレードは30分以上続きません。

•すべてのJavascriptおよび.NETコードはABCXYZのコーディング規則に従って作成する必要があります。

l 安全性 (Safety）

安全性はシステム使用時に環境または人間の健康を害しないシステムであるかどうかに関する要件です。

病院の健康診断および治療管理システムの場合は、処方箋を印刷して患者に送信する前、医師が確認画面の[承認]ボタンを押す必要があります。

なぜなら、医師の承認なしで看護師などによって発行された処方箋によって、何か人間の健康に影響を及ぼす可能性のあるエラーが引き起こされた場合、それは極めて重大な問題となり得ます。

l 法律・コピーライト (Legal and Copyright）

法律・コピーライトは必要な法的手続き、ワードマーク・商標・または顧客のロゴを正しく使用する方法などに関する規制を定めた要件です。

例:ABC社によって作成された製品または添付ファイルに関連するすべての知的財産権(IPR) は、サービスパッケージの結果で、当社が所有します。

顧客のロゴを使用する時、ロゴがフレーム、パレット、サイズ、背景色など正しく使用されていることが必要です。

l インストール可能性 (Install Ability）

インストール可能性についての非機能要件はフレッシュインストール、再インストール、アップグレード、およびアンインストールを含むインストールプロセスの要件を指します。

例：システムインストールは、C#および関連ライブラリの経験が3年以上あるお客様のソフトウェア開発パートナーまたはシステム管理者が行う必要があります。

プラグインのアップグレードによってシステムのデータとデータ構造が変更されません。

l アクセシビリティ (Accessibility）

アクセシビリティはあらゆるユーザー（特に視覚や聴覚などに障害を持つユーザーなど）がシステムを使用できるようサポートする能力に関する要件です。例：Eラーニングシステムは、聴覚障害者向けのAUDIOバージョンの隣にあるTEXTバージョンのコースをサポートしています。また、視覚障害者の向けに音声制御をサポートしています。