Comment documenter les règles métier

Je me demande quelle serait la méthode officielle et la plus couramment utilisée pour documenter les règles commerciales? Aussi comment documentez-vous les spécifications de l'interface utilisateur des artefacts de développement (par exemple, la documentation des champs de formulaire et la façon dont les boutons se comportent sur le formulaire, le texte d'information, etc.)

Pour les règles commerciales, je pense que @Joppe a souligné l'UML que nous pensions tous.

Les diagrammes de cas d'utilisation offrent un excellent aperçu de la façon dont les acteurs / rôles interagissent avec le système et ce que fait le système. Pour un cas d'utilisation complexe, des informations supplémentaires expliquées textuellement aideront beaucoup ( préconditions , postconditions , dépendances des exécutions UC précédentes , etc. )

Il existe des diagrammes qui offrent également une excellente vue d'ensemble de l'entreprise à différents niveaux:

• Diagramme de la machine à états s'il existe des états à documenter.
• Diagramme d'activité . Pour les cas d'utilisation complexes, vous devrez peut-être approfondir les détails. Le niveau des détails est à vous et dépend de qui va lire la documentation. Celui-ci peut ne pas sembler une documentation professionnelle, mais avec le bon niveau de détails, il pourrait le devenir.

Juste un conseil, attribuez un code à chaque cas d'utilisation (par exemple: UC-1 , UC-n ). Ceux-ci seront utiles ultérieurement, lors de la documentation de l'interface utilisateur.

Pour la documentation de l'interface utilisateur, la pratique courante (de nos jours) est de faire des wireframes . Bien mieux que les captures d'écran car il semble plus propre et plus simple. Par exemple, jetez un œil à WireframeSketcher

Les wireframes peuvent ne pas être une documentation suffisante, donc, pour chaque écran, faites une brève introduction et décrivez chaque bouton. De plus, faites des références à l'UC impliqué dans l'écran ( voyez maintenant pourquoi les codes UC sont utiles ). Cela rendra votre documentation cohérente.

Le point des outils comme Wireframesketcher est qu'ils font des maquettes interactives. Parfait pour donner quelque chose d'interactif au client pendant que vous concevez ou développez.

N'oubliez pas de documenter le plan de navigation . Nav. Le plan n'a pas de diagramme UML, mais le diagramme de la machine d'état peut être utilisé à la place. Ce n'est pas pour ce qu'il a été fait, mais quand même.

Enfin, gardez à l'esprit à qui vous vous adressez.

• Technicien : vous pouvez approfondir les détails et utiliser les détails techniques.

• Pas technicien : éviter les détails techniques (ni liés à la langue ni au code). Essayez d'être clair et simple et utilisez les mêmes termes / mots que ceux utilisés par le client. Pensez comme si vous n'aviez aucune idée de la programmation.

La documentation se fait souvent dans des cas d'utilisation et d'autres formes de prose. De plus, il peut être extrêmement utile d'avoir des diagrammes UML et d'autres formes graphiques qui vous donnent un aperçu à un niveau supérieur et sont faciles à comprendre en un temps plus court que la lecture de pages et de pages.

Et enfin et surtout, la meilleure documentation à mon humble avis sont des cas de test qui exécutent les règles métier. De cette façon, vous pouvez modifier le code et découvrir que vous violez une règle commerciale. Sinon, la documentation risque toujours d'être périmée et obsolète.

La forme la plus courante est probablement les cas d'utilisation . Vous pouvez les compléter avec des maquettes d'écran et des descriptions.

Un livre que je recommanderais est "Writing Effective Use Cases" par Alistair Cockburn. Il décrit comment vous pouvez écrire des cas d'utilisation à différents niveaux de détail, comment éviter de tomber dans l'approche guidée par le `` modèle '', et simplement s'en tenir à la documentation des bits nécessaires et pertinents.

Quelle que soit la méthode que vous utilisez, assurez-vous qu'ils peuvent être activement maintenus. Ce devraient être des documents vivants. Le fait de loger les documents dans un système de contrôle de version ou une sorte de système de gestion de documents comme Sharepoint peut grandement contribuer à les maintenir à jour. Garder une trace des règles de l'entreprise à travers des documents Word joints aux e-mails est une façon horrible de résoudre le problème, car cela conduit à plusieurs versions flottantes.

Je recommande fortement de séparer strictement les règles métier de la spécification du système en référant uniquement les règles métier du cas d'utilisation et de la conception de l'interface utilisateur. Ma technique préférée est: - Avoir une liste de règles métier identifiées dans une feuille de calcul. - Dans la conception du système, spécifiez les cas d'utilisation, les user stories ou autres, spécifiez simplement "L'utilisateur entre les informations comme spécifié dans la règle métier BR012", "Le système calcule le montant total comme spécifié dans la règle métier BR510". Je recommande cet article http://www.allaboutrequirements.com/business-rules/

Essayez de générer un diagramme UML à l'aide du code Visual Studio et du plugin Plant UML