非機能要件の定義の際に重要な6つの項目とは？機能要件との違いも解説

非機能要件とは？

システム開発において、機能案件とはクライアントからニーズをヒアリングし、システムに組み込むための機能を定義することです。非機能要件は機能案件とは反対に、クライアントから希望された機能ではない要件のことを指します。

具体的には、システムを設計する際に必要な性能やセキュリティに関して実現するべき要件が非機能要件に該当します。

ソフトウェア開発の種類

ソフトウェア開発やシステム開発において、一般的に最初に行われる工程が要件定義です。また、要件定義の中でもクライアントから求められる機能を定義することを「機能要件」、機能要件に当てはまらないものを「非機能要件」と呼びます。

ここでは、ソフトウェア開発の種類である機能要件と非機能要件についてそれぞれ解説していきます。

「機能要件」は顧客の要望をかなえるもの

機能要件とは、ソフトウェア開発においてクライアントから求められている「必ず実装するべき機能」のことを指します。機能要件はクライアントから希望されている機能であるため、非常に重要な機能と言えます。

また、機能要件はヒアリングの際にクライアントから直接聞き取ることができるため、どのような要件があるのか抽出しやすいです。機能要件はそのソフトウェアに必要な機能であるため、機能要件が満たされていない場合はプロジェクト自体が失敗となってしまいます。

「非機能要件」は顧客の要望以外の副次的なもの

非機能要件とは、前述の機能要件に当てはまるもの以外の機能を指します。ソフトウェア開発の主な目的以外の機能のことで、そのソフトウェアの性能やユーザビリティ、セキュリティといったソフトウェアの質を左右する副次的な部分となります。

非機能要件はクライアントから希望ではありませんが、品質の高い非機能要件を定めることで、クライアントの満足度向上につながります。

非機能要件の定義の際に重要な6つの項目とは？

非機能要件の内容は非常に多岐にわたるため、すべてを網羅することは難しいでしょう。

非機能要件の項目を大きく分けると、「移行性」「システム環境・エコロジー」「セキュリティ」「性能・拡張性」「可用性」「運用・保守性」という6つの分野に分けることができます。

ここでは、非機能要件の定義の際に重要な6つの項目について解説していきます。

1：移行性

移行性とは、既存の旧システムから新しいシステムへの移行に関する要件のことです。主にシステム移行の方法や移行中のシステム停止期間、具体的な移行計画、トラブル発生時の対処法などについて目標を設定します。

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

システム環境・エコロジーとは、システム開発の際の制約となる法令の有無や、システムの利用人数、拠点数、システムを利用するために必要なハードウェアの制限事項などに関する要件のことです。

また、システムを運用することによって、労働環境や自然環境などに与える影響についても検討する必要があります。システム構築に法令や条例などが関係する場合は、プロジェクト自体に大きな影響を与える内容となります。

3：セキュリティ

セキュリティとは、システムの安全性に関する要件のことです。システム運営上でのリスク管理にも関係しています。

具体的には、データ暗号化の方法やシステムへの不正アクセスを防止するための認証機能や機能制限、不正を監視するためのログの保存期間といった内容について検討し、取り決めを行います。

4：性能・拡張性

性能・拡張性とは、システムそのもののパフォーマンスと、将来的にシステムの性能を拡張できるかどうかという要件のことです。性能面では、システムが利用できるデータ量や処理速度がクライアントの現在の業務量に対応できるか否かなどを検討します。

拡張性の面では、今後クライアントの事業の変化などによって業務量が増えた場合、作業のパフォーマンスを落とさずに増強できるかといった点を検討します。

5：可用性

可用性とは、システムの稼働率がどの程度であれば許容できるのかという要件のことです。可用性とはシステムが継続して稼働し続けられる能力を指す言葉で、システムが稼働している時間と、システムが停止してから復旧にかかる時間の割合が可用性となります。

たとえば可用性が99.99%の場合、1,000時間の稼働の中でシステムが停止する時間は1時間以内であるという意味です。

6：運用・保守性

運用・保守性とは、システム運用の時間帯や運用・保守するために必要な監視の仕組み、バックアップするデータの範囲といった要件のことです。システムを運用していくため必要となる要素について検討していきます。

また、システムを保守するために必要な保守計画や、システムに異常が発生した場合の対応についても検討します。運用・保守性はBCPにも関連する要素であるため、検討する際には慎重に検討すべき項目です。

＞＞ システム運用と保守とは？それぞれの仕事内容など違いについて徹底解説！

非機能要件を数値化するための3つの指標

ここまで紹介してきたとおり、非機能要件では幅広い内容を扱うため、非機能要件を設計する際には具体的にどのような数値で表せばよいのか迷うケースも多いでしょう。そのような場合、「SLA」「RASIS」「SLO」といった指標が重要です。

ここでは非機能要件を数値化するための3つの指標について解説していきますので、参考にしてみてください。

1：サービスレベル契約「SLA」

SLAは、Service Level Agreement（サービスレベル契約）の頭文字を取ったものです。

SLAはサービスの提供元であるベンダーと契約者の間で取り交わされるもので、ベンダーがどのような内容のサービスをどのような性能基準で、どのようなレベルまで保証するのかといった内容を明らかにしたものです。

SLAでは可用性とアップタイム、応答時間、あらゆるレベルの問題に対してヘルプデスクが返答を行うまでの時間、性能のベンチマーク値などについて記載されます。

2：コンピュータサービス全般の指標「RASIS」

RASISは、Reliability（信頼性）、Availability（可用性）、Serviceability（保守性）、Integrity（保全性）、Security（安全性）の5項目の頭文字を取ったものです。

RASISは非機能要件にのみ関係した指標ではなく、ソフトウェアやサービス全般の品質に関する指標基準となっています。計算によって指標値を表せるはじめの3項目のみで「RAS」と表現されることもあります。

3：サービスレベル項目「SLO」

SLOは、Service Level Objects（サービスレベル項目）の頭文字を取ったものです。SLOでは前述のSLAで合意した契約内容について、各項目を達成するための具体的な評価基準や目標を示すものです。

たとえば、「あらゆるレベルの問題に対してヘルプデスクが返答を行うまでの時間」のSLOであれば、「着信から返答するまでの時間が3分以内で達成率80%以上」といった内容になります。

顧客に合った非機能要件を定義するための5つのポイント

非機能要件はクライアントから提案することができません。非機能要件の定義を行う際には、クライアントの隠れた要求を引き出すためにいくつかのポイントを押さえることが大切です。

ここでは顧客に合った非機能要件を定義するための5つのポイントを紹介していきますので、参考にしてみてください。

• どのような機能か図で説明する
• こちらから実現可能な機能を提示する
• 顧客に押し売りはしない
• 3つの案を提示する
• 具体的な説明を心がける

1：どのような機能か図で説明する

非機能要件について説明を行う際には、どのような機能なのかわかるように図を活用しましょう。非機能要件を言葉で説明しようとすると、システムに詳しくないクライアントにはわかりづらいです。

そのため、資料には図を多めに使用して直感的にわかりやすくするのがおすすめです。

2：こちらから実現可能な機能を提示する

前述のとおり、システム開発の主目的ではない非機能要件がクライアントの方から出てくることはないため、システム開発側から機能を提案することが大切です。

非機能要件はシステムを裏から支えるような品質の部分に関する内容となるため、システムに詳しいこちら側から提案し、クライアントに決めてもらう必要があります。

3：顧客に押し売りはしない

非機能要件の決定権はあくまでクライアントにあるため、押し売りはしないようにしましょう。開発側としてはおすすめしたい非機能要件のプランが決まっていたとしても、費用を出しているのはクライアントです。

そのため、内部のシステム的に「必ずこうしなければいけない」要件がある場合は、うまくそのプランを選択してもらえるように誘導しましょう。

4：3つの案を提示する

非機能要件について複数の案の中から1つを決めなければならない場合、「松」「竹」「梅」のように3つに分け、それぞれのメリットデメリットについて提示すると良いでしょう。

「松」「竹」「梅」の基準については「開発側のおすすめ順」や「予算が必要になる順」などがありますが、特に取り決めはありません。それぞれのメリットデメリットを説明し、クライアントに選んでもらうと良いでしょう。

5：具体的な説明を心がける

非機能要件についてクライアントに説明する際には、具体的な説明を心がけましょう。クライアントとの間に認識の齟齬を発生させないためにも、それぞれの項目をしっかりと理解してもらい、取り決めを行うようにしましょう。

非機能要件で気を付けること

非機能要件はクライアントからの要求ではないため、実際に実装するかどうかは事前にしっかりと認識をすり合わせ、合意しておくことが大切です。

システム開発側からしてみれば良い機能であっても、クライアントの業務に沿っていなければ満足度の向上にもつながらないでしょう。

非機能要件とはどのようなものか理解した上で顧客と話し合おう

非機能要件とはシステムの性能やユーザビリティなどに関する要件のことで、顧客の満足度を高める要因になります。

ぜひ本記事で紹介した非機能要件を定義する際に重要な項目や、顧客に合った非機能要件を定義するためのポイントなどを参考に、顧客にとって本当に必要な非機能要件を定義できるようにしましょう。