QbookジャーナルQBOOK JOURNAL

クライアントの満足度に関わる「非機能要件」の重要性

最終更新日時:2020.05.29 (公開日:2018.08.06)

クライアントの満足度に関わる「非機能要件」の重要性

ソフトウェア開発は、クライアントが要求する機能を、要件定義書等で定義し、それに合わせて設計・実装していきます。しかし、クライアントが要求する機能は最低限必要な事項であり、クライアントの満足度を高めるためには、ユーザビリティなどに関わる「非機能要件」も考慮する必要があります。
今回は、クライアントの満足度に関わる非機能要件の重要性についてご紹介します。

機能要件と非機能要件の違い

8607-00015-02

機能要件は、ソフトウェアで定義される要件のうち、機能に関するものを言います。
例えば、社員名簿の管理システムの場合、「社員番号で検索することができる」「社員の写真を一覧画面に表示できる」といった、ソフトウェアの処理内容や画面表示などの最低限実装されていなければならないものを指します。
非機能要件とは、ソフトウェアの使いやすさ・性能・信頼性・拡張性・運用性・セキュリティなどといった、機能以外の要件です。非機能要件はユーザーの満足度に大きく影響するため、機能要件とともに重要なポイントとなります。

非機能要求グレード6つのカテゴリ

機能要件(および非機能要件)は、ソフトウェアをどのように設計すべきか、という開発者の視点に基づいた概念です。一方、クライアントがソフトウェアを利用して達成したいこと・実現したいことを具体化したものを機能要求(および非機能要求)と呼びます。機能要件は機能要求をもとに、非機能要件は非機能要求をもとに整理していくことになります。

非機能要求については、様々な団体や、研究者による定義が存在します。日本では、独立行政法人情報処理推進機構(IPA)が「非機能要求グレード2018」を2018年4月に公開しており、この中で非機能要求は6つのカテゴリに分類されています。本稿では、それをご紹介いたします。

【1】可用性

システムサービスを継続的に利用可能とするための要求です。
例えば、稼働時間・メンテナンス予定などの運用スケジュールがクライアントの利用に支障を及ぼさないことや、障害が発生した際の復旧手順・スケジュールが事前に用意され、復旧日数が許容できる長さであること、などが可用性の観点の要求にあたります。

【2】性能・拡張性

システムの性能と将来のシステム拡張に関する要求です。
具体的には、今後の機能追加の可能性を考慮した設計になっているか、同時に利用するクライアント数やデータ負荷に耐えられるか、などの観点が挙げられます。

【3】運用・保守性

システムの運用と保守のサービスに関する要求です。
例えば、ソフトウェアの利用目的に合わせて稼働時間を確保できていることや、データのバックアップを適切な形式・頻度で取れていること、運用時の役割分担や手順のマニュアル化などがこれに該当します。

【4】移行性

現行システム資産の移行に関する要求です。
例としては、旧システムの資産であるマスターデータやトランザクションデータを新システムへ安全に移行できるか、移行する場合の負担はどの程度か、などの観点が考えられます。

【5】セキュリティ

情報システムの安全性の確保に関する要求です。
例えば、機密性の高い情報へのアクセスには利用制限がかけられているか、不正なアクセスをブロックできているか、といった面をクリアするための観点です。

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

システムの設置環境やエコロジーに関する要求です。
例としては、サーバーの設置環境が免震・耐震されているか、機材を故障させないための温度・湿度の管理ができているか、エネルギー面で環境に配慮できているか、などといった観点があります。

クライアント視点から要求の実現レベルを見える化するため、段階的に各項目を詳細化しながら「早期に」「誤解なく」「漏らさずに」確認できるようにします。
上記を整理できたら、非機能要件の整理と非機能要件テストの実行に移っていきましょう。

クライアントの満足度を高めるのは「非機能要件」

機能要件はクライアントへのヒアリングなどを通して明確になってきますが、非機能要件に関してはクライアントが意識していない部分もあるため、定義漏れが発生する可能性があります。ヒアリング内容と併せて、上記で解説した6つのカテゴリの観点からも、あわせて分析・要件定義を行うことが重要です。

非機能テストで非機能要件を確認しよう

8607-00015-03

非機能テストとは、非機能要件を備えたソフトウェアになっているかどうかを確認するためのテストです。代表的な非機能テストとして、以下の5つが挙げられます。

性能テスト

実際の利用状況を想定・再現した環境でソフトウェアを動かし、要件に沿って意図通りに動くことを確認するテストです。ここでは主に、時間当たりの処理量や速度、応答時間やメモリの消費具合などのパフォーマンスを確認します。

ストレステスト

ソフトウェアが実際のデータ量やアクセス数に耐えうる構造になっているか確認するテストです。通常時想定のデータ量はもちろん、突発的にアクセスが集中した場合などの異常な状況下で、システムがダウンするなど、クライアントのシステム利用に支障がないかどうかをチェックします。

ユーザビリティテスト

ソフトウェアがクライアントにとって使いやすいか、分かりやすい操作性になっているかどうかを確認するテストです。具体的には、画面の表示や配置を見たとき、クライアントがやりたいことをできるかどうか、直感的に操作できるか、などの観点でテストを行います。

保守性テスト

ソフトウェアを長期的に運用していく中で、維持・管理がしやすいかどうかを確認するためのテストです。具体的には、機能の改修や不具合の検知がしやすい構造になっているか、コードの修正・拡張がしやすいかなどの観点が挙げられます。

セキュリティテスト

ソフトウェアが、悪意のある外部からの攻撃に対して、脆弱な部分がないか、重要情報の流失などの運用上のリスクがないかをテストします。「ペネトレーションテスト」「脆弱性診断」とも呼ばれています。

おわりに

今回はクライアントの満足度に関わる、非機能要件について一般的な内容をご紹介しました。
機能要件に定義されている機能は、クライアントからすれば実装されていて当たり前のものであるため、クライアントが意識していないニーズを掘り起こし、非機能要件を適切に定義することが満足度を向上させる鍵となります。非機能要件が満たされているかを確認する際には、今回ご紹介した非機能テストを取り入れてみてください。

資料ダウンロード

執筆者:Qbook編集部

ライター

バルテス株式会社 Qbook編集部。 ソフトウェアテストや品質向上に関する記事を執筆しています。