在客户编写规格文档方面的部分困难在于，客户通常不知道如何将客户想要的东西翻译成实际描述客户需求的语言。尽管客户可能会说他们希望某种行为存在于系统中，但他们通常并不关心细节，直到他们看到并使用并体验了软件后，客户感觉与他们的行为并不完全匹配。需要。
当客户描述业务流程时，他们通常会遗漏许多相关信息。通常，此信息与有关过程的事情有关，这些过程通常在客户的特定领域内被理解，因此被认为是理所当然的，并且通常不会传递给程序员。在其他时候，客户实际上并不知道如何处理系统中的所有边界条件，因此正在寻求程序员的指导。有时，这只是可用性的一个简单案例，客户认为他们希望某件事以一种方式起作用，但是后来当事情变得更加清晰时，他们改变了主意。
好的，足够“程序员的客户关系101”。问题是让客户使用商业可读的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文章的重点。因此，是的，软件本身不能由客户编写，但是软件的说明肯定可以（并且IMHO应该）由客户编写。对于它的价值，我没有读过Fowler的文章说客户不应
我觉得我们的程序员有时可能会忘记，我们的客户在理解业务和业务流程方面通常非常聪明，当然比我们做得更好。当他们没有程序员告诉他们如何构建软件系统时，客户通常会采用其他（可能效率较低）的方法来解决其特定的业务管理问题。我的意思是指简单的数据库（认为Access）或电子表格，甚至是手写的分类帐，并具有定义良好的规则和程序来管理这些过程。许多客户所缺乏的并不是确定系统如何工作的方法，而是确定系统的构建方式，更重要的是，如何有效地向操作人员描述系统的行为规则。也有技巧实际构建的系统。
如果确实对缺乏可写性达成了共识，那么您是否会看到一种工具的问题，该工具可以从实际测试中生成业务可读的场景，而不是从场景开始并对其进行检测。
我认为这是错误地解决问题的方法。如果该文档旨在以任何方式表示规范，我会看到一个从测试生成文档的工具存在很大问题。为了测试场景，您需要了解它，因此该场景必须已经存在，以便您都可以为它定义测试。如果您以BDD语法描述方案，那么您已经指定了方案，因此只能在事后对方案进行检测。另一方面，如果您有一个工具可以让客户以良好的编程友好型DSL描述系统，并且该工具可以用来生成用作测试套件的代码模板，那么我d表示这种工具将具有巨大的价值。它不会看到客户将程序员排除在方程式之外，并且它将帮助减少实现客户需求并以BDD方式生成测试编码的需求所需的工作量，并且可能使客户的需求更容易理解。但是，这不能代替拥有经验丰富的软件开发人员来帮助客户将客户的需求与客户的需求区分开。