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

最終更新日時:2021.11.11 (公開日:2018.08.06)
クライアントの満足度に関わる「非機能要件」の重要性

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

今回は、クライアントの満足度に関わる非機能要件の重要性についてご紹介します。

非機能要件とは

非機能要件とは文字通り、機能面以外の要求全般のことです

顕在的な要求ではなく、潜在的な要求といえるでしょう。

例えば「自社の商品を簡単に購入できる機能がほしい」というのが機能要件で、「画面表示までの待ち時間は3秒」「多くのユーザーが一度にアクセスしても、サーバーダウンしないようにする」など、性能やセキュリティ、運用性などに関する要求を指します。

非機能要件を満たさなければ、機能要件が十分でも良いシステム開発ができない可能性があります。

機能要件だけでなく、非機能要件の定義もしっかりと行わなければなりません。

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

8607-00015-02

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

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

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

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

【1】可用性

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

【2】性能・拡張性

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

【3】運用・保守性

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

【4】移行性

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

【5】セキュリティ

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

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

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

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

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

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

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

8607-00015-03

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

性能テスト

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

ストレステスト

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

ユーザビリティテスト

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

保守性テスト

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

セキュリティテスト

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

おわりに

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

資料ダウンロード

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

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

非機能要件とは

非機能要件とは文字通り、機能面以外の要求全般のことです

顕在的な要求ではなく、潜在的な要求といえるでしょう。

例えば「自社の商品を簡単に購入できる機能がほしい」というのが機能要件で、「画面表示までの待ち時間は3秒」「多くのユーザーが一度にアクセスしても、サーバーダウンしないようにする」など、性能やセキュリティ、運用性などに関する要求を指します。

非機能要件を満たさなければ、機能要件が十分でも良いシステム開発ができない可能性があります。

機能要件だけでなく、非機能要件の定義もしっかりと行わなければなりません。

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

クライアントの要求は、大きく二つに分類できます。

クライアントの要求には顕在的な要求と潜在的な要求があり、どちらも実現することがシステム開発では大切です。

「こういう機能がほしい」という要求のなかには、さらに細かな「こういう場合はこうしてほしい」という要求が隠れています。

この細かな要求を定義するのが、非機能要件です。

機能要件と非機能要件のそれぞれの違いについて、詳しくご説明します。

8607-00015-02

機能要件

機能要件とは、前述の通りクライアントの顕在的な要求でのことです。

大企業や大規模な開発を依頼するクライアントの場合は提案依頼書などを作成し、まとまった要求を提示してもらえる場合もあります。

しかし小規模の開発や中小企業の場合は、丁寧にヒアリングをして、クライアントの要求を引き出さなければなりません。

ここで引き出した要求は、目に見える部分の機能についての要求が多いです。

自発的に性能やセキュリティ面、運用性などについての要求を伝えてくれるクライアントは、少ない傾向にあります。

目に見える顕在的な要求は設計を行う上では大切な情報ですが、表向きの要求に隠れた潜在的な要求を引き出すことで、よりよいシステム開発が可能なのです。

非機能要件

クライアントの潜在的な要求である非機能要件とは、前述した通り「機能要件以外の要件」です。

「自社の商品を簡単に購入できる機能がほしい」という要求をもとにシステム開発をしても、画面表示に時間がかかったりすぐにサーバーダウンしたりしてしまうシステムであれば、クライアントの満足度は低くなるでしょう。

明示的な機能以外に、性能やセキュリティ面、運用性などを叶えたシステム開発であれば、逆に満足度を上げられるはずです。

非機能要件は「画面表示までの待ち時間は3秒」「多くのユーザーが一度にアクセスしても、サーバーダウンしないようにする」などのような、クライアントが「搭載していて当然の機能」だと思っている要件であり、システム開発には必要な芯の部分であるといえるでしょう。

そのため目に見える機能要件だけではなく、その裏に隠れた非機能要件をクライアントから引き出すことが、プロジェクトの成功へとつながります。

<h2class="cf">非機能要求グレードの6大項目

機能要件(および非機能要件)は、ソフトウェアをどのように設計すべきか、という開発者の視点に基づいた概念です。

一方、クライアントがソフトウェアを利用して達成したいこと・実現したいことを具体化したものを機能要求(および非機能要求)と呼びます。機能要件は機能要求をもとに、非機能要件は非機能要求をもとに整理していきます。

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

【1】可用性

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

【2】性能・拡張性

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

【3】運用・保守性

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

【4】移行性

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

【5】セキュリティ

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

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

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

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

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

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

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

8607-00015-03

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

性能テスト

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

ストレステスト

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

ユーザビリティテスト

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

保守性テスト

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

セキュリティテスト

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

非機能要件の書き方

機能要件と同じように、非機能要件はシステム開発の上流工程である「要件定義」のはじめの段階で洗い出します。

目に見える部分の機能要件と比べ、目に見えない潜在的な非機能要件の検討は難易度が高いといえます。

その理由はクライアント自身が非機能要求について意識しておらず、クライアントをヒアリングしながら引き出していかなければならないからです。

非機能要件の書き方の手順は以下の通りです。

・一覧表の仮作成

・要件の確認

・非機能要件を選定

上記のそれぞれの項目について、詳しくご紹介します。

一覧表の仮作成

非機能要件を設定する前提として、機能要件の検討が完了している必要があります。

機能要件で選定した機能自体が変更になった場合、求められる潜在的な非機能要件も大きく変わる可能性があるからです。

機能要件の検討が完了したら、まずは非機能要件を洗い出します。

しかし前述した通りクライアントは非機能要求を意識していないことが多く、直接聞いても何も得られない可能性が高いです。

そのため非機能要件の一覧を仮作成します。

機能要件をもとに、性能やセキュリティ面、運用性などを考慮しながら分類し、開発するシステムに合わせて仮作成を行いましょう。

非機能要件の一覧作成には、下記を参考にするとよいでしょう。

モデルシステム

・社会的影響がほとんど無いシステム

・社会的影響が限定されるシステム

・社会的影響が極めて大きいシステム

可用性の継続性レベル

レベル1:定時内(9時~17時)

レベル2:夜間のみ停止(9時~21時)

レベル3:1時間程度の停止(9時~翌8時)

レベル4:若干の停止あり(9時~翌8:55)

レベル5:24時間無停止

参考:IPA「非機能要件グレード」https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html

要件の確認

非機能要件の一覧仮作成が完了したあとは、クライアントに適切な要件を確認する必要があります。

このように提示することで、「システムはこの時間帯に可動を停止してほしい」「サイト内の検索では3秒以内に検索を完了させたい」などのような、具体的な要求が出てくるでしょう。

注意点としては、潜在的な要求をなぜそうしたいのか、理由をきちんと把握することです。

そうしないと、クライアントの要求を採用するしか方法はなく、代替案を提示できません。

また、クライアントがその場の思いつきで「こういう機能にしたい」と回答する場合もあるため、根拠をしっかりと確認しておくことが重要です。

非機能要件を選定

非機能要求の確認をクライアントと行った後は、実際に要件を選定します

ここでは、クライアントの要求をすべて採用すれば良いというわけではありません。

非機能要求の実現の程度に応じて、コストの増減が出てくるからです。

例えば24時間停止する時間がなくフル稼働のシステムと、9時~17時のみ稼働するシステムであれば、当然24時間フル稼働のシステムのほうがコストはかかります。

品質が良いものの方が良いと考えるのは当たり前のことですが、非機能要求を満たせば満たすほどコストがかかってしまうことをクライアントに理解してもらわなければなりません。

その上で、非機能要件の選定を行います。

おわりに

今回はクライアントの満足度に関わる、非機能要件について一般的な内容をご紹介しました。

機能要件に定義されている機能は、クライアントからすれば実装されていて当たり前のものであるため、クライアントが意識していないニーズを掘り起こし、非機能要件を適切に定義することが満足度を向上させる鍵となのです。

クライアントからは出にくい非機能要求を引き出すために、非機能要件を定義する際には一覧を仮作成してから確認をするようにしましょう。

要件に応じてかかるコストも変わるため、非機能要求の充実に伴いコストが上がることを理解してもらった上で、非機能要件を選定することが重要です。

非機能要件が満たされているかを確認する際には、今回ご紹介した非機能テストを取り入れてみてください

資料ダウンロード

執筆者:Qbook編集部

ライター

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