[要求仕様の美学]

具体例から学ぶ仕様書の作法─読みやすさを考慮し表形式でまとめる:第4回

2009年2月16日(月)福田 修

これまで、要求仕様書に書くべき17項目を個別に見てきた。今回はいよいよ、実際に仕様書を書いてみる。仕様書は、システムの背景や全体像を端的にまとめるイントロダクション、具体的な要求項目を列挙するシステム要求という2部構成にすると見やすい。用語の定義や業務フロー図、画面イメージなどは別紙にする。

 要求仕様書には必ず記載すべき必須項目とケースによっては省いても構わないオプション項目がある。前回(システム化の狙いや背景に言及し、経営判断や開発計画立案を支援する:第3回)は必須10項目と、一部のオプション項目を説明した。今回は、残りのオプション5項目を解説し、仕様書の具体例を示す。

要求仕様書のオプション項目―開発手法や言語を指定する

 前回、7つある要求仕様書のオプション項目の中から「用語の定義」「業務フロー図」の2項目を説明した。オプション項目にはこのほか、「期待すべき効果」「画面イメージ」「利用できる資源」「開発に用いる資源」「開発方法に関する要求」の5つがある。以下で1つずつ見ていこう。

(3)期待すべき効果

これは、必須項目の1つである「目的・狙い」に含まれる内容ではある。しかし、目的・狙いに細かい内容を書きすぎると要求の全体像が分かりにくくなってしまう。このため、効果額の算出根拠などを詳細に記述する場合は独立した項目を立てたほうがよい。

期待すべき効果は、「定量的効果(金額換算できる効果)」と「定性的効果(金額換算できない効果)」に分けて記述する。定量的効果は効果値や金額換算値、算定根拠を次のように記述する。

  • 効果値…業務負荷軽減**時間/月
  • 金額換算…***円/年
  • 算定根拠… パート時給*円×*時間×12カ月

なお、業務負荷が軽減されてもそれを金額に換算できない場合は、定性的効果と整理する。負荷が軽減された分をほかの業務に回すため人員削減できない、従って人件費も減らない、といった場合などである

(4)画面イメージ

システム開発に先立って、利用者が「こんな画面がほしい」という具体的なイメージを持っていることがある。そうした場合は、要求仕様書の段階から画面イメージを提示し、開発に携わる関係者が共通認識を持てるようにしておくとよい。

画面イメージは、WebアプリケーションであればHTMLで作成するのが望ましいが、描画ツールで作成してもよい。このとき、単なる画面イメージだけでなく、画面上に表示するデータ項目の説明も書くようにする。

(5)利用できる資源

この項目では、システム開発にあたって利用できる資源を提示する。これにより、「どの部分は既存の資源を活用できるのか」「新たに購入する必要があるのはどの部分か」などを明確にできるため、費用見積もりの精度を上げられる。具体的には、「既存の社内ネットワークを利用する」「新規のハードを購入せず、既存の基盤上にシステムを構築する」「ソフトはオープンソースを利用する」といった内容を記述する。

利用できる資源についてすでに関係者内で認識済みの場合、要求仕様書では省略しても構わない。このため、この項目はオプション的な位置付けとする。

(6)開発に用いる資源

パッケージソフトや開発ツールなどを用いる場合は、製品名、導入時期を明記する。製品をまだ特定していない場合でも、取得者は少なくともパッケージソフトや開発ツールの利用を検討するかどうかについて記述する。「検討する」という場合は、供給者側が中心になって最適な製品を選考することになる。

(7)開発方法に関する要求

システムの内容や企業のシステム化指針によっては、最適な開発手法や開発言語が決まっていることがある。そうした場合は、要求仕様の段階で手法や言語などを指定しておくとよい。例えば、「開発手法はプロトタイプ型、開発言語はJava」などと記載する。

バックナンバー
要求仕様の美学一覧へ
関連キーワード

要求仕様 / 要件定義

関連記事

トピックス

[Sponsored]

具体例から学ぶ仕様書の作法─読みやすさを考慮し表形式でまとめる:第4回これまで、要求仕様書に書くべき17項目を個別に見てきた。今回はいよいよ、実際に仕様書を書いてみる。仕様書は、システムの背景や全体像を端的にまとめるイントロダクション、具体的な要求項目を列挙するシステム要求という2部構成にすると見やすい。用語の定義や業務フロー図、画面イメージなどは別紙にする。

PAGE TOP