要件定義というと、系の計算機側の要件を定義しようとすることがある。

顧客の要件との乖離が生まれる第一段階かもしれない。

顧客の要件を定義するために必要な事項を羅列する。

顧客の行動様式

顧客がどういう行動を取るかを様式化してみるとよい。

今考えている抽象度で様式化できないのであれば、もっと抽象度の高い次元を考えるか、
もっと抽象度の低い次元を考えるとよい。

現在考えている抽象度が、計算機側の要件を定義しようとしている可能性がある。

顧客の目的

顧客の行動様式を確認する前に、顧客の目的を深掘りしてしまうと、
架空の世界に嵌まり込んでしまうかもしれない。

顧客の行動様式を把握してあれば、顧客の目的が、
顧客の行動様式とどれくらい整合しているか、何が矛盾しているかを確認できる。

矛盾していることは、悪いことではない。矛盾は動的進化の要因であり、可能性である。
顧客の目的を無矛盾にしてしまったら、動くよい体系は作れない。

顧客の目標

顧客の目的がうまくつかめない時、先に顧客の目標から扱うことがある。

しかし、顧客の目標は、しばしば容易に計算機の要件に適合してしまい、安直な設計に陥ることがある。

顧客の目標は、顧客の行動様式に照らし、暫定的な顧客の目的を設定してみるとよい。
目的、目標、行動様式の組み合わせの中で、計算機がどういう手助けができるかを発想するとよい。

要件と制約

要件と制約は、要件に制約を含む集合定義をしている場合と、制約に要件を含む集合定義をしている場合と、要求と制約に包含関係を認めない定義をしている場合の３つの立場が存在する可能性がある。

顧客が全体としてどれか一つの立場を取っているという仮説は危険である。
上層部と、現場とで全く逆の用語を使っている組織はたくさんある。

経営者と合意したからいい体系が設計できるとは限らない。
逆に、経営者と合意していないと危険が多すぎる。

要件定義をする時に、制約との集合関係を、部署ごとに確認していくとよい。

参考資料(reference)

要望・要求・要件・仕様・制約・前提の違いは？
https://qiita.com/digdagdag/items/2808205d89344ab8a3a1

自己参照(self reference)

仮説・検証(82) 顧客指向のプログラミング(customer oriented programming)
https://qiita.com/kaizen_nagoya/items/6f3bc42253486b4b4818

仮説・検証（41）顧客から聞いた話
https://qiita.com/kaizen_nagoya/items/94a17a78f33dc8356a15

文書履歴(document history)

ver. 0.01 初稿 2019001 午後
ver. 0.02 参考資料追記 20190601 夜