これまで、要求仕様書に書くべき17項目を個別に見てきた。今回はいよいよ、実際に仕様書を書いてみる。仕様書は、システムの背景や全体像を端的にまとめるイントロダクション、具体的な要求項目を列挙するシステム要求という2部構成にすると見やすい。用語の定義や業務フロー図、画面イメージなどは別紙にする。
要求仕様書の作成例―原稿入稿システム
2回にわたり、要求仕様書の必須項目とオプション項目について書く理由や書き方を解説した。ここで、筆者が作成した要求仕様書を掲載する。この仕様書は、駅などに置かれているフリーペーパーを出版するJ社のシステム開発案件を想定した。
1ページめは仕様書全体のイントロダクションと位置づけ、システム化の全体像を俯瞰できる内容を記述する。具体的には、必須項目の最初の4つ(システム化の目的や現行の問題点、解決策の概要、用途・利用者)を明記する(図1)。続くページでは、必須項目やオプション項目を項目ごとに整理する(図2~5)。システム要求は、表形式で書くとまとめやすく読みやすい。
オプション項目は別紙にする(図5)。この例では、3つのオプション項目(用語の定義、業務フロー図、開発方法に関する要求)を記述した。もちろん、利用できる資源や開発に用いる資源、画面イメージといったこの仕様書では言及していないオプション項目を必要に応じて加えてもよい。
今回で、要求仕様の書き方についての説明を終わる。次回からは、人間工学の観点から見た要求仕様について考えていく。
ドクター福田の「文章力アップ」処方箋
今月の悪文「テストケースは全部できなかった」
一見して問題がなさそうなこの文章も、このコラムでおなじみの多義文です。100件のテストケースについて「100件すべてテストできなかった」と「100件のうち90件はテスト済みで10件は残った」という2つの意味にとれるからです。「全てのテストケースを確認していない」という文章も似たような多義文です。
このように文が2つの意味を持ってしまうのは、否定文で表現しているからです。肯定文を使えば、多義文を避けられます。例えば、「テストケースの完了件数は0件である」あるいは「テストケースの完了数は90件である」とすれば一意に決まります。正確さを求められる技術文では、否定表現は使わないようにしたいものです。
福田 修 ふくだ おさむ
CSK、日本インフォメーション・エンジニアリングを経て、1997年にテクノロジー・オブ・アジアを設立、代表取締役に就任。適切な情報技術の動向把握に長け、 2000年問題の効果的解決、インドのSI会社との提携、Webアプリケーションへの取り組み、オブジェクト指向設計/開発の導入などに早期から対応し、後発システムベンダーへの指導的立場にもある。関連論文多数あり。
http://www.toasia.co.jp/
- 要求仕様作成における最大のコツ─機能の2割をカットする:第14回(2009/11/02)
- システム仕様を数式に変換─Z言語で要求仕様を厳密に記述する:第13回(2009/10/02)
- 業務の粒度やアクターの役割を明確化し、システムのふるまいをUMLで表現する:第12回(2009/09/04)
- スケッチ、設計図、プログラミング言語UMLの利用法を再確認する:第11回(2009/08/06)
- ブレーンストーミング、KJ法、NM法、マインドマップ─発想法のエッセンスを理解する:第10回(2009/07/06)