Je suis actuellement dans un processus de recueil d'exigences pour 15 interfaces différentes qui récupèrent et/ou envoient des données vers une application en cours d'évolution sur laquelle je travaille. Nous ne sommes pas simplement en train de passer à une nouvelle version de l'application. Nous avons deux versions de celle-ci en cours d'utilisation par différents services de l'entreprise, de sorte que nous sommes également chargés de les consolider afin que tout le monde utilise la même version de l'application, celle la plus récente.
J'ai mis en place 12 séances de recueil d'exigences différentes (certaines interfaces pouvant être combinées).
Certaines séances ne prennent que 2 heures, d'autres 4 heures, et les dernières une journée entière. Je tiens ces séances sur une période de 20 jours.
Pendant les séances, le sponsor de l'entreprise est très impliqué. Elle commence chacune des sessions par une introduction, explique le sujet du projet, et énonce l'ordre du jour de la réunion.
Etant l'analyste d'affaires, je prends des notes sur les conversations, les exigences, et les souhaits que les gens énoncent. J'interromps la conversation lorsque cela est nécessaire pour obtenir des éclaircissements ou plus de détails, mais j'essaie généralement de laisser celle-ci se dérouler et limite mes interruptions au minimum. Je trouve que si j'interromps les experts métier, ils perdent parfois le fil de leur pensée ou ne peuvent pas faire les remarques pertinentes qu'ils avaient l'intention de faire à l'origine. Lorsque cela est possible, je garde mes questions pour une pause dans la conversation.
Nous avons certains sujets que nous couvrons dans chaque réunion, telles que l'approche pour les déploiement/bascules et les tests.
Lors de la discussion sur le déploiement, nous parlons des étapes nécessaires pour mettre la nouvelle application à disposition des utilisateurs. Nous discutons également de tous les impacts qu'il peut y avoir sur les interfaces que nous traitons et comment prévenir ceux-ci.
Lors de la discussion sur les tests, nous demandons à l'architecte combien d'environnement de tests il a pour cette interface et quel type de données nous pouvons nous attendre à voir dans l'environnement et quels sont les données dont nous avons besoin.
Les autres sujets que nous couvrons durant la réunion sont spécifiques à chaque interface. Par exemple, si nous recevons des commandes d'un système, nous discutons des types de commandes que nous recevons et des données qu'il nous envoie.
Un dernier point que j'ai oublié de mentionner est que je n'ai jamais travaillé avec cette application auparavant, par conséquent tout est nouveau pour moi. Ces réunions sont intenses et j'apprends beaucoup sur l'activité en même temps que je documente les besoins du métier.
source originale: The analyst coach
Aucun commentaire:
Enregistrer un commentaire