機能仕様書に関する覚書
1. 機能仕様書とは
- システムの機能について記された文書
- システムの機能とはユーザーにとって意味のあるシステムの動作を示す
- 意味のあるシステムの動作とは、その機能が正常に完了することでユーザーが何らかの目的を達成できる状態を得られることと言い換えられる
- 例えば、ログイン機能は機能が正常に完了することでユーザーはシステムにログインするという目的を達成できる
- 例えば、商品登録機能は機能が正常に完了することでユーザーは商品をシステムに登録するという目的を達成できる
- など
- ユースケースと言い換えてもよい
- 意味のある粒度かつ最小単位の粒度を見出す必要がある
2. 機能仕様書のアウトライン
- 1. 機能概要
- 2. 構造
- 3. 外部システム連携
- 4. ビジネスルール
- 5. エラー処理
- 6. 備考
- 関連資料
3. 各項目について
機能概要
機能概要では次の内容について説明する
- 機能が果たすべき仕事、機能が目指す状態
- 誰によって使用されるか
- どのように呼び出されるのか
構造
- 機能の構造について説明する
- 機能の構成要素(ユーザーからアプリケーション、DB、外部システム)のつながりを図で示すことが望ましい
- ただし、具体的なロジック(データのチェック内容、処理の手続き)については言及しない(コードと等価になるので工数のムダになる為)
- 単純なCRUDシステムなど自明である場合は省略してもよい
外部システム連携
- 外部システム連携のリスト
- 処理中で発生する外部システム連携を漏れなくリストアップ
- API通信やジョブキュー、ファイル転送などなど
ビジネスルール
- 関連するビジネスルールの説明もしくは解説資料へのリンク
- 状態を扱うものや複雑な判定ロジックが必要なものはここで説明する
エラー処理
- エラー処理方針の説明
- 基本的なルールがまとめてあるのであればそちらへのリンクでもよい
- 特殊なエラー処理が必要である場合はその旨記述すること
備考
- 上記の項目以外で注意すべき点、検討が必要な点など
関連資料
- 要件定義書やミーティング議事録など関連情報へのリンク
4. 機能仕様書に書かない事柄
モジュール構造
- モジュール構造はアプリケーションのアーキテクチャについて説明するを資料を別途作成すべき
- 個別の機能ごとにモジュール構造を記述するのは記述内容の重複やそこから発生する修正漏れのリスクがあって危険
- 機能仕様書は「その機能が何と関係していて、何をするのが役割なのか?」に集中しておけばよい
DB構造
- モジュール構造と同じくDB構造はそれについて説明する資料を別途作成すべき(ER図など)
Appendix-1. サンプル
- 1. 機能概要
- 機能の説明
- 利用者
- 想定利用方法
- 2. 構造
- 機能構成要素の図
- 3. 外部システム連携
- 外部システム連携対象一覧
- 4. ビジネスルール
- ビジネスルールの説明もしくは説明資料へのリンク
- 5. エラー処理
- エラー処理方針
- 6. 備考
- 関連資料