ガイドライン: ソフトウェア要求仕様書
トピック
ソフトウェア要求仕様 (SRS) では、プロジェクトに関するすべての要求を収集して整理することに焦点を当てます。たとえば、製品の特定のリリースの各機能について完全なソフトウェア要求を記述するために、別々のソフトウェア要求仕様を作成することが望ましい場合があります。これには、システムのユース・ケース・モデルから取り込んだいくつかのユース・ケースが含まれ、この機能の機能要求、対応する詳細な補足仕様書を記述します。
それらの要求を収集するためのツールは何種類かあるでしょう。要求はいろいろな成果物からさまざまなツールを使用して収集できることに注意してください。たとえば、補足仕様書内のテキスト文書化ツールを使用して、機能外要求や設計上の制約などの文書に記述されている要求を収集することが適切な場合もあるでしょう。一方、ユース ケース内の機能要求の一部 (または全部) を収集することが有益なこともあれば、ユース ケース モデルを定義するニーズに適したツールを使用することが便利なこともあります。
使用するツールの違いに注目することに、大した理由はありません。いずれにしても、要求を収集することが本題であるので、手元のツールにあまり注意を払うことなく、要求を効率よく収集して整理することに焦点を合わせるべきです。ツールではなく要求に焦点を合わせ、ソフトウェア要求仕様内の収集された要求は情報のパッケージを構成するものと想定します。システムに関連する種々の要求を詳しくまとめてソフトウェア要求仕様 (SRS) と呼ばれるパッケージ (以下、SRS パッケージ) を作成します。
SRS パッケージは、開発構想書と関係があることは明らかです。実際、開発構想書はソフトウェア要求仕様への入力情報として役立ちます。しかし、この 2 つの成果物は別々のニーズに応えるものであり、通常は作成者も異なります。プロジェクトのこの段階で、プロジェクトの焦点は、ユーザーのニーズ、目的と目標、対象とする市場、システムの機能に関する広範な記述から、それらの機能を実装する方法の詳細へと移ります。
ここで必要なものは、システムの外部的な振る舞いを完全に記述した成果物を収集したもの、またはパッケージです。つまり、「それらの機能を提供するために、システムはこういうことを行う必要があります」と具体的に記述したものが必要なのです。それを SRS パッケージと呼びます。
SRS パッケージは、ISO 9000 に準拠している証として作成され、その後でプロジェクトの進行につれて隅に押しやられて無視されてしまうような、凍結される著作物ではありません。それどころか、SRS パッケージは発展的な生きた成果物です。実際、開発者による実装作業において、SRS パッケージには多くの用途があります。SRS パッケージはすべての関係者の間での情報交換の基盤として役立ちます。その情報交換には、開発者同士の間と、開発者と外部のグループ (ユーザーを始めとするほかの利害関係者) の間の、両方が含まれます。公式にまたは非公式に、SRS パッケージは種々の関係者間の契約的な合意を表します。SRS パッケージに合意が記載されていない場合、開発者はパッケージを使用すべきではありません。SRS パッケージに合意が記載されている場合、開発者はその機能を使用する責任を負います。
ソフトウェアの要求仕様はプロジェクト管理者の参照標準となります。プロジェクト管理者には、開発者によって生成されたプログラムを読み、それを直接開発構想書と比較するような時間もエネルギーも技能もないことでしょう。プロジェクト管理者はプロジェクト チームと討論する際の参照標準として SRS パ ッケージを使用すべきです。
前に触れたように、SRS パッケージは設計グループと実装グループへの入力情報となります。プロジェクトの編成の仕方にもよりますが、開発者は早い段階から、開発構想書の作成につながった、問題解決と機能定義の作業に関与していた可能性があります。しかし、プログラムでなすべきことを決定するために開発者が焦点を合わせる必要があるのは、SRS パッケージなのです。SRS パッケージはソフトウェアのテストと QA を担当するグループへの入力情報ともなります。それらのグループも初期の検討に部分的に関与しているべきです。そうすれば、それらのグループのメンバーは開発構想書に盛られた「構想」をよく理解できるでしょう。しかし、ソフトウェアのテストと QA を担当するグループの使命は、開発されたシステムが SRS パッケージに盛り込まれている要求を実際に満たすことを検証するために、テスト・ケースと QA プロシージャーを作成することです。SRS パッケージは、それらのグループが計画を立案しテストを実施する際の参照標準としての役割も果たします。
ユース ケース モデルとユース ケース内で機能要求を定義するために推奨するアプローチの詳細は、「ガイドライン: ユース ケース モデルとガイドライン: ユース ケースを参照してください。
システムに関する機能外要求は成果物: 補足仕様書」などに記述されています。次に、これらの要求を定義する際に守るべきガイドラインについて説明します。
機能外要求の収集と検証においては、前提条件と問題点のリストを記録してください。
作業の中には、満足の行く答えが得られないものもあるでしょう。これは情報不足の場合や、単に担当者が設計の信頼性を損ないかねない答えだと受け留めたことが理由になっている可能性があります。したがって、以下のように 2 つのリストを作成し、設計の研究段階では両方を維持するようにしてください。
要求と設計プロセスで仮定する前提条件すべてのリスト。その前提条件の裏にある理由や考えも含める。前提条件は、該当プロジェクトの範囲外であったり、プロジェクト終了後に出てくると思われる関連のサブプロジェクトや作業項目を識別するのにも使用できます。
主要な問題点すべてのリスト (ショーを中断させる可能性のある重大な懸念事項)。
問題点は、各フェーズの終了ごとに、顧客にレビューしてもらう必要があります。前提条件も、各フェーズ終了時にレビューする必要がありますが、さほど重要ではないもののレビューは、必ずしも顧客に依頼するのが最善とは限りません。
前提条件と問題点はすべての成果物に当てはまりますが、特に機能外要求では高い共通性があります。
クライアントの組織の地理的分散を文書にします。
このシステムに影響を受けるビジネスの部分の地理的分散を文書化します。この定義は、影響を受けないサイトでも、主要な IT 設備をホストするものであれば含める必要があります。移動する組織の部分は、特記事項とします。たとえば、動き回りながらワークステーションを使用する営業陣などです。特殊な自然言語サポート (NLS) を行う必要のある可能性を持つ地理上の位置をメモします。
要求では、特別なアプリケーション パッケージの使用が指定されているでしょうか。システム設計における決断を大きく左右する可能性のある重要な"既知の条件"の 1 つに、事前定義されたソフトウェア論理とデータ構成を可能にするために特定のアプリケーション パッケージを使用する必要があるかどうかということが挙げられます。ソフトウェア パッケージには、柔軟性が高く大幅なカスタマイズが可能なものと、反対に決まった形を変えられないものとがあります。パッケージは、このような構成要素と決断をたとえば以下のような形で規定します。
- ワークステーション タイプ
- 接続メソッド
- プロセッサと直接アクセス記憶装置のタイプ (DASD)
- システム管理プログラム
- データの構成、配置、管理
- プログラミング言語
- バッチ インターフェイス
- プロセスとデータの関係
- ビジネス論理
- 画面設計とエンドユーザー インターフェイス
- 性能と可用性の特性
- 印刷のための既存または必要なアーキテクチャ。たとえば、使用頻度の高いデータ印刷フォーマット (PostScript、PCL、IPDT) など。
- 各国語対応 (NLS)
指定のパッケージのいずれかが、設計にどのような影響をもたらすかを理解しておくことは重要です。"指定の"パッケージを所有している場合は、そのパッケージに関する技術や知識が入手できるようにしておきます。これらは、たとえば以下のような人物によりもたらされます。
- パッケージ ベンダー。
- 外部のコンサルタント。
- 特別に教育を受けた設計チームのメンバー。
この知識をすぐに得られるといった思い込みはなくすことです。必要になったら利用できるように確保しておいてください。
設計の自由度を制限する要求のそのほかの既知の条件をすべて記載します。
これは、作業の早い段階では明示されないが、設計の自由度を制限する可能性のある特定の要求を把握するためです。たとえば、以下のようなものがないか調べます。
- 既存のプロセッサまたはオペレーティング システム イメージの使用
- 既存ワークステーションの設備の使用
- 既存ネットワークの使用
- 既存のシステム管理慣習の使用
- 以下のような特定のモデルの使用「プレゼンテーション、ビジネス、データ アクセスなどの論理を明示し、それらが相互に関係するところとその方法を明示するようなクライアント / サーバー システムのモデルを使用して設計しなければならない。」
これらの既知の条件の中に、新しいシステムに影響を及ぼすものがあるでしょうか。新規システムを既存のプロセッサ、オペレーティング システム イメージ、またはネットワーク構成で実行する必要がある場合、既存プラットフォームと作業量の特性が新規システムに影響を及ぼすことはないでしょうか。
従来の作業量に要した接続と処理の能力はどの程度でしょう か。
従来の作業量では、どのようなセキュリティ管理がなされているでしょうか。これらを記録し、新規システムのセキュリティ要件を検討する際に点検してください。
従来の作業量の可用性の特性はなにか。
のちに新規システムの可用性の設計に影響を及ぼす可能性のある事柄はすべて記録してください。たとえば、従来の作業量ではプロセッサすべてを毎晩シャットダウンすることを要求するでしょうか。
要求では、特別なハードウェアの使用が指定されているでしょうか。
これは一般的な用語 ("高速フラットベッド プロッタをサポートするシステムが必要です"など) で記述されている場合と、専門的な用語 ("既存の Panda Corp ATM をサポートします"など) で記述されている場合があります。以下について、できるだけ詳しく記録してください。
- ハードウェアまたはソフトウェアの事前条件すべて
- ベンダーとそのサポート組織
- 各国語対応 (NLS) についての注意点
- 暗号化設備
要求では、既存データの使用が指定されているでしょうか。指定されている場合は、それがシステム設計に影響します。ドキュメント :
- データが現在存在しているシステム
- データの構造 (相対またはフラット ファイルなど)
- データのサイズ
- 今日このデータを使用するユーザーとシステム
- 可用性についての注意点 (データベース保守やバッチ アクティビティのためにデータが利用できなくなる期間など)
- データの移動やコピーができるかどうか。
クライアントは、テクニカル アーキテクチャまたは IT 戦略、あるいはその両方 (または同等の基準) を持つでしょうか。
テクニカル アーキテクチャは、おおよそ以下のようなものです。
- 企業のテクニカル プラットフォーム
- 企業のテクニカル インフラストラクチャ
- テクノロジー アーキテクチャ
テクニカル アーキテクチャには、ユーザーに対し以下のような内容が定義されている場合があります。
- コンピューティング センターの数と用途
- 企業のネットワーク接続 (WAN)
- 特定の設備のローカルな接続 (LAN)
- クライアント / サーバー インフラストラクチャ サービス (ミドルウェア) の網羅
· ネットワーク・リソースと属性を追跡するディレクトリーと命名サービス · ネットワーク・リソースを、その使用を承認されていない登録ユーザーにより使用されることを予防し、その承認レベルを守るセキュリティー・サービス · ネットワーク全体の日付と時刻を統制する時刻サービス · ネットワーク内の多様なシステムにおけるリソースのリカバリーを調整するトランザクション管理サービス
- 新アプリケーションに使用される開発メソッド
- 以下のような、サポートしている製品の容認された組み合わせ
· ハードウェア
· システム管理プログラム
· "Office" など、幅広いアプリケーション・ソフトウェア
· ヘルプ・デスクの使用
· セキュリティー規則
このリストは非常に長いものになり得るので、記載項目を厳しく管理するか、まったく力を入れないかのいずれかになるでしょう。
以下のようなサブアーキテクチャの使用を特に必要とするか、あるいは除外するような要求を記録します。
- OSI または SNA
- UNIX**
- SAA
- OS/2* EE の PS/2*
パッケージ アプリケーションのソリューションの使用により自動的に指定されることのある特殊アーキテクチャ。アプリケーション パッケージには、それ自体がアーキテクチャ定義であるものがあります。
クライアントが要する開放度 (つまり、ベンダーの独立性と相互対話の能力) を記録します。テクニカル アーキテクチャがあれば、ほとんどの場合、それに準拠して設計する必要があります。テクニカル アーキテクチャを読み、システム設計に影響する規則を理解する必要があります。
クライアントにはシステムが対応すべきネットワーク アーキテクチャがあるでしょうか。ネットワーク アーキテクチャとは、高度な接続のための規則の共通の組み合わせと、共通のトランスポート インフラストラクチャのことです。これには、集配線装置や回線を含めたバックボーンのネットワークの定義が含まれる可能性もあります。このようなアーキテクチャがあれば、基本的な規則とトポロジーを理解し、以下を記録してください。
物理トポロジー (つまり、ネットワークの基本が地方または都市のいずれであるのか、ネットワーク接続の密度が高いのか低いのかなどについて) の注意点。
現在のネットワーク インフラストラクチャがサポートする高レベル接続機能。
これらの接続機能をサポートするために使用される接続の基準 (たとえば SNA、OSI、TCP/IP など)。
サポートされているプログラミング インターフェイス。
以下のような、クライアント / サーバーのレイヤ間または基本のシステム モデルのレイヤ間の接続についてのネットワーク アーキテクチャ定義
- クライアント ワークステーションと LAN 相対サーバー間の相対データ アクセスは、指定の相対データベース製品のプロトコルを通じて行う必要がある
- プレゼンテーション論理は必ずワークステーションに存在し、データ アクセス論理は必ず中央のホスト システムに存在する必要がある
クライアントの接続についてのポリシーは文書化されているでしょうか。
テクニカル アーキテクチャやネットワーク アーキテクチャがなくても、接続ポリシーは存在する可能性があります。
ポリシーの以下の点について記録してください。
- (1 戸の建物内で、または建物や組織外部へ接続するための) 特定のプロトコルまたは通信設備の使用
- 既存の設備やソフトウェアに対応するために自ずと必要となる特定のプロトコルがあるか
- 既存の接続設備 (ケーブル、電気配線、ネットワークや周辺機器のコントローラ、電話など) を使用すべきかどうか。ポリシーがなくても、使用できる物理設備のタイプについて制約がある場合があります (政策、国による規定、物理スペース、大家、第三者の参加など)。それらの制約を記録する。
- 物理設備のインストールや変更が必要になりそうな場合は、請負業者や電話会社などの第三者の作業が必要になる可能性がある。契約や責任の管理方法を理解する。これは、ビジネスが国際的な接続を含む場合に特に重要となる。
- モバイル ユーザーへのサポート
クライアントにはそのほかのポリシー、基準、または要求には明示されていない規則があるでしょうか。次に例を示します。
- 新システムのエンドユーザーへのインターフェイスはすべて、ドラッグ アンド ドロ ップというアクションが可能となるようにオブジェクト指向に設計しなければならない
- 新システムはすべて、クライアント / サーバー アプリケーション モデルに基づいていなければならない
- 新システムはすべて、オープン スタンダードで定義されなければならない
- 文章を右から左へ書く操作などの、各国語サポート (NLS) の基準とポリシー
- ユーザー承認、アクセス制御、データ保護の管理責任と基準を定義するセキュリティ ポリシー
- 特殊な設備や接続またはセキュリティが自ずと必要となるようなアプリケーション インターチェンジ基準 (UNEDIFACT や VISA など)
そのほかのポリシーがある場合は、それらをよく理解し、入手可能であるようにし、設計プロセスが進行した段階で、確実に基準に沿った設計をできるようにします。パッケージ アプリケーション ソリューションの使用により、自動的に何らかの基準が設定されることがあります。
以下に対し、ユーザーや部署に専用のローカル プログラムを追加したり開発したりすることを許可するポリシーは何でしょうか。
- ワークステーション
- サーバー (特にディスク容量)
管理しなければ、ローカル コンポーネントを購入した本来の目的であるシステムの構築のためのリソースが、ローカルであっという間に使い果たされてしまう可能性があります。生産システムがようやく現場で使用できるようになった頃には、もうインストールすることができないかもしれません。
ビジネス プロセスをもっと細かいビジネス プロセスやトランザクションなどに細分化するには、アプリケーション開発担当者と共同で作業します。
それは、次の質問の数値を調べなければならないので、どれを計上すべきかを決定する必要があるからです。
ビジネス プロセスは複数の小さなビジネス トランザクションのいくつかのインスタンス (たとえば顧客の 1 注文にある複数のアイテムの注文) を開始することがあり、数値の記録 においてはこれらの乗数を忘れないようにしなければなりません。ただし、あまり詳細にとらわれすぎてはいけません。特に、複雑なシステムでは要注意です。
ビジネス「プロセス」(たとえば、「顧客の注文の処理」など) は、通常「アプリケーション」(IT 用語) で実装されるか、複数のアプリケーションに渡って実装されます。各アプリケーション内には、通常多数の IT「トランザクション」が存在します。たとえば、「在庫数の照会」や「顧客へのレター作成」などです。
それぞれの団体が、我々が合意しようとしている単体を識別するために独自の名前を使用しています。たとえば、"トランザクション"がアプリケーション開発にかかわる人々に意味するものと、インフラストラクチャ関係の人々に意味するものとは全く異なっています。情報収集のためには、それぞれの名前を関連づけるための共同作業は重要です。
4.1 の各単体について、規模とサイズ調整の情報を調べ、記録してください。たとえば"測定単位"では、以下を調べ記録します。
- 各ビジネス プロセスやアプリケーションを使用すると予想されるユーザーの、平均数とピーク時の数
- ピークの発生周期 (毎日、毎週、毎月など、状態に応じ記録)
- ピーク時と平均時に必要とされるトランザクション処理速度
- 各データ グループのデータ要素とインスタンス数とそのサイズ
クライアントには、ビジネス プロセスの一部またはすべてに対し、性能基準が指定されていることがあります。ただし、システム サポート プロセス (システム バックアップなど) とアプリケーション開発プロセスの性能目標がわかれば、それも記録してください。各カテゴリに対し、以下を記録します。
- カテゴリ別の応答 / ターンアラウンド要求
- 測定部位
- 別の時期には別の基準があるかどうか (たとえばオフピークや夜間)
- リカバリ時や非常時にも基準を満たす必要があるかどうか
- 性能保証が要求されているか
- 性能要求が満たされない場合、誰かに与える影響はどんなものか
- ビジネス プロセスが利用可能であると判断できるパフォーマンス状態の最低ライン (つまり、それを下回るとシステムは"遅い"のではなく"利用できない"と見なされるライン) を明記する
- パッケージ アプリケーションのソリューションが既に選択されている場合、その性能特性を参照できるようにする。その全体が今必要というわけではないかも知れませんが、将来必要となる可能性が高いので、その入手方法を確保しておく必要がある。第三者から必要な数値の回答を得るには長時間を要する場合があるので、すぐに問い合わせる。
可用性の要求を設定するには、以下のような方法をお勧めします。
- システムの真のエンド ユーザー、彼らが実行するビジネス プロセス、そして彼らがそのプロセスを実行する時間帯を見極める
- サービス可用性 (または非可用性) がエンド ユーザーのビジネスの目的達成に与える影響を分析します
- エンド ユーザーがビジネスの目的達成に何を必要とするかが直接反映されている可用性要求を特定します
- パッケージ アプリケーションのソリューションが既に選択されている場合、エンド ユーザーから見たアプリケーションの可用性の特徴は、その構造と設計により大きく影響されることに注意してください。継続して操作するよう設計されていないパッケージを継続的に操作させるのは非常に難しい場合があります。特に、保守とバッチ ウィンドウなどでそれが顕著です。
可用性の要求を決定する際には、以下のガイドラインをご検討ください。
- 可用性の要求は、システム全体に"グローバル"なレベルに設定するのではなく、細分化されたレベルに設定してください。たとえば、個々のプロセス、ユーザー グループ、データ グループ別などに設定します。これにより、設計者はエンド ユーザーに合わせたより柔軟な設計ができます。これは、継続的な可用性を非常に高いレベルで要求されるシステムには特に重要です。
以下に例を示します。
- ステートメント"システムは毎日 24 時間起動しつづけ、ニューヨークと香港のユーザーに対応しなければならない"よりも、ステートメント"ニューヨークのユーザーは、自分たちのデータを、ニューヨーク時間の午前 7 時から午後 7 時までトランザクション可能である必要があり、香港のユーザーは、自分たちのデータを、香港時間の午前 7 時から午後 7 時までトランザクション可能である必要がある"のほうが、設計者にとって柔軟に設計する余地はかなり大きくなります。後者の場合は、設計者にとっては、片方の時間帯は生産時間の最中であっても、他方の時間帯のデータやシステム コンポーネントに対する保守を実行できるという柔軟性があります。
- ATM アプリケーションでは、月曜日の午前 3 時に現金の預金や引き落としを行なえるかどうかは重要でも、その時間に正確な口座残高を示すことができるかどうかはさほど重要ではありません。
- 可用性の「望ましい」特性と、「必須の」特性とをはっきり区別します。たとえば、"ATM は預金と引き落としを一日 24 時間受け付けることができなければならない。ATM が一日 24 時間正確な口座残高を提示できれば望ましい。ただし、口座残高照会プロセスがときどき中断することがあってもかまわないが、中断は 10 分未満とし、午前 3:00 から 4:00 までの間だけしか発生しないものとする。"
- 特定の可用性の目標が達成されなくても、ユーザーのビジネス目的の達成には直接関係がないのであれば、その目標はシステムの可用性要求として記述するには不適である可能性があります。
- エンドユーザーから見て、作業能力に間接的にしか作用しないような可用性要求 (たとえば、"IMS 制御領域が起動している必要がある"など) は、直接作用するもの (たとえば、"キャッシュ ディスペンサは、X と Y という作業ができなければならない"など) ほど利用価値はないことが多いのです。
各ビジネス プロセスとそれを実行する必要があるユーザー グループに対し、ユーザーがそのプロセスを実行できなければならない時間帯を特定します。ユーザー グループには直接関係しないプロセスに対しても、この作業を行ってください。
異なる時間帯に複数のユーザー グループ (上記のニューヨークと香港の例のような場合) は、別々に扱う必要があります。
また、休日などのように、アプリケーションが不要である日が時々あれば、それも示します (これにより、設計者はより大規模な保守のために柔軟に利用できます)。アプリケーションの予想寿命において、こうしたサービス時間帯にどのような変更が予見できるでしょうか。
システムのサービス時間帯は、そのシステムが対話するほかのシステムに影響されることもあります。
このシステムに規定のサービス時間帯は、予想寿命の間にどのように変化し得るでしょうか。
規定のサービス時間帯におけるサービスの中断が原因でもたらされるビジネスへの影響、金銭的費用、リスクを把握してください。
そのシステムに本当に重要な可用性要求を特定するには、ビジネス プロセスとユーザー グループの組み合わせを考え、以下によりもたらされるビジネスへの影響を特定してください。
- 規定の時間内の、短期的な中断または受け入れがたいほど遅い応答。この指定のアプリケーションに関して"短期的"と"受け入れがたいほど遅い"というのがどの程度を指すのか定義します ("ビジネス プロセスの性能基準"を参照)
- 上記の規定の時間内の、より長期のいろいろな長さの中断 (1 分、数分、15 分、30 分、1 時間、2 時間、4 時間など)
- サービスの長期中断 (シフト制、1 日、数日など)
- ユーザー グループとは直接的な関係がないプロセス (たとえば、一夜ごしの小切手の清算など) も検討してください
それぞれの停止の影響を計り、非常時のプロシージャを特定し、停止による真のビジネスへの影響を軽減する方法を検討してください。
この影響を、できるだけ金額に換算して数値化するようにしてください (奪われるスタッフや設備の生産性の金銭換算額、現在喪失したビジネスの価値、顧客の不満により喪失を予想される将来のビジネス、金利、罰金など)。
停止の時期、それが計画されたものかそうでないか、またどのビジネス プロセスやユーザーに影響するのかなどの条件別の費用とリスクの違いを反映するために必要な情報を、できるだけたくさん提示してください。
サービスの中断によるビジネスや金銭上の影響が、このシステムの予想寿命中にどのように変化するか。
これらの重要であると合意されたビジネス プロセスをレビューし、システムが一時的に利用不可能になっても、そのプロセスにとって最も重要な要素は進行できるようにするための代替手段を特定してください。ビジネス機能を縮小して一時的に操作を続けるようにすると、重要なプロセスとデータ間の相互依存から来る可用性の影響を抑えることができる場合があります。
以下に例を示します。
- 完全機能 1 株式レコードを読み取り更新します
- 縮小機能 1 株式レコードの更新情報を入力し、将来の更新時までキューに入れます
- 完全機能 2 最新の顧客の残高を読み取ります
- 縮小機能 2 顧客の残高を代替ソースから読み取ります。ただしこのソースは最新のものではない可能性があります。
- 完全機能 3 コンピュータのダイアリを更新します
- 縮小機能 3 紙に印刷されたダイアリを更新します
システムが縮小機能で稼動している場合は、ビジネス プロセスにとって許容範囲である限界がある場合があります。たとえば、時間切れの顧客の残高は、24 時間超過より古くてはなりません。
通常、規定の時間帯にサービスが中断した場合 ("規定のサービス時間帯"を参照) の影響は、停止期間とそのほかの条件により変化します。停止の状態によっては、ユーザーがビジネス プロセスを実行するのにほとんど影響がないこともあります。たとえば、日中でも使用度の低い期間に発生した短期の停止や、ユーザー グループの一部にしか影響のないもの、または許容範囲の手作業による非常時プロシージャがある場合などです。そのほかの停止で、より期間が長いものや日中の"重要な"期間に発生したものは、より大きな影響を持つことになります。
以下に例を示します。
- 加工ラインの制御プロセスが短期的に停止しても生産性にはあまり影響がありません。なぜなら、事前に印刷された作業行程にしたがって作業を続行することができ、変更点は後で入力するために手で書き込んでおくことができるからです。しかし、1 時間を超える停止では、シフトの残り時間中ラインを停止することになりかねません。
- 扱いドル高の多い金融システムが取引終了 1 時間前に停止すると、莫大な額の金利費用や罰金などが発生する可能性があります
- 生命を脅かす緊急事態に対する警察や消防隊の措置は、出動システムが利用できなくなっても、手動の代替プロシージャを使用して実行できます。しかし、出動作業が増大するために応答時間が遅延し、生命が危険にさらされる可能性が高まることもあり得ます。
- 航空システムやホテル予約システムのピーク時の停止は、顧客が競合他社に電話して予約してしまうという現在のビジネス機会の喪失ばかりでなく、顧客の失望感が高ければ、次回からは先に他社に電話するようになるかもしれず、将来の機会喪失にもつながりかねません。
"通常"の状況で適用される「可用性とリカバリの基準」を特定します。
コンピューティング設備全体の大規模な喪失やシャットダウンなどの、"障害"の状況は考えません。
"サービス停止による費用"で取り上げたビジネスと金銭的な費用とリスクを基に、ユーザー グループが、彼らに割り当てられたビジネス プロセスを、重大な障害なく実行するために満たすべき可用性の基準を設定します。このような基準は、以下のような形式で指定してください。
- 発生した停止のうち何パーセントが、指定の分 / 秒数以内にリカバリすべきか
- ユーザーが特定の機能を実行できない期間は、何週間 / 何か月 / 何年を超えてはならないか
停止が計画されたものかそうでないか、その時期 ("重要"な期間対使用度の低い期間など)、また全ユーザーに影響するのか、一部のユーザーだけなのかなどの条件を反映するために必要な情報を、できるだけ具体的に指定してください。
可用性の基準を不必要に厳しく設定すると、実装費用が大幅に増大するので注意してください。一般に、ある特定の停止条件の組み合わせによるビジネスや金銭的な費用やリスクがあまり大きくない場合は、その組み合わせは可用性基準からは除外すべきである可能性があります。
"規定されたサービス時間帯"と"サービス停止による費用"で述べたように、システムの予想寿命内に規定されたサービス時間帯が変わる可能性があり、サービス停止によるビジネスや金銭的な費用やリスクが変わる可能性がある場合は、その結果として可用性の基準がどのように変化するかを予測します。
暗号化を使用する場合は、上記以外にもリカバリーや可用性について注意すべき事柄があります。次に例を示します。
- システム外にある秘密情報をリカバリする能力
- 暗号で保護されたデータのリカバリには、必ず適切な暗号キーのリカバリとの組み合わせで行うこと
障害リカバリは設計プロジェクトで網羅すべき問題でしょうか (コンピューティング設備全体の大規模な喪失やシャットダウンなどの"障害"状態における可用性についてです)。もしそうなら、リカバリの基準は何でしょうか。
ビジネス プロセスすべてに、障害リカバリ機能が必要というわけではありません。重要であり、障害リカバリを必要とするプロセスを選択してください。そのプロセスの中でも、すべての機能を網羅する必要はないかもしれません。
- どのくらいの時間内にサービスを回復する必要があるでしょうか。この時間は、障害発生時からの時間でしょうか、それともリモート サイトへ移動することを決心したときからでしょうか
- どのような条件が揃うと、組織はローカルにではなくリモート サイトからの回復を決断するのでしょうか
- ビジネスの操作を続行するために、リモート サイトのデータはどのくらい新しいものである必要があるでしょうか。まったく最新のものであるべきか、数分の誤差は許されるのか、それとも昨日のデータでもよいのでしょうか。
- サービスが最初にリモート サイトから回復されるのはいつでしょうか
- 将来的にいつかの時点で行うのでしょうか
- リモート サイトにおけるこのアプリケーションの回復の優先順位は、同一のコンピューティング設備に依存するほかのビジネス アプリケーションと比較してどの程度でしょうか
システムの部位により、また障害のタイプにより、さまざまな基準があることに留意してください。
アプリケーションの予想寿命内に、上記の障害リカバリ要求に対してどのような変更が予想されるでしょうか。
できるだけ回復の早いシステムを設計するには、設計者はアプリケーション実装時に、そのアプリケーションの機能上の要求を満たしつつどのような応用が可能かをよく知っている必要があります。設計者は、以下のチェックポイントを確認してください。
1. 必要な保守作業を実行するとき、以下のいずれかの状態でシステムを短期的に稼動できますか。
a. 照会のみ行い、更新はしない。
b. ユーザーからの更新要求を受け付けるが、実際にデータベースを更新するのではなく、保守作業が終了してから更新する。
2. データのリカバリが必要な停止に対して、以下のうち最も重要なのはどれですか。
c. 最新のものではないデータを使用しても、サービスをできるだけ速やかに回復する。
d. 時間がかかってもすべてのデータを最新のものにリカバリしてから、サービスを回復する。
3. 障害発生時にユーザー要求が"処理中"であった場合、サービスのリカバリ後にユーザーが要求を再入力できることが保証されていますか。
4. このシステムの可用性に影響する可能性のあるテクニカル以外の注意点があるでしょうか。たとえば、プロセス A の利用は、プロセス B が利用可能であるユーザーに対してのみ許可する、というようなビジネス ポリシーなど。
上記の設計の注意点は、将来変わる可能性があるか。
ビジネスに重要なプロセスには、システムが部分的に一定期間利用不可能になっても、そのプロセスの最重要な要素だけは機能している状態に見せるための代替手段を決めておくと便利です。ビジネス機能を縮小して一時的に操作を続けるようにすると、重要なプロセスとデータ間の相互依存から来る可用性の影響を抑えることができる場合があります。
1. 保護するデータを特定してください。
2. それぞれのデータ タイプに対しどのような問題が起こり得るかを以下のように特定 してください。
- 事故による損傷や破壊
- 意図的な損傷や破壊
- 商業情報
- 詐欺
- ハッキング
- ウィルス
1. 物理的なセキュリティに対する脅威を特定してください。
2. 脅威の原因となり得る人物を特定してください。
- データ センターのスタッフ
- そのほかの IT スタッフ (開発者など)
- 組織の IT 以外のスタッフ
- 組織外の人物
3. 特に以下の点に関連して、特別な場合のセキュリティ要求を特定してください。
4. 情報の自由の条例のように、このシステムのセキュリティ設計に影響する可能性のある一般的規則はありますか。
5. パッケージ アプリケーションのソリューションには、独自のサブシステムが備わっている場合があります。"既に"パッケージがある場合は、そのセキュリティ機能に注意してください。
セキュリティ要求を設定し分類するために、以下の手段を利用できます。
1. 論理的または物理的なセキュリティにより保護される必要のあるオブジェクトをリストします。
2. 各オブジェクトについて露出度を特定します。通常は以下のように分類できます。
- 表示アクセス (機密性は守りません)。口座情報、クライアント リスト、商標など。
- 更新アクセス。詐欺、隠ぺい、資産の改ざん等の目的でデータが変更される可能性があります。
- 資産喪失。他人が所有物を奪い、本来の所有者には利用できない状態 (障害による損失から明らかになる)。その例を下に示します。クライアント リストと見込み客クライアント、連絡先など。
オブジェクトすべてが上記の露出で注意が必要なわけではありません。
3. 自分の環境において考えうるすべての脅威を特定してください。次のような例があります。
- 不満を持つ従業員
- 未承認の従業員
- 公の場所でのオープン ターミナル セッション
- ハッカー
- 盗聴
- 機器の喪失 (ノート PC など)
4. 各オブジェクトに、発生し得る脅威を設定し、それを露出度と関連づけます。
1 か所に静止したオブジェクト (ハードディスクの中など) と、移動中のオブジェクト (転送中のものなど) の両方に対するセキュリティ要求を確認する必要があります。
設計によりオブジェクトの場所がセキュリティで保護されていない領域へ拡張される場合があるので、この項は再度確認する必要があります。
システム設計によっては、非常に高度なセキュリティーを要求するものがあります。それは、現在の設計についての判断の中心となります。セキュリティー要求の高いシステムでは、要求が高くなければ選択できたはずの構造やコンポーネントが選択できなくなることがあります。ですから、現在設計中のシステムを特にセキュリティー要求の高いものにするかどうかを、この時点で決断してください。次に例を示します。
- 軍用機密システム
- 高額の送金システム
- 機密人事情報を処理するシステム
特に高いセキュリティが必要であると判断される場合は、セキュリティの専門家や弁護士に依頼し、システムの設計面でサポートを受けてください。
使いやすさの要求により、ユーザー インターフェイスの使いやすさのレベルが定義されます。
使いやすさの要求は、使用にあたりシステムで達成せねばならない最低限の使いやすさのレベルに設定する必要があります。これは、システムで達成可能と思われるレベルに設定してはいけません。つまり、使いやすさの要求は、ターゲット (上限) とみなすべきではないのです。使いやすさの要求では、システムの使いやすさの最低限の許容ラインが定義されなければなりません。したがって、使いやすさの要求が満たされても、使いやすさを向上させることをやめる必要はありません。
使用してもらうためにシステムによって実現されるべきことは、ほとんどの場合、システムがとって代わる代替の方法によって変わります。システムが、システムを使用する以外の方法よりもはるかに使いやすいことが求められるのは当然です。代替の方法では次を利用します。
- 既存の手動プロシージャ
- 既存のシステム
- 競合商品
- 以前のバージョンのシステム
使いやすさの要求は、新しいシステムの必要性を採算性の点からも証明するために挙げられる場合があります。顧客が新しいシステムに 3 億円投資しなければならない場合、顧客の人材にかかる作業量を減らして年間 1 億円を節約できる可能性があるという使いやすさの要求を課す可能性があります。
一般的な使いやすさの要求の例をいくつか、下に示します。
- 最大実行時間 - トレーニングを受けたユーザーが一般的なシナリオを実行するまでの時間。
- 最大エラー率 - トレーニングを受けたユーザーが、一般的なシナリオについて平均したエラーの数。
評価に関連する唯一のエラーは、修復不可能なエラーで、客足が遠のいたり、監視対象のハードウェアに障害が発生するなど、組織に対してマイナスの影響があります。エラーの唯一の結果が修正に時間がかかる場合、評価される実行時間に影響します。
- 学習時間 - ユーザーが指定された最大実行時間より速くシナリオを実行できるようになるまでの所要時間。
以下は、"受信メール メッセージの管理"ユース ケースに固有の使いやすさの要求の例です
- 「メール ユーザー」はマウス クリック 1 回で「メール メッセージ」を配置できなければならない
- 「メール ユーザー」はキーボードのキー 1 つで「メール メッセージ」のテキストをスクロールできなければならない
- 「メール ユーザー」が受信済みの「メール メッセージ」を読んでいるときは、新着の「メール メッセージ」によって邪魔されてはならない
|