Personal tools
You are here: Home executable Knowledge Project Management IEEE1362-1998
Document Actions

IEEE1362-1998

by YAMADA Masaki last modified 2006-06-12 18:32

操作要件書の書き方

IEEE Std 1362-1998, IEEE Guide for Information Technology - System Definition - Concept of Operation Document より

山田正樹(メタボリックス)

masaki@metabolics.co.jp


Title page

(表題ページ)

Revision chart

(改訂履歴)

Preface

(前書き)

Table of contents

(目次)

List of figures

(図版一覧)

List of tables

(表一覧)

1. Scope

(範囲)

この節では、ConOpsとその対象となるシステムの概要を書く。

1.1. Identification

(識別)

この小節では、識別番号、表題、このConOpsが対象とするシステムやサブシステムの省略名を(もしあれば)書く。システム全体に関する複数のConOps文書を階層的あるいはネットワーク的に作成している場合には、他のConOps文書とこの文書との関連も書いておくべきである。

1.2. Document overview

(文書の概要)

この小節では、このConOps文書作成の目的をまとめて展開する。この文書を誰に向けて書いているかも明記する。さらにこの小節では、このConOpsの利用に際しての機密性やプライバシーについても書いておく。また、残りの部分についての概要を記述する。

ConOps文書の目的はほとんどの場合、以下のいずれかである。

  • 提案するシステムに対するユーザのニーズや期待について、購買者や開発者に伝える
  • ユーザのニーズや、このニーズを充たすためにシステムがどのようにふるまえばよいかということに関する購買者や開発者の理解を伝える

しかし、ConOps文書を他の目的に用いることもある。例えば、複数のユーザ集団/購買組織/開発者間で合意を形成したいような場合である。

ConOps文書の対象者にはさまざまな人々がいる。

  • ユーザは、自分たちの代表者が自分たちのニーズと欲求を正しく指定しているかどうかを見極め、開発側が自分たちのニーズを正しく理解しているかどうかを確かめるためにこの文書を読むだろう
  • 購買者は、ユーザのニーズと、開発者のニーズに対する理解についての知識を得るためにこの文書を読むだろう
  • 開発者は通常、システム開発の基礎とするために、また開発チームの新メンバがConOpsの対象となる問題領域とシステムに馴染むためにこの文書を読むだろう

1.3. System overview

(システム概要)

この小節では、このConOpsの対象となる提案システムあるいはサブシステムの目的を手短かに述べる。内容としては、システムの一般的性質を述べ、プロジェクトのスポンサ、ユーザの代表、開発組織、支援者の代表、証明者(あるいは組織)、システムを稼動させる運用センタあるいはサイトなどを明確にする。また、現状システムや提案システムに関連する他のドキュメントも明らかにしておく。

システムをグラフィクスで表すことを強く薦める。これにはコンテキスト図やトップ・レベルのオブジェクト図、それ以外にもシステムとその環境を表現できるような図を用いればよい。

ここで引用するその他の文書としては、プロジェクトの認可、関連する技術文書、重要な論文、関連するプロジェクトについての文書、リスク分析報告書、実現可能性に関する調査書などがあげられる。その他にもあるだろう。

2. Referenced documents

(参照)

この節では、このConOps文書で参照するすべての文書の識別番号、題名、版、日付けを列挙する。通常の経路では入手できないような文書については、その入手元についても明確にしておく。

3. Current system or situation

(現在のシステムや状況)

節3では、現在あるがままのシステムや状況(自動化されているにしろ、手動であるにしろ)を記述する。変更を加えるべき現行システムがない場合には、提案システムの開発の動機となった状況について記述する。この場合には、以下の小節を状況の動機を記述するのに適した形に変えてもよい。

またこの節では、読者を問題領域に導き入れる。これによって、読者は要求された変更や強化の理由をよりよく理解できるようになる。

3.1. Background, objectives, and scope

(背景、目的、範囲)

この小節で、現在のシステムや状況の概観を与える。それには適用対象、背景、使命、目的、範囲などが含まれる。現行システムの背景の記述に加えて、この小節では現行システムの動機も短くまとめておく。システムの動機の例としては、あるタスクの自動化やあるよくない状況への対処などがある。現行システムの目標も、それを果たすのに用いられる戦略、解決法、戦術、方法、技術とともに定義しておく。運用モード、ユーザ層、運用環境へのインタフェースなどが提案システムの範囲を定義することになるので、それらもこの小節で概要を書き、以下の小節では詳細を書く。

3.2. Operational policies and constraints

(運用のポリシーと制約)

この小節では、現在のシステムや状況に適用される運用のポリシーと制約について記述する。運用のポリシーとは、現行システムの運用に関してあらかじめ決められている管理上の決定事項である。通常は意志決定活動のガイドとなる一般的な文章や理解の形をとっている。ポリシーは意志決定の自由度を制限するが、ある程度の自由は許容する。運用上の制約とは、現行システムの運用に科せられた制限である。運用上の制約の例としては、以下のようなものがある。

  • システム運用の時間に関しての制約(例えば機密性の高い端末へのアクセスの制限)
  • システム運用可能な人数の制約
  • コンピュータ・ハードウェアの制約(例えばX計算機を使わなければならない)
  • 運用設備の制約(事務所など)

3.3. Description of the current system or situation

(現在のシステムや状況について)

この小節には、現行システムの記述の大部分が含まれる。それは現在のシステムや状況の記述で、場合に応じて、以下のようなものである。

  1. 運用環境とその特性(characteristics)
  2. 主要なシステム・コンポーネントとそれらの間の相互接続
  3. 外部のシステムや手続きへのインタフェース
  4. 現行システムの能力(capability) 、機能(function)、特徴(feature)
  5. 現在のシステムや状況をユーザの視点から理解するのに十分なだけの、入力、出力、データ・フロー、制御フロー、手動/自動化された処理単位(process)を表現するチャートや附随説明
  6. システム運用の費用
  7. 運用上のリスク要因
  8. 速度、スループット、量、頻度などの運転性能
  9. 可用性、正確さ、効率、拡張可能性、柔軟性、相互運用性、保守容易性、可搬性、信頼性、再利用可能性、支援容易性、生存可能性、利用容易性などの品質属性
  10. 緊急時運用に際しての安全性、機密性、プライバシー、合一性(integrity)、連続性への準備

この小節の目的は現行システムとその運用方法を記述するものなので、この目的に適う適当なツールや技法を利用してかまわない。重要なのは、この文書の対象とするすべての読者がシステムの記述を完全に理解できるように、十分に簡素に、十分に明確にしておくことである。また、ConOpsはユーザの用語を用いて記述するように心掛けることも重要である。つまり、多くの場合計算機特有の用語(ジャーゴン)は避けるべきということになる。

ConOps文書は特に複数の異なる種類の読者にとって理解できるものでなければならないので、できるだけ図的な表現方法を使いたいものである。有用な図的表現としては、作業細分化構造(WBS)、N2チャート、シーケンス図、アクティビティ図、機能フロー・ブロック図、構造チャート、割り当て図、データ・フロー図(DFD)、オブジェクト図、コンテキスト図、コンテ(storyboard)、E-R図などがある。

運用環境の記述では、可能ならば、現行システムの運用に用いられている設備、機器、計算機ハードウェア、ソフトウェア、人員、運用手続きを指定しておく。読者が運用に用いられている機器の数、バージョン、容量などについてよく分かるように、必要なだけ詳細に記述する。例えば、現行システムにデータベースが含まれているならば、記憶装置の容量についても指定し、ユーザの運用能力に有効な影響を与えるような情報を提供する。同じく、現行システムが通信リンクを使っているならば、ユーザの能力、応答時間、スループットのような要因に影響をおよぼすようなリンクの容量についても記述する。

現行システムの運用や運用環境に影響を及ぼすような安全性、機密性、プライバシーの見解についても記述する。

ConOps文書の著者は、現行システムについての明確な記述が達成される限りにおいて、システムや状況に適した形でこの小節の情報を組織化してよい。もし記述の一部分が大部になるのであれば、それを付録に入れたり、参照の形で取り入れてもよい。付録に入れるとよいと思われる素材の例としては、データ辞書があげられる。参照の形で取り入れるとよいと思われる素材の例としては、現行システムの運用ポリシーの詳細マニュアルや手続き書がある。

3.4. Modes of operation for the current system or situation

(現在のシステムや状況の運用モード)

この小節では、現在のシステムや状況の運用のさまざまなモード(運用モード、制限モード、保守モード、教育モード、緊急モード、移動時、平時、戦時、地上時、飛行中、活性モード、アイドル・モードなど)について記述する。すべてのユーザ層に対して適用されるすべてのモードを網羅する。重要なモードとしては、制限モード、バックアップ・モード、緊急モードなどがあるだろう。特に地理的に離れたサイトや機器にまたがるようなモードでは、システムの運用の観点から重要な影響があるものである。

さらにこの小節は、モードごとに下位レベルの小節に分割してもよい。相互参照マトリックスを用いて、各モードにシステムの処理単位、手続き、能力、機能などを関連づけるのがよい場合もある。

3.5. User classes and other involved personnel

(ユーザ層とユーザ以外の関係者)

ユーザ層とは、ユーザがシステムとどのように相互作用するかという基準で切り分けたものである。ユーザ層を区別する要因としては、共通する責任、熟練の度合い、作業活動、システムとの相互作用のモードなどがある。異なるユーザ層は、システムとの相互作用において異なる運用シナリオをもつ。この文脈でいえば、ユーザとは現行システムと相互作用する人々のことで、それには運用ユーザ、データ入力スタッフ、システム・オペレータ、運用サポート・スタッフ、ソフトウェア保守者、トレーナなどがある。

この小節は、内容を伝えるのに役立つならば、さらに以下のように組織立てることもできる。

3.5.1. Organizational structure

(組織構造)

この小節では、現行システムと関係のあるさまざまなユーザの集団やユーザ層の現時点での組織構造を記述する。組織図は、この目的に役立つ図的表現方法である。

3.5.2. Profiles of user classes

(ユーザ層の輪郭)

この小節では、現行システムの各ユーザ層の輪郭を記述する。あるユーザが複数の役割を演じる場合には、役割ごとに異なるユーザ層として指定しなければならない。

オペレータや保守者も含めて、現行システムの各ユーザ層ごとに別の小節に記述する。それぞれごとにユーザ層の記述を並べるが、それには責任、教育、背景、熟練の度合い、活動、現行システムの相互作用のモードを入れる。

3.5.3. Interactions among user classes

(ユーザ層間の相互作用)

この小節では、現行システムに関わる複数のユーザ層の間での相互作用を記述する。特にユーザ集団やオペレータ、保守者の間の相互作用を書かなければならない。システムのユーザ間に起こる相互作用とユーザとユーザ以外の人との間に起こる相互作用、また、組織内での相互作用と組織境界をまたがる相互作用の中で現行システムの運用に関係しているものはすべて記述しなければならない。その中には、公式なものも非公式なものも含まれる。

3.5.4. Other involved personnel

(他の関係者)

この小節では、システムと直接には相互作用しないが、現行システムに影響を与え、あるいは現行システムから影響を受けるような人々について記述する。例としては、執行管理者、ポリシー決定者、ユーザの顧客などがある。これらの各人はシステムと直接的な相互作用は持っていないが、新規の、あるいは変更されたシステムとは大きな影響関係を持つことになるのである。

3.6. Support environment

(支援環境)

この小節では、現行システムの支援に関する考え方と支援環境について記述する。その内容は支援を行う代理者、設備、機器、支援ソフトウェア、修理あるいは交換条件、保守レベルと保守サイクル、保存/配分/供給の方法などである。

4. Justification for and nature of changes

(現状変更の正当性と性質)

ConOps文書の4節では、新しいシステムの開発、あるいは現行システムの変更の動機となった、現在のシステムや状況の欠点について記述する。この節は、現在のシステムや状況を記述したConOpsの3節から、提案システムを記述したConOpsの5節への橋渡しの役目を果たすことになる。変更の元となる現行システムがない場合には、この節ではその旨を書いて、新規システムの特徴の正当性を記述する。

4.1. Justification of changes

(現状変更の正当性)

この小節では、

  1. 新しい、あるいは更新されるユーザのニーズ、使命、目的、環境、インタフェース、人員などの新規/変更システムが必要とする要因を手短かにまとめる
  2. 新しい、あるいは更新された要因に応えることができないような現在のシステムや状況の不足点や制限をまとめる
  3. 新しい、あるいは更新されるシステムの正当性を用意する
    1. 提案システムが新しい機会に合わせるためのものならば、この機会に合わせるために新規システムを開発しなければならない理由を記述する
    2. 提案システムが現在の運用を強化するためのものならば、現行システムを変更するという決断に至った根拠を記述する
    3. 提案システムが新しい機能能力を実現するためのものならば、なぜその機能が必要かを記述する

4.2. Description of desired changes

(必要とされる現状変更について)

この小節では、4.1.で指定した要因に応えるために必要となる、新規/変更システムの能力、機能、処理単位、インタフェース、その他の変更についてまとめる。変更は、このConOps文書の3節に記述した現行システムにもとづくものとする。変更の元となる現行システムが存在しない場合には、この小節には新規システムが提供する能力をまとめる。記述には必要に応じて以下のものを含める。

  1. 能力の変更: 新規/変更システムがその目的や要求に合わせるために付加/削除/変更する機能と特徴の記述
  2. システム処理の変更: 同じ入力に対して新たな出力を行う、あるいは新たな入力に対して同じ出力を行うようなデータ変換の処理単位の変更についての記述
  3. インタフェースの変更: インタフェースに変更をもたらすようなシステムの変更や、システムに変更をもたらすようなインタフェースの変更についての記述
  4. 人員の変更: 新しい要求、ユーザ層の変化などによる人員の変更についての記述
  5. 環境の変更: システムの機能、処理単位、インタフェース、人員の変更をもたらすような運用環境の変更や、システムの機能、処理単位、インタフェース、人員の変更によって環境にもたらされる変更の記述
  6. 運用の変更: 上記の変更によってもたらされるユーザの運用上のポリシー、手続き、方法、毎日の作業ルーチンの変更の記述
  7. 支援の変更: システムの機能、処理単位、インタフェース、人員の変更によってもたらされる支援要求の変化や、支援環境の変更によってもたらされるシステムの機能、処理単位、インタフェース、人員の変更についての記述
  8. その他の変更: ユーザに影響を与える(他のカテゴリにはあてはまらない)その他の変更

4.3. Priorities among changes

(現状変更の優先順位)

この小節では、必要とされる変更や新たな変更の優先度を指定する。それぞれの変更は、なければならない/あった方がよい/あってもよいの三つに分類される。あった方がよい/あってもよいの二つについては、その中でさらに優先順位をつける。変更の元となる現行システムが存在しない場合には、この節では提案システムの特徴を分類し、優先順位をつける。

  1. 必須の特徴: 新規/変更システムでなくてはならない特徴。この特徴が実現されなかった場合の影響をそれぞれの必須特徴ごとに説明する
  2. 望ましい特徴: 新規/変更システムにあった方がよい特徴。それぞれにさらに優先順位をつける。なぜこの特徴が望ましいのかをそれぞれの特徴ごとに説明する
  3. あってもよい特徴: 新規/変更システムにあった方がよい特徴。それぞれにさらに優先順位をつける。なぜこの特徴があってもよいのかをそれぞれの特徴ごとに説明する

要求される変更と新しい特徴をなければならない/あった方がよい/あってもよいの三つに分類することは、提案システムの開発中の意志決定プロセスにとって重要なこととなる。また、予算が超過したり、スケジュールが遅れた場合、この情報にもとづいてどの特徴は完成させなければならないか、どの特徴は延期したり、省略してよいかの決断をくだすときにも役に立つだろう。

4.4. Changes considered but not included

(今回含まれなかった現状変更)

この小節では、検討はしたもののこのConOps文書の4.2節には含まれなかった変更と新しい特徴、またその根拠を指定する。検討はされたが、提案システムには含まれなかった変更や機能を記述しておくことによって、著者は自分達の分析活動の結果を文書として残しておくことができる。この情報は、システム開発に関わるユーザ、購買者、開発者のような他のメンバが、ある変更や特徴について検討されたかどうか、検討されたならばなぜ今回の開発には含まれなかったかを知りたい場合に役に立つはずである。特にソフトウェアにおいては、何が変更、強化されたかとか、何がまだ安全性や機密性に欠けるか(例えばあるシナリオや回避策において)などを外に向かって知らせることがあまりないものである。

4.5. Assumptions and constraints

(前提と制約)

この小節では、この節で指定する変更や新しい特徴に適用される前提条件や制約条件について記述する。これには、新規/変更システムの開発や運用上ユーザが影響を被るようになるすべての前提条件や制約条件について記述しなければならない。前提条件とは、正しいはずであると考えられるような条件のことである。前提条件の例としては、システムの負荷が今後2年間の内に2倍になり、より高性能な新規システムが必要になる、というようなものがある。制約条件とは、新規/変更システム、あるいはシステムの開発/変更プロセスに外部から課せられる制限のことである。制約条件の例としては、外部インタフェース要件、スケジュールや予算の制限などがある。

5. Concepts for the proposed system

(提案システムの概念)

この節では、ConOps文書の4節で指定された望まれる変更から導かれる提案システムについて記述する。この節で記述するのは、高レベルでの提案システムであり、設計の詳細までは指定しないで提供できる操作上の特徴を表すものである。ここで用いる記述の方法と記述の詳細さの度合いは状況に応じて異なる。詳細度は、提案システムを運用すればユーザのニーズと購買者の要求が満たされるいうことを納得させるのに十分なものでなければならない。

場合によっては、ConOpsに詳細設計のあるレベルまでを提供する必要があることもあるだろう。ConOpsは設計の指定まで含んでいてはいけないが、提案システムの運用上の詳細を明らかにするために典型的な設計の方針のいくつかの例を含むことはありうる。提案システムの記述に実際の設計上の制約まで含む必要がある場合には、無用な誤解を避けるためにそれが必要であったということを明示しておくべきである。

註 - 提案システムの特徴の中で、元のシステムのものと同じものがある場合には、小節番号と小節名の後に「変更無し」と書き添えておく。

5.1. Background, objectives, and scope

(背景、目的、範囲)

(3.1.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.2. Operational policies and constraints

(運用のポリシーと制約)

(3.2.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.3. Description of the proposed system

(提案システムについて)

(3.3.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.4. Modes of operation

(運用モード)

(3.4.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.5. User classes and other involved personnel

(ユーザ層とユーザ以外の関係者)

(3.5.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.5.1. Organizational structure

(組織構造)

(3.5.1.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.5.2. Profiles of user classes

(ユーザ層の輪郭)

(3.5.2.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.5.3. Interactions among user classes

(ユーザ層間の相互作用)

(3.5.3.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.5.4. Other involved personnel

(他の関係者)

(3.5.4.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

5.6. Support environment

(支援環境)

(3.6.と同様の内容を、現在のシステムや状況の代わりに新規/変更システムについて記述する)

6. Operational scenarios

(運用シナリオ)

シナリオとは、提案システムがどのように運用され、ある与えられた状況下でユーザや外部インタフェースとどのように相互作用するかをステップごとに記述したものである。シナリオは、提案システムのさまざまな部分がすべてどのように機能し、どのように相互作用するかを読者があたかもその場にいて理解できるように書かなければならない。システムのすべての部分、ユーザ、その他のものがどのように相互作用するかをシナリオに書くことで、それらを一体化することができる。シナリオは、システムがしてはいけないことを記述するのに用いられることもある。

シナリオは複数の節、小節に分けて書く。それぞれのシナリオには、システムの役割、ユーザとの相互作用、他のシステムとの相互作用を描き出すようにして、運用の時系列を記述する。運用シナリオは、提案システムのすべてのユーザ層とすべての運用モードに対して書く。それぞれのシナリオには、提案システムの運用上の諸点を統一的に理解できるように、適切なイベント、アクション、入力、情報、相互作用を含める。この情報の一部分には、プロトタイプ、絵コンテ、ビデオやハイパーメディアによるプレゼンテーションなどのようなメディアを利用してもよい。

多くの場合、各シナリオについていくつかのバリエーションを作ることになる。通常の運用の場合を一つ、重い負荷がかかっている場合が一つ、例外が起きた場合が一つ、縮小機能モードでの運用を一つ、などである。

シナリオはいくつかの重要な役割を果たしている。まず、システムの各部分を全体として一貫性のあるものにまとめあげることである。シナリオは、運用上の能力を提供するためにいかにして各部分が相互作用しているのかをConOps文書のユーザに理解してもらう手助けとなる。シナリオの第2の役割は、提案システムの運用上の詳細をユーザに提供することにある。つまり、ユーザの役割や、システムをどのようにして運用するのか、どのような運用上の特徴が提供されるのか、ということを理解してもらうのである。

その他にもシナリオは、導き出された要件、特質、重要な問題を解決するためのプロトタイプの準備などの定義と割当ての助けとなるシミュレーション・モデルの開発に役立つ場合もある。

さらにシナリオは、ユーザーズ・マニュアルの最初の草稿や検収試験計画の策定のベースにもなる。購買者や開発者にとっても、システム設計がユーザのニーズや期待を満たすものかどうかを検証するのに役立つはずである。

シナリオは、いくつかの異なる方法で表すことができる。一つのやり方は、提案システムの主な処理機能ごとにシナリオを指定するやり方である。このやり方だと、この節には各処理単位ごとに一つの小節があることになる。また、スレッドを基にしたやり方もあり得る。この場合には、提案システムのトランザクションの種類に沿ってシナリオを書くので、各小節は相互作用の種類ごとに一つのシナリオ+機能縮小/過負荷/バックアップのようなモードに対応したシナリオがあることになる。また、システムのユーザ能力ごとの情報フローに沿って書くやり方、システムの制御フローに沿って書くやり方、オブジェクトやイベントに焦点を当てて書くやり方などがあり得る。

シナリオはConOpsの重要な基本要素であり、大いに強調されなければならない。指定されたシナリオの数と詳細度は、プロジェクトで認識されているリスクと重要度に比例するはずである。

7. Summary of impacts

(影響のまとめ)

この節では、提案システムがユーザ、開発者、支援/保守組織に与える運用上の影響を記述する。また、新しいシステムが開発/設置/教育されている期間にユーザ、購買者、開発者、支援/保守組織に与える一時的な影響も記述する。

この情報を提供するのは、購買代理者、ユーザ集団、支援/保守組織が新規システムの開発期間中や新規システムへの移行期間中に、新規システムによってもたらされる変化に備え、影響の計画をたてる猶予を与えるためである。

7.1. Operational impacts

(運用上の影響)

この小節は、提案システムの運用中にユーザ、開発者、支援/保守代理者に与えると予見される運用上の影響を記述する下位レベルの小節から構成する。ここで記述する影響としては以下のようなものがある。

  • 主要/副次コンピュータ運用センタとのインタフェース
  • 手続きの変更
  • 新しいデータ源の利用
  • システムに入力するデータの量、種類、タイミングの変化
  • データ保持要件の変化
  • 緊急/災害/事故の条件に基づいた運用の新しいモード
  • 要求されたデータが間に合わない場合に入力データを用意する新しい方法
  • 運用予算の変化
  • 運用上のリスクの変化

7.2. Organizational impacts

(組織上の影響)

この小節は、提案システムの運用中にユーザ、開発者、支援/保守代理者に与えると予見される組織上の影響を記述する下位レベルの小節から構成する。ここで記述する影響としては以下のようなものがある。

  • 責任の変更
  • 職位の追加/削減
  • ユーザの教育/再教育
  • 人員の数、スキル・レベル、位階、配置などの変化
  • 緊急/災害/事故時に不慮の出来事に備えて運用を行う副サイトに必要な人員の数とスキル・レベル

7.3. Impacts during development

(開発中の影響)

この小節は、提案システムの開発プロジェクト中にユーザ、開発者、支援/保守代理者に与えると予見される影響を記述する下位レベルの小節から構成する。ここで記述する影響としては以下のようなものがある。

  • 契約の判定に先立つ調査、会議、議論への関与
  • レビューと、初期運用能力やそれに引き続くシステムの進化の評価、データベースの開発と変更、必要な教育へのユーザと支援者の関与
  • 新規システムと現行システムの並行運用
  • 提案システムのシステム・テスト期間中に運用に与える影響

8. Analysis of the proposed system

(提案システムの分析)

この節では、提案システムに対して検討された、利益、制限、利点、欠点、選択肢とトレード・オフについての分析を提供する。

8.1. Summary of improvements

(改善点のまとめ)

この小節では、提案システムが提供することになる利益の量(可能な範囲で質)についての概要を記述する。この概要は、あてはまる場合には下記の項目を含む。それぞれについて、利益をConOpsの4.1で特定された不足に関係付けて述べる。

  • 新しい能力 - 追加された新しい特徴や機能
  • 拡張された能力 - 現行の能力のアップグレード
  • 削除された能力 - 使われていない、古くなった、混乱のもととなる、危険であるなどの理由で取り去られた能力
  • 改善された性能 - 応答時間の改善、必要な記憶領域の削減、品質の向上など

8.2. Disadvantages and limitations

(欠点と制限)

この小節では、提案システムの欠点や制限の量(可能な範囲で質)についての概要を記述する。欠点としては、人員の教育の必要性、仕事場の再構成、新しいスタイルのユーザ・インタフェースへの変化などがあるだろう。また制限としては、ユーザが希望したが今回は含まれなかった特徴、新しい能力を実現するために低下した現行の能力、特定の複雑な運用における要望よりも大きな応答時間などがあるだろう。

8.3. Alternatives and trade-offs considered

(考慮した対案とトレードオフ)

この小節では、検討した主な選択肢、それらの間でのトレード・オフ、到達した結論の根拠を記述する。ConOps文書の文脈において、選択肢というのは運用上のものであって設計上のものではない。ただし、設計上の選択肢が新規システムの要求する運用能力によって制限されるような場合はこの範囲ではない。この情報は、現時点であるいは後になって、与えられたやり方がちゃんと分析/評価されたかどうか、なぜあるやり方や解法が却下されたのかを判断するのに役立つことになる。この種の情報は、往々にして記録しておかなければ分からなくなってしまうのである。

9. Notes

(註)

この節には、このConOps文書の理解を助けるだろうと思われる付加情報を書く。この節には、この文書で用いられているすべてのアクロニム/略語のアルファベット順の一覧(それぞれの意味も)、こん文書を理解するの必要な用語や定義の一覧が必要である。

Appendices

(付録)

この文書の利用や維持を簡単にするために、いくつかの情報をこの文書の付録に入れておく。よくある例としては、チャートや分類データなどがある。各付録は、その情報が本来置かれているべき文書本体の部分から参照されているようにしなければならない。付録は、取扱いを容易にするために別の文書として製本してもよい。

Glossary

(用語集)

ConOps文書で用いられている(が、このConOps文書の読者にはあまり馴染みのない)用語の明確で簡潔な定義は大変重要である。概念分析とConOps文書の作成の工程をとおして、用語集を保守し、アップデートしなければならない。解釈の誤りから生じる無駄な作業を避けるためにも、すべての定義は関係者全員がレビューし、合意している必要がある。


Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: