はじめての設計をやり抜くための本【設計編】第3章外部設計の手法⑪非機能要件定義とシステム設計
■非機能要件とは
システムの利用者にとって機能要件を実現することがシステムを利用する目的である。非機能要件はシステム利用者がシステムを利用するために補助的に必要なシステムの品質や性能のこと。
・サービスレベルアグリーメント（SLA）：サービスの提供事業者とその利用者の間で結ばれる、サービスのレベル（定義、範囲、内容、達成目標等）に関する合意サービス水準、サービス品質保証
・サービスレベルオブジェクティブ（SLO）：事業者が自社のサービスレベル（サービス品質）に関する目標・評価基準を定めたもの
・事業継続計画：災害や大規模なシステム障害が発生しても事業が継続できるように対策を用意する。
※非機能要件定義で扱う内容はシステムへの高負荷、長時間運用して初めて発見されるような問題なので軽視されてしまう。しかし、その内容はシステム全体に影響するので、いざ問題が発生すると復旧に多くの時間がかかる。
機能要件はシステム利用者であるユーザー企業担当者にどのような機能がほしいが聞けばいい。非機能要件は品質や性能に関するものでユーザー企業担当者に聞いても明確な返答は得られない。
非機能要件とは機能要件以外のもの＝漠然としている
→非機能要件の基準「ISO／IEC9126品質特性モデル」が一般的に広まっている。
ISO／IEC9126はシステムの品質特性を網羅的に定義したもの。
→重点的に対応する品質特性と特別な対応が不要な品質特性を明確にできる。
上記の表では内容に不明な部分が多い。そのため品質副特性を含めて詳細化したそれぞれの特性を記載する。
◯機能性
機能性の内容を機能要件か非機能要件に分けると、機能要件には機能性の品質副特性である合目的性が該当する。非機能要件にはそれ以外の品質特性と品質副特性が該当する。
◯信頼性
最近のシステムは開発効率を高めるために、さまざまなミドルウェアやフレームワーク、ライブラリを組み合わせて構築する。
※その開発環境のマイナーバージョンやリビジョンが低い場合は成熟度が低い可能性がある。
[成熟性の指標]
・平均故障間隔（MTBF）
故障が発生するまでのシステム稼働時間の平均
※似た指標に平均故障時間（MTTF）があるが、MTTFは修理不可能なものに対して使用される。一般的にソフトウェアは修理可能なのでMTBFを使用する。
MTBF = システムの総稼働時間 ／ 故障回数
復元力は障害が発生してから、いかに早く正常に動作するように回復できるかを指す。
[復元力の指標]
・平均修復時間（MTTR）
障害の発生から平均してどのくらいの時間で修復できるかを指す。稼働率は可用性の指標でもある。
稼働率 = MTBF ／ （MTBF + MTTR）
例：仮に１年間障害なしで稼働するシステムがあり、１年に１回だけ障害が発生する場合、その障害の復旧に１時間かかる場合、稼働率は次のようになる。
MTBF = 365日 × 24時間 = 8760時間
MTTR = 1時間
稼働率 = MTBF ／ （MTBF + MTTR）= 8760／（8760 + 1）= 99.99%
障害許容性（フォールトトレランス：FT）
障害が発生してもシステム全体がダウンせずに動き続ける特性を指す。障害が発生しても動き続けるために２重化や多重化といったシステムの冗長化をするのが定石である。
ハードウェアの例：複数台のハードディスクを仮想的に１台に見せるようにRAID構成にする。RAID構成にすることでハードディスクが1台破損してももう１台にデータが書き込まれているのでデータが失われない。
サーバーの例：WebサーバーやWebアプリケーションサーバーを同じ構成で複数台配置する（→表：サーバーの冗長化構成）。方法としては、ロードバランサを配置してクラスタリングする。もしくは冗長化したサーバー郡でセッションを維持する方法。
◯使用性
ユーザビリティのこと。
◯効率
効率は「性能」に関する品質特性。効率が良ければ性能が良くなる。
普段、性能やパフォーマンスと呼んでいるのは効率の品質副特性である時間挙動である。
[時間挙動の指標]
・スループット
単位時間にシステムがレスポンスを返すことができる数
・レイテンシ
システムが１つのリクエストからレスポンスを返すまでの時間
一般的にレイテンシが小さければスループットは大きくなる。ただし、
サーバーのCPU使用率やメモリ使用率などのリソースが上限に達するか、
ネットワークの帯域が足りなくなると、レイテンシだけ大きかったりスループットだけが小さかったりする。
※時間挙動を評価するにはスループットとレイテンシの両方を調査する必要がある。
◯保守性
システムの修正のしやすさを表す品質特性
◯可搬性
※通常のサーバーシステムであれば、インストールは一度のため可搬性は重要ではない。可搬性が必要になるのは、パッケージソフトやクライアントアプリケーションなど、多数の環境で実行されるようなソフトウェアのみ。
非機能要件定義として検討すべき内容は、機能性の品質副特性の合目的性を
除いた全てである。※ただし、可搬性は重要ではない。
[補足]
・信頼性と効率に関しては具体的な目標値をユーザー企業担当者に定時してもらう。スループット、レイテンシ、稼働率には具体的な目標値を設定する。
・機能性のセキュリティに関しては、公開されているセキュリティガイドラインを参考にして検討する。
Webアプリケーションであれば、独立行政法人情報処理推進機構（IPA）のセキュリティセンターが作成した「安全なWebサイトの作り方」を参考にして、セキュリティ問題について対応を検討する。
[セキュリティ問題の例]
・SQLインジェクション
・OSコマンドインジェクション
など、合計10項目
以上で⑪非機能要件定義とシステム設計を終了します。
次回は、⑫システムインフラ設計と配置設計について記載します。
この記事が気に入ったらサポートをしてみませんか？