英語の学習

要求には2種類ある。

第一には、開発対象システムに、発注者、顧客、ユーザが、機能として、何をさせることを望んでいるかと言うfunctional requirements 「機能要求」。

第二には、性能要求(システムへの負荷、1時に活きている端末の台数、応答時間他)、開発コストや運用コスト、開発のデッドラインなどからなるnon-functional requirements 「非機能要求」。

requirements engineering 「要求工学」は、「要求の獲得、仕様化に関係する科学と技術の分野」のこと。

非機能要件とは

非機能要件とは、その名の通り「機能以外の全ての要件」のことです。

機能要件が「システム構築にあたり、顧客が必要とする機能の要件」であるのに対し、非機能要件は「必要とする機能以外の要件」を指します。例えば、性能や可用性、セキュリティなどが上げられます。

構築したシステムが顧客の希望する機能全てを実装していたとしても、処理性能があまりに悪かったり、障害から復旧するのに時間がかかったりするようでは、運用に耐えられません。そのため、これらについても要件をきちんと定義することが大切です。

顧客によっては、実装する機能の要件にばかり時間を費やしてしまい、非機能要件が決められないまま進めてしまったがばかりに、十分な性能が発揮されないシステムが出来上がることも少なくありません。非機能要件は機能要件と同じくらい大事であると考えましょう。

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

非機能要件で定義すべき項目は多岐にわたるため、「FURPS+」や「JIS X25010：2013(ISO/IEC 25010：2011)」など、整理されているものを参考にするとよいでしょう。

ここでは、IPA（独立行政法人情報処理推進機構）が公開している「非機能要求グレード」をご紹介します。非機能要求グレードでは、6つの項目に分類しています。

①可用性
可用性は、システムを継続利用するための要件です。機器の冗長化や運用スケジュール、障害時の復旧方法などを定義します。

②性能・拡張性
システムの処理性能および拡張に関する要件です。構築するシステムで処理するトランザクション数や利用ユーザー数、負荷などを決めます。また、将来のキャパシティ・プランニングを検討します。

③運用・保守性
システムの運用・保守に関する要件です。システムの監視方法やバックアップ方法、問題発生時の体制などを決めておきます。

④移行性
現行システムからの移行に関する要件です。新システムへ移行するための移行期間、移行体制、移行リハーサルなど、移行計画についての要件を定義します。

⑤セキュリティ
システムのセキュリティ確保について定義します。アクセス制限や不正検知・監視の方法、システム運用者に対する情報セキュリティ教育について定義します。

⑥環境・エコロジー
システムを設置する環境・エコロジーに関する要件を定義します。環境負荷を低減する構成や、電気設備・規格の適合性について定義します。

非機能要件を定義するには

それでは、非機能要件を定義するための具体的な流れについて解説します。

機能要件を決めておく

非機能要件を決める前に、機能要件を決めておきましょう。なぜなら、実装する機能によって非機能要件が変わる場合があるからです。

また、機能要件を決める場合は、顧客がシステムに求める要件の背景や目的が明確になります。非機能要件も、それらを加味して考えることが必要です。

非機能要件を定義する手順

ここでは、具体的に非機能要件を定義するための手順について解説します。

手順1. システムの方向性を確認

対象システムがどのような方向性のものであるかによって、非機能要件も大きく変わります。例えば、基幹システムのような企業にとって極めて重要なシステムであれば、性能や可用性は高いものが求められます。逆に小規模で影響の小さいシステムであれば、ある程度許容された要件となります。

手順2. 非機能要件の草案を作成

IPAの非機能要求グレードでは、各項目について推奨される要求レベルが定義されており、顧客要望に併せて推奨値を調整することで、非機能要件がまとめられるようになっています。これらを参考にし、非機能要件の草案を作成していきます。作成したら、それが実現可能である内容であることを確認しておきましょう。

【非機能要求グレード2018　システム基盤の日機能要求に関する項目一覧】

※引用:IPA「システム構築の上流工程強化（非機能要求グレード）」

手順3. 非機能要件の推奨案を提示、顧客と合意を得る

システムや顧客要件に合わせて推奨値を決めたら、草案を顧客に提示・説明して合意を得ます。草案を提示することで、初めて顧客から細かい要件が出る場合もあるでしょう。それらを盛り込みながら要件を少しずつ定義していきます。顧客から出された要件は、その理由についても確認しましょう。代替案を提示するために必要です。

非機能要件を決めたら、その内容を要件定義書に記載します。要件定義書を元に設計が行われるため、要件定義書は誰が見てもわかるように曖昧な文言は避けましょう。また、図示化しておくのも有効です。

非機能要件の定義をスムーズに進めるために

非機能要件を定義するのに、機能要件とは異なるアプローチを取る場合があります。ここでは、機能要件との違いを元に、非機能要件をスムーズに定義するためのポイントを解説します。

顧客からは非機能要件が出てこない

顧客から非機能要件について出てくることは、なかなかありません。機能要件については話が出ることはあっても、可用性やセキュリティなど細かい点について、顧客が意識して要件をまとめているケースは少ないと考えたほうがよいでしょう。顧客が他のシステムも持っている場合は、それと同様と考えている場合もあります。

そのため、開発側から決めるべき非機能要件をまとめておき、顧客に対して提案することで顧客の意識を向けることができ、スムーズに進められます。

提案は比較できるようにしておく

非機能要件を決めるのに、最終決定権は顧客にあることを忘れてはいけません。開発側から提案するにしても、顧客が最終決定するための材料もあわせて提示できなければ、顧客は決断することができません。

可用性やセキュリティなどの項目について、いくつかの案とともにメリット・デメリットを提示します。ここは、システムの専門家としての腕の見せ所です。顧客とコミュニケーションを取りながら、顧客からの期待以上の案を提案できれば、満足度を高められます。

その他の非機能要件も考えておく

IPAの非機能要求グレードに記載されている項目以外にも、考慮すべき非機能要件はあります。例えば操作性（ユーザビリティ）が上げられます。利用ユーザーを想定した操作性にしなければ、あまりに使い勝手の悪いシステムになる可能性があります。

画面の見た目など操作性の基準となるものを作ってまとめておくと、操作性の高いシステムを構築できます。

まとめ

本記事では、非機能要件について解説しました。非機能要件は、顧客に意識されにくい部分ではありますが、機能要件と同じくらい重要です。

機能要件は顧客からヒアリングして定義していきますが、非機能要件は事前に項目や決めるべき内容を開発側から提示して、顧客に判断してもらうという点でアプローチが異なります。

要件定義の工程で機能要件・非機能要件を細かく決め、顧客と合意を取っておけば、満足度の高いシステムを構築できます。