Lors de la description des exigences en utilisant UML, toute tentative d’ordonner les cas d’utilisation ou de fournir des informations de séquence parmi les cas d’utilisation est une mauvaise pratique, et ne peut que mener à un mauvais usage des diagrammes de cas d’utilisation UML.
Il faut décrire les Processus Métier pour le système à l’étude, car cela fournira l’ordre dans lequel les choses doivent se passer avec beaucoup de détails. Le Processus Métier peut être documenté dans la section Aperçu/Contexte d’un document d’Exigences Produit. OMG définit une notation BPMN pour décrire les Processus Métier (voir http://www.bpmn.org/), qui est fondamentalement basée sur un diagramme d’activité UML 2.0 avec un certain nombre d’icônes/fonctionnalités supplémentaires. Cette notation cependant n’ajoute pas grand-chose d’autre que de la confusion pour le non-expert. Je suis en effet très favorable aux diagrammes auto-explicatifs/non ambigus, car selon mon expérience les diagrammes UML doivent être revus et approuvés par des experts en la matière qui ne sont généralement pas des experts UML. Donc, à moins que vous n’ayez une très bonne raison d’utiliser BPMN, utilisez simplement des diagrammes d’activité pour décrire les Processus Métier. BPMN, bien que basé sur UML 2.0, a encore besoin d’une consolidation avec les notations UML.
Autrement, il est important de ne pas entreprendre UML sans une méthodologie. Afin d’être très performant dans la documentation d’un système de quelque complexité que ce soit, il est important de suivre une méthodologie formelle. Personnellement j’aime utiliser une méthodologie basée sur RUP, spécialement pour la documentation des exigences et de l’architecture, tandis que les principes d’approche agile peuvent être utilisés pour la conception et le développement…