顧客が仕様書を書くという点で困難なことの一部は、顧客が実際に顧客が必要とするものを説明する言語に翻訳する方法を顧客が知らないことです。顧客はシステムに特定の動作が存在することを望んでいると言うかもしれませんが、一般的に、顧客が彼らと完全に一致しないと感じる方法で動作するソフトウェアを見て使用し、経験するまで、特徴にあまり関心がありませんニーズ。
顧客がビジネスプロセスを説明するとき、多くの場合、多くの関連情報が省略されます。多くの場合、この情報は、顧客の特定のドメイン内で一般的に理解されているプロセスに関するものに関連しているため、当然のことと見なされ、プログラマーに伝えられないことがよくあります。それ以外の場合、顧客はシステム内のすべての境界条件に対処する方法を実際に知らず、ガイダンスをプログラマに求めています。場合によっては、使いやすさの単純なケースであり、顧客は何かを何らかの方法で機能させたいと考えていますが、後で物事が異なるように動作することが明らかになると気が変わります。
わかりました、「プログラマーのための顧客関係101」の十分。問題は、顧客がビジネスで読み取り可能なDSLを使用して仕様の定義方法を定義することに価値があるかどうかです。ガイダンスでは、答えは暫定的な「はい」であり、次の質問が思い浮かぶので、プログラマーにもっと簡単に定義させることができるのに、なぜ顧客にDSLを作成してもらうのかという暫定的だと思います。シンプルでありながら豊富な言語を顧客に提供して、システムの動作方法を定義しますか？
顧客にシステムがどのように機能するかを説明する言語を提供すると、次の行に沿って何かを言うステートメントになります。
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
このタイプのステートメントは、顧客が基本的にシステムに想定する全体的な形を提供するか、または顧客がシステムとは何かを説明しているという別の見方を提供して、要件を非常に明確な方法で説明します。顧客にもう少し物事について考えてもらいたい場合は、次のようなステートメントを使用して、機能が従わなければならない規則を説明するように依頼することができます。
"Given 'some system state', When 'some action occurs', Then expect 'some result'
再び非常に明確な説明、今回は方法についてシステムは動作するはずです。問題は、これによりソフトウェア開発者がすべての空白を埋め、顧客が周辺でしか認識していない可能性のある詳細を引き出す必要性に代わるものではないということです。顧客はプログラマーによって「トレーニング」されて機能や動作をプログラマーにとって使いやすい形式で記述することができますが、顧客には実際に意味のあるテストケースを生成したり、実装を提供したりするスキルや知識がありませんコード。これは、OPが言及したMartin Fowlerの記事のポイントだと思いました。そのため、ソフトウェア自体は顧客によって書き込み可能ではありませんが、ソフトウェアの説明は顧客によって書かれることができます-そして私見すべきです-。それが価値があることについては、私は顧客がすべきではないと言っているとしてファウラーの記事を読みませんでした
プログラマーは、ビジネスやビジネスプロセスの理解という点で、一般的に顧客が一般的に非常に賢いことを忘れてしまうことがあると感じています。ソフトウェアシステムの構築方法を教えてくれるプログラマーがいない場合、顧客は一般に、特定のビジネス管理の問題を解決するために、他の（おそらく効率の低い）手段に頼ります。これは、単純なデータベース（Accessを考える）またはスプレッドシート、あるいは手書きの台帳でさえも、それらのプロセスを管理するための明確に定義されたルールと手順を意味します。多くの顧客に欠けているのは、システムがどのように機能する必要があるかを決定する手段ではなく、むしろそれをどのように構築すべきかを決定する手段であり、さらに重要なことに、システムの行動ルールをどのように効率的に記述するか実際にシステムを構築するためのスキルを持っています。
書き込み可能性の欠如について実際にコンセンサスがある場合、ツールで問題が発生し、シナリオを開始してそれらを計測する代わりに、実際のテストからビジネスで読み取り可能なシナリオを生成しますか？
これは問題を間違った方向で見ていると思います。その文書が何らかの形で仕様を表すことを意図している場合、テストから文書を生成するツールに大きな問題が発生するでしょう。シナリオをテストするには、シナリオを理解する必要があります。したがって、両方のシナリオでテストを定義するには、シナリオがすでに存在している必要があります。BDD構文でシナリオを説明する場合、すでに指定しているため、事後のシナリオのみをインスツルメントできます。一方、顧客がシステムをプログラミングに適したDSLで記述できるツールがあり、そのツールを使用してテストスイートとして使用されるコードテンプレートを生成できる場合、私はdそのようなツールには大きな価値があると言う。顧客がプログラマーを方程式から外すのを見ることはなく、顧客の希望を取り、テストでエンコードされた要件をBDD形式で生成するために必要な労力を削減するのに役立ち、おそらく顧客の希望をより簡単に理解できるようになります。ただし、顧客が顧客のニーズと顧客のニーズを区別できるように、経験豊富なソフトウェア開発者を手に入れるのに代わるものではありません。