機能仕様書に何を書くか

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

いわゆる仕様書というものを読むことがあるのですが、読んでいて「わかるような、わからないような・・・」と思わざるを得ない仕様書もあります。

どの仕様書も「プログラムが行うこと」、例えば「次の条件でデータAを参照する」というような記述がありはするものの、「なぜ、なんのためにデータAを参照するのか」については一切説明がなかったりします。

次の条件でデータAを参照する。
※条件に合致するデータが存在する場合は、○○と判断し、
条件に合致するデータが存在しない場合は、□□と判断する。

くらいの一言があればグッとわかりやすくなると思うんですけどね。

「それじゃどこまで書けばいいのか」、「○○と判断し、□□と判断するのは何のためなのか?」という疑問もでてきそうで、この辺りは実に微妙、ケース・バイ・ケースではあるな、とは思います。

何のために?を愚直に五回ほど繰り返せば、終いには「企業の継続」とか「社会貢献」とか出てきそうですからね。

それでも、よほど自明な場合を除き、仕様書を読むであろう人がその機能や処理の目的や意図を理解できるだろう、という書き手の意識は必要だと思います。

機能や処理(=手段)だけを記載して、あとは上位の仕様書を読めとか、行間を読め、というのはいささか乱暴だな、と思うのです。

これはプログラムの仕様書に限った話ではありません。いわゆる上流工程を行う人の中にも、業務要件(顧客が実現したいこと)は伝えずシステム要件(システムが実装すべき機能など)だけを伝える人がいますが、これもよくありません。

機能や処理の目的を知っていると選択肢(代替案、回避案)の数が増えます。その(顧客にとっての)重要度によって力の入れ具合も変える事もできます。手を抜くという意味ではなく、リソース配分の最適化です。

このエントリーをはてなブックマークに追加
Facebook にシェア
Pocket
LINEで送る

カテゴリーIT