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

IEEE830-1998

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

ソフトウェア要求仕様書の書き方

IEEE Std. 830-1998, IEEE Recommended Practice for Software Requirements Specificationより

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

masaki@metabolics.co.jp


Table of Contents

(目次)

1. Introduction

(はじめに)

SRSの「はじめに」では、SRS全体の概要を書く。

1.1. Purpose

(目的)

この小節では

  • SRSの目的を描写する
  • SRSが意図する聴衆を指定する

1.2. Scope

(範囲)

この小節では

  • これから作るソフトウェア成果物に名前を付ける
  • このソフトウェア成果物が何であるか(必要ならば、何でないか)を説明する
  • 指定されたソフトウェアの適用について、対応する利点、目的、目標を含めて記述する
  • もし上位レベルの仕様書(例えばSyRS)があれば、同様の記述と矛盾がないようにする

1.3. Definitions, acronyms, and abbreviations

(定義、略語、短縮形)

この小節では、このSRSを解釈するのに必要となるすべての用語、略語、短縮形の定義を提供する。この情報はSRSの一つあるいは複数の付録を参照する形、あるいは他のドキュメントを参照形で提供してもよい。

1.4. References

(参照)

この小節では

  • このSRSのどこかで参照しているすべてのドキュメントの完全な一覧を提供する
  • それぞれのドキュメントの題名、(相当する場合には)レポート番号、日付、出版組織を特定する
  • 参照ドキュメントの入手元を指定する

1.5. Overview

(概要)

この小節では

  • このSRSの残りの部分に書かれていることを記述する
  • このSRSの構成を説明する

2. Overall description

(全容)

SRSのこの節では、成果物とその要件に影響のある一般的な要因を記述する。この節では、個々の要件については述べない。それらの要件はこのSRSの3節で詳細に定義するので、ここではその背景を述べ、個々の要件を容易に理解できるようにする。

2.1. Product perspective

(成果物の見通し)

SRSのこの小節では、この成果物と他の関連する成果物との見通しを明らかにする。成果物が自立していて、完全に自己完結的なものである場合には、ここにその旨を述べる。またよくあるように、このSRSで定義する成果物がより大きなシステムの一コンポーネントである場合には、この小節で上位システムの要件をこのソフトウェアの機能性(functionality)に関連づけ、そのシステムとソフトウェアの間のインタフェースを特定する。

上位システムの主要なコンポーネント、相互関連、外部インタフェースを示すブロック図を添えるとよい。

さらにこの小節では、ソフトウェアがさまざまな制約の中でどのように振る舞うかを記述する。制約としては例えば以下のようなものがある。

  1. システム・インタフェース
  2. ユーザ・インタフェース
  3. ハードウェア・インタフェース
  4. ソフトウェア・インタフェース
  5. 通信インタフェース
  6. メモリ
  7. 操作
  8. 設置先における調整要件

2.2. Product functions

(成果物の機能)

SRSのこの小節では、ソフトウェアが動作する主な機能のまとめを提供する。例えば会計プログラムのSRSでは、ここにそれぞれの機能で必要となる顧客の会計方法や出荷票についてあまり詳細に過ぎないように指定する。

場合によっては、ここで必要となる機能のまとめは(もしあれば)このソフトウェア成果物に個々の機能を割り当てている上位レベルの仕様書の節から直接取られることもある。目的をはっきりさせるために以下のことについて注意する。

  • 顧客、あるいはそれ以外のこのドキュメントを初めて読む人にも理解しやすいようなかたちで、機能の一覧を組織だてる
  • それぞれの機能やその間の関連を示すために、文章や図などを使う。図を使うのは成果物の設計を示すためではなく、単に変数間の論理的な関係を示すためだけである。

2.3. User characteristics

(ユーザの特性)

SRSのこの小節では、成果物を使うと考えられるユーザの一般的な特性(教育レベル、経験、技術的な専門性など)を記述する。ここでは特定の要件を述べることはせず、ある要件仕様がSRSの3節で後述される理由を書いておく。

2.4. Constraints

(制約)

SRSのこの小節では、開発者の選択肢を限定する他の項目についての一般的な記述を提供する。例えば

  1. 調整ポリシー
  2. ハードウェアの制限 (e.g. 信号のタイミング要求)
  3. 他のアプリケーションとのインタフェース
  4. 並列操作
  5. 監査機能
  6. 制御機能
  7. 高水準言語の要求
  8. 信号のハンドシェーク・プロトコル (e.g. XON-XOFF, ACK-NACK)
  9. 信頼性要件
  10. アプリケーションの重要性
  11. 安全性、機密性の考慮

2.5. Assumptions and dependencies

(仮定と依存)

SRSのこの小節では、SRSで述べた要件に影響を及ぼす要因をそれぞれ列挙する。これらはソフトウェアの設計上の制約ではなく、SRSの要件に影響を及ぼしうる変化のことである。例えばこのソフトウェア成果物用のハードウェアに特定のオペレーティング・システムが用意されるかもしれないという仮定などがそれに当たる。もし実際にそのオペレーティング・システムが用意されなければ、SRSはそれに対応して変更しなければならない。

2.6. Apportioning of requirements

(要件の割振り)

SRSのこの小節では、システムの将来のバージョンまで延期される可能性のある要件を特定する。

3. Specific requirements

(個々の要件)

SRSのこの節には、設計者がこれらの要件を満たすシステムを設計するのに十分な、また試験者がシステムがこれらの要件を満たしていることを試験するのに十分な、詳細度でソフトウェア要件をすべて記述する。この節をとおして、述べられたすべての要件は、ユーザ、オペレータ、あるいはその他の外部システムによって外面的に認められ得るものでなければならない。これらの要件は最低、システムへのすべての入力(刺激) 、システムからのすべての出力(反応)、システムが入力に反応して、あるいは出力を出すために行なうすべての機能を記述しなければならない。ここは通常SRSの中でも最大の、かつもっとも重要な部分なので以下の原則を適用するようにする。

  • 個々の要件は、4.3.(よいSRSの条件)で述べたすべての特性に従うように述べなければならない
  • 個々の要件は、関連する以前のドキュメントを相互参照しなければならない
  • すべての要件は、一意に識別できなければならない
  • 読みやすさを最大にするように要件を組織だてることに慎重な注意を払う

要件を組織だてる特定の方法を試してみる前に、要件を構成するさまざまな項目(5.3.1~7に述べている)をよく理解しておくとよいだろう。

要件の組織立てには以下のようなやり方がある。

  • システム・モードごと
  • ユーザの種類ごと
  • オブジェクトごと
  • 機能(feature)ごと
  • 入力(stimulus)ごと
  • 出力(response)ごと
  • 機能階層ごと

3.1. External interface requirements

(外部インタフェース要件)

これはソフトウェア・システムへのすべての入力とソフトウェア・システムからのすべての出力の詳細な記述である。2節でのインタフェース記述とは相補的なものとし、同じ情報をここで繰り返さない。

内容、形式としては以下のようなものがある。

  • 項目名
  • 目的の記述
  • 入力元、あるいは出力先
  • 正当な範囲、正確さ、寛容さ
  • 尺度の単位
  • タイミング
  • 他の入出力との関連
  • 画面の形式/構成
  • ウィンドウの形式/構成
  • データ形式
  • コマンド形式
  • 終了メッセージ

3.1.1. User interfaces

3.1.2. Hardware interfaces

3.1.3. Software interfaces

3.1.4. Communications interfaces

3.2. Functional requirements (ここは手法によって変わる)

(機能要件)

機能要件では、ソフトウェアが入力の受付と処理、出力の処理と生成を行なうときに発生するすべての基本的な行動を定義する。それらは一般的に「このシステムは......する」というような"shall"文の一覧になる。

例えば以下のようなものがある。

  • 入力の正当性チェック
  • 操作の正確な並び
  • 非正常な状態への応答、例えば
    • オーバーフロー
    • 通信関係
    • エラーの扱いと回復
  • パラメータの効果
  • 入力に対する出力の関係、例えば
    • 入出力の並び
    • 入力を出力に変換する公式

機能要件を副機能やサブプロセスに分割するのが適当な場合もある。ただしそれはソフトウェア設計も同じように分割されるべきであるということではない。

3.3. Performance requirements

(性能要件)

この小節では、ソフトウェアやソフトウェア全体と人間との相互作用における静的/動的な数値上の要件を指定する。静的な数値上の要件には以下のようなものがある。

  • サポートする端末の数
  • サポートする同時ユーザ数
  • 取り扱う情報の量と種類

静的な数値上の要件は、「容量 (Capacity)」という題の別の小節に記述する場合もある。

動的な数値上の要件には、例えば、それぞれ正常時/ピーク負荷条件での一定時間内のトランザクション数、タスク数、処理すべきデータ量などがある。

これらの要件はすべて測定可能な形で記述する。

例えば、「操作者はトランザクションが完了するまで待たされないようにする」ではなく、「トランザクションの95%は1秒以内に終了する」のように書く。

註 - ある特定の機能にのみ適用される数値は、通常その機能の処理についての段落で指定する。

3.4. Logical database requirements

(論理データベース要件)

ここでは、データベースに置かれる情報の論理的な要件を指定する。以下のようなものがある。

  • さまざまな機能で塚割れる情報の型
  • 使用頻度
  • アクセス能力(capability)
  • データ本体とそれらの間の関係
  • 一貫性の制約
  • データ保持要件

3.5. Design constraints

(設計上の制約)

ここでは、他の標準やハードウェアの限界からもたらされる設計上の制約について指定する。

3.6. Sofrware system attributes

(ソフトウェア・システムの属性)

要件として用いられるソフトウェアの属性はたくさんある。要件属性が達成されたことを客観的に検証可能なように指定することが重要である。属性要件には例えば以下のようなものがある。

  • 信頼性
  • 可用性
  • 機密性
  • 保守容易性
  • 移植可能性

3.7. Other requirements

(その他の要件)

Appendixes

(付録)

付録は実際のSRSの一部とは認められない場合もあるし、必要というわけでもない。例えば以下のようなものがある。

  • 入出力の形式の例、費用分析の記述、ユーザ調査の結果
  • SRS読者の助けとなる補助情報、あるいは背景情報
  • このソフトウェアが解決しようとする問題の記述
  • 機密性、輸出、初期ロード、その他の要件を満たすための、コードやメディアの特別なパッケージングの指示

付録を含む場合には、SRSはこの付録を要件の一部と認めるのかどうかをはっきりと述べなければならない。

Index

(索引)


Powered by Plone, the Open Source Content Management System

This site conforms to the following standards: