Découvrez comment exporter facilement vos spécifications et vos ressources au format HTML, PDF ou Microsoft Word.
Lire la suiteSignaler des tâches
Panneau d'administration « Modern Requirements »
Découvrez comment utiliser efficacement le panneau d'administration de Modern Requirements pour prendre pleinement le contrôle de votre projet.
Lire la suiteRéutilisation des exigences
Réutilisation des exigences
Découvrez comment réutiliser les exigences dans Azure DevOps
Azure DevOps est une plateforme exceptionnelle qui offre une source unique de vérité.
Pour de nombreuses équipes, cette affirmation suffit à elle seule à les inciter à envisager d'utiliser la plateforme ALM leader mondial pour la gestion de leurs exigences. La possibilité de relier les tâches de développement aux exigences, et celles-ci aux cas de test, est une opportunité difficile à laisser passer.
Mais que faire si vous n'avez pas besoin de toutes les fonctionnalités d'une plateforme ALM complète ?
Et si vous aviez simplement besoin d'une solution pour gérer vos exigences ?
Vous pouvez exploiter toutes les fonctionnalités avancées de Modern Requirements4DevOps pour transformer votre projet Azure DevOps en une solution complète de gestion des exigences. L'une de ces fonctionnalités est la possibilité de réutiliser des exigences dans différents projets, collections et serveurs à l'aide de l'outil de réutilisation de Modern Requirements4DevOps.
Vous souhaitez réutiliser des spécifications ?
Vous êtes au bon endroit.
Ce que vous apprendrez dans ce bref article :
- Avantages de la réutilisation des exigences
- Les deux types d'exigences en matière de réutilisation
- Comment exploiter efficacement la réutilisation des exigences
Les avantages de la réutilisation des exigences
Lorsque l'on évoque les avantages de la réutilisation des exigences, il y a un point qu'il convient d'aborder en premier lieu.
La question qui m'est le plus souvent posée par les équipes matérielles est la suivante : « En quoi cela pourrait-il bien profiter à des équipes qui ne travaillent pas dans le domaine logiciel ? »
Avant de commencer, précisons que la réutilisation des exigences ne concerne pas uniquement les équipes de développement logiciel.
La réutilisation des spécifications est un sujet qui suscite souvent l'intérêt.
En effet, dans l'économie mondiale, on constate que les entreprises se concentrent sur des domaines ou des secteurs spécifiques au sein de certaines industries. Cela les amène à développer des produits dans un domaine précis ou autour d'une solution donnée, et à se concentrer exclusivement sur les quelques domaines dans lesquels elles peuvent vraiment exceller.
Cela signifie que, lorsque vous développez des projets, des solutions ou des systèmes, une équipe peut souvent réutiliser des éléments d'un projet antérieur. C'est là que la réutilisation des exigences entre en jeu.
En permettant à une équipe de réutiliser ces exigences dans le projet suivant, celle-ci peut réduire la charge de travail nécessaire au démarrage d'un nouveau projet.
Pour certaines personnes, cela va peut-être déjà de soi.
Ce qui n'est peut-être pas évident, cependant, c'est que la réutilisation peut également constituer un excellent moyen de gérer les exigences dont la portée dépasse le cadre du projet. Cela inclut les exigences non fonctionnelles ou les risques qui doivent être pris en compte au niveau de l'ensemble de l'entreprise. Cela permettrait même à votre équipe de réutiliser des exigences dont l'objectif est strictement réglementaire ou axé sur la conformité. Cette fonctionnalité peut s'étendre aussi bien aux équipes logicielles qu'aux équipes matérielles et peut même aider les équipes produit dédiées à un composant physique ou à un livrable.
Les deux types de réutilisation des exigences
Réutilisation des exigences par référence
La réutilisation des exigences par référence est un moyen rapide d'intégrer des exigences existantes à votre projet en créant simplement des liens vers celles-ci. Cela vous permet d'accéder directement à ces éléments de travail et de consulter l'ensemble du contenu, des liens et des pièces jointes associés sans avoir à les copier au sein d'un même projet ou d'un projet à l'autre.
Réutilisation des exigences par copie
Dans Azure DevOps, les fonctionnalités permettant de copier des exigences ou d'autres éléments de travail d'un projet à un autre sont très limitées. Mais lorsque vous intégrez Modern Requirements4DevOps à votre environnement Azure DevOps, la réutilisation des exigences atteint son plein potentiel.
Lorsqu'on aborde la réutilisation des exigences par copie, trois grandes approches doivent être prises en compte.
Comment réutiliser efficacement les exigences
Après avoir visionné les vidéos ci-dessus, il apparaît clairement que l'outil Modern Requirements4DevOps Reuse est efficace pour la réutilisation des exigences.
Il offre un contrôle total sur les exigences que vous choisissez de réutiliser, vous permet de les personnaliser et de les relier à l'élément de travail d'origine.
Cela signifie que, quelle que soit la destination de vos spécifications, vous pouvez les envoyer à l'aide de l'outil Modern Requirements4DevOps Reuse. Il existe toutefois plusieurs façons d'utiliser cet outil de manière plus efficace.
La première mention notable concerne l'association de l'outil de réutilisation avec l'outil « Modern Requirements4DevOps Baseline ».
Qu'est-ce qu'une version de référence ?
De nombreuses équipes utilisent des versions de référence pour leurs exigences sans même s'en rendre compte.
Une version de référence est un instantané des éléments de travail à un moment donné.
De nombreuses équipes utilisent simplement les versions des documents Microsoft Word comme version de référence.
Lorsqu'il s'agit de consigner les exigences à un moment donné, la fonctionnalité Modern Requirements4DevOps présente de nombreux avantages par rapport à l'approche traditionnelle utilisant Microsoft Word. Grâce aux « baselines » de Modern Requirements4DevOps, vous pouvez consigner un ensemble de tâches telles qu'elles se présentaient à la date de votre choix.
Cela signifie que si vous souhaitez consigner vos exigences telles qu'elles étaient il y a deux semaines, vous pouvez facilement créer une version de référence pour ces exigences à cette date. Cela met directement en évidence les avantages de l'outil de réutilisation ajouté par Modern Requirements4DevOps.
En associant l'outil « Réutilisation » à notre référence, vous pouvez non seulement sélectionner l'ensemble des exigences que vous souhaitez réutiliser, mais aussi choisir la version de ces exigences. Cela vous permet de réutiliser la version la plus pertinente et la mieux adaptée de vos exigences dans votre prochain projet.
Il convient également de mentionner l'importance d'utiliser efficacement les opérations de préfixation, de postfixation et autres lors de la réutilisation des exigences.
Lorsque vous réutilisez des exigences, l'outil Modern Requirements4DevOps Reuse vous permet de personnaliser la manière dont les exigences réutilisées s'afficheront dans le projet de destination.
L'écran qui vous permet d'effectuer cette opération est présenté ci-dessous :
L'utilisation de cette fonctionnalité vous permettra d'ajouter facilement un préfixe ou un suffixe aux exigences une fois qu'elles auront atteint le projet de destination que vous avez choisi. Comme indiqué ci-dessus, vous pouvez également choisir d'envoyer ces exigences vers un chemin de domaine spécifique (comme le matériel ou les logiciels, par exemple), ou même vers une itération donnée, afin de décider du moment où elles seront traitées.
La fonctionnalité la plus couramment utilisée dans les options de champ est toutefois la possibilité d'ajouter une balise.
Souvent, lorsque vous transférez des exigences d'un projet à un autre, vous souhaitez pouvoir facilement identifier et suivre ces exigences dans le projet de destination. L'ajout d'une balise vous permettra de le faire.
Quel est le lien avec l'option « Source Work Item » ?
Cette option vous permet d'établir un lien entre le work item que vous réutilisez et celui que vous créez dans votre projet de destination.
Quel lien cela crée-t-il ?
Cela relie votre nouvel élément de travail de destination à votre élément de travail d'origine via le lien « Related » (Lié) ou tout autre type de lien que vous avez configuré dans l'espace d'administration.
Sur l'image ci-dessous, vous pouvez voir un cas de test que j'ai copié d'un projet à un autre, en utilisant à la fois le préfixe « CL- » et l'option « Link to source work item » (Lier à l'élément de travail source).
Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from. While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead.
Comment fusionner des lignes de base copiées ?
Baseline est un outil très utile, que vous souhaitiez réutiliser un seul élément de travail ou une longue liste d'éléments de travail issus de votre projet ou bibliothèque source. Dans Modern Requirements, vous pouvez créer des liens entre votre source et les éléments de travail copiés afin de pouvoir retracer l'origine de ces derniers.
Même s'il existe des liens entre eux, les éléments de travail copiés sont toujours considérés comme indépendants des éléments de travail sources, ce qui signifie que toute modification apportée aux éléments de travail copiés ou aux éléments de travail sources n'aura aucune incidence sur leur équivalent.
Vous vous demandez peut-être : comment synchroniser les modifications lorsque cela s'avère nécessaire ? Supposons que vous disposiez d'une bibliothèque dans laquelle tous vos éléments de travail relatifs aux spécifications de conception sont enregistrés, et que vous les ayez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certaines conceptions dans la bibliothèque et que vous souhaitez que toutes les spécifications de conception copiées soient synchronisées, il vous suffit d'utiliser la fonctionnalité Fusionner, qui se trouve sous « Références source copiées » ou « Références cible copiées » dans l'onglet Détails du module Références.
Baseline est un outil très utile, que vous souhaitiez réutiliser un seul élément de travail ou une longue liste d'éléments de travail issus de votre projet ou bibliothèque source. Dans Modern Requirements, vous pouvez créer des liens entre votre source et les éléments de travail copiés afin de pouvoir retracer l'origine de ces derniers.
Même s'il existe des liens entre eux, les éléments de travail copiés sont toujours considérés comme indépendants des éléments de travail sources, ce qui signifie que toute modification apportée aux éléments de travail copiés ou aux éléments de travail sources n'aura aucune incidence sur leur équivalent.
Vous vous demandez peut-être : comment synchroniser les modifications lorsque cela s'avère nécessaire ? Supposons que vous disposiez d'une bibliothèque dans laquelle tous vos éléments de travail relatifs aux spécifications de conception sont enregistrés, et que vous les ayez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certaines conceptions dans la bibliothèque et que vous souhaitez que toutes les spécifications de conception copiées soient synchronisées, il vous suffit d'utiliser la fonctionnalité Fusionner, qui se trouve sous « Références source copiées » ou « Références cible copiées » dans l'onglet Détails du module Références.
Vous vous souvenez de la définition d'une version de référence ? Il s'agit d'un instantané d'éléments de travail sélectionnés à un moment donné. Ainsi, quelles que soient les modifications apportées aux éléments de travail inclus dans la version de référence, l'instantané enregistré reste inchangé. Par conséquent, même si nous avons fusionné les versions de référence, les modifications s'appliquent aux dernières versions des éléments de travail, et non aux versions de référence elles-mêmes. Cela vous semble un peu difficile à comprendre ?
Nous vous invitons à regarder la vidéo de 5 minutes intitulée « Fusionner des lignes de base copiées ».
Want to experience reuse’s full potential?
Essayez gratuitement Modern Requirements4DevOps dès aujourd'hui.
Nous vous offrons la possibilité de tester notre solution de gestion des exigences dans votre propre environnement Azure DevOps, ou dans un environnement que nous mettons à votre disposition et qui comprend des données d'exemple.
Table des matières
Articles récents
Signaler des tâches
Learn how to easily output requirements and assets in either...
Panneau d'administration « Modern Requirements »
Learn how to effectively use the Modern Requirements admin panel...
Réutilisation des exigences
Reusing Requirements January 2, 2020 Reading Time: 8 minutes Learn...
Importation des exigences dans Azure DevOps
Importation des exigences dans Azure DevOps
Découvrez comment importer facilement des spécifications (et certains éléments) dans votre projet ADO
Lorsque vous migrez vers Azure DevOps, ou lorsque vous travaillez hors ligne sans être connecté à votre projet Azure DevOps existant, vous devez trouver un moyen d'importer vos nouvelles exigences dans Azure DevOps.
De nombreuses équipes sont confrontées au problème de l'intégration dans Azure DevOps des spécifications qu'elles ont créées dans Excel, Word ou d'autres outils. Heureusement, il existe plusieurs méthodes simples pour y parvenir sans avoir à ajouter une longue séance de copier-coller à votre processus !
Dans cet article, nous allons passer en revue plusieurs méthodes permettant d'importer des exigences.
L'une de ces options est gratuite, et certaines sont des fonctionnalités disponibles en ajoutant Modern Requirements4DevOps à votre projet Azure DevOps.
Les thèmes abordés dans cet article sont les suivants :
- Importation de données depuis Microsoft Excel
- Importation de données depuis Microsoft Word
- Importation de diagrammes et de maquettes dans Azure DevOps
Importation de données depuis Microsoft Excel
Que vous disposiez de l'ensemble ou d'une partie de vos exigences existantes dans Excel, ou que vous souhaitiez exporter des exigences depuis un outil interne vers un fichier .csv, il existe un moyen gratuit d'importer vos exigences dans votre projet Azure DevOps.
Il s'agit d'une solution gratuite, à condition que vous disposiez déjà d'Azure DevOps et d'Excel.
La première étape consiste à vérifier que vous disposez du complément Microsoft Excel intitulé « Team tab ».
Vous pouvez télécharger ce module complémentaire directement ici:
(Sur la page mentionnée ci-dessus, Azure DevOps Office® Integration 2019 figure dans la section « Autres outils, frameworks et composants redistribuables». )
Si vous avez cliqué sur le lien ci-dessus, vous pourrez activer l'onglet « Équipe » dans Excel.
Une fois activée, cette extension vous permet de relier une feuille Excel directement à un projet donné au sein de votre organisation Azure DevOps.
Une fois cette fonctionnalité activée, vous disposerez de deux fonctions principales :
1) Vous pourrez publier des exigences dansvotre projet à partir d'Excel
2) Vous pourrez exporter des exigences devotre projet versExcel
Cela signifie que vous pouvez modifier vos exigences depuis l'une ou l'autre des interfaces et synchroniser ces modifications avec votre projet. Par exemple, si vous importez des exigences dans Excel et y apportez des modifications, vous pouvez publier ces modifications pour les répercuter sur les exigences de votre projet.
Une fois que vous avez exécuté le programme d'installation que vous avez téléchargé, vous êtes prêt à activer l'extension.
Activer l'onglet « Équipe» dans Excel :
- Ouvrir Excel
- Créer une feuille vierge
- Cliquez sur Fichier
- Cliquez sur Options
- Cliquez sur « Compléments »
- Sélectionnez « Compléments COM » dans le menu déroulant situé vers le bas de la fenêtre
- Sélectionnez « Team Foundation Add-In », puis cliquez sur OK.
Si vous rencontrez des difficultés avec cette procédure, cliquez sur ce lien.
Si l'onglet « Équipe » apparaît désormais dans Excel, vous êtes prêt à importer vos exigences !
Utilisation de l'onglet « Équipe » dans Excel
Dans cette vidéo, nous vous expliquons comment votre équipe peut utiliser les fonctionnalités d'importation offertes par le complément de l'onglet « Équipe » d'Excel.
Importation de données depuis Microsoft Word
La deuxième méthode pour importer des exigences dans votre projet consiste à utiliser Microsoft Word.
Cette fonctionnalité est une « fonctionnalité en avant-première » disponible avec toute licence Enterprise Plus de Modern Requirements4DevOps. Cela signifie que tout utilisateur de votre organisation disposant d'une licence Enterprise Plus pourra accéder à la fonctionnalité d'importation de fichiers Word et l'utiliser.
Si vous n'utilisez pas encore Modern Requirements4DevOps, vous pouvez tester cette fonctionnalité d'importation depuis Word en essayant Modern Requirements4DevOps dès aujourd'hui !
Alors, comment fonctionne l'importation depuis Word ?
Avertissement : comme il s'agit d'une fonctionnalité en avant-première, il ne faut pas s'attendre à ce que ce soit la solution la plus élégante, et cela nécessitera généralement quelques connaissances en programmation. Mais rien de bien compliqué : si vous pouvez faire appel à un développeur familiarisé avec le XML (ou tout autre langage de script) pendant une vingtaine de minutes, tout devrait bien se passer.
L'importation depuis Word fonctionne à partir d'un document Word correctement formaté qui utilise différents titres pour représenter les différents éléments de travail / exigences et leurs propriétés dans votre document.
Prenons par exemple un cahier des charges que vous avez peut-être déjà au format Word.
Vous avez probablement rédigé votre introduction, votre aperçu, votre champ d'application et d'autres éléments contextuels en utilisant le style « Titre 1 ».
Vous pourriez également inclure vos épopées, vos fonctionnalités et vos récits utilisateurs dans ce document.Votre document pourrait ressembler à ceci :
Titre 1 – Introduction
-> Paragraphe – C'estici que va tout le texte de l'introduction…
Titre 1 – Présentation
-> Paragraphe –Tout le texte de la présentation va ici…
Titre 1 – Champ d'application
-> Paragraphe –Tout le texte du champ d'application va ici…
Titre 1 – Exigences
-> Titre 2 – Nom de l'épopée
–> Titre 3 – Nom de la fonctionnalité
—> Titre 4 – Nom de l'histoire utilisateur
—-> Paragraphe – Description de l'histoire utilisateur ci-dessus
Votre document est peut-être un peu différent, mais ce n'est pas grave.Les principes que vous allez découvrir restent les mêmes.
L'importation depuis Word nécessite un document (illustré ci-dessus) et un ensemble de règles (expliqué ci-dessous).
En général, un administrateur crée un ensemble de règles que votre équipe utilisera pour importer des documents, et cette opération ne doit être effectuée qu'une seule fois.Ainsi, si vous disposez déjà d'un document et que votre administrateur a créé un ensemble de règles, vous êtes prêt à commencer.
Si votre administrateur doit créer un ensemble de règles, poursuivez votre lecture.
La création d'un ensemble de règles est extrêmement simple et s'effectue en modifiant un fichier XML.
Le fichier XML que vous créez déterminera la manière dont l'outil d'importation Word analyse votre document pour :
1) Identifier les parties du document qui constituent des éléments de travail ?
2) Identifier les parties du document qui constituent les propriétés d'un élément de travail donné ?
Si vous suivez ce tutoriel en temps réel, il peut être utile de télécharger ce fichier de règles pour commencer et de regarder la vidéo suivante :
Utilisation de l'ensemble de règles d'exemple pour commencer
Dans cette vidéo, nous vous expliquons comment utiliser le fichier de règles type pour importer un document d'exigences simple. N'oubliez pas que la création d'un ensemble de règles est généralement une opération ponctuelle.
Importation de diagrammes et de maquettes dans Azure DevOps
Les diagrammes, les maquettes et les modèles de cas d'utilisation peuvent constituer des outils extrêmement utiles pour la rédaction et la collecte des exigences.
C'est pourquoi, grâce à Modern Requirements4DevOps, votre équipe peut facilement créer toutes ces visualisations directement depuis votre projet. Vous bénéficiez ainsi d'un modèle de « source unique de vérité » où tout est intégré à votre projet.
Mais peut-être disposez-vous déjà de schémas et de maquettes que vous aimeriez ajouter à votre projet Azure DevOps et associer aux exigences. Est-il possible d'importer ces ressources ?
La réponse est oui.
Notre outil de maquette et notre outil de schéma vous permettront tous deux d'intégrer facilement des maquettes ou des schémas existants dans votre projet Azure DevOps.
Pour ce faire, il vous suffit d'enregistrer votre ressource au format .png ou .jpeg à partir de l'outil de maquette ou de schéma de votre choix.
Vous pouvez ensuite importer la ressource que vous avez créée soit dans l'outil de simulation Modern Requirements4DevOp (maquettes),soit dansl'outil de schéma (schémas).
Vous vous demandez peut-être : « Mais si nous les téléchargeons au format .png ou .jpeg, comment pourrons-nous modifier nos schémas et nos maquettes ? » Eh bien, vous ne pourrez pas. Mais il y a tout de même une bonne raison de procéder ainsi.
Si vous souhaitez relier un seul diagramme à 25 exigences sans utiliser Modern Requirements, vous devrez ouvrir chacune des 25 exigences et les relier individuellement.
Lorsque vous mettrez à jour votre diagramme ultérieurement, vous devrez rouvrir les 25 exigences et modifier la pièce jointe.
Avec Modern Requirements4DevOps, vous pouvez toutefois créer un élément de travail « Diagramme » auquel vous pouvez associer directement toutes vos exigences nécessaires via le panneau de droite. Cela signifie que vous pourrez regrouper tous vos diagrammes en un seul endroit et, lorsque l'un d'entre eux devra être mis à jour, vous pourrez facilement y ajouter votre nouvelle image et associer votre pièce jointe à cet élément de travail unique.
Conclusion
Dans cet article, nous avons présenté trois méthodes différentes pour importer à la fois les exigences et leurs ressources dans votre projet Azure DevOps.
Vous pouvez importer des spécifications depuis Excel ou Word, ou encore importer vos schémas et maquettes existants.
Si vous souhaitez utiliser Modern Requirements4DevOps pour optimiser votre processus de gestion des exigences, n'hésitez pas à essayer notre produit ici !
Le module FAQ
Le module FAQ
La solution pour la collecte initiale des besoins
Dans cet article, nous présentons les fonctionnalités et les avantages du module FAQ.
Ce module a été conçu pour aider les équipes chargées de recueillir les exigences au début de leur processus de gestion des exigences. En créant des listes de questions, les équipes peuvent facilement consigner et réutiliser leurs connaissances du processus de collecte afin de poser les bonnes questions qui permettront d'obtenir les meilleures exigences.
Qu'est-ce que le module FAQ ?
Le module FAQ est un référentiel de listes de questions que votre équipe peut créer, modifier, adapter et utiliser pour recenser les besoins. En utilisant ce module pour constituer une base de connaissances pour votre équipe, vous avez l'assurance que chaque membre sera en mesure de communiquer efficacement avec les parties prenantes.
En élaborant la meilleure série de questions dans ce domaine, votre équipe peut s'assurer de toujours recueillir les meilleurs besoins possibles.
Le principal avantage de ce module est qu'il permet à votre équipe de constituer une base de connaissances pouvant être utilisée aussi bien par des analystes métier expérimentés que par ceux qui pourraient être amenés à recueillir des exigences dans un domaine qui leur est peu familier. Le module FAQ contient d'emblée plus de 3 000 questions couvrant de nombreux sujets différents.
Ces thèmes comprennent plusieurs modèles de conformité aux normes ISO, ainsi que des modèles portant sur des exigences non fonctionnelles telles que l'évolutivité, la réutilisabilité ou l'opérabilité, qui peuvent être utilisés pour la collecte des exigences.
Pour de nombreuses équipes, ce module remplacera les listes de questions sous Excel qu'elles utilisaient peut-être auparavant.
Afin de s'aligner sur les autres modules de la suite d'outils Modern Requirements, le module FAQ intègre ce qui était auparavant un processus isolé et le relie directement à votre projet. Cela signifie que vos équipes peuvent facilement ajouter des exigences à votre projet en répondant simplement aux questions de votre liste de FAQ.
Quels sont les avantages du module FAQ ?
L'intérêt de notre module FAQ peut se résumer en deux points simples.
- Le module FAQ permet de définir des exigences plus précises en guidant le processus de collecte des exigences, ce qui augmente les chances de réussite du projet.
- Le module FAQ réduit le temps consacré à la collecte d'informations tout au long de votre projet, ce qui permet à votre équipe de se mettre plus rapidement au travail.
En tirant parti des précieuses connaissances d'analystes métier expérimentés, vous pouvez créer des modèles de questions spécifiques à un domaine qui facilitent la structuration du processus de collecte des exigences. Ainsi, vous pouvez confier à n'importe quel analyste métier, quel que soit son niveau d'expérience, la tâche de rencontrer une partie prenante, tout en étant certain qu'il parviendra à définir des exigences complètes et exploitables.
Comme votre équipe n'a plus besoin de créer des modèles de questions ni de copier ensuite les exigences recueillies dans votre outil de gestion des exigences, elle peut avancer plus rapidement dans le processus de collecte des exigences. Cela signifie qu'elle consacre davantage de temps à affiner des exigences plus précises et moins de temps à copier-coller des user stories qui risquent de nécessiter des modifications supplémentaires.
Quels sont les cas d'utilisation du module FAQ ?
Lorsque nous discutons avec les membres de notre communauté de leur utilisation du module FAQ, ils nous expliquent souvent comment ce module a permis de rationaliser leurs processus et de faciliter la gestion de la phase de collecte des informations dans le cadre de leurs projets.
Même les équipes qui n'ont pas pour habitude d'utiliser des listes de questions nous font savoir, une fois qu'elles ont rejoint notre communauté, à quel point elles apprécient de pouvoir rassembler les connaissances de tous les membres de leur équipe dans une liste cohérente.
Voici les cas d'utilisation que nous avons observés pour le module FAQ.
CAS D'UTILISATION 1
Mon équipe procède actuellement à la collecte des exigences dès le début, puis avance de manière itérative tout au long du projet. Nous utilisons actuellement Excel pendant la phase de collecte des exigences, mais cela nous oblige à recopier ensuite ces exigences dans l'outil de notre choix.
En tant qu'équipe chargée de recueillir les exigences dès le début du projet, nous avons là une occasion idéale d'utiliser une liste de questions spécialement conçue pour ce domaine. Cependant, recourir à Excel pour gérer cette liste de questions revient à se condamner à un long processus de copier-coller par la suite.
Les opérations de copier-coller sont généralement sources d'erreurs et prennent beaucoup de temps. C'est souvent au cours de ces opérations déjà longues qu'un membre de l'équipe se rend compte qu'il a omis une propriété d'un élément de travail pour laquelle il a besoin de l'avis des parties prenantes.
Dans ce cas, l'utilisation du module FAQ signifie que la liste de questions est déjà disponible dans votre projet Azure DevOps. Lorsque vous poserez votre question à votre partie prenante, vous pourrez y répondre dans votre liste de questions FAQ, ce qui créera automatiquement une exigence pour vous.
Vous pouvez alors ouvrir directement cette exigence et poser toutes les questions complémentaires qui vous viennent à l'esprit pendant que vous êtes encore en présence de votre partie prenante. Cela permet de gagner du temps et rend le processus de collecte d'exigences plus approfondi, tout en évitant à votre équipe de passer à côté d'occasions d'obtenir les bonnes informations au bon moment.
CAS D'UTILISATION 2
Mon équipe travaille dans un environnement soumis à des réglementations et nous devons nous assurer que nous mettons en place l'ensemble des mesures nécessaires pour rester en conformité et pouvoir faire l'objet d'un audit.
L'un des principaux atouts du module FAQ réside dans le fait que vous pouvez utiliser bon nombre de nos modèles prédéfinis liés à la conformité pour recenser les besoins. Ces modèles ont été élaborés en collaboration avec bon nombre de nos clients actuels, ainsi qu'en partenariat avec des experts reconnus dans ces domaines.
Dans ce cas, les équipes ayant accès au module FAQ peuvent s'adresser à des experts du domaine et à des consultants afin d'élaborer une liste de questions qui les aidera à définir toutes les exigences nécessaires à la conformité et au respect de la réglementation. Une fois créées, ces listes de questions peuvent être réutilisées dans plusieurs projets et déployées à maintes reprises.
Comment utiliser efficacement le module FAQ ?
Le module FAQ offre des avantages considérables aux équipes qui en sont à la phase de collecte des exigences de leur projet. Voici quelques exemples d'utilisation de ce module pour favoriser la réussite de votre projet.
Utilisez les modèles de listes de questions prédéfinis
Lorsque les utilisateurs ont besoin d'un modèle concernant les exigences non fonctionnelles ou les normes ISO, ils peuvent se lancer rapidement en utilisant l'un de nos modèles intégrés. Ces modèles contiennent déjà bon nombre des questions les plus importantes relatives à ces sujets. Les utilisateurs peuvent partir d'un modèle prédéfini, supprimer les questions qui ne sont pas pertinentes et/ou ajouter de nouvelles questions si nécessaire.
Créez vos propres modèles de listes de questions
Si l'un de nos modèles prédéfinis ne répond pas à vos besoins, vos équipes peuvent facilement créer des listes de questions à partir de zéro. En partant d'un modèle vierge, votre équipe peut facilement élaborer un ensemble complet de questions qui facilitent et optimisent le processus de recueil des exigences.
Une fois la liste de questions établie, elle peut être réutilisée dans différents projets pour vous aider lors de la phase de collecte d'informations ultérieure.
Créez des listes de questions destinées aux membres les moins expérimentés de votre équipe
En établissant des listes de questions, vous offrez un véritable guide à tout membre qui serait moins familier avec un domaine, une solution ou un système. Ces listes constituent alors un excellent outil pour accompagner les analystes métier débutants, ou les analystes métier expérimentés issus d’un autre domaine, pendant la phase de collecte des exigences. Les équipes comprennent que la qualité des questions que nous posons au début d’un projet se répercute directement sur la qualité des exigences que nous recueillons.
En créant des listes de questions à l'aide de notre module FAQ, vous vous assurez d'obtenir dès le départ les spécifications les plus précises possibles.
Services MR – Surveillance des e-mails, identifiant personnalisé, indicateur de modification
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 ».
Lire la suiteUtilisation d'Alice : assistante en administration
Ce module, inspiré de l'intelligence artificielle, a été conçu pour aider votre équipe à recenser rapidement les besoins.
Lire la suiteConfiguration de l'onglet « Agent MR / Services »
Configuration de Modern Requirements4DevOps à l'aide de l'onglet « Agent/Services » de MR
Dans cet article, nous expliquons comment configurer l'onglet « MR Agent / Services » dans MR4DevOps. L'onglet « Services » offre actuellement aux utilisateurs trois fonctionnalités supplémentaires pour tout projet utilisant Azure DevOps (anciennement VSTS).
Durée de lecture : 25 minutes
Utilisation de l'onglet « Services » pour configurer
Modern Requirements4DevOps
MR Services (anciennement MR Agent) est l'un des composants de Modern Requirements4DevOps qui s'installe automatiquement avec l'application principale. Il s'agit d'un framework qui permet d'étendre les fonctionnalités d'Azure DevOps à l'aide de déclencheurs.
IMPORTANT :
Veuillez noter que les services MR ne sont accessibles qu'avec les services Azure DevOps utilisant une adresse IP publique pour communiquer avec VSTS (services Azure DevOps). Si une machine ne dispose pas d'un accès public, les services VSTS Azure DevOps ne pourront pas être utilisés (car ils nécessitent un accès public pour communiquer avec la machine). Il est conseillé aux utilisateurs de contacter leurs administrateurs réseau afin de modifier la valeur pour indiquer l'adresse IP publique de leurs machines, y compris le port correspondant.
À l'heure actuelle, MR Services (MR Agent) comprend les trois sous-composants suivants :
- Identifiant personnalisé
- Drapeau sale
- Surveillance des e-mails
Une authentification correcte de l'utilisateur est requise avant de configurer l'un de ces composants. Les fichiers de configuration de ces composants ne fonctionneront pas tant que l'organisation concernée (dans Azure DevOps) ou la collection (dans TFS) n'aura pas été enregistrée via une procédure d'authentification.
TABLE DES MATIÈRES
- Authentification des utilisateurs des services MR
- Identification manuelle d'un nouveau projet dans les organisations ADO
- Configuration des identifiants personnalisés
- Configuration de la fonctionnalité « Dirty Flag »
- Configuration de la fonctionnalité de surveillance des e-mails
- Contacter le service d'assistance
Authentification des utilisateurs des services MR
- Lancez la version intégrée de l'application et sélectionnez le Exigences actuelles pour le DevOps option sous le Onglet « Paramètres ».
Le panneau d'administration s'affiche.
- Cliquez sur le Onglet « Services ».
Les options de l'onglet « Services » s'affichent.
Le sous-onglet « Paramètres » propose deux options :
- Définition de l'intervalle de temps pour analyser l'organisation Azure DevOps (ou la collection TFS) à la recherche de nouveaux projets
- Enregistrement de l'organisation actuelle (les identifiants de l'utilisateur administrateur sont requis pour cette option)
Remarque : veuillez saisir les valeurs pour ces deux paramètres en une seule fois. Les utilisateurs ne peuvent pas configurer un paramètre tout en laissant l'autre en attente.
Entrez la durée de l'analyse automatique (entre 1 et 60).
Cette valeur détermine l'intervalle, en minutes, après lequel l'organisation Azure DevOps enregistrée sera analysée à la recherche de nouveaux projets.
- Fournissez les identifiants de connexion autorisés (avec des droits d'administrateur TFS).
Une fois l'authentification réussie, l'organisation actuelle est enregistrée et un message de confirmation s'affiche.
Identification manuelle d'un nouveau projet dans votre organisation Azure DevOps
La section précédente décrit la procédure permettant de personnaliser la fréquence des analyses automatiques pour l'organisation Azure DevOps. La valeur indiquée dans l'image ci-dessus signifie que l'organisation sera analysée toutes les 30 minutes pour détecter les nouveaux projets.
Toutefois, si l'utilisateur vient de créer un nouveau projet et souhaite s'y atteler immédiatement, il doit l'identifier manuellement (le projet) dans l'organisation Azure DevOps. Pour ce faire, les étapes suivantes sont nécessaires :
- Saisissez la commande suivante dans CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin
- Une fois dans le répertoire bin, tapez la commande suivante : MRAgent
Le menu des options s'affiche.
- Type 4 puis cliquez sur Entrée.
- Saisissez le nom de l'organisation Azure DevOps pour rechercher de nouveaux projets.
Si aucun message d'erreur ne s'affiche, cela signifie que le processus de détection des nouveaux projets créés après l'enregistrement d'une organisation Azure DevOps ou l'application de sa configuration s'est déroulé avec succès.
Configurer la fonctionnalité « Identifiant personnalisé »
« Custom ID » est un composant de MR Services (MR Agent) qui permet d'attribuer des identifiants personnalisés aux éléments de travail, en plus de leurs identifiants par défaut. Ces identifiants personnalisés ne remplacent pas les identifiants d'origine, mais viennent les compléter. Ils permettent de retracer l'origine des éléments de travail (c'est-à-dire de savoir quelle équipe a créé un élément de travail donné).
Pour que l'identifiant personnalisé fonctionne correctement, les utilisateurs doivent créer manuellement les deux éléments suivants :
- Un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel l'ID personnalisé doit être appliqué).
- Un autre dossier portant le nom de l'organisation Azure DevOps ou de la collection TFS (pour laquelle un identifiant personnalisé est requis) sous le nom du dossier Azure DevOps (TFS).
Le dossier de l'organisation concernée devrait également contenir le config.xml fichier contenant l'ensemble de la configuration. La hiérarchie des fichiers et des dossiers doit se présenter comme indiqué ci-dessous, à l'aide du modèle de texte et de l'image correspondante :
Comme le montre l'image ci-dessus, un échantillon Config.xml Le fichier est placé dans le Identifiant personnalisé dossier.
- Créez à cet emplacement un dossier portant le nom du serveur Azure DevOps (sur lequel le composant doit être appliqué).
- Accédez au dossier que vous venez de créer, puis créez-y un autre dossier en lui attribuant le nom de votre organisation Azure DevOps (à laquelle le composant doit être appliqué).
- Copiez le xml fichier (évoqué précédemment) dans le dossier nouvellement créé, c'est-à-dire le dossier portant le nom de l'organisation Azure DevOps.
Ce fichier contient le schéma de la configuration souhaitée.
Configuration du fichier XML d'identifiant personnalisé
- Ouvrez le xml fichier dans le Bloc-notes ou n'importe quel éditeur de texte.
- Définissez la valeur de la IDScope ajouter une balise selon les besoins, par exemple :
– Collection -> appliquer la portée du compteur au niveau de la collection.
– Projet -> appliquer la portée du compteur au niveau du projet.
– Équipe -> appliquer la portée du compteur au niveau de l'équipe. - La balise« FieldReferenceName »avec la valeur« Override »définie sur« Yes »signifie que le champ défini par l'utilisateur (entre les balises) sera pris en compte pour l'identifiant personnalisé. La valeur« Override »définie sur« No »signifie que le champ par défaut « MR.CID » sera pris en compte et appliqué pour l'identifiant personnalisé. Cela signifie que les utilisateurs doivent définir ce champ dans leur modèle TFS avec le même nom de référence, c'est-à-dire MR.CID.
- La balise« CollectionUrl »nécessite l'URL de la collection TFS à laquelle l'identifiant personnalisé doit s'appliquer. (Remarque : assurez-vous que l'URL ne se termine pas par « \ »)
- “Projects DefaultNoOfChar” tag denotes the number of characters to pick up from the project name, if the project name is not defined in the tag<Project Name= “ ”>. By default its value is 5. Update the value if desired.
- Indiquez le nom du projet TFS (par exemple, Project Name = « GITNew ») et son nom personnalisé (par exemple, Prefix = « GTN ») qui seront utilisés dans les identifiants personnalisés.
- «Séquence n° 1La valeur de la balise « » indique le nombre de groupes d'identifiants personnalisés créés dans le fichier de configuration et sert à identifier et à distinguer les identifiants. Il s'agit toujours d'un champ exclusivement numérique qui doit rester unique. La balise « Sequence » se compose d'une combinaison du type d'élément de travail, du formatage requis pour le champ d'identifiant et du compteur de départ.
- La valeur« WIType »doit indiquer le type de Work Item auquel l'identifiant personnalisé doit s'appliquer. De plus, si nécessaire, plusieurs Work Items peuvent être définis pour une même configuration afin d'être appliqués en tant que groupe.
- La balise« FieldFormat »sert à définir le format d'identification requis pour l'identifiant personnalisé.
Exemple : [PN] Req #####[PN] est utilisé comme espace réservé pour le préfixe du nom de projet défini ci-dessus.
Pour plus d'informations sur le format numérique, veuillez consulter le lien suivant :
https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings - La balise « FieldCounter » est nécessaire pour définir le numéro ou la série à partir de laquelle le compteur d'identifiant personnalisé doit démarrer. Une fois la valeur du compteur appliquée (fichier de configuration appliqué), elle ne peut en aucun cas être modifiée.
- Une fois la configuration du fichier terminée, enregistrez-le puis fermez-le.
Attribution d'un identifiant personnalisé à des éléments de travail existants
- Tapez la commande suivante dans l'invite de commande : cd :\Program Files\Modern Requirements\MR-Agent\bin
- Une fois dans le répertoire bin, tapez la commande suivante : MRAgent
Le menu des options s'affiche.
- Type 1 puis cliquez sur Entrée.
- Saisissez l'URL de l'organisation Azure DevOps (ou de la collection TFS).
Si aucun message d'erreur ne s'affiche, cela signifie que l'identifiant personnalisé a été correctement appliqué aux éléments de travail existants de la collection.
Configurer la fonctionnalité « Dirty Flag »
« Dirty Flag » est un composant de MR Services (MR Agent) qui sert à marquer certains éléments de travail comme « modifiés » (en raison d'un changement des exigences), afin que les parties prenantes concernées puissent les examiner une seule fois au lieu de poursuivre leur travail sur la base d'exigences obsolètes.
Pour que le « Dirty Flag » fonctionne correctement, les utilisateurs doivent créer manuellement les deux éléments suivants :
- Un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le drapeau « Dirty » doit être appliqué).
- Un autre dossier portant le nom de l'organisation Azure DevOps ou de la collection TFS (pour laquelle le drapeau « Dirty » est requis) sous le nom du dossier Azure DevOps (TFS).
Le dossier de collecte correspondant devrait également contenir le config.xml fichier contenant l'ensemble de la configuration. La hiérarchie des fichiers et des dossiers doit se présenter comme indiqué ci-dessous, à l'aide du modèle de texte et de l'image correspondante :
Comme le montre l'image ci-dessus, un échantillon Config.xml Le fichier est placé dans le Drapeau sale dossier.
- Créez à cet emplacement un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit être appliqué).
- Accédez au dossier que vous venez de créer, puis créez-y un autre dossier portant le nom de l'organisation Azure DevOps (ou de la collection TFS) à laquelle le composant doit s'appliquer.
- Copiez le xml fichier (évoqué précédemment) dans le dossier nouvellement créé, c'est-à-dire le dossier portant le nom de l'organisation Azure DevOps (ou de la collection TFS).
Ce fichier contient le schéma de la configuration souhaitée.
Configuration du fichier XML « Dirty Flag »
- Ouvrez le xml fichier dans le Bloc-notes ou n'importe quel éditeur de texte.
- Définissez la valeur de l'URL de la collection à l'aide de la URL de la collection
Chaque balise d'action comporte un Source partie et un Cible partie. La partie « Source » indique à MR Services (MR Agent) ce qu'il doit rechercher pour déclencher le drapeau « Dirty » ; la partie « Cible » indique à MR Services (MR Agent) quels types d'éléments de travail seront marqués comme « Dirty » en cas de déclenchement.
- Dans la section Source, la balise« WIType »indique le type de tâches avec lesquelles le drapeau « Dirty » fonctionnera. Il est possible d'utiliser plusieurs types de tâches en les séparant par une virgule «,».
- La balise« FieldReferenceName »indique le ou les champs de l'élément de travail (la liste est fournie dans la balise WIType ) qui seront vérifiés.
- Le «Valeur du champLa balise « » indique la valeur exacte de la Nom de référence du champ qui déclenchera le drapeau « Dirty ».
Si plusieurs champs sont cochés, l'indicateur « Dirty » ne sera activé que lorsque toutes les valeurs de champ correspondront, c'est-à-dire selon la logique « ET ».
- Le «WIType »de la section cible indique le type d'éléments de travail qui seront marqués comme modifiés si la condition de la section source est remplie.
- Une fois la configuration terminée, enregistrez et fermez le fichier de configuration.
Configuration de la fonctionnalité de surveillance des e-mails
Email Monitor est un composant de MR Services (MR Agent) qui sert à créer automatiquement des tâches à partir d'e-mails. Une adresse e-mail spécifique est configurée à cet effet et, une fois la configuration terminée, tous les e-mails envoyés à cette adresse entraînent la création ou la mise à jour de tâches. Le processus comprend les étapes suivantes* :
- Configuration du fichier de configuration du moniteur de messagerie (situé à un emplacement spécifique)
- Saisie et vérification des paramètres de messagerie
Chacune de ces étapes est détaillée ci-dessous.
*Pour les serveurs Azure DevOps (TFS) locaux, MR Services (MR Agent) ajoute automatiquement l'emplacement correspondant dans le fichier de paramètres de l'application (AppSettings.config). Toutefois, si Azure DevOps Services est utilisé, l'ordinateur de l'utilisateur doit disposer d'une adresse IP active que les services Azure DevOps peuvent utiliser pour accéder au système et communiquer. Cette adresse IP doit être ajoutée dans le fichier de configuration AppSettings. La procédure à suivre est détaillée dans les étapes suivantes :
- Accédez au dossier d'installation de MR Services (MR Agent) (mis en évidence sur l'image) et ouvrez le Paramètres d'application fichier de configuration dans un éditeur de texte.
Le URL de l'application est automatiquement défini sur l'ordinateur local.
Remplacez cette valeur (pour Azure DevOps Services uniquement) par l'adresse IP active de votre machine, en incluant le port correspondant.
*Contactez votre administrateur réseau pour obtenir l'adresse IP active et les informations relatives au port- Enregistrez et fermez le fichier de configuration.
Configurations de synchronisation dans le fichier APPSETTING
Au bas de la fichier de configuration , trois paramètres de synchronisation sont proposés aux utilisateurs.
S'abonnerProgramme
- Fonctionne avec tous les composants de MR Services
- Permet de vérifier les nouveaux projets/collections
- La valeur par défaut « 30 »* correspond au nombre de minutes après lesquelles MR Services (MR Agent) recherche de nouveaux projets. Les utilisateurs peuvent configurer cette valeur (en minutes) en fonction de leurs besoins.
*Cette valeur peut également être configurée via le panneau d'administration.
Appliquer tout le calendrier
- Ne fonctionne qu'avec un identifiant personnalisé
- Permet d'attribuer un identifiant personnalisé aux éléments de travail nouvellement créés
- La valeur par défaut « 30 » correspond au nombre de minutes au bout desquelles MR Services (MR Agent) recherche de nouvelles tâches et leur attribue des identifiants personnalisés. Les utilisateurs peuvent configurer cette valeur (en minutes) en fonction de leurs besoins.
E-mailVérifier le calendrier
- Fonctionne uniquement avec Email Monitor
- Permet de vérifier si un nouvel e-mail est arrivé, à partir duquel des tâches pourraient être créées ou mises à jour
- La valeur par défaut « 15 » correspond au nombre de minutes après lesquelles MR Services (MR Agent) effectue une vérification des e-mails. Les utilisateurs peuvent configurer cette valeur (en minutes) en fonction de leurs besoins.
Configuration de la surveillance des e-mails
Pour que le moniteur de messagerie fonctionne correctement, les utilisateurs doivent créer manuellement les éléments suivants :
- Un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le moniteur de messagerie doit être appliqué).
Le dossier serveur concerné doit également contenir le fichier config.xml, qui regroupe tous les paramètres de configuration. La structure du dossier et du fichier doit se présenter comme indiqué ci-dessous, à l'aide du modèle de texte et de l'image correspondante :
* Remarque : dans les versions actuelles d'Email Monitor, la hiérarchie s'arrête au dossier du serveur, et le fichier doit être placé dans ce dossier. Toutefois, dans les versions futures, la hiérarchie s'étendra jusqu'au dossier de l'organisation (à l'instar des autres composants de MR Services (MR Agent)). Veuillez consulter votre administrateur ou contacter Modern Requirements si vous avez des doutes à ce sujet.
Comme le montre l'image ci-dessus, un fichier Config.xml d'exemple se trouve dans le dossier EmailMonitor.
- Créez à cet emplacement un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit être appliqué).
- Accédez au dossier que vous venez de créer et copiez le xml fichier (évoqué précédemment) dans ce dossier, c'est-à-dire le dossier portant le nom du serveur Azure DevOps (TFS).
- Ce fichier contient le schéma de la configuration souhaitée.
Configuration du fichier XML du moniteur de messagerie
- Ouvrez le xml fichier dans le Bloc-notes ou n'importe quel éditeur de texte.
- Définissez la valeur de la URL du serveur ajouter une balise selon les besoins, par exemple :
- Définissez de la même manière la valeur pour URL de la collection (y compris le Projet par défaut)
IMPORTANT
– Les valeurs pour les deux URL du serveur et URL de la collection devrait correspondre à la structure de dossiers décrite précédemment.
– Assurez-vous que l'URL ne se termine pas par une barre oblique « / »
– L'utilisateur peut définir plusieurs URL de collection dans le fichier de configuration. - Indiquez la valeur de E-mail de l'administrateur. Cette adresse e-mail sert de solution de secours au cas où la fonctionnalité souhaitée ne pourrait pas être mise en œuvre à l'aide de l'adresse définie dans Courriel balise (expliquée à l'étape suivante).
Remarque : le fichier de configuration ne peut contenir qu'une seule adresse e-mail d'administrateur.
- «CourrielLa balise « » est la balise principale de ce fichier ; elle définit l'adresse à laquelle l'e-mail doit être envoyé. Les e-mails envoyés à cette adresse serviront à créer les types de tâches souhaités. Configurez la Courriel ajouter une balise si nécessaire
- Courriel: Indiquez l'adresse e-mail à laquelle les e-mails doivent être envoyés pour la création ou la mise à jour des tâches. Si certains critères ne correspondent pas aux valeurs souhaitées, un e-mail d'avertissement sera envoyé à l'adresse E-mail de l'administrateur définie ci-dessus.
Remarque : plusieurs adresses e-mail peuvent être définies dans le fichier de configuration.
- Type de tâche : Définissez le type de tâche à créer. Dans l'exemple suivant CatégorieRéférence représente le type de catégorie interne des éléments de travail. La présence de plusieurs valeurs dans cette balise signifie que le type d'élément de travail approprié sera créé en fonction du modèle du projet d'équipe. Par exemple, si le projet d'équipe utilise le modèle CMMI, l'e-mail créera un élément de travail de type « Exigence ». De même, pour un projet basé sur la méthode Agile, une « User Story » sera créée, et pour un projet basé sur Scrum, un élément de « Project Backlog » sera créé.
- FieldReference = « System.Title » : Indique quel sera le titre de l'élément de travail à créer. L'exemple suivant montre que l'objet de l'e-mail deviendra le titre de l'élément de travail.
- OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
- OnUpdate=”false” Cela signifie que, pour les éléments de travail existants, le champ « Titre » ne serait pas mis à jour.
- FieldReference = « System.Description »: Indiquez où enregistrer les informations provenant des e-mails reçus (c'est-à-dire dans quelle propriété/quel champ de l'élément de travail). L'exemple suivant utilise le Description champ prévu à cet effet.
- OnCreate= ”true” means that for new Work Items, the content of the email (described next) would be used to populate the Description field of the work item.
- OnUpdate=”false” means that for existing Work Items, the Description field would not be overwritten. Instead the update would go to the comments/history section of the work item.
La dernière partie de ce champ indique la composition du champ « Description ». Les informations suivantes composeraient le champ « Description » :
- Sender Name shown inside <> e.g.
- Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
- Le corps de l'e-mail a été ajouté sur une nouvelle ligne
- La finale FieldReference = « System.History » est utilisé pour les e-mails de discussion qui suivent la création d'un élément de travail. Au lieu de remplacer le Description champ, les informations relatives à l'e-mail sont ensuite enregistrées dans le Commentaires champ (appelé en interne Histoire). La composition de la Histoire le domaine est plus ou moins le même qu'à Description champ évoqué plus haut. Il est recommandé aux utilisateurs de conserver les paramètres d'origine de cette balise.
- Une fois la configuration du fichier terminée, enregistrez-le puis fermez-le.
- Courriel: Indiquez l'adresse e-mail à laquelle les e-mails doivent être envoyés pour la création ou la mise à jour des tâches. Si certains critères ne correspondent pas aux valeurs souhaitées, un e-mail d'avertissement sera envoyé à l'adresse E-mail de l'administrateur définie ci-dessus.
Déploiement de l'outil de surveillance des e-mails
Email Monitor peut être configuré en définissant les paramètres appropriés dans le panneau d'administration. Ces paramètres sont accessibles via l'onglet « Services ».
La section « Services » du panneau d'administration comporte actuellement deux onglets : Paramètres & Surveillance des e-mails
L'onglet « Paramètres » permet de gérer 1) l'authentification des utilisateurs et l'enregistrement de l'organisation, 2) la recherche de nouveaux projets.
Email Monitor prend en charge toutes les options liées aux e-mails évoquées précédemment dans la section consacrée à la ligne de commande.
Configuration des options de Email Monitor
- L'onglet « Email Monitor » de la section « Services » permet de configurer les paramètres de messagerie.
- Pour accéder aux options, cliquez sur l'onglet « Email Monitor », comme le montre l'image ci-dessous.
- Si l'utilisateur n'a pas enregistré son organisation (en fournissant les informations requises dans le sous-onglet « Paramètres »), il est redirigé vers le sous-onglet « Paramètres » lorsqu'il clique sur le sous-onglet « Surveillance des e-mails », à moins qu'il ne saisisse les informations demandées.
- Les paramètres d'Email Monitor sont répartis en sections, chacune permettant de configurer un paramètre spécifique.
- Tous les paramètres nécessaires sont configurés une seule fois. Les utilisateurs ne peuvent pas configurer certains paramètres tout en laissant d'autres en suspens.
- La première section sert à configurer le projet par défaut et l'adresse e-mail de l'administrateur.
- La deuxième section sert à configurer l'adresse e-mail qui sera utilisée pour la surveillance des e-mails.
En cliquant sur Enregistrer une adresse e-mail ouvrirait une fenêtre contextuelle dans laquelle il serait possible de configurer les paramètres réseau de la messagerie (par exemple, SSL, POP3, IMAP, etc.).
- La troisième section sert à définir les paramètres (qui permettront) d'extraire le contenu des éléments de travail à partir des e-mails envoyés à l'adresse e-mail enregistrée.
Une fois tous les paramètres configurés, cliquez sur le bouton « Enregistrer les modifications » pour déployer le moniteur de messagerie.
Articles connexes
Contacter le service d'assistance
Contacter le service d'assistance
Le panneau d'administration de Modern Requirements4DevOps
Dans cet article, nous expliquons comment utiliser le panneau d'administration de Modern Requirements4DevOps pour activer et désactiver certaines fonctionnalités dans chaque module de MR4DevOps.
Lire la suiteMise en œuvre des exigences modernes pour le DevOps
Dans cet article, nous vous expliquons les étapes simples à suivre pour que les équipes puissent activer Modern Requirements4DevOps, tant dans notre version intégrée que dans notre version autonome.
Lire la suite
