正常系だけ書くと、異常系は実装が決める

依頼文は、たいてい成功する流れから書かれます。「カードで支払える。成功したら注文完了画面を出す」。

ところがプログラムは、相手が応答しないときにも何かをします。待ち続けるかもしれないし、エラー画面を出すかもしれないし、自動で送り直すかもしれない。「何もしない」も含めて、動作は必ず何かに決まっています。 決めたのは、書いたコードと、使ったライブラリの既定値です。

依頼文が決めなかった以上、選んだのは実装した人か AI です。

要件の書き方 EARS の論文(2009)は、この場所を名指ししています。

“Unwanted behaviour” is a general term used to cover all situations that are undesirable. This includes failures, disturbances, deviations from desired user behaviour and any unexpected behaviour of interacting systems. The authors’ experiences suggest that unwanted behaviour is a major source of omissions in early requirements, necessitating costly rework.

望まれない振る舞いとは、故障・外乱・利用者が期待から外れた操作・連携する相手システムの想定外の振る舞い。本教材はこれらをまとめて異常系と呼びます。

論文の定義を裏返すと、依頼文に向ける問いになります。壊れたら? 乱されたら? 打ち間違えたら? 相手が想定外を返したら?

NASA のシステムズエンジニアリング・ハンドブックの付録C(要件の妥当性確認チェックリスト)も、信頼性の項目で同じ場所を問います。

Are there error detection, reporting, handling, and recovery requirements?

Are undesired events (e.g., single-event upset, data loss or scrambling, operator error) considered and their required responses specified?

検出・報告・処理・回復。異常が起きたとどう気づき、誰に伝え、その場でどうし、どう戻るかの4つです。1つでも書かれていなければ、そこは実装が決めます。

依頼文に書かれずに残りやすい異常を並べます。

異常の種類          例                        詳しく扱う場所
故障                相手が応答しない          第12期「壊れる前提で組む」
誤操作              カード番号を打ち間違える   この回
相手の想定外        返ってきた形式が違う       この回
同時実行            2人が同時に在庫を減らす    第17期「原子性は割り込みを防がない」

同時実行は、依頼文に無くても、消える更新として表に出ます。仕組みは第17期で、送り直しの意味は第12期「リトライは意味を変える」で扱います。

ただし、型やチェックリストが埋めるべき中身まで見つけるわけではありません。論文自身が、事例で漏れが消えたという主張は慎重に扱うべきだと書いています。また脚注では、望まれる振る舞いとの区別は a matter of viewpoint, or even a matter of “style” だと認めています。どこからを異常と呼ぶかも、書き手が決めることです。