要件を明確にする手法に長けていくのは、熟練の技の世界のように思われますが、セオリーとして確立されていることもあります。その一つが、"Validation"（チェック）という型の要件です。Validationは、入力値をチェックして、問題がある場合にはエラーを出すというタイプの要件です。
Validation系の要件では、仕様を＜違反＞するケースをテストしてみるとよいです。違反ケースがすっとかけるようであれば、Validation系の仕様として優れていると判断します。
たとえば、日本では、税番号のような制度がないので、あまりピンとこないかもしれませんが、bawbrが経験してきた中で、税番号のような制度を持つ国は多いです。そのような国では、税番号をマスタに必須で入力しなければいけないというチェックをかけたいという要件が出てきます。これを例に説明をしてみたいと思います。
具体的には、得意先マスタ（顧客マスタ／取引先マスタ）のある項目を必須入力にするという仕様にします。いい例なので取り上げてみたいと思います。
税番号の制度は国によって決められるので、得意先の所在する国を前提条件として記載したいとおもうと、まず、こう書いてしまいがちです。
（例１）「得意先の国がAの場合、税番号は必須とする。」
（違反ケース？）得意先の国がAの場合、税番号が必須となっていない。
違反ケースになっていない。正しい違反ケースは以下のとおりです。
（正しい違反ケース）得意先の国がAの場合に、税番号がブランクである。
「に」という助詞をつけたり、必須に対し「ブランク」と反対語を使わないと、違反ケースがかけません。すっとかけないというのはこういうことです。
そもそも、このグローバル化している世界で、その得意先が輸出先となる場合もあります。日本からその得意先に輸出する際に、日本のシステム側で税番号が必須とするわけがありません。SAPなど、グローバルに使えるERPを使っている場合には、現地国と日本で同じシステムを使っていることも、いまや普通です。こんな仕様を書いたら、日本からその得意先に輸出するための得意先の税番号を入れなければならなくなってしまいます。
必須という言葉がでてきたら、本当に必須なのか吟味する必要があります。必須としたとたん、税番号のない得意先が許されないからです。別の言葉で言い換えてみましょう。まず平たく、「なければならない」という言葉を使うのがよいでしょう。
また、税番号は得意先に固有のものであって、現地法人aの存在とは別です。しかし、現地法人aと取引する段になって、税番号が必須になるのです。だから、下記のように書きます。
（例２）「A国で、現地法人aの得意先に税番号がなければならない」
（違反ケース）A国で、現地法人の得意先に税番号がない。
違反ケースがすっとかけました。これはValidationの仕様として優れていると判断してよいことになります。
