Vous pouvez traiter la "documentation sur le langage omniprésent" comme un projet de personnalisation de logiciel: vous devez prendre un logiciel pour la gestion de la documentation et l'adapter à votre besoin spécifique. Dans les projets logiciels, vous commencez normalement par rassembler les besoins des utilisateurs, puis vous créez une architecture d'information et une solution de conception, puis vous passez à la mise en œuvre. Voici l'exemple de ce processus.
Quels sont les besoins de l'utilisateur pour cela? Dans certaines organisations, des personnes ayant des fonctions différentes dans différents domaines souhaitent utiliser un dialecte linguistique commun pour décrire leurs problèmes et leurs solutions. Ce dialecte sera défini uniquement par son vocabulaire (mots et figures de style), car la prononciation n'est probablement pas importante ici et la grammaire sera basée sur la forme littéraire de la langue. Pour documenter le dialecte, vous devez concevoir une structure de documentation qui conviendra le mieux à la gestion d'un vocabulaire (glossaire).
Les gens peuvent vouloir utiliser cette documentation pour apprendre la signification du mot ou de l'acronyme, pour trouver le mot correct par son synonyme ou sa définition ou pour apprendre tous les mots qui composent le domaine.
Pour ces besoins des utilisateurs, wiki est en effet un bon choix. Comment ça se met? Dans un bon système wiki comme Confluence ou MediaWiki, il est possible de:
- Créez un article pour chaque terme.
- Définissez la structure commune des articles dans un modèle, afin qu'ils contiennent des sections communes, qui peuvent être utilisées pour l'agrégation.
- Ajoutez facilement des liens vers des définitions de termes dans d'autres articles wiki.
- Créez des tableaux agrégés avec des définitions de termes et intégrez-les dans d'autres documentations.
Actuellement, j'utilise Confluence pour documenter l'architecture de l'information et les définitions de langage omniprésentes en font partie. Le niveau le plus élevé de cette documentation sont les articles de domaine. Dans chaque application, il existe plusieurs domaines, par exemple la sécurité, les paiements, etc. Ces domaines sont définis par un certain nombre d'interactions de l'utilisateur avec le système, qui peuvent être décrites via un langage omniprésent, donc je mets les définitions de ces interactions dans des sous-pages distinctes et des définitions des termes introduits par ces interactions dans les sous-pages des pages d'interaction. Je mets des tableaux agrégés sur les pages parents afin qu'il soit possible de voir, par exemple, quels scénarios sont constitués du domaine et quels termes y sont définis.
Lorsque cette structure de documentation est terminée et que je passe à des spécifications système plus détaillées, je peux simplement me référer aux définitions IA et UL des scénarios, par exemple "le composant A implémente l'intégration avec le système B pour prendre en charge l'interaction C (lien de scénario IA) en transmettant des informations sur Z (liaison UL) ".