仕様は一方の面からだけで表現するとバグを生む

on


例えば、クライアントアプリケーションの機能Aは、自動で更新処理をする、とする。この機能Aはポリシーでその機能の振る舞いを制御できるときに、機能Aの仕様の表現は先の“自動で更新処理をする”で充分だろうか。


表1

機能A 自動で更新処理をする。


機能仕様に関わらず、仕様を定義していく中でただ文言だけで仕様の振る舞いを書いていくと“やることだけ”を書いて満足してしまい、その反対の面まで気が回らない。


やることだけ書いてあって、それで機能仕様の大元の要件を幸いにもカバーしていればそれはそれでよかったね、なんだけれど、ときどきそうはいかないケースも出てくる。


それは自動で更新処理をしてもいいけど、手動では更新処理をさせたいくないという要件があるとき。



表2

機能A 自動で更新処理をする。手動で更新処理はできないようにする。


表1も表2も“自動で更新処理をする”という要件の実装はできるんで一見よさそうなんだけれど、手動で更新処理をしたときに実行できてしまうとそれが仕様どおりなのか、不具合なのかが曖昧になる。


どっちかと言えば、バグ。不具合。なぜなら、わざわざ“自動”で更新処理すると謳っているのだから、手動ではやらせたくないのである。だから、機能仕様を書く場合は、表2のように機能を両面から考えて振る舞いを記載しないと仕様としてバグを生んでしまうのだ。


これは、機能が“1”であるとき、“1”以外まで書こうね、ということであって、それはMECEで機能仕様のふるまいを記載しておきましょう、ということです。