仕様書を書くのは難しいです。
仕様は仕様書にまとめるものです。仕様書はテストの妥当性を証明するためのご神体なので、正しく書かなければなりません。説明資料、引継ぎ、自己防衛。仕様書を書く能力はシステム開発者である私自身を救うのです。
ハードウェアの製品仕様書にぽんぽん仕様が追加されることがないように、ソフトウェアの要求仕様書にも安易に仕様を追加してはいけません。色々な要望や要求があるのは構わないのですが、仕様に書き表した時点で評価の対象になると考えています。
世の中には、仕様書のようで仕様書でない文書が跋扈しています。プログラムをかける人はそれなりにいますが、仕様をうまく書ける人はそこまで多くないと思っています。個人的に仕様書の書き方にこだわるのはそういう理由だからかもしれません。
用語
紛らわしい言葉が多く登場します。今のところ、以下のように理解しています。
- 機能要件
- システムが備えていなければならない機能のこと。これが肝。
- 非機能要件
- システムや機能に対し、追加要件として暗に期待していること。
- 要求仕様
- システムに要求する仕様。利害関係者向けに、機能要件と非機能要件をまとめたもの。
- 機能仕様
- 要求仕様を満たすために設計する、機能モジュールが遵守すべき基準。結合テストで評価する。 システムは基本設計で機能モジュールに分割される。非機能仕様を満たすための機能仕様を検討する。
- 非機能仕様(システム要件)
- 非機能テストを実施して検証する、非機能品質の達成基準。システムテストで検証する。
- 設計仕様
- 何かしら設計した仕様のこと。機能仕様を指すことが多いが、詳細設計にも使われる。
今日悩んだのは、開発後に仕様が決まることが多い仕様のうち、説明するのが難しい制御仕様や複数要素が複雑に絡んだ仕様をどのようにまとめるか、ということだった。これらは非機能品質を高めるために複雑なのであって、仮に一生懸命仕様書に落とし込んだとしても、組み合わせによる動作不良を検出する結合テストでOK/NG判定をする対象としては適さない気がするからである。制御機能そのものが動くことは詳細設計または単体(コンポーネント)テストとして評価すべきだろう。機能レベルでいえば、正しい操作できちんと制御できるかどうかが肝だからだ。そのため、機能仕様の一文一要件とは区別すべき、というのが悩んだ末の結論であった。