Aller au contenu

Services MR - Surveillance des e-mails, identifiant personnalisé, indicateur de modification

Les fonctionnalités supplémentaires de Modern Requirements4DevOps

Dans cet article, nous présentons certaines des fonctionnalités supplémentaires disponibles dans l'édition Enterprise Plus de Modern Requirements4DevOps. Ces fonctionnalités sont appelées « MR Services ».

Ces fonctionnalités offrent un meilleur contrôle sur les modifications apportées aux tâches, vous permettent de relier votre projet à un service de messagerie électronique et contribuent à améliorer la traçabilité et la convivialité de votre projet.

Service de surveillance des e-mails adapté aux besoins actuels

La fonctionnalité Email Monitor permet d'accéder à votre projet par un moyen qui n'existe pas dans Azure DevOps. En d'autres termes, elle vous permet de communiquer avec votre projet par e-mail. Les équipes se retrouvent souvent dans des situations où elles échangent des e-mails au sujet d'un élément de travail qui devrait être créé, et elles parviennent souvent, grâce à ces échanges, à définir un besoin précis qui doit être intégré à leur projet.

Grâce à la fonctionnalité « Email Monitor », votre équipe peut désormais transformer directement ces communications externes en tâches.

En activant la fonctionnalité « Email Monitor » dans le panneau d'extension Modern Requirements4DevOps, vous pouvez indiquer une adresse e-mail qui permettra d'intercepter et de générer toutes les exigences qui lui sont envoyées par e-mail.

Cas d'utilisation du service de surveillance des e-mails

Le cas d'utilisation le plus courant de la fonctionnalité « Email Monitor » est le suivant :

Je dirige une grande entreprise et j'aimerais que tous les membres de mon équipe signalent les bugs qu'ils détectent dans mon logiciel dans mon projet Azure DevOps.

Une fois Email Monitor entièrement configuré avec l'adressebugs@myorganization.com, n'importe quel membre de mon organisation peut simplement envoyer un e-mail àbugs@myorganization.com, et je peux alors demander qu'un ticket soit créé dans mon projet.

Parallèlement, l'e-mail à l'origine de la création du bug est également envoyé aux personnes concernées par ce projet. Les membres concernés peuvent désormais participer à la discussion relative à cet élément de travail par e-mail, et tous les échanges par e-mail seront ajoutés aux propriétés de discussion de cet élément de travail au sein de votre projet.

Cette fonctionnalité unique permet à des personnes extérieures de contribuer à la réussite de votre projet sans avoir besoin d'un accès complet à votre projet Azure DevOps. Les intervenants externes peuvent désormais participer aux discussions relatives à un élément de travail, sans que vous ayez à leur accorder un accès à votre projet.

 

Drapeau rouge / Liens suspects

La fonctionnalité « Dirty Flag / Suspect Link » contribue à la réussite de vos projets en rendant les modifications apportées aux éléments de travail à la fois consultables et, de manière générale, plus visibles.

Cette fonctionnalité a pour but de mettre automatiquement en évidence toutes les exigences susceptibles d'être affectées par la modification d'une exigence liée. Vous pouvez considérer cette fonctionnalité comme un moyen d'évaluer l'impact des modifications apportées aux exigences au sein de votre projet.

Comment fonctionne le système « Dirty Flag / Liens suspects » ?

Cette fonctionnalité vous permet de surveiller les éléments de travail qui répondent à certaines conditions. Lorsque ces éléments de travail changent, la fonctionnalité de surveillance signale tous les éléments de travail associés.

Prenons un exemple :

L'User Story 1 vient d'être mise en état « Terminée ». S'il est possible de configurer le drapeau « Dirty » / les liens suspects pour qu'ils déclenchent un signalement dès qu'une modification est apportée à une User Story en état « Terminée » (par exemple, une modification d'un champ tel que « Description »)

Cela signifie que si le champ « Description » de l'User Story 1 est modifié à l'avenir, toutes les exigences qui y sont associées seront marquées d'un indicateur « Dirty ».

Cela permet à votre équipe de détecter facilement si une exigence répondant à un certain ensemble de critères (que vous définissez) subit une modification. Une fois identifiées, toutes les tâches directement liées seront signalées par la fonctionnalité « Dirty Flag / Suspect Link ».

Pour reprendre notre exemple, si le champ« Description »de l'User Story 1 venait à changer, nous pourrions marquer d'un indicateur « Dirty » tous les cas de test directement liés qui pourraient devoir être modifiés afin de tester les nouveaux critères.

Les indicateurs d'erreur activés sur ces cas de test prendraient la forme d'une balise de tâche.

Les balises s'affichent dans l'éditeur d'éléments de travail standard d'Azure DevOps.

Lorsque le tag « Dirty Flag » est activé sur des éléments de travail, ce tag inclut à la fois l'identifiant et la révision de l'élément de travail modifié, ce qui permet à votre équipe d'identifier facilement quelle exigence a été modifiée et a déclenché la fonctionnalité « Dirty Tag / Suspect Link ».

Identifiants personnalisés

De nombreuses applications permettent d'ajouter des identifiants personnalisés aux éléments de travail. L'objectif de ce type de fonctionnalité est de rendre un champ plus lisible et plus identifiable.

Notre fonctionnalité « Custom ID » offre les mêmes avantages, auxquels s'ajoutent ceux liés à l'utilisation du module « Queries ».

Les identifiants personnalisés peuvent être configurés en tant que propriété personnalisée associée à chacun de vos éléments de travail.

La propriété « Custom ID » permet d'identifier facilement toutes les informations nécessaires relatives à un élément de travail donné, le tout dans un seul champ. Elle s'avère également être un outil extrêmement utile pour identifier la source d'une exigence dans le cadre de requêtes inter-projets.

En vous permettant de regrouper les informations dans un seul champ, vous rendez un élément de travail plus accessible aux utilisateurs moins impliqués. La fonctionnalité « ID personnalisé » respecte les directives suivantes :

  1. On peut attribuer un code unique aux tâches. Par exemple, le code d'une tâche de type « Exigence » serait REQ, et celui d'une tâche de type « User story » serait US.
  2. Vous pouvez définir le numéro de départ à partir duquel vos types d'éléments de travail seront numérotés par incréments. Par exemple, vous pouvez spécifier que la numérotation des identifiants personnalisés des User Stories commence à 00001 ; l'identifiant personnalisé de chaque User Story sera alors incrémenté à partir de ce numéro.
  3. Vous pouvez également ajouter un préfixe de projet facultatif à tout identifiant personnalisé. Par exemple, un nom de projet tel que « Projet X » pourrait se voir attribuer le préfixe PX.
  4. Enfin, vous pouvez choisir d'inclure le champ « Portée » de n'importe quel élément de travail. Le numéro d'identification n'apparaît pas dans le champ « Portée » ; la portée peut être « Équipe », « Projet » ou « Collection ».

En reprenant l'exemple présenté dans la directive ci-dessus, l'identifiant personnalisé du premier élément de travail « Requirement » (00001) du projet X serait « PX-REQ-00001 » – qui correspond à la concaténation du préfixe du projet, du code de l'élément de travail et du numéro

Durée de lecture : 5 minutes

Demandez une démonstration !

Réduire les efforts liés aux tests d'acceptation utilisateur

Réduction de 50 % des efforts consacrés aux tests d'acceptation utilisateur

Un gain de temps avéré

Un gain de temps de 80 % lors de la création d'analyses de traçabilité

Simplifier les procédures d'approbation

Réduction significative des délais de validation

Améliorer les performances

Amélioration de la productivité de 50 %

Réduire les retouches

Réduction de 10 fois des retouches en phase de développement

Simplifier la mise en conformité

Réduction de 40 % des efforts liés à la production de rapports de conformité

New MR Logo cropped
Products
New MR Logo cropped

Exigences actuelles pour le DevOps

End-to-end requirements management in Azure DevOps.

Copilot4DevOps

AI-powered assistance for DevOps workflows.

Agents4DevOps

Autonomous AI agents for DevOps execution.

AI Sync Bridge

Real-time data sync across tools and systems.

Pourquoi des exigences modernes ?

Designed to work natively within Azure DevOps, Modern Requirements extends the platform with powerful capabilities that help teams capture, manage, and validate requirements more effectively.