<プロジェクト名>
補足仕様書
バージョン <1.0>
[メモ: 次のテンプレートは、Rational Unified Process で使用することを目的に提供されたものです。 大括弧で囲まれた青色のテキスト (style=InfoBlue) は、 作成者に対する説明用ですので、本文書を公開する前に削除してください。 このスタイルの後に入力した段落は自動的に通常の形式 (style=Body Text) に設定されます。]
改訂履歴
日付 |
バージョン |
説明 |
作成者 |
<dd/mmm/yy> |
<x.x> |
<詳細> |
<名前> |
|
|
|
|
|
|
|
|
|
|
|
|
目次
補足仕様書
[「はじめに」には、補足仕様書の全体的な概要を記述します。 この補足仕様書の目的、範囲、定義、頭字語、略語、参考資料、概要を記載します。
補足仕様書は、ユースケース・モデルのユースケースではすぐには把握されないシステム要件を把握します。このような要求には、次のものがあります。
・ 法規制に関する要求 (アプリケーション規格を含む)
・ 構築されるシステムの品質属性 (使いやすさ、信頼性、性能 、サポートのしやすさに関する要求を含む)
・ オペレーティング・システムと環境、互換性の要求、設計上の制約などのその他の要求]
[補足仕様書の目的を定義します。]
[補足仕様書の範囲について簡単に説明します。関連するプロジェクト、その他、この文書が影響を及ぼす事項を記述します。]
[ここでは補足仕様書を解釈する上で必要となるすべての用語、頭字語、略語の定義を説明します。 この用語等の定義については、プロジェクトの用語集を参照するようにしてもかまいません。]
[ここには補足仕様書で参照されている参考資料の一覧を記載します。各資料は、タイトル、レポート番号 (該当する場合)、日付、および発行元を明記します。その参考資料がどこで入手できるかを明記してください。この参考資料については、付録または別の資料を参照するようにしてもかまいません。]
[ここでは補足仕様書のこの項目以降の内容とその構成について説明します。]
[ここでは、システムの追加機能の要求を自然言語の形で記述します。]
[要求の内容をここに記述します。]
[ここには、使いやすさに関連するすべての要求を記述します。次に例を示します。
・ 一般的なユーザーおよびパワー・ユーザーが、特定業務がこなせるようになるために必要とするトレーニング時間の指定
・ 標準的な作業に関する計測可能な所要時間の指定
・ IBM の CUA 標準、Microsoft の GUI 標準などの一般的な規格の使いやすさに準拠するための要求の指定]
[要求の内容をここに記述します。]
[ここには、システムの信頼性に関連する要求を記述します。例えば、以下のような事項を記載します。
・ 可用性。作業可能な時間の割合 (xx.xx%)、利用可能時間数、保守のためのアクセス方法、低下モードにおける操作などを示す。
・ 平均故障間隔 (MTBF)。通常は時間単位で示すが、日、月、年の単位で示しても可。
・ 平均修理時間 (MTTR)。故障発生後、システムを運用不能状態にしておける許容時間。
・ 正確性。システムの出力に必要な精度 (解像度) や正確さ (一般的な基準による) の指定。
・ 最大バグ発生率または最大障害発生率。通常、コード 1,000 行あたりのバグの数 (バグ/KLOC)、 またはファンクション・ポイントあたりのバグの数 (バグ/ファンクション・ポイント) で示す。
・ バグ発生率または障害発生率。バグを、低、高、重大のレベルに分類する。 要求には「重大」なバグ (例えば、データの完全な消失、システム機能の特定部分が完全に使用不能になることなど) の定義を記述する必要がある。]
[要求の内容をここに記述します。]
[システムの性能に関する特性の概略をここに記述します。具体的な応答時間もここに記載します。関連するユースケースがあれば、その参照先を名前を挙げて示します。 通常、すべての必要な機能は、ユースケース形式または単純テキストで、 性能に関する記述 (システムが備えるべき能力や機能の高さを記載) を併記する必要があります。 この性能記述は、できるだけ関係する機能の近くに記載するようにしてください (ユースケース記述の「特殊要件」の部分など)。 ここには、テストの必要のある要求に関する記述を記載できますが、この要求は特定の機能に合わせられるわけではありません。
・ トランザクションの応答時間 (平均、最大)
・ スループット (1 秒あたりのトランザクション)
・ 処理能力 (例: そのシステムが処理できる顧客数やトランザクションの上限値)
・ 低下モード (システムのパフォーマンスが低下した場合に許容できる操作のモード)
・ リソースの使用状況 (メモリー、ディスク、通信など)]
[要求の内容をここに記述します。]
[ここには、コーディングの基準、命名規則、クラス・ライブラリー、保守のためのアクセス方法、 保守ユーティリティーなど、構築するシステムに対するサポートのしやすさまたは保守のしやすさを向上させるすべての要求を記述します。]
[要求の内容をここに記述します。]
[ここでは、構築するシステムに関するすべての設計上の制約を記述します。設計上の制約とは、条件として指定され、遵守しなければならない設計上の決定事項を表します。 この中には、ソフトウェアの言語、ソフトウェアの処理要件、開発ツールに対する使用規定、アーキテクチャー上または設計上の制約、 購入するコンポーネントの指定、クラス・ライブラリーなどがあります。]
[要求の内容をここに記述します。]
[システム・エンジニアリングの場合、他に対処すべき要件、要求が生じる可能性があります。]
[例えば重量、サイズ、消費電力など。]
[例えば湿度、汚染物質、温度、電気的、機械的など。]
[安全性、セキュリティー、その他の品質要因 (耐久性など)。]
[システムを使用またはサポートする人員を支援するためにそのシステムに必要な要求を記述します。 例えば、トレーニング機能 (トレーニングに必要な装置と資料を含む)、保守機能、インターフェースの記述や規格では収まらない人間工学的な考慮事項が含まれます。]
[物流管理に関する考慮事項について、システムに対する要求を記述します。これには保守、サポート、配送、提供、既存システムとの調整が含まれます。]
[必要に応じて、オンライン・ユーザー文書、ヘルプ・システム、通知に関するヘルプなどの要求を記述します。]
[ここには、システムで使用するあらゆる購入コンポーネント、 ライセンス上または使用上の制限の適用、および関連する互換性と相互運用性またはインターフェース基準を記述します。]
[ここには、システムでサポートする必要のあるインターフェースを記述します。システムをインターフェース要求に合わせて開発し、 検証できるように、十分な特定性、プロトコル、ポート、論理アドレスなどを記述します。 システム内部のインターフェースに対するすべての要求を記述する必要があります。 このような必要性は、例えばシステム設計により、既存のハードウェア・コンポーネントやソフトウェア・コンポーネントを内部で使用するよう制限されるときに生じます。]
[システムで実装されるユーザー・インターフェースを記述します。]
[ここには、論理構造、物理アドレス、期待される動作など、 システムでサポートするすべてのハードウェア・インターフェースを記述します。]
[ここには、システムでサポートするソフトウェア・インターフェースについて、サポートする (サポートが必要な) 操作やシグナル、プロトコルおよびデータ特性に関する内容を記述します。]
[ローカル・エリア・ネットワークなど、ほかのシステムまたはデバイスに対するすべての通信インターフェースを記述します。]
[ライセンス付与の適用、またはシステムが備えるべきその他の使用上の制限に関連するすべての要件を記述します。]
[ここには、システムに関連する必要な法律上の免責事項、 保証、著作権の表記、特許の表記、ワード・マーク、商標、ロゴの適合性の問題をすべて記述します。]
[ここには、対象のシステムに適用し、該当するすべての標準、および そのような標準の特定項目の参照を記述します。例えば、 法律上の標準、品質上の標準、規制上の標準、使いやすさに関する業界標準、相互運用性、国際化、オペレーティング・システムの適合性などについて記述します。]