Parte da dificuldade em termos de o cliente redigir um documento de especificações é que o cliente geralmente não sabe como traduzir as coisas que o cliente deseja para um idioma que realmente descreve o que o cliente precisa. Embora o cliente possa dizer que deseja que determinado comportamento exista em um sistema, geralmente não se preocupa tanto com as minúcias até que tenha visto, usado e experimentado o software trabalhando de uma maneira que o cliente considera que não corresponde exatamente à sua. necessidades.
Quando os clientes descrevem um processo de negócios, geralmente deixam de fora muitas informações relevantes. Frequentemente, essas informações estão relacionadas a coisas sobre um processo que são comumente entendidas no domínio específico do cliente e, portanto, são consideradas um dado adquirido e muitas vezes não são transmitidas ao programador. Em outros momentos, o cliente não sabe como lidar com todas as condições de contorno de um sistema e procura orientação para o programador. Às vezes, é tudo um caso simples de usabilidade, com o cliente pensando que quer que algo funcione de uma maneira, mas depois mudando de ideia quando fica mais claro que as coisas devem funcionar de maneira diferente.
Ok, chega de "relações com clientes 101 para programadores". A questão é se ainda há valor em fazer com que o cliente use uma DSL legível para negócios para definir como definir uma especificação. Acredito que, com orientação, a resposta é uma tentativa de 'sim', e digo tentativa porque a próxima pergunta que vem à mente é: por que um cliente criaria uma DSL quando você pode ter um programador que defina mais facilmente uma que fornecer ao cliente uma linguagem simples e rica para definir como um sistema precisa funcionar?
Quando você fornece a um cliente um idioma para descrever como ele gostaria que um sistema funcionasse, você terminaria com instruções que diziam algo como:
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
Esse tipo de declaração acaba descrevendo um requisito de uma maneira muito clara, fornecendo a forma geral que o cliente basicamente deseja que o sistema assuma, ou outra maneira de encará-lo é que o cliente está descrevendo o que é o sistema. Se você deseja que seu cliente pense um pouco mais sobre as coisas, peça-lhes que descrevam as regras às quais o recurso deve obedecer, usando várias declarações semelhantes, talvez:
"Given 'some system state', When 'some action occurs', Then expect 'some result'
Novamente descrições muito claras, desta vez sobre comoo sistema deve se comportar. O fato é que isso não substituirá a necessidade de um desenvolvedor de software preencher todos os espaços em branco e fornecer detalhes adicionais dos quais o cliente pode estar apenas perifericamente ciente. Embora o cliente possa ser 'treinado' pelo programador para descrever os recursos e comportamentos em um bom formato amigável para o programador, ele não terá realmente as habilidades ou o conhecimento para gerar casos de teste significativos nem fornecer a implementação código. Acho que esse foi o ponto do artigo de Martin Fowler ao qual o OP se referiu. Portanto, sim, o software em si não é gravável pelo cliente, mas a descrição do software certamente pode - e o IMHO deveria - ser escrita pelo cliente. Pelo que vale, eu não li o artigo de Fowler dizendo que o cliente não deveria '
Eu sinto que nós programadores às vezes esquecemos que nossos clientes geralmente são muito inteligentes em termos de compreensão de seus negócios e processos de negócios, certamente muito melhores do que nós. Quando eles não têm um programador para lhes dizer como construir um sistema de software, os clientes geralmente recorrem a outros meios - talvez menos eficientes - para resolver seus problemas específicos de gerenciamento de negócios. Com isso, quero dizer bancos de dados simples (pense em Access) ou planilhas, ou mesmo livros escritos à mão, e com regras e procedimentos bem definidos para gerenciar esses processos. A falta de muitos clientes não é um meio de determinar como um sistema precisa funcionar, mas como ele deve ser construído e, mais importante, como descrever com eficiência as regras comportamentais de um sistema para as pessoas quenão tem as habilidades para realmente construir o sistema.
Se realmente houver um consenso sobre a falta de capacidade de gravação, você veria um problema com uma ferramenta que, em vez de começar com os cenários e instrumentá-los, geraria cenários legíveis aos negócios a partir dos testes reais?
Eu acho que isso está olhando para o problema da maneira errada. Eu veria um grande problema com uma ferramenta que gera documentação a partir de testes se essa documentação pretendesse representar uma especificação de alguma forma. Para testar um cenário, é necessário entendê-lo; portanto, o cenário já deve existir para que você defina um teste para ele. Se você descreve o cenário em uma sintaxe BDD, já o especificou e, portanto, só pode instrumentar os cenários após o fato. Se, por outro lado, você tivesse uma ferramenta que permitisse ao cliente descrever um sistema em uma boa DSL otimizada para programação, e se essa ferramenta pudesse ser usada para gerar os modelos de código que seriam usados como suíte de testes, então eu ' Eu diria que haveria um grande valor nessa ferramenta. Ele não veria o cliente tirando programadores da equação e ajudaria a reduzir o esforço necessário para atender aos desejos do cliente e gerar requisitos codificados para teste de uma maneira BDD, e talvez tornasse os desejos do cliente mais facilmente compreendidos. No entanto, não seria um substituto ter um desenvolvedor de software experiente à disposição para ajudar o cliente a separar as necessidades do cliente e as necessidades do cliente.