Recueil de besoin, engénierie des exigences
Cette étape comporte les activités suivantes (les trois premières se déroulent en parallèle, la quatrième est un peu décallée dans le temps par rapport aux trois autres:
Identifications des acteurs ( au sens UML)[modifier | modifier le wikicode]
En lisant le cahier des charges, en dialogant avec les représentants du client, on repère l'organisation effective et l'on crée une liste de rôles qui seront joués par les personnes. Le support de l'identification des acteurs est un [diagramme de Use Case] dans lequel on représente les [acteurs] et leurs relations mais pas encore les [use cases]
Dessin des processus suivis par les utilisateurs du système.[modifier | modifier le wikicode]
Le support est un diagramme BPMN dans lequel on représente les enchainements des actions des acteurs, on utiise les swimm lanes pour montrer la frontière avec le système et donc les points d'interaction. Le diagramme BPMN montre des actions manuelles qui ne donnent pas lieu à la création de fonctions dans le système, ces actions manuelles ne seront plus décrite par la suite et notamment ne donneront pas lieu à des Use Cases.
Identification des objets du domaine[modifier | modifier le wikicode]
Dans la phase de recueil des besoins, le parcours utilisateur est décrit par des diagrammes de processus a priori dans le formalisme BPMN. Ces diagrammes répondent à la question "qui fait quoi ?" et correspondent à des phrases sujet - verbe - complément ( quelqu'un fait quelque chose), où le sujet est représenté par une swimm lane, le verbe par une activité et le complément par un objet ou un message. Ces objets et cs messages constituent le modèle des objets du domaine. Dans cette phase du projet, les objets du domaine sont les objets du monde réel. Dans l'idée que le système doit répondre au plus près au besoin de l'utilisateur on pose le postulat que tout objet du monde réel est a priori candidat a devenir un objets dans le système.
Mais a priori seulement, car entre le recueil des besoins et l'implémentation, un travail d'abstraction devra être produit qui pourra avoir pour résultat de créer dans le système des objets qui n'ont pas de correspondance dans le monde réel.
Identification des use cases.[modifier | modifier le wikicode]
L'établissement de la liste des uses cases vient après l'établissement de la liste des acteurs.
Les acteurs sont des entités qui ont des besoins dans le champ dans lequel le système doit proposer des services.
Pour répondre aux besoins des utilisateurs le système propose des services, c'est la liste de ces services que l'on appelle des uses cases. Les uses cases sont reliés aux acteurs par un lien "uses", les liens "uses" montrent les interactions entre les acteurs et le système.
Dans les équipes françaises, use case est souvent synonyme de fonctionnalité, il n'est pas faux de considérer qu'effectivement cela correspond à un décalage de terminologie, et qu'il n'y a pas d'erreur grave à assimiler use case - service - fonctionnalité.
Pour la bonne compréhension entre les intervenants et conserver un vocabulaire homogène, il convient d'éviter d'utiliser le terme fonctionnalité et de préférer use case et service.
Back to Le processus de développement