「要件」にも種類がある！

システムが絡む案件では、要件定義が重要であると言われます。しかし、そもそも「要件」とは何でしょうか？
要件の前にまず、システム発注をしたいと思った「動機」が存在します。「客単価を上げたい」「業務の効率化を図りたい」等、これらが「要求」です。
国際規格 (ISO2382-20) および日本工業規格 (JISX0020) では、「要求とは、システムが満たさなければならない必須条件」と定義しています。

要求の段階では、まだ漠然と「やりたい事」をまとめた、という位置づけです。これらを「システムの機能」として一つ一つ整形した物が「要件」です。
漠然とした「要求」を「要件」としてきちんと定義するのが、要件定義という事になります。最終的に、ここで定義された項目をチェックし、検収という形になりますので、非常に重要な項目です。

実はこの要件の中に、なかなか扱いが難しい・・と受注側が頭を悩ませる種類の物があります。それが「非機能要件」と言われる要件です。まず、要件には次のような種類があります。

１：システムやソフトウェアに求める機能の要件である「機能要件」
２：それ以外の「非機能要件」

この非機能要件が、くせ物です。

非機能要件の重要性

非機能要件とは何でしょうか。どうして重要なのでしょうか。

まず、機能要件とは、「商品が表示出来る事」、「スタッフがデータを印刷出来る事」など、システムの備えるべき機能の事です。
それに対して非機能要件とは、それ以外の要件、具体的にはレスポンスやセキュリティなど、そのシステムを提供するのに必要な条件という事になります。(株)オージス総研　正木氏が書かれた[1] 機能外要求と ISO9126では、

機能外要求は、非機能要求と呼ばれることもあり、ソフトウェアの提供する機能が達成すべき性能や制限を表す要求です。
たとえば、インターネットバンキングで「預金者が送金できること」は機能要求、「Web ブラウザで送金ボタンを押して10 秒以内に送金処理を終えること」や、「本人以外が勝手に預金者の口座を使って送金できないこと」は機能外要求です。

実際のソフトウェア開発の現場では、機能要求と比較して機能外要求は識別しにくいということをよく耳にします。

とあります。
この非機能要件、機能要求とは違い、発注者側が使ってみるまで全く気付かない、といった事も多い項目です。また、「当然、やってくれてるんでしょ？」という暗黙の了解の世界でもあります。
例えば、先ほどの「関連商品・売れ筋商品を表示するシステム」の例で言うと、売れ筋商品の表示に30秒かかるとしましょう。これではお客様がブラウザを閉じてしまいかねません。
しかし機能要求では「商品を表示する」ですから、要件定義に基づくテストではOKという事になってしまいます。

「そんなに時間がかかるなんて常識的に考えて使えないじゃないか！」と発注側は思いますが、ハードウェアの性能やコストの面から、これが最高のパフォーマンスだった場合も考えられます。
「○秒以上はダメだなんて言わなかったじゃないですか！」受注側の言い分はこうなってしまいます。

勿論、これらは大袈裟な例であり、受注者側で「想定出来る非機能要件」を経験から拾い上げていくのが現実で、常識的な事まで逐一定義せよ、と言うわけではありません。非機能要件の重要性を理解して欲しい、という意味なのです。
非機能要件は、性能や安定稼働、外部システムとの連携のしやすさなど、そのシステムに求める「品質」に深くかかわる項目です。ですから、非機能要件が増えれば(高いレベルを求めれば)その分、当然コストが上がるという事になります。
必ずしも必要でない要件と、優先する要件を振り分けて、予算も含めたバランスを考える事が大切ですが、これを考えられるのは受注側ではなく、発注者にしか出来ない事です。
受注者にサポートして貰いながら、発注者側がこの非機能要求を洗い出さないと、後々大幅なコストアップを迫られるという事になりかねないのです。

次のページでは、実際にどうやって非機能要件を定義するか考えてみます。

実際に出来た物を使ってみないと、わからないのでは？

とは言っても、実際にどんな項目に対して、非機能要件を考えれば良いのでしょうか。上流工程である要件定義の段階で考えよ、と言われても難しいかと思います。

先ほども引用した[2] 機能外要求と ISO9126では、機能外要求の定義に国際規格である、ISO 9126-1 「ソフトウェア品質モデル」を活用する事を提案しています。(翻訳されたものが、JIS規格になっています。JISX0129-1)

国際規格を利用してみよう！

ISO 9126-1 では「ソフトウェア品質モデル」というものを定義しています。
非機能要件を探す際に、「良い品質である事の条件」が解れば、それに照らし合わせて望む機能を探せる事になり、手間が省けます。
この国際規格はまず6つの特性に分類され、さらに27の副特性に分類されており、ボリューム満点ですので、その中からどんな事を考慮すべきか抜粋しました。

6つの特性を大体理解し、どんな可能性があるかリストアップしてみて下さい。その中で優先順位を決め、受注者と相談しながら「非機能要件」を攻略して下さい！

■機能性(適切性・正確さ・相互運用性・セキュリティ　等)
ソフトウェアが指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェア製品の能力。

(例）※「機能外要求と ISO9126」から引用
・消費税の計算は1円未満を切り捨てとする事。
・販売管理システムとの相互運用性を保証する事。
・社内ユーザとそのアクセス権を管理できる事。

■信頼性(成熟性・障害許容性・回復性　等)
指定された条件の下で利用する時、指定された達成水準を維持するソフトウェア製品の能力。

(例）※「機能外要求と ISO9126」から引用
・サービスを24時間提供可能な事。
・MTTR(平均復旧時間)は1時間以内であること。

■使用性(理解性・習得性・運用性・魅力性　等）
指定された条件の下で利用する時、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力。

(例）※「機能外要求と ISO9126」から引用
・顧客がマニュアルを見ずに操作できる事。

■効率性(時間効率・資源効率　等)
明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力。

(例)※「機能外要求と ISO9126」から引用
・ユーザにストレスを与えない応答時間である事。
・システムアーキテクチャ設計書で指定された範囲でディスクとメモリを使用する事。

■保守性(解析性・変更性・安定性　等)
修正のしやすさに関するソフトウェア製品の能力。

(例)※「機能外要求と ISO9126」から引用
・障害原因を分析するためのログ機能を備える事。
・稼働したままコンポーネントをバージョンアップ出来る事。

■移植性(設置性・共存性・置換性　等)
ある環境から他の環境に移すためのソフトウェア製品の能力。

(例)
・アップグレードが容易に出来る事。
・容易にインストール作業が出来る事。