システム開発における要求分析モデルとして、ユースケースを中心に説明してきました。
ユースケースはユーザの目的をモデル化したモデル要素であり、システムがユーザに提供する機能を表現するという意味で機能要求のモデルといえます。第1回では、図1[営業社員のシステム・ユースケース]に示すユースケースを用いた要求モデルを作成しましたが、これは機能要求ということになります。
しかし、要求仕様は機能要求だけで構成されるわけではありません。実際のシステム開発では「ユーザの目的」とは別の観点でさまざまな要求を定める必要があります。このような機能外の要求のことを非機能要求と呼びます。
今回は、この非機能要求について説明します。
非機能要求を考える上では、システムの品質という切り口が重要です。
ISO/IEC 9126は、ソフトウェア開発における品質特性を定義しています。ISO/IEC 9126のJIS版がJIS X 0129です。本稿では日本語になっているJIS X 0129をベースに説明します。
JIS X 0129では表1[JIS X 0129の品質特性]に示す品質特性を定めています。
| 品質特性 | 定義 | 品質副特性 | 定義 |
|---|---|---|---|
| 機能性 | ソフトウェアが、指定された条件の下で利用されるときに、明示的及び暗示的必要性に合致する機能を提供するソフトウェアの能力 | 合目的性 | 指定された作業及び利用者の具体目標に対して適切な機能の集合を提供するソフトウェア製品の能力 |
| 正確性 | 必要とされる精度で、正しい結果若しくは正しい効果、又は同意できる結果若しくは同意できる効果をもたらすソフトウェア製品の能力 | ||
| 相互運用性 | 一つ以上の指定されたシステムと相互作用するソフトウェア製品の能力 | ||
| セキュリティ | 許可されていない人又はシステムが情報又はデータを読んだり、修正したりすることができないように、及び許可された人又はシステムが情報又はデータへのアクセスを拒否されないように、情報又はデータを保護するソフトウェア製品の能力 | ||
| 機能性標準適合性 | 機能性に関連する規格、規約又は法律上及び類似の法規上の規則を遵守するソフトウェア製品の能力 | ||
| 信頼性 | 指定された条件下で利用するとき、指定された達成水準を維持するソフトウェア製品の能力 | 成熟性 | ソフトウェアに潜在する障害の結果として生じる故障を回避するソフトウェア製品の能力 |
| 障害許容性 | ソフトウェアの障害部分を実行した場合、又は仕様化されたインタフェース条件に違反が発生した場合に、指定された達成水準を維持するソフトウェア製品の能力 | ||
| 回復性 | 故障時に、指定された達成水準を再確立し、直接に影響を受けたデータを回復するソフトウェア製品の能力 | ||
| 信頼性標準適合性 | 信頼性に関連する規格、規約又は規則を遵守するソフトウェア製品の能力 | ||
| 使用性 | 指定された条件の下で利用するとき、理解、習得、利用でき、利用者にとって魅力的であるソフトウェア製品の能力 | 理解性 | ソフトウェアが特定の作業に特定の利用条件で適用できるかどうか、及びどのように利用できるかを利用者が理解できるソフトウェア製品の能力 |
| 習得性 | ソフトウェアの適用を利用者が習得できるソフトウェア製品の能力 | ||
| 運用性 | 利用者がソフトウェアの運用及び運用管理を行うことができるソフトウェア製品の能力 | ||
| 魅力性 | 利用者にとって魅力的であるためのソフトウェア製品の能力 | ||
| 使用性標準適合性 | 使用性に関連する規格、規約、スタイルガイドまたは規則を遵守するソフトウェア製品の能力 | ||
| 効率性 | 明示的な条件の下で、使用する資源の量に対比して適切な性能を提供するソフトウェア製品の能力 | 時間効率性 | 明示的な条件の下で、ソフトウェアの機能を実行する際の、適切な応答時間、処理時間及び処理能力を提供するソフトウェア製品の能力 |
| 資源効率性 | 明示的な条件の下で、ソフトウェアの機能を実行する際の、資源の量及び資源の種類を適切に使用するソフトウェア製品の能力 | ||
| 効率性標準適合性 | 効率性に関連する規格または規約を遵守するソフトウェア製品の能力 | ||
| 保守性 | 修正のしやすさに関するソフトウェア製品の能力 | 解析性 | ソフトウェアにある欠陥の診断または故障原因の追及、及びソフトウェアの修正箇所の識別を行うためのソフトウェア製品の能力 |
| 変更性 | 指定された修正を行うことができるソフトウェア製品の能力 | ||
| 安定性 | ソフトウェアの修正による、予期せぬ影響を避けるソフトウェア製品の能力 | ||
| 試験性 | 修正したソフトウェアの妥当性確認ができるソフトウェア製品の能力 | ||
| 保守性標準適合性 | 保守性に関連する規格又は規約を遵守するソフトウェア製品の能力 | ||
| 移植性 | ある環境から他の環境に移すためのソフトウェア製品の能力 | 環境適用性 | ソフトウェアにあらかじめ用意された以外の付加的な作業または手段なしに、指定された異なる環境にソフトウェアを適応させるためのソフトウェア製品の能力 |
| 設置性 | 指定された環境に設置するためのソフトウェア製品の能力 | ||
| 共存性 | 共通の資源を共有する共通の環境の中で、他の独立したソフトウェアと共存するためのソフトウェア製品の能力 | ||
| 置換性 | 同じ環境で、同じ目的のために、他の指定されたソフトウェア製品から置き換えて使用することができるソフトウェア製品の能力 | ||
| 移植性標準適合性 | 移植性に関連する規格又は規約を遵守するソフトウェア製品の能力 |
これらの品質特性は、ソフトウェア製品の品質を計測する尺度となりますが、必ずしも最高度の品質を常に目指すというわけではありません。なぜなら、最高度の品質を達成するためには、相応のコストがかかるからです。このため費用対効果の観点から、システムが達成すべき品質のレベルを定める必要があります。これが要求仕様となるのです。
このような品質に対する要求は、前述したユースケースなどを用いた機能要求とは視点が異なるものですが、重要な要求仕様であることは変わりありません。このような機能以外の要求を非機能要求や機能外要求と呼びます。本稿では非機能要求と呼ぶことにします。
非機能要求は表1[JIS X 0129の品質特性]に示すように、たくさんの項目がありますが、どのシステムでも濃淡の違いはあるにしても同じ枠組みになります。必ず必要となるので、仮に明示的に顧客が要求仕様として定義しなかった場合でも、開発サイドで要求仕様として意識しておく必要があります。
ISO/IEC 9126は、規格書らしくソフトウェアの品質特性に関して、必要と考えられる内容が網羅されています。しかし、それだけにポイントを絞らないと使いこなせません。そのような事情もあり、要求の種類を示す概念としてUP(Unified Process)も推奨しているFURPS+が広く使われています。
FURPS+では要求を以下に示す種類に分類しています。
これらに加えて、システム設計上の制約事項を「+」として表現したものがFURPS+です。
この5つの要求の分類は、前述したISO/IEC 9126とも共通点が多くなっています。
FURPS+の「機能」はユーザが必要とする機能を指すのに対して、ISO/IEC 9126の「機能性」は、機能の十分性という意味での品質を指すので少しニュアンスが異なります。
一方、FURPS+の「使いやすさ」、「信頼性」、「サポートのしやすさ」はそれぞれISO/IEC 9126の「使用性」、「信頼性」、「保守性」に対応します。
FURPS+に独自の項目としては「性能」が、ISO/IEC 9126に独自の項目としては「効率性」、「移植性」があります。ただしFURPS+の「性能」は、ISO/IEC 9126の「効率性」と関連付けて考えることができるでしょう。
非機能要求を考える上での枠組みとしてISO/IEC 9126(JIS X 0126)やFURPS+がありますが、あくまでも枠組みです。こららの枠組みは、そのまま利用するというよりも、開発対象のシステムに応じてチューニングして用いる必要があります。
ボクの経験上の考え方からFURPS+を参考に、非機能要求の候補をマインドマップとしてまとめてみたのが図2[非機能要求]です。
「使用性」、「信頼性」、「性能」、「保守性」、「その他」を軸にそれぞれの非機能要求について考えていきましょう。
ISO/IEC 9126では、品質特性「使用性」の品質副特性として、「理解性」、「習得性」、「運用性」、「魅力性」、「使用性標準適合性」を定めています。
要求仕様という観点から、図2[非機能要求]では、UI、ユーザ対応、運用という切り口にしてみました。
理解性、習得性、魅力性、使用性標準適合性といった特性は、UIという実装技術を軸に考えたほうが分かりやすいので、これらの項目を作る代わりにUIという項目を設けています。
UIという項目の配下にはUI方式という実装技術の項目があり、Web、GUI、CUI、CLIといった実装技術を挙げています。システムの使用する実装技術を選択した上で、理解性、習得性、魅力性、使用性標準適合性について考えていけばよいでしょう。
また、UIデザインに関する使用性標準適合性についてはUIデザイン標準という項目を挙げています。
使用性における理解性、習得性といった品質を上げるためには、きめの細かいユーザ対応が必要となります。図では、マニュアル、教育、質問、障害対応についての項目を挙げています。
ハードウェアの分野では信頼性を表す概念としてRAS(Reliability, Availability, Servicability)や、RASにIntegrity(保全性)、Security(セキュリティ)を追加したRASIS(Reliability, Availability, Servicability, Integrity, Security)を用います。
このRASISをソフトウェアの信頼性を示す枠組みとして流用することも可能と思われます。本稿では、このRASISを切り口にして信頼性について考えます。
企業システムでもCPUやハード・ディスクなどのハードウェアも構成要素になっているので、この部分についてはRASISの考え方をそのまま適用することができます。一方、企業システムのソフトウェア部分はRASISを適用する場合でも、多少の調整が必要と思われます。そして、最終的にはハードウェアに対するRASISとソフトウェアに対するRASISを定め、この2つを合わせてシステム全体のRASISを検討することになります。
今回は、非機能要件というテーマなのでRASISをソフトウェアに適用する部分に議論を絞ることにします。
RASISは「広義の"信頼性"」、RASISの構成要素であるReliabilityは「狭義の"信頼性"」と考えることができます。FURPS+のReliabilityは「広義の"信頼性"」とすると、RASISを枠組みとして採用して対応付け、RASISのReliabilityは「狭義の"信頼性"」として、一構成要素として扱うとよいでしょう。
RASISの最初の項目である信頼性(Reliability)は、システムが故障する間の平均時間であるMTBF(Mean Time Between Failures)で表します。
| (1) |
MTBFは"故障のしにくさ"を数値化したものと考えると分かりやすいと思います。
MTBFを使用するにあたって注意が必要なのが、MTBFはもともと工場で大量に製造するハードウェア製品の信頼性のための指標であるという点です。このため、一つ一つ手作りで開発する企業システムにおけるソフトウェアの信頼性の指標としてMTBFを厳密に適用することは現実には難しいのではないかと思います。
たとえば、「今回開発するシステムのMTBFは5692.5時間です」といった仕様化を行っても、現在のソフトウェア技術では、この数値を直接裏書する根拠がありませんから、単なる努力目標ということになります。このため、現実的な意味で顧客との意識あわせという意味では「故障により年に2、3度はシステムが停止することがあります」、「故障によるシステム停止は10年に一度あるかないかです」といったレベルの詳細度で十分でしょう。
どちらかというと、「ハードディスクをRAID化するとコストは○円」、「マルチクラスタを導入するとコストは○円」というように選択できる実装技術とコストの対応関係を主に考え、「"ハードディスクをRAID化するとコストは○円"かかりますが、故障の頻度は○月に一度のレベルまで下がる」、「"マルチクラスタを導入するとコストは○円"かかりますが、故障の頻度は○年に一度のレベルまで下がる」、という切り口で、提案可能なシステム構成を主とし、それぞれのシステム構成のコストに対して得られるメリットとしてMTBFを利用するとよいのではないかと思います。
もちろん意識の高い顧客の場合にはMTBFを指定してくることもあるでしょうが、その場合にはその数値に合わせたシステム構成を提案していけばよいでしょう。
RASISの2つ目の項目である可用性(Availability)は、稼働率として表します。稼働率が高いシステムは可用性が高いということになります。
可用性は大きく故障に対する可用性と運用に関する可用性に分けることができます。
故障に対する可用性は、以下の式によって表されます。
| (2) |
可用性を高くするためには、故障間隔をできるだけ長くし(MTBFをできるだけ大きくする)、故障した場合の修理時間をできるだけ短く(MTTR(後述)をできるだけ小さくする)します。
このためには、ハードウェアの多重化を中心とするシステム構成をとることになります。可用性を高めるためのシステム設計については「第36回アプリケーションアーキテクチャ」で取り上げましたので参考にしてください。
故障によるシステム停止とは別に、設備管理、運用要員のコストの問題(夜間や休日はシステムを停止したい等)や、バックアップなどシステムの保守に必要な時間を取るために、システムを停止する必要があります。
このような通常の運用における稼働時間も可用性の一つの項目として考えておくとよいでしょう。
運用における稼働時間は平均動作不能時間であるMDT(Mean Down Time)と平均動作可能時間であるMUT(Mean Up Time)を用いて表現します。
| (3) |
可用性の場合もMTBFの場合と同様に、細かい数値を精査するよりも、運用やコストを軸にした切り口で考えていくとよいと思います。夜間や休日は停止するシステムであれば、運用の稼働率についてはそれほど気にする必要はありませんが、24時間稼動のシステムであれば、運用スケジュールとそのコストについて要求仕様として定義しておく必要があります。
RASISの3つ目の項目である保守性(Serviceability)は、故障が発生してから通常のサービス提供を再開するまでにかかる平均期間であるMTTR(Mean Time To Repair)で表します。
| (4) |
ISO/IEC 9126では保守性を品質特性として定義しており、その品質副特性として「解析性」、「変更性」、「安定性」、「試験性」、「保守性標準適合性」を定義しています。
ただし、ISO/IEC 9126の保守性はMaintainabilityであり、RASISの保守性であるServiceabilityとはニュアンスが異なります。つまり、RASISの保守性(Serviceability)は、保守性の度合いを計測可能な数値であるMTTRとして定義したものであるのに対して、ISO/IEC 9126の保守性(Maintainability)は「解析性」、「変更性」、「安定性」、「試験性」、「保守性標準適合性」という形で保守性を構成する枠組みを定義したものというわけです。『MTTRを高めるためには、「解析性」、「変更性」、「安定性」、「試験性」、「保守性標準適合性」を高めていかなくてはならない』、というように両方の視点を関連付けて考えるとよいでしょう。
要求仕様として保守性を考える場合には、MTBFの場合と同様に、細かい数値を精査するよりも、運用やコストを軸にした切り口で考えていくとよいと思います。保守性の場合には、「解析性」、「変更性」、「安定性」、「試験性」、「保守性標準適合性」といった項目に対する達成レベルとそれにかかるコストを軸にし、これとMTTRを連動して考えることになります。
RASISの4つ目の項目である保全性(Integrity)は、システムが故障した場合などに、データに異常が残ったりなどの影響が起きないことに対する品質です。
元々ハードウェア向けの指標であるRAS/RASISでは、信頼性、可用性、保守性よりは扱いが小さくなっており、RASではなくRASISに入っています。しかし、企業システムの場合には、データの保全性上の問題は業務の継続に極めて深刻なダメージを与えるという意味で、システムダウンよりも影響が大きいとも言え、RASの3項目と同等以上の配慮を行う必要があります。
企業システムの場合、データの保全性は100%保たれなければならないので、保全のレベルを定義するという形にはならないと思いますが、要求仕様の観点からは、トランザクションなどデータの保全性を担保するメカニズムについての各種の選択を確認しておくとよいでしょう。
RASISの5つ目の項目であるセキュリティ(Security)は不正なアクセスの行われにくさに対する品質です。RASISの訳としては機密性や安全性が使われることが多いようですが、ここではソフトウェアで一般的に用いられている用語である"セキュリティ"を用いることにします。
セキュリティも保全性と同様にハードウェア的な仕様としては扱いが小さくRASではなくRASISに入っています。しかし、近年のネットワーク環境の充実によって、セキュリティは極めて重要な問題になっていることは言うまでもありません。RASの3項目と同等以上の配慮を行う必要があります。
ISO/IEC 9126では、品質特性「機能性」の品質副特性として「セキュリティ」が定義されています。ISO/IEC 9126では、「機能性」に分類されていますが、ここではRASISにしたがって「信頼性」として考えることにします。
セキュリティの強度にはいくつかの段階があり、それぞれ実現するためのコストが大きく変わってきます。要求仕様では、実現のレベルを定義することになります。
セキュリティとして、図では暗号化、認証、権限確認、監査、セキュリティ管理を項目として挙げました。
暗号化は、データを秘匿するために用います。システムの扱うデータをどの程度暗号化して、データの秘匿性を高めるかという点を明らかにしておかなければなりません。
認証は、正しいユーザがログインしたことを暗号技術を用いて検証する機能です。
企業システムで認証がないシステムは考えにくいですが、要求仕様として、認証のあり/なしや実現方式について意識あわせを行っておくとよいでしょう。特に、認証はユーザ管理やLDAPなどのディレクトリサービスなどとの連携が必要になるケースも多く、機能上/運用上での制約が発生しますので、この点についても確認しておく必要があります。
権限確認は、ユーザの許可された操作のみを行うことを制御する機能です。
要求仕様では、どの程度の粒度で権限確認をするのかを確認しておきます。
本格的にセキュリティの強度を上げるためには、システムの動作状況を監査する機能が必要となります。このためには、実行プログラムにセキュリティ・ログを出力する機能を盛り込む必要があるのに加えて、監査用のツールなどを開発しなければなりません。
これらの機能を実現するためには、非常に大きな開発コストが発生します。要求仕様では、このため、開発コストと得られるメリットの観点から、監査のあり/なし、監査がある場合の実現レベルを定義しておく必要があります。
以上で説明したように、セキュリティ機能は非常に大きな機能セットとなり、その運用も複雑です。
このため、運用を円滑に進めるためには、セキュリティ管理の機能を開発することが望ましいでしょう。もちろん、開発コストが発生するので、費用対効果の観点から要求仕様として定義しておく必要があります。
ISO/IEC 9126では品質特性「効率化」の品質副特性として「時間効率性」、「資源効率性」、「効率性標準適合性」を定義しています。この中の「時間効率性」が、FURPS+の「性能」に直接対応します。
図では性能として実行性能とスケーラビリティを挙げています。以下でそれぞれについて説明します。
実行性能としては、レスポンスとスループットが代表的な項目です。
レスポンスは、機能の実行を依頼してから返答があるまでの時間です。実行性能として一般的な項目です。たとえば、『「実行」キーを押してから結果を表示するまでに3秒以内』というような要求仕様になります。
一方スループットは、一定時間内に処理できる仕事の量を示す項目です。"一定時間内に処理できる仕事の量"という形で細かく数値化するよりも、『同時に1000台の端末を使用した場合に、「実行」キーを押してから結果を表示するまでに3秒以内』というような、実運用に即した定義のほうがよいでしょう。
レスポンスとスループットはどちらも重要な性能要件であり、要求仕様として定義しておく必要があります。
スケーラビリティとしては、クライアント規模やサーバ規模を上げても、ハードウェアの増強のみで、プログラムを変更することなく動作することができる能力です。
スケーラビリティを高めるためには、システム設計時に相応の考慮が必要であり、またハードウェア構成を含めコストにも直接影響してくるので、必要なスケーラビリティの範囲を要求仕様として定義しておく必要があります。
スケーラビリティを高めるためのシステム設計については「第36回アプリケーションアーキテクチャ」で取り上げましたので参考にしてください。
管理、監視、保守、運用計画といった非機能要求も確認しておく必要があります。
開発するシステムがシステム管理フレームワークに全面的に載っていくのであれば、これらの仕事をシステム管理フレームワーク側で行うことが可能になります。
そうでない場合には、目的を達成する方法を具体化、詳細化させなくてはなりません。
OSが提供するツールやコマンドを使用し、手作業でこれらの作業を行うのであれば、運用手順書というまとめ方になるでしょうし、システムの機能として提供する必要があるのであれば、機能要求として計上しなければなりません。
FURPS+の「+」にあたるその他の項目として、システム構築の各種制約条件を要求仕様として定義しておく必要があります。
システムの非機能要求として、ハードウェア構成、ネットワーク構成、使用するOSやミドルウェアなどがあります。
ISO/IEC 9126では、品質特性「機能性」の品質副特性の一つに「相互運用性」を定義しています。FURPS+では、「その他」の項目になります。
相互運用性の項目としては以下のものが考えられます。
ISO/IEC 9126では、すべての品質特性で、その品質副特性の一つに「標準適合性」を定義しています。
使用する必要がある標準規格についても、要求仕様として明確にしておく必要があります。
ISO/IEC 9126では、品質特性「移植性」を定義しています。FURPS+では、「その他」に分類することになります。
開発したプログラムの移植性も要求仕様として明確にしておく必要があります。この場合、今回の開発対象であるシステムだけではなくて、将来に渡って開発するシステム群を包括的にターゲットとする要求仕様を考えることも有効でしょう。
要求仕様を定義する場合、どうしてもユースケースに代表されるような機能要求に目がいってしまいます。しかし、ここまで説明してきたとおり、品質特性の観点からさまざまな非機能要求が存在することがお分かりいただけたと思います。
続けて、機能要求と非機能要求の関係について考えてみましょう。
機能要求は、図3[機能要求]に示すように独立した構成要素として存在しています。
ここで、機能要求と非機能要求の関係ですが、図4[機能要求と非機能要求]に示すように、非機能要求は、機能要求に編み込まれて実現されることになります。つまり、エンド・ユーザの目には直接触れることはありませんが、機能の内部に実装されることになるのです。
しかし、これで安心してはいけません。非機能要求は直接エンド・ユーザの目に触れることはありませんが、非機能要求を実現した処理は確実にプログラム内に存在することになります。この「処理」がプログラム内にある以上、これを管理することが必要になります。システムを円滑に進めるためには、単なる運用規則というのではなく、専用の運用機能がシステム内に用意されていなければなりません。
このため図5[運用系の非機能要求]に示すように非機能要求に対応する管理機能をシステムで実現する必要が出てきます。
つまり、何らかの機能をシステムで実現することになるわけです。この機能は、非機能要求ではなく、機能要求として定義するのが妥当です。これを本稿では、運用系の機能要求と呼ぶことにします。
一方、ユースケースという形でユーザの目的から派生した要求仕様をサービス系の機能要求と呼ぶことにします。
今までの議論で、以下の種類の要求があることが分かりました。
これらの要求の関係は図6[要求仕様の関係]に示すようになります。
ビジネスモデリングなどを通じて抽出されたビジネス要求から、サービス系の機能要求が作成されます。もちろん、このサービス系の機能要求が要求仕様の中核です。
しかし、ここまで述べたように必要となる要求はこれだけではありません。システムの品質特性やシステムの制約事項を要求としてまとめた非機能要求を定義する必要があります。そして、非機能要求から派生して、運用系の機能要求を定義し、システムの機能として実現していく必要があるのです。
それでは、運用系の機能要求はどのような構成になるでしょうか。色々な考え方があると思いますが、ボクの切り口をマインドマップとしてまとめた運用系の機能要求を図7[運用系の機能要求]に示します。
図では、運用系の機能要求として、「管理」、「監視」、「保守」、「復旧」の項目を挙げました。以下で、それぞれの項目について説明します。
「管理」は、システムのさまざまな振舞いを管理するための機能です。以下で、主なものについて見ていきましょう。
データベースのテーブルは、業務で日々発生するデータを格納するトランザクション・テーブルと、トランザクション・テーブルに格納されるデータのメタ・データを管理しているマスター・テーブルに分けられます。
トランザクション・テーブルは業務システムが更新します。
一方、マスター・テーブルはシステム管理者が必要に応じて更新します。このためマスター・テーブルを更新するためのマスター管理機能が必要となります。
セキュリティ上の要求から、システムの利用者をユーザとして管理する必要があります。このためには、システム利用者のアカウントを管理するユーザ管理機能を提供する必要があります。
セキュリティ管理では、セキュリティに関する各種の管理を行います。
代表的なものとしては、システム利用者の認証と権限確認の管理があります。これはユーザ管理と連動して行うことになるでしょう。
この他にも、CAの管理、監査などが管理の対象となるでしょう。
アプリケーション管理では、アプリケーションやコンポーネントのバージョン管理を行います。また、障害修正のためのパッチの管理をする必要がある場合もあるでしょう。
また、クライアントとサーバ、あるいは複数のサーバでシステムが構成されている場合、これらのシステム上で動作するアプリケーションやコンポーネントのバージョン、さらには組み合わせなどの構成管理も管理対象となります。
以上の機能の実現に、システム管理フレームワークを使用するのであれば非機能要求のみとなるでしょうし、管理機能をシステム側に作りこむのであれば機能要求として計上しておかなければなりません。
システムの保全を行うためには、故障を未然に防ぐことが重要です。このためには、システムの動作状況を監視する必要があります。
異常が発生して停止しているコンポーネントがないか、スプールが溢れていないか、といったチェックを常に行う必要があります。
システムが検知した異常をシステムのコンソールに表示したり、アラートとしてシステム管理者に通知するといった機能が必要となります。これらの機能の実現に、システム管理フレームワークを使用するのであれば非機能要求のみとなるでしょうし、管理機能をシステム側に作りこむのであれば機能要求として計上しておかなければなりません。
また、システムが正常に動作していても、それだけでは安心できません。セキュリティ上の攻撃を受ける可能性があるためです。この点についても考慮に入れる必要があります。
つまり、システムへの侵入者やファイルの改竄といったセキュリティ上のチェック項目についても常に監視を行う必要があります。
システムの保全を効率的に行うためには、一定のルーチン作業として保守作業を行う必要があります。故障が発生する前に、適切な保守作業を行っておくことで、故障の発生を防ぎ、故障が発生した場合の被害を最小化することができます。
図では、システム更新、バックアップ、起動・停止の項目を挙げています。
システムの故障を未然に防ぐためには、寿命が近くなったハードウェアの交換や、OSやアプリケーションといったソフトウェアのバージョンアップ、あるいは障害修正を行ったソフトウェアモジュールの入れ替えといった作業を行う必要があります。
OSの提供する機能を利用して手動でシステム更新を行う運用であれば機能要求には入ってきませんが、システム側でシステム更新のUIやスクリプトを提供する場合などは、運用系の機能要求として計上しておく必要があります。
最近ではRAIDなどを簡単に利用できるようになったので、ハードウェア的な故障に対するデータの保全性は容易に確保できるようになりました。しかし、RAIDであってもアプリケーションバグや、ユーザの誤操作によるデータ破壊に対しては無力です。このため、現在でもバックアップは必須の作業です。
OSの提供する機能を利用して手動でバックアップを取る運用であれば機能要求には入ってきませんが、システム側でバックアップのUIやスクリプトを提供する場合などは、運用系の機能要求として計上しておく必要があります。
システムの起動と停止についても、機能要求として検討する必要があるかもしれません。
保守を行うためには、システムの停止と起動を行うことになりますが、24時間運用のシステムなどでは、システムを停止するスケジュールをユーザに警告したり、ユーザが利用中に停止を行う場合の強制ログアウト機能などを提供しなければならないかもしれません。このような機能をシステムが提供する場合、そのための設定を行う管理機能が必要となるでしょう。
この場合、システム管理者をアクターとして、システムの停止から保守作業、システムの再起動までのユースケースを作成して、システムの提供する機能を明確化し機能要求として計上することになります。
「保守」は、故障発生前にシステムの保全を行う定期的な作業です。しかし、故障が発生したしまった場合、「保守」ではなくて、システムの保全を行うための「復旧」が必要となります。
障害調査をアシストするための機能をシステムに作りこむ必要があるかもしれません。
OSやミドルウェアが提供するログ機能に、固定的なログを出力するだけであれば運用規則で対処可能でしょう。しかし、障害調査の目的でログのレベルを変えたり、運用を止めたりする機能が必要となるのであれば、機能要求として開発を検討する必要があります。
システムに不具合が発生し障害調査の結果、システムの一部を改修しなければならないことが判明したとします。このような場合、システムを改修する手順について考えなくてはなりません。
システム全体を停止し、手動でアプリケーションやコンポーネントを置き換えたり、システム管理のフレームワークを利用するような場合には、運用を考えればよいだけですが、自前でこのような機能を作成する場合には、機能要求として考えておく必要があります。
故障によってシステムが停止した場合、システム内の状態が異常な状態になることがままあります。たとえば、RDBMSで管理しているREDOログや、アプリケーション側で管理しているアプリケーションレベルのトランザクションを、正常な状態に戻す必要があります。また、ファイルシステムが破壊されている場合などは、バックアップからデータを戻す必要があります。このような復旧に関しても、運用系の機能要求として考慮に入れる必要があるでしょう。
今回は、非機能要求について確認しました。
非機能要求は、機能要求よりも共通性が高いので、一度パターン化することができれば、長い期間有効に利用することができます。このパターン化の枠組みとしてISO/IEC 9126(JIS X 0129)、FURPS+、RASISを利用するとよいでしょう。
ただし、分野や応用ごとに微妙に必要な項目や、項目の軽重が異なるので、目的に応じてチューニングをする必要があります。このチューニングがアーキテクトの腕の見せ所というわけです。
非機能要求はあまり表には出てきてきませんが必ず必要になる仕様です。また、一般的には同じ分野の仕事を続けて行うことが多いので、非機能要件のパターンを確立しておくと、再利用できる可能性は極めて高いものになります。
かなり地味ではあるものの必ず必要となり、パターン化が有効に働く技術である非機能要求を、きちんと業務の中に取り込む姿勢の有無がプロとアマチュアの差ということになりそうです。
International Organization for Standardization,http://www.iso.org/
ISOのホームページです。
ホームページの「Search」に"9129"を指定して検索すると、ISO/9129:1988のページにたどり着くことができます。ISO 9129:1988は、PDFまたはテキスト版を購入すると内容を参照することができます。
日本工業標準調査会ホームページ,http://www.jisc.go.jp/
JISの標準化を行っている日本工業標準調査会のホームページです。
データベース検索の「JIS検索」ページで"JISX0129"で検索すると、JIS X 0129のページにたどり着くことができ、PDFをWebブラウザで閲覧することができます。
ソフトウェア品質特性（ＩＳＯ／ＩＥＣ９１２６）の解説, http://www.cam.hi-ho.ne.jp/adamosute/software-quality/iso9126.htm
ソフトウェア品質マネジメント情報サイト(http://www.cam.hi-ho.ne.jp/adamosute)にあるISO/IEC 9126の解説ページです。
みんなが悩む要求管理-ソフトウェア要求の詳細な分類,玉川憲, http://www.atmarkit.co.jp/farc/rensai/re＿mgt02/re＿mgt02.html
FURPS+は、このページを参考にしました。
FURPSやFURPS+は、名前はよく聞くのですが、原典を特定することができなかったので、正確な定義などを確認することができませんでした。ボクの調査では、FURPSは『Practical Software Metrics for Project Management and Process Improvement』が原典ではないかと思われるのですが、現在のところ未入手なので参考情報です。