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.