山田正樹(メタボリックス)
masaki@metabolics.co.jp
(目次)
(はじめに)
SRSの「はじめに」では、SRS全体の概要を書く。
(目的)
この小節では
(範囲)
この小節では
(定義、略語、短縮形)
この小節では、このSRSを解釈するのに必要となるすべての用語、略語、短縮形の定義を提供する。この情報はSRSの一つあるいは複数の付録を参照する形、あるいは他のドキュメントを参照形で提供してもよい。
(参照)
この小節では
(概要)
この小節では
(全容)
SRSのこの節では、成果物とその要件に影響のある一般的な要因を記述する。この節では、個々の要件については述べない。それらの要件はこのSRSの3節で詳細に定義するので、ここではその背景を述べ、個々の要件を容易に理解できるようにする。
(成果物の見通し)
SRSのこの小節では、この成果物と他の関連する成果物との見通しを明らかにする。成果物が自立していて、完全に自己完結的なものである場合には、ここにその旨を述べる。またよくあるように、このSRSで定義する成果物がより大きなシステムの一コンポーネントである場合には、この小節で上位システムの要件をこのソフトウェアの機能性(functionality)に関連づけ、そのシステムとソフトウェアの間のインタフェースを特定する。
上位システムの主要なコンポーネント、相互関連、外部インタフェースを示すブロック図を添えるとよい。
さらにこの小節では、ソフトウェアがさまざまな制約の中でどのように振る舞うかを記述する。制約としては例えば以下のようなものがある。
(成果物の機能)
SRSのこの小節では、ソフトウェアが動作する主な機能のまとめを提供する。例えば会計プログラムのSRSでは、ここにそれぞれの機能で必要となる顧客の会計方法や出荷票についてあまり詳細に過ぎないように指定する。
場合によっては、ここで必要となる機能のまとめは(もしあれば)このソフトウェア成果物に個々の機能を割り当てている上位レベルの仕様書の節から直接取られることもある。目的をはっきりさせるために以下のことについて注意する。
(ユーザの特性)
SRSのこの小節では、成果物を使うと考えられるユーザの一般的な特性(教育レベル、経験、技術的な専門性など)を記述する。ここでは特定の要件を述べることはせず、ある要件仕様がSRSの3節で後述される理由を書いておく。
(制約)
SRSのこの小節では、開発者の選択肢を限定する他の項目についての一般的な記述を提供する。例えば
(仮定と依存)
SRSのこの小節では、SRSで述べた要件に影響を及ぼす要因をそれぞれ列挙する。これらはソフトウェアの設計上の制約ではなく、SRSの要件に影響を及ぼしうる変化のことである。例えばこのソフトウェア成果物用のハードウェアに特定のオペレーティング・システムが用意されるかもしれないという仮定などがそれに当たる。もし実際にそのオペレーティング・システムが用意されなければ、SRSはそれに対応して変更しなければならない。
(要件の割振り)
SRSのこの小節では、システムの将来のバージョンまで延期される可能性のある要件を特定する。
(個々の要件)
SRSのこの節には、設計者がこれらの要件を満たすシステムを設計するのに十分な、また試験者がシステムがこれらの要件を満たしていることを試験するのに十分な、詳細度でソフトウェア要件をすべて記述する。この節をとおして、述べられたすべての要件は、ユーザ、オペレータ、あるいはその他の外部システムによって外面的に認められ得るものでなければならない。これらの要件は最低、システムへのすべての入力(刺激) 、システムからのすべての出力(反応)、システムが入力に反応して、あるいは出力を出すために行なうすべての機能を記述しなければならない。ここは通常SRSの中でも最大の、かつもっとも重要な部分なので以下の原則を適用するようにする。
要件を組織だてる特定の方法を試してみる前に、要件を構成するさまざまな項目(5.3.1~7に述べている)をよく理解しておくとよいだろう。
要件の組織立てには以下のようなやり方がある。
(外部インタフェース要件)
これはソフトウェア・システムへのすべての入力とソフトウェア・システムからのすべての出力の詳細な記述である。2節でのインタフェース記述とは相補的なものとし、同じ情報をここで繰り返さない。
内容、形式としては以下のようなものがある。
(機能要件)
機能要件では、ソフトウェアが入力の受付と処理、出力の処理と生成を行なうときに発生するすべての基本的な行動を定義する。それらは一般的に「このシステムは......する」というような"shall"文の一覧になる。
例えば以下のようなものがある。
機能要件を副機能やサブプロセスに分割するのが適当な場合もある。ただしそれはソフトウェア設計も同じように分割されるべきであるということではない。
(性能要件)
この小節では、ソフトウェアやソフトウェア全体と人間との相互作用における静的/動的な数値上の要件を指定する。静的な数値上の要件には以下のようなものがある。
静的な数値上の要件は、「容量 (Capacity)」という題の別の小節に記述する場合もある。
動的な数値上の要件には、例えば、それぞれ正常時/ピーク負荷条件での一定時間内のトランザクション数、タスク数、処理すべきデータ量などがある。
これらの要件はすべて測定可能な形で記述する。
例えば、「操作者はトランザクションが完了するまで待たされないようにする」ではなく、「トランザクションの95%は1秒以内に終了する」のように書く。
註 - ある特定の機能にのみ適用される数値は、通常その機能の処理についての段落で指定する。
(論理データベース要件)
ここでは、データベースに置かれる情報の論理的な要件を指定する。以下のようなものがある。
(設計上の制約)
ここでは、他の標準やハードウェアの限界からもたらされる設計上の制約について指定する。
(ソフトウェア・システムの属性)
要件として用いられるソフトウェアの属性はたくさんある。要件属性が達成されたことを客観的に検証可能なように指定することが重要である。属性要件には例えば以下のようなものがある。
(その他の要件)
(付録)
付録は実際のSRSの一部とは認められない場合もあるし、必要というわけでもない。例えば以下のようなものがある。
付録を含む場合には、SRSはこの付録を要件の一部と認めるのかどうかをはっきりと述べなければならない。
(索引)