Une partie de la difficulté pour le client à rédiger un document de spécifications est que le client ne sait souvent pas comment traduire les choses qu'il veut dans une langue qui décrit réellement ce dont le client a besoin. Bien que le client puisse dire qu'il souhaite qu'un certain comportement existe dans un système, il ne se préoccupe généralement pas des détails tant qu'il n'a pas vu, utilisé et expérimenté le logiciel fonctionnant d'une manière qui, selon le client, ne correspond pas tout à fait à son Besoins.
Lorsque les clients décrivent un processus métier, ils laissent souvent de côté beaucoup d'informations pertinentes. Souvent, ces informations concernent des éléments d'un processus qui sont généralement compris dans le domaine particulier du client et qui sont donc considérés comme acquis et souvent non relayés au programmeur. À d'autres moments, le client ne sait pas vraiment comment gérer toutes les conditions aux limites d'un système et se tourne vers le programmeur pour obtenir des conseils. Parfois, il s'agit d'un simple cas d'utilisation, le client pensant qu'il veut que quelque chose fonctionne d'une manière, mais changeant ensuite d'avis lorsqu'il devient plus clair que les choses devraient fonctionner différemment.
Ok, donc assez de "relations clients 101 pour les programmeurs". La question est de savoir s'il est toujours utile que le client utilise un DSL lisible par l'entreprise pour définir comment définir une spécification. Je pense qu'avec des conseils, la réponse est un «oui» provisoire, et je dis provisoire parce que la question suivante qui me vient à l'esprit est la suivante: pourquoi voudriez-vous qu'un client crée une DSL alors qu'un programmeur peut en définir plus facilement une qui fournir à un client un langage simple mais riche pour définir comment un système doit fonctionner?
Lorsque vous avez fourni à un client un langage pour décrire comment il aimerait qu'un système fonctionne, vous allez vous retrouver avec des déclarations qui disent quelque chose comme:
"for a given 'subsystem', as a 'business entity' I want 'some feature' so that I might achieve 'some result'".
Ce type de déclaration finit par décrire une exigence d'une manière très claire, en fournissant la forme globale que le client souhaite essentiellement que le système prenne, ou une autre façon de voir les choses est que le client décrit ce qu'est le système. Si vous souhaitez que votre client réfléchisse un peu plus aux choses, vous pouvez alors lui demander de décrire les règles auxquelles la fonctionnalité doit obéir en utilisant un certain nombre de déclarations similaires peut-être à:
"Given 'some system state', When 'some action occurs', Then expect 'some result'
Encore une fois, des descriptions très claires, cette fois sur la façon dontle système doit se comporter. Le fait est que cela ne remplacera pas la nécessité pour un développeur de logiciels de remplir tous les espaces vides et de révéler d'autres détails dont le client ne peut être conscient qu'à la périphérie. Bien que le client puisse être `` formé '' par le programmeur pour décrire les fonctionnalités et les comportements dans un format convivial et convivial, le client n'aura pas vraiment les compétences ou les connaissances pour générer des cas de test significatifs, ni pour fournir l'implémentation code. C'était, je pense, le point de l'article de Martin Fowler auquel l'OP a fait référence. Donc, oui, le logiciel lui-même n'est pas accessible en écriture par le client, mais la description du logiciel peut très certainement - et à mon humble avis devrait - être écrite par le client. Pour ce que ça vaut, je n'ai pas lu l'article de Fowler comme disant que le client ne devrait pas
Je pense que nous, les programmeurs, pouvons parfois oublier que nos clients sont généralement très intelligents en termes de compréhension de leurs activités et de leurs processus métier, certainement beaucoup mieux que nous. Quand ils n'ont pas de programmeur pour leur dire comment construire un système logiciel, les clients recourent généralement à d'autres moyens, peut-être moins efficaces, pour résoudre leurs problèmes particuliers de gestion d'entreprise. J'entends par là de simples bases de données (pensez à Access) ou des feuilles de calcul, ou même des livres écrits à la main, et avec des règles et des procédures bien définies pour gérer ces processus. Ce qui manque à de nombreux clients n'est pas un moyen de déterminer comment un système doit fonctionner, mais plutôt comment il doit être construit , et plus important encore, comment décrire efficacement les règles de comportement d'un système aux personnes quin'ont les compétences nécessaires pour construire réellement le système.
S'il y a effectivement un consensus sur le manque d'écriture, verriez-vous un problème avec un outil qui, au lieu de commencer par les scénarios et de les instrumenter, générerait des scénarios lisibles par l'entreprise à partir des tests réels?
Je pense que cela examine la question dans le mauvais sens. Je verrais un gros problème avec un outil qui génère de la documentation à partir de tests si cette documentation était destinée à représenter une spécification de quelque manière que ce soit. Pour tester un scénario, vous devez le comprendre, par conséquent, le scénario doit déjà exister pour que vous puissiez à la fois définir un test pour celui-ci. Si vous décrivez le scénario dans une syntaxe BDD, vous l'avez déjà spécifié et vous ne pouvez donc instrumenter les scénarios qu'après coup. Si d'un autre côté vous aviez un outil qui permettrait au client de décrire un système dans une belle DSL conviviale pour la programmation, et si cet outil pouvait être utilisé pour générer les modèles de code qui seraient utilisés comme suite de tests, alors je '' Je dirais qu'il y aurait une grande valeur dans un tel outil. Cela ne verrait pas le client retirer les programmeurs de l'équation, et cela aiderait à réduire l'effort requis pour répondre aux souhaits du client et générer des exigences codées pour les tests de manière BDD, et pourrait peut-être rendre les souhaits du client plus faciles à comprendre. Ce ne serait cependant pas un substitut à la présence d'un développeur de logiciels expérimenté pour aider le client à séparer les besoins du client de ses désirs.