Learn how to easily output requirements and assets in either HTML, PDF, or as Microsoft Word documents.
Continuer la lectureÉléments de travail de déclaration
Panneau d’administration des exigences modernes
Learn how to effectively use the Modern Requirements admin panel to take full control of your project.
Continuer la lectureExigences de réutilisation
Exigences de réutilisation
Apprenez comment réutiliser les exigences dans Azure DevOps
Azure DevOps est une plateforme incroyable qui offre une source unique de vérité.
Pour de nombreuses équipes, cette seule affirmation suffit à envisager d’utiliser la plateforme ALM leader mondiale pour la gestion des exigences. Pouvoir lier les tâches de développement aux exigences, et celles-ci aux cas de test, est difficile à manquer.
Mais que se passe-t-il si vous n’avez pas besoin de toutes les fonctionnalités d’une plateforme ALM complète?
Et si vous n’avez besoin que d’une solution pour vos besoins en gestion des exigences?
Vous pouvez utiliser toutes les fonctionnalités riches 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 les exigences à travers différents projets, collections et serveurs à l’aide de l’outil Modern Requirements4DevOps Reuse.
Vous cherchez à réutiliser les exigences?
Tu es au bon endroit.
Ce que vous apprendrez dans ce court article :
- Avantages des exigences de réutilisation
- Les deux types d’exigences de réutilisation
- Comment les exigences de réutilisation peuvent être utilisées efficacement
Les avantages de la réutilisation des exigences
Quand on parle des avantages de la réutilisation des exigences, il y a une chose qui doit d’abord être abordée.
La question la plus fréquente que je reçois des équipes matérielles est : « Comment cela pourrait-il bénéficier aux équipes qui ne sont pas liées au logiciel? »
Donc, avant de commencer, la réutilisation des exigences ne concerne pas seulement les équipes logicielles.
La réutilisation des exigences est un sujet qui attire souvent l’attention des gens.
Cela s’explique par le fait que, dans l’économie mondiale, nous voyons des entreprises se concentrer sur un domaine ou des domaines donnés au sein de certaines industries. Cela conduit des entreprises à développer des produits dans un domaine précis, ou autour d’une solution donnée, et à vraiment cibler les quelques domaines dans lesquels elles peuvent vraiment réussir.
Cela signifie qu’en construisant des projets, des solutions ou des systèmes, une équipe peut souvent réutiliser des éléments d’un projet précédent. C’est là que la réutilisation des exigences entre en jeu.
En permettant à une équipe de réutiliser ces exigences dans le prochain projet, elle peut réduire les frais généraux nécessaires pour démarrer un nouveau projet.
Pour certaines personnes, cela peut déjà être évident.
Ce qui n’est peut-être pas évident, cependant, c’est que la réutilisation peut aussi être un excellent moyen de gérer des exigences qui dépassent le niveau du projet. Cela inclurait les exigences non fonctionnelles ou les risques qui doivent être considérés comme un mandat à l’échelle de l’entreprise. Cela irait même jusqu’à permettre à votre équipe de réutiliser des exigences dont le but est strictement réglementaire ou axé sur la conformité. Cette fonctionnalité peut être étendue aux équipes logicielles et matérielles et peut même aider les équipes de produit dédiées à un composant physique ou à un livrable.
Les deux types d’exigences de réutilisation
Réutilisation des exigences par référence
Réutiliser les exigences par référence est un moyen rapide d’introduire les exigences existantes dans votre projet simplement en créant des liens avec elles. En faisant cela, vous pourriez avoir un accès direct à ces éléments de travail et revoir tout le contenu associé, les liens et les pièces jointes sans les copier réellement dans ou entre projets.
Réutilisation des exigences par copie
Dans Azure DevOps, il y a très peu de fonctionnalités pour copier les besoins ou autres tâches d’un projet à un autre. Mais lorsque vous ajoutez Modern Requirements4DevOps à votre environnement Azure DevOps, la réutilisation des exigences atteint son plein potentiel.
Lorsqu’on discute des exigences de réutilisation par copie, il y a trois approches principales à considérer.
Comment réutiliser efficacement les exigences
Après avoir regardé les vidéos ci-dessus, il est évident que l’outil de réutilisation Modern Requirements4DevOps est efficace pour réutiliser les besoins.
Il offre un contrôle total sur les exigences que vous choisissez de réutiliser, vous permet d’appliquer des personnalisations à ces exigences et vous permet de lier les exigences à l’élément du travail source.
Cela signifie que, peu importe où vous souhaitez envoyer les exigences, vous pouvez le faire en utilisant l’outil Modern Requirements4DevOps Reuse. Mais il y a des façons d’utiliser l’outil de réutilisation plus efficacement.
La première mention notable est en associant l’outil de réutilisation à l’outil Modern Requirements4DevOps Baseline.
Qu’est-ce qu’une référence?
Beaucoup d’équipes utilisent des lignes de base d’exigences sans même s’en rendre compte.
Une référence est un instantané des éléments de travail à un moment donné.
Pour de nombreuses équipes, ils utilisent simplement des versions de documents Microsoft Word comme référence.
Lorsqu’on parle de capturer les besoins à un moment donné, il y a plusieurs raisons pour lesquelles la fonctionnalité Modern Requirements4DevOps est meilleure que l’approche traditionnelle de Microsoft Word. Avec Modern Requirements4DevOps Baselines, vous pouvez enregistrer un ensemble d’éléments de travail tels qu’ils étaient à la date de votre choix.
Cela signifie que si vous voulez enregistrer vos exigences telles qu’elles étaient il y a deux semaines, vous pouvez facilement créer une référence pour ces exigences à cette date. Cela se prête directement aux avantages de l’outil de réutilisation ajouté par Modern Requirements4DevOps.
En combinant l’outil de Réutilisation avec notre Baseline, vous pouvez non seulement choisir l’ensemble d’exigences que vous souhaitez réutiliser, mais aussi la version de ces exigences. Cela vous permet d’appliquer la meilleure et la plus appropriée version de vos besoins à votre prochain projet.
La prochaine mention notable est d’utiliser efficacement le préfixe / postfixe / et d’autres opérations lors de la réutilisation des exigences.
Lors de la réutilisation des exigences, l’outil Modern Requirements4DevOps Reuse vous permet de personnaliser la façon dont les exigences réutilisées apparaîtront dans leur projet de destination.
L’écran qui vous permet de faire cela peut être vu ci-dessous :
Utiliser la fonctionnalité ci-dessus vous permettra d’ajouter facilement un préfixe ou un postfixe aux exigences une fois qu’ils atteignent votre projet de destination choisi. Comme vu plus haut, vous pouvez aussi choisir d’envoyer ces exigences à un chemin de zone spécifique (comme le matériel ou le logiciel, par exemple), ou même dans une itération donnée afin de décider quand ces exigences seront prises en charge.
La fonctionnalité la plus couramment utilisée dans les options de champ, cependant, est la possibilité d’ajouter une balise.
Souvent, lorsque vous envoyez des exigences d’un projet à un autre, vous voulez pouvoir facilement identifier et retracer ces exigences dans votre projet de destination. Ajouter une étiquette vous permettra de le faire.
Quel est le lien avec l’option Source Work Item?
Cette option vous permet d’établir un lien entre l’élément de travail que vous réutilisez et celui que vous créez dans votre projet de destination.
Quel lien cela crée-t-il?
Il relie votre nouvel élément de travail de destination à votre œuvre original via le lien « Apparenté » ou tout type de lien que vous avez configuré dans la zone d’administration.
Dans l’image ci-dessous, vous pouvez voir un cas de test que j’ai copié d’un projet à l’autre, en utilisant à la fois le préfixe « CL- » et les options « Lien vers 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 les lignes de base copiées?
Baseline est un outil très utile, peu importe si vous voulez réutiliser un seul élément de travail ou une longue liste de travaux de votre projet ou bibliothèque source. Dans Exigences Modernes, vous pouviez créer des liens entre vos éléments d’œuvres sources et copiés afin de localiser l’origine de ces éléments copiés.
Bien qu’il y ait des liens entre les deux, les éléments de l’œuvre copiés sont toujours considérés comme indépendants des éléments de l’œuvre source, ce qui signifie que tout changement que vous faites aux éléments copiés ou à l’œuvre source n’affectera pas leur équivalent.
Vous pourriez demander : comment synchroniser les changements quand c’est nécessaire? Supposons que vous ayez une bibliothèque où tous vos éléments de conception sont sauvegardés, et que vous les avez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certains designs dans la bibliothèque et que vous voulez que toutes les spécifications de conception copiées soient synchronisées, vous pouvez simplement utiliser la fonctionnalité de fusion, qui se trouve sous Source/Copied Baseline(s) ou Target Copied Baseline(s) dans l’onglet Détails du module Baseline.
Baseline est un outil très utile, peu importe si vous voulez réutiliser un seul élément de travail ou une longue liste de travaux de votre projet ou bibliothèque source. Dans Exigences Modernes, vous pouviez créer des liens entre vos éléments d’œuvres sources et copiés afin de localiser l’origine de ces éléments copiés.
Bien qu’il y ait des liens entre les deux, les éléments de l’œuvre copiés sont toujours considérés comme indépendants des éléments de l’œuvre source, ce qui signifie que tout changement que vous faites aux éléments copiés ou à l’œuvre source n’affectera pas leur équivalent.
Vous pourriez demander : comment synchroniser les changements quand c’est nécessaire? Supposons que vous ayez une bibliothèque où tous vos éléments de conception sont sauvegardés, et que vous les avez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certains designs dans la bibliothèque et que vous voulez que toutes les spécifications de conception copiées soient synchronisées, vous pouvez simplement utiliser la fonctionnalité de fusion, qui se trouve sous Source/Copied Baseline(s) ou Target Copied Baseline(s) dans l’onglet Détails du module Baseline.
Vous vous souvenez encore de la définition d’une référence? Un instantané des éléments de travail sélectionnés à un moment donné. Donc, peu importe les changements que nous avons apportés aux éléments de travail de base, l’instantané sauvegardé ne changera pas. Donc, même si on a fusionné les bases de base, les changements sont faits sur les dernières versions des éléments de travail, pas sur les bases elles-mêmes. Ça semble un peu difficile à comprendre?
Veuillez regarder la vidéo de 5 minutes Merge Copied Baselines.
Want to experience reuse’s full potential?
Essayez Modern Requirements4DevOps gratuitement dès aujourd’hui.
Nous vous offrons la possibilité d’essayer notre solution de gestion des exigences dans votre propre environnement Azure DevOps, ou dans un environnement que nous fournissons incluant des données d’échantillons.
Table des matières
Articles récents
Éléments de travail de déclaration
Learn how to easily output requirements and assets in either...
Panneau d’administration des exigences modernes
Learn how to effectively use the Modern Requirements admin panel...
Exigences de réutilisation
Reusing Requirements January 2, 2020 Reading Time: 8 minutes Learn...
Importation des exigences vers Azure DevOps
Importation des exigences dans Azure DevOps
Apprenez comment importer facilement des exigences (et certains assets) dans votre projet ADO
Lorsque vous passez à Azure DevOps, ou que vous travaillez hors ligne en dehors de votre projet Azure DevOps existant, vous avez besoin d’un moyen d’intégrer vos nouvelles exigences créées dans Azure DevOps.
Beaucoup d’équipes ont le problème d’intégrer les exigences qu’elles ont créées dans Excel, Word et ailleurs dans Azure DevOps. Heureusement, il existe quelques façons simples de faire cela sans avoir à vous soucier d’ajouter une longue session de copier/coller à votre processus!
Dans cet article, nous allons couvrir plusieurs façons différentes de répondre aux exigences d’importation.
L’une de ces options est gratuite, et certaines sont des fonctionnalités offertes par l’ajout de Modern Requirements4DevOps à votre projet Azure DevOps.
Les sujets abordés dans cet article sont les suivants :
- Importation des exigences depuis Microsoft Excel
- Importation des exigences à partir de Microsoft Word
- Importation de diagrammes et de maquettes dans Azure DevOps
Importation des exigences depuis Microsoft Excel
Que vous ayez toutes ou partie de vos exigences existantes dans Excel, ou que vous souhaitiez exporter les exigences d’un outil interne vers un fichier .csv, il existe une façon gratuite d’importer vos exigences dans votre projet Azure DevOps.
C’est une solution gratuite – à condition que vous ayez déjà Azure DevOps et Excel.
La première étape est de vous assurer d’avoir la complétion Microsoft Excel appelée « onglet Équipe ».
Vous pouvez télécharger cet add-in directement d’ici :
(Sur la page mentionnée ci-dessus, Azure DevOps® Office Integration 2019 est listé dans la section Autres outils, cadres et redistribuables.)
Si vous cliquez sur le lien ci-dessus, vous pourrez activer l’onglet Excel.
Une fois activée, cette extension vous permet de connecter directement un feuille Excel à un projet donné dans votre organisation Azure DevOps.
Lorsque vous l’activez, vous aurez deux fonctions principales à votre disposition :
1) Vous pourrez publier les exigences de votre projet à partir d’Excel
2) Vous pourrez extraire les exigences de votre projet vers Excel
Cela signifie que vous pouvez travailler sur vos besoins depuis l’une ou l’autre interface et connecter les changements à votre projet. c’est-à-dire que si vous intégrez les exigences dans Excel et faites des modifications, vous pouvez publier ces modifications en sauvegarde de vos exigences dans votre projet.
Après avoir lancé l’installateur que vous avez téléchargé, vous êtes prêt à activer l’extension.
Activation de l’onglet Équipe dans Excel :
- Ouvrir Excel
- Créez une feuille vierge
- Cliquez sur Fichier
- Cliquez sur les options
- Cliquez sur les modules complémentaires
- Choisissez les modules complémentaires COM dans le menu déroulant près du bas de la fenêtre
- Sélectionnez « Ajout de l’équipe Fondation » et sélectionnez OK.
Si vous avez des problèmes avec ce processus, suivez ce lien.
Si vous voyez maintenant l’onglet Équipe dans Excel, vous êtes prêt à importer les exigences!
Utilisation de l’onglet Équipe Excel
Dans cette vidéo, nous expliquons comment votre équipe peut utiliser les capacités d’importation offertes par l’onglet Excel Team.
Importation des exigences à partir de Microsoft Word
La deuxième façon d’importer les exigences dans votre projet est via Microsoft Word.
Cette fonctionnalité est une « fonctionnalité d’aperçu » disponible avec n’importe quelle licence Enterprise Plus Modern Requirements4DevOps. Cela signifie que tout utilisateur de votre organisation disposant d’une licence Enterprise Plus pourra accéder et utiliser la fonction d’importation de Word.
Si vous n’utilisez pas actuellement Modern Requirements4DevOps, vous pouvez essayer cette fonction d’importation de mots en essayant Modern Requirements4DevOps dès aujourd’hui!
Alors, comment fonctionne l’importation de mots?
Avertissement : En tant que fonction de prévisualisation, vous devez vous attendre à ce que ce ne soit pas la solution la plus jolie, et qu’il faudra généralement des connaissances en codage. Mais pas grand-chose – et si vous pouvez emprunter un développeur familier avec le xml (ou tout autre langage de script) pendant 20 minutes, vous devriez très bien vous en sortir.
L’importation de Word fonctionne en ayant un document Word bien 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.
Par exemple, prenons un exemple de BRD que vous avez peut-être déjà au format Word.
Vous avez probablement vos éléments d’introduction, d’aperçu, de portée et d’autres éléments de contexte utilisant le style du titre 1.
Vous pourriez ensuite inclure vos Épopées, Fonctionnalités et Histoires d’utilisateur dans ce document également. Votre document pourrait ressembler à ceci :
Titre 1 – Introduction
-> paragraphe – Tout le texte de l’introduction va ici...
Titre 1 – Aperçu
-> paragraphe –Tout le texte du Résumé est ici...
Cap 1 – Portée
-> paragraphe – Tout le texte du Scope va ici...
Titre 1 – Exigences
-> Titre 2 – Nom d’Epic
–> Titre 3 – Nom de la caractéristique
—> Titre 4 – Nom de l’histoire utilisateur
—-> Paragraphe – Description de l’histoire utilisateur ci-dessus
Maintenant, votre document peut être un peu différent, mais ce n’est pas grave. Les principes que vous allez apprendre sont les mêmes.
L’importation de mots nécessite un document (illustré ci-dessus) et un ensemble de règles (expliqué ci-dessous).
Typiquement, un administrateur crée un ensemble de règles que votre équipe utilisera pour importer les documents, et cela ne devra être fait qu’une seule fois. Donc, si vous avez déjà créé un document et que votre administrateur a créé un système de règles, vous êtes prêt.
Si votre administrateur doit créer un ensemble de règles, lisez la suite.
Créer un ensemble de règles est incroyablement simple et se fait en modifiant un fichier XML.
Le fichier XML que vous créez déterminera comment l’outil d’importation de Word analyse votre document pour :
1) Quelles parties du document sont des éléments de travail?
2) Quelles parties du document sont des propriétés d’un élément de travail donné?
Si vous travaillez là-dessus en temps réel, il pourrait être utile de télécharger ce fichier de règles comme point de départ et de regarder la vidéo suivante :
Utiliser l’ensemble de règles d’exemple pour commencer
Dans cette vidéo, nous expliquons comment utiliser le fichier de règles d’exemple pour importer un document d’exigences simple. N’oubliez pas que la création d’un ensemble de règles est généralement un processus unique.
Importation de diagrammes et de maquettes dans Azure DevOps
Les diagrammes, les maquettes et les modèles de cas d’utilisation peuvent être des outils incroyables pour créer et obtenir des besoins.
C’est pourquoi, avec Modern Requirements4DevOps, votre équipe peut facilement construire toutes ces visualisations directement à partir de votre projet. Cela vous permet de bénéficier d’un modèle à source unique de vérité où tout est intégré à votre projet.
Mais peut-être avez-vous déjà des diagrammes et des maquettes que vous aimeriez ajouter à votre projet Azure DevOps et les connecter aux exigences. Est-il possible d’importer ces ressources?
La réponse est oui.
Notre outil de maquettes et notre outil de diagrammes vous permettront d’intégrer facilement des maquettes ou diagrammes existants dans votre projet Azure DevOps.
Pour ce faire, il suffit de sauvegarder votre asset comme un fichier .png ou .jpeg à partir de l’outil de maquette/diagramme de votre choix.
Vous pouvez ensuite téléverser votre asset créé soit dans l’outil de simulation Modern Requirements4DevOp (maquettes) ou l’outil Diagram (diagrammes).
Vous vous le demandez peut-être, mais si nous le téléversons en .png ou .jpeg, comment peut-on modifier nos diagrammes et maquettes? Eh bien, tu ne peux pas. Mais il y a une raison pour laquelle tu devrais faire ça malgré tout.
Si vous voulez connecter un seul diagramme à 25 exigences sans utiliser les exigences modernes, vous devrez ouvrir les 25 exigences et les relier à chaque exigence individuelle.
Lorsque vous mettrez à jour votre diagramme à l’avenir, vous devrez rouvrir les 25 exigences et changer la pièce jointe.
Avec Modern Requirements4DevOps cependant, vous pouvez créer un élément de travail Diagramme auquel vous pouvez lier directement toutes vos exigences nécessaires à l’aide du bon panneau. Cela signifie que vous pourrez avoir votre diagramme au même endroit, et lorsque ce diagramme doit être mis à jour, vous pourrez facilement ajouter votre image mise à jour et connecter votre pièce jointe à cet élément de travail unique.
Conclusion
Dans cet article, nous avons abordé trois façons distinctes d’importer à la fois les exigences et leurs ressources dans votre projet Azure DevOps.
Vous pouvez importer des exigences via Excel ou Word, ou importer vos diagrammes et maquettes existants.
Si vous souhaitez utiliser Modern Requirements4DevOps pour soutenir votre processus de gestion des exigences, envisagez d’essayer notre produit ici!
Le module FAQ
Le module FAQ
La solution pour la collecte des besoins à l’avance
Dans cet article, nous abordons les caractéristiques et avantages du module FAQ.
Ce module a été conçu pour aider les équipes qui recueillent les exigences au début de leur processus de gestion des exigences. En créant des listes de questions, les équipes peuvent facilement capturer et réutiliser leurs connaissances du processus d’élection pour poser les bonnes questions qui répondent aux meilleures exigences.
Qu’est-ce que le module FAQ?
Le module FAQ est un dépôt de listes de questions que votre équipe peut construire, modifier, modifier, modeler et utiliser pour obtenir des exigences. En utilisant le module FAQ pour bâtir une base de connaissances pour votre équipe, vous pouvez avoir confiance que chaque membre de l’équipe peut s’engager efficacement avec les parties prenantes.
En construisant le meilleur ensemble de questions dans ce domaine, votre équipe peut s’assurer d’obtenir toujours le meilleur ensemble d’exigences possible.
Le principal avantage de ce module est qu’il permet à votre équipe de bâtir une base de connaissances pouvant être utilisée à la fois par des BA expérimentés et par ceux qui pourraient avoir besoin d’obtenir des exigences dans un domaine inconnu. Le module FAQ est déjà rempli de plus de 3000 questions couvrant de nombreux sujets différents.
Ces sujets incluent plusieurs modèles de conformité ISO, ainsi que des modèles sur des sujets d’exigences non fonctionnelles tels que la scalabilité, la réutilisabilité ou l’opérabilité, qui peuvent être utilisés pour l’élicitation.
Pour de nombreuses équipes, ce module remplacera leurs listes de questions basées sur Excel qu’elles utilisaient auparavant.
Pour rester en ligne avec les autres modules de l’ensemble d’outils Exigences modernes, le module FAQ relie directement ce qui était auparavant un processus déconnecté à votre projet. Cela signifie que vos équipes peuvent facilement ajouter des exigences à votre projet simplement en fournissant des réponses aux questions de votre liste de questions FAQ.
Quelle valeur offre le module FAQ?
La valeur de notre module FAQ peut être décrite en deux points simples.
- Le module FAQ aide à créer de meilleures exigences en guidant le processus d’elicitation, ce qui augmente les chances de succès du projet.
- Le module FAQ réduit le temps consacré à l’elicitation tout au long de votre projet, permettant à votre équipe de commencer à construire plus rapidement.
En utilisant les connaissances précieuses des BA expérimentés, vous pouvez créer des modèles de questions spécifiques au domaine qui aident à structurer le processus d’élicitation. Cela signifie que vous pouvez envoyer n’importe quel analyste de recherche de n’importe quel niveau d’expérience dans une pièce avec un intervenant et avoir confiance qu’il créera des exigences complètes et applicables.
En n’ayant plus besoin de créer des modèles de questions puis de copier les exigences obtenues dans votre outil de gestion de données, votre équipe peut avancer plus rapidement dans le processus d’élicitation. Cela signifie plus de temps passé à itérer sur des exigences plus précises et moins de temps passé à copier-coller des histoires utilisateur qui auront probablement besoin de plus de travail.
Quels sont les cas d’utilisation du module FAQ?
Lorsque nous discutons avec notre communauté de leur utilisation du module FAQ, ils décrivent souvent les façons dont ce module a simplifié leur processus et facilité la navigation de la phase d’élection des projets.
Même avec des équipes qui n’utilisent traditionnellement pas de liste de questions, après avoir rejoint notre communauté, elles nous diront combien de valeur ajoutée elles voient à la capacité de regrouper les connaissances de tous les membres de leur équipe en une liste cohérente.
Voici les cas d’utilisation que nous avons vus pour le module FAQ.
CAS D’UTILISATION 1
Mon équipe recueille actuellement les besoins dès le départ et avance de façon itérative dans notre projet par la suite. Nous utilisons actuellement Excel pendant la phase de collecte des exigences, mais cela signifie que nous copions les exigences dans notre outil de prédilection par la suite.
En étant une équipe qui recueille les exigences dès le départ, cela offre une occasion parfaite d’utiliser une liste de questions conçue pour ce domaine. Mais utiliser Excel comme moyen de faciliter cette liste de questions est une recette pour un long processus de copier-coller plus tard.
Les processus de copier/coller sont généralement sujets aux erreurs et longs. C’est souvent, lors de ces processus déjà longs de copier/coller, qu’un membre de l’équipe reconnaît qu’il a oublié une propriété d’un poste de travail sur laquelle il a besoin de l’avis des parties prenantes.
Dans ce cas, utiliser le module FAQ signifie que vous aurez déjà la liste des questions dans votre projet Azure DevOps. Lorsque vous posez 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 ensuite ouvrir cette exigence directement et poursuivre les questions de suivi que vous pourriez avoir pendant que vous êtes encore avec votre partie prenante. Cela fait gagner du temps et rend le processus d’électorat plus complet, tout en empêchant votre équipe de manquer des occasions d’obtenir la bonne information au bon moment.
CAS D’UTILISATION 2
Mon équipe travaille dans un domaine conforme/réglementé et nous devons nous assurer de construire l’ensemble complet des exigences pour rester conformes et auditables.
L’une des meilleures fonctionnalités du module FAQ est que vous pouvez utiliser plusieurs de nos modèles préconçus liés à la conformité pour obtenir des exigences. Nos modèles préconçus ont été créés en partenariat avec plusieurs de nos clients existants, ainsi que grâce à des partenariats avec des leaders d’opinion dans ces domaines.
Dans ce cas, les équipes ayant accès au module FAQ peuvent parler à des experts du domaine et des consultants et constituer la liste de questions qui les aidera à établir toutes les exigences nécessaires à la conformité et à la réglementation. Une fois créées, ces listes de questions peuvent être réutilisées dans plusieurs projets et déployées encore et encore.
Comment puis-je utiliser efficacement le module FAQ?
Le module FAQ offre des avantages incroyables aux équipes dans la phase d’électtion de leur projet. Voici quelques façons d’utiliser le module pour faciliter la réussite de votre projet.
Utilisez les modèles de liste de questions préconstruits
Lorsque les utilisateurs ont besoin d’un modèle sur les exigences non fonctionnelles ou sur des sujets ISO, ils peuvent commencer rapidement en utilisant l’un de nos modèles intégrés. Ces modèles contiennent déjà plusieurs des questions les plus importantes sur ces sujets. Les utilisateurs peuvent commencer avec un modèle préconstruit et supprimer les questions non pertinentes et/ou ajouter de nouvelles questions nécessaires.
Créez vos propres modèles de liste de questions
Si l’un de nos modèles préconçus ne répond pas à vos besoins, les équipes peuvent facilement constituer des listes de questions à partir de zéro. En commençant par un modèle vierge, votre équipe peut facilement constituer un ensemble complet de questions qui rendent l’obtention des besoins un processus simple et plus efficace.
Une fois la liste de questions établie, elle peut être réutilisée entre les projets pour aider à la phase d’évinction ultérieure.
Créez des listes de questions pour des membres moins expérimentés de votre équipe
En constituant des listes de questions, vous offrez effectivement des conseils à tout membre qui pourrait être moins familier avec un domaine, une solution ou un système. Ces listes sont alors un excellent outil pour guider les nouveaux BA ou les BA expérimentés d’un autre domaine, durant la phase d’elicitation. Les équipes comprennent que la qualité des questions que nous posons au début d’un projet se reflète directement dans la qualité des exigences que nous suscitons.
En constituant des listes de questions avec notre module FAQ, vous pouvez vous assurer d’obtenir les meilleures exigences possibles dès la première fois.
Services MR – Moniteur de courriel, ID personnalisé, Drapeau Sale
Dans cet article, nous abordons certaines des fonctionnalités supplémentaires disponibles dans l’édition Enterprise Plus de Modern Requirements4DevOps. Ces fonctionnalités sont appelées services MR.
Continuer la lectureUtiliser Alice : Assistante BA
This module is an AI-inspired module built to help your team elicit requirements quickly.
Continuer la lectureConfiguration de l’Agent/Onglet Services MR
Configuration de Modern Requirements4DevOps à l’aide de l’onglet Agent/Services MR
Dans cet article, nous expliquons comment configurer l’onglet Agent / Services MR dans MR4DevOps. L’onglet Services offre actuellement aux utilisateurs 3 fonctionnalités supplémentaires à tout projet utilisant Azure DevOps Service (anciennement VSTS).
Utilisation de l’onglet Services pour configurer
Exigences modernes4DevOps
MR Services (anciennement appelé MR Agent) est l’un des composants de Modern Requirements4DevOps qui est automatiquement installé avec l’application principale. C’est un cadre qui offre de l’extensibilité à Azure DevOps en utilisant des déclencheurs.
IMPORTANT :
Veuillez noter que les services MR ne sont accessibles qu’avec les services AZURE DEVOPS utilisant une IP LIVE/publique pour communiquer avec VSTS (Azure DevOps services). Si une machine n’a pas d’accès public, les services VSTS Azure DevOps ne pourraient 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 pour modifier la valeur de l’adresse IP active de leurs machines, y compris le port concerné.
Actuellement, les Services MR (Agent MR) comportent les trois sous-composantes suivantes :
- ID personnalisé
- Drapeau Sale
- Moniteur de courriels
Une authentification utilisateur appropriée est requise avant la configuration de ces composants. Les fichiers de configuration de n’importe quel composant ne fonctionneront que si l’organisation pertinente (dans Azure DevOps) ou la collection (dans TFS) est enregistrée via authentification.
Authentification des utilisateurs des services MR
- Lance la version intégrée de l’application et sélectionne le Exigences modernes4DevOps option sous la onglet Paramètres.
Le panneau d’administration s’affiche.
- Cliquez sur le Onglet Services.
Les options pour l’onglet Services sont affichées.
L’onglet Paramètres propose deux options :
- Définir un intervalle de temps pour scanner l’organisation Azure DevOps (ou la collection TFS) pour les nouveaux projets
- Enregistrement de l’organisation actuelle (des identifiants administrateur sont requis pour cette option)
Note : Entrez les valeurs pour ces deux réglages en une seule fois. Les utilisateurs ne peuvent pas choisir de configurer un paramètre tout en laissant l’autre en attente.
Entrez l’intervalle de temps pour le balayage automatique (devrait être entre 1 et 60).
Cette valeur détermine l’intervalle en minutes après lequel l’organisation Azure DevOps enregistrée sera analysée pour les nouveaux projets.
- Fournissez des identifiants de connexion autorisés. (avec les droits d’administrateur TFS).
Après l’authentification réussie, l’organisation actuelle est enregistrée et un message de confirmation s’affiche.
Identifier manuellement un nouveau projet dans votre organisation Azure DevOps
La section ci-dessus expliquait le processus pour personnaliser le temps de balayage automatique pour l’organisation Azure DevOps. La valeur montrée dans l’image ci-dessus signifie que l’organisation serait scannée toutes les 30 minutes pour le nouveau projet.
Cependant, si l’utilisateur vient de créer un nouveau projet et veut travailler dessus immédiatement, il doit l’identifier manuellement (le projet) dans l’organisation Azure DevOps. Les étapes suivantes sont requises pour y parvenir :
- Voici la commande suivante sur CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin
- Une fois dans le répertoire bin, entrez la commande suivante : MONSIEUR
Le menu des options s’affiche.
- Type 4 et cliquez sur Entrée.
- Voici la valeur d’organisation Azure DevOps à analyser pour de nouveaux projets.
Si aucun message d’erreur n’est affiché, le processus a été réalisé avec succès pour analyser les nouveaux projets créés après l’enregistrement d’une organisation Azure DevOps ou l’application de sa configuration.
Configurez la fonction ID personnalisé
L’ID personnalisé est un composant des services MR (agent MR) utilisé pour fournir des identifiants personnalisés aux éléments de travail en plus de leurs identifiants de travail par défaut. Les identifiants personnalisés ne remplacent pas les identifiants d’origine, ils les complètent plutôt. Les identifiants personnalisés peuvent être utilisés pour suivre l’origine de l’élément de travail (c’est-à-dire quelle équipe a créé un élément de travail particulier).
Pour que l’ID personnalisé fonctionne correctement, les utilisateurs doivent créer manuellement les deux éléments suivants :
- Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel l’ID personnalisé est requis).
- Un autre dossier porte le nom d’une organisation Azure DevOps ou de la collection TFS (sur laquelle l’ID personnalisé est requis) sous le nom du dossier Azure DevOps (TFS).
Le dossier d’organisation pertinent devrait aussi inclure le config.xml contenant toutes les configurations. La hiérarchie des fichiers et des dossiers devrait apparaître telle qu’affichée ci-dessous, en utilisant le motif de texte et l’image pertinente :
Comme décrit dans l’image ci-dessus, un échantillon Config.xml le fichier est placé dans le CustomId Dossier.
- Créez un dossier nommé d’après le nom du serveur Azure DevOps (sur quel composant doit s’appliquer) à cet endroit.
- Entrez dans le dossier nouvellement créé et créez à nouveau un autre dossier ici avec le nom de l’organisation Azure DevOps (sur quel composant doit s’appliquer).
- Copiez le XML (mentionné plus tôt) dans le nouveau dossier créé, c’est-à-dire Dossier avec le nom d’organisation Azure DevOps.
Ce fichier contient le plan pour la configuration désirée.
Configuration du fichier XML Custom ID
- Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
- Définir la valeur de la IDScope Étiquette selon les exigences, par exemple :
– Collection -> appliquer un champ de contre-champ au niveau de la collection.
– Projet -> appliquer la portée contraire au niveau du projet.
– Équipe -> appliquer un contre-scope au niveau équipe. - La balise « FieldReferenceName » avec la valeur « Overrie » « Oui » signifie que le champ défini par l’utilisateur (entre les étiquettes) sera considéré pour l’ID personnalisé. La valeur « Overrie » « Non » signifie que le champ par défaut « MR. CID » sera pris en compte et demandé pour l’ID 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 sur laquelle l’ID personnalisé doit s’appliquer. (Note : Veuillez vous assurer que l’URL ne doit pas se terminer 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.
- Fournir le nom du projet TFS (par exemple Nom du projet = = GITNew ») et son nom personnalisé (par exemple préfixe = « GTN ») pour être utilisés dans des identifiants personnalisés.
- “Séquence ID="1 »« La valeur de l’ID de l’étiquette indique le nombre de groupes différents d’ID personnalisés créés dans le fichier de configuration et sert à identifier et différencier de l’ID. Ce sera toujours un champ uniquement numérique et devrait rester unique. La balise Séquence consiste en une combinaison du type d’Élément de travail, de la mise en forme requise sur le champ ID et du compteur pour commencer.
- La valeur « WIType » nécessite le type d’élément de travail sur lequel l’ID personnalisé est requis pour s’appliquer. De plus, si nécessaire, plusieurs éléments de travail pourraient être définis pour que la même configuration s’applique en groupe.
- L’étiquette « FieldFormat » est utilisée pour définir la mise en forme de l’ID requise sur l’ID personnalisé.
Exemple : [PN] Req #####[PN] est utilisé comme substitut pour le préfixe défini ci-dessus du nom du projet.
Pour une référence au format numérique, veuillez consulter le lien suivant :
https://docs.microsoft.com/en-us/dotnet/standard/base-types/custom-numeric-format-strings - L’étiquette « FieldCounter » est requise pour définir le numéro ou la série d’où le compteur d’ID personnalisé doit commencer. Une fois la valeur du compteur appliquée (le fichier de configuration est appliqué), elle ne peut en aucun cas être modifiée.
- Après avoir complété avec succès le fichier de configuration, sauvegardez et fermez le fichier.
Application d’un identifiant personnalisé sur des éléments de travail existants
- Entrez la commande suivante sur CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin
- Une fois dans le répertoire bin, entrez la commande suivante : MONSIEUR
Le menu des options s’affiche.
- Type 1 et cliquez sur Entrée.
- Entrez la valeur URL d’organisation Azure DevOps (ou TFS Collection).
Si aucun message d’erreur n’est affiché, l’ID personnalisé a été appliqué avec succès sur les éléments de collection existants.
Configurez la fonction Dirty Flag
Dirty Flag est un composant des services MR (agent MR) utilisé pour marquer certains éléments de travail comme inactifs (en raison d’exigences modifiées) afin que les parties prenantes concernées puissent examiner ces éléments une seule fois au lieu de poursuivre avec les exigences obsolètes.
Pour que le Dirty Flag fonctionne correctement, les utilisateurs doivent créer manuellement les deux éléments suivants :
- Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le Dirty Flag doit s’appliquer).
- Un autre dossier nommé d’après l’organisation Azure DevOps ou la collection TFS (sur laquelle le drapeau Dirty est requis) sous le nom du dossier Azure DevOps (TFS).
Le dossier pertinent de la collection devrait également inclure le config.xml contenant toutes les configurations. La hiérarchie des fichiers et des dossiers devrait apparaître telle qu’affichée ci-dessous, en utilisant le motif de texte et l’image pertinente :
Comme décrit dans l’image ci-dessus, un échantillon Config.xml le fichier est placé dans le Drapeau Sale Dossier.
- Créez un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit s’appliquer) à cet endroit.
- Entrez dans le dossier nouvellement créé et créez à nouveau un autre dossier ici avec le nom de l’organisation Azure DevOps (ou de la collection TFS) (sur quel composant doit s’appliquer).
- Copiez le XML (mentionné plus tôt) dans le nouveau dossier créé, c’est-à-dire Dossier avec le nom d’organisation Azure DevOps (ou collection TFS).
Ce fichier contient le plan pour la configuration désirée.
Configuration du fichier XML Dirty Flag
- Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
- Définir la valeur de l’URL de la collection à l’aide de la CollectionURL
Chaque balise Action possède une Source partie et a Cible partie. La partie Source indique aux Services MR (Agent MR) quoi surveiller pour déclencher le Signal Rouge; la partie Cible indique aux Services MR (Agent MR) quels types d’éléments seront étiquetés comme sales en cas de déclenchement.
- Dans la section Source, l’étiquette « WIType » indique le type d’éléments de travail avec lesquels le Dirty Flag fonctionnera. Plusieurs types d’éléments de travail pouvaient être utilisés avec une virgule « , » comme séparateur.
- La balise « FieldReferenceName » indique le(s) champ(s) de l’élément de travail (la liste est fournie dans l’étiquette WIType ) qui seront cochés.
- Le "FieldValue" indique la valeur exacte de la FieldReferenceName ça déclenchera le Dirty Flag.
Si plusieurs champs sont cochés, le Dirty Flag ne sera déclenché que lorsque toutes les valeurs de champ sont correspondantes, c’est-à-dire en utilisant la logique AND.
- Le « WIType » de la section cible indique le type d’éléments de travail qui seront marqués comme sales si la condition de la section source est remplie.
- Sauvegardez et fermez le fichier de configuration après son achèvement réussi.
Mise en place de la fonction Surveillance des courriels
Email Monitor est un composant des services MR (MR Agent) utilisé pour créer automatiquement des éléments de travail à partir des courriels. Une adresse courriel particulière est configurée à cette fin et, une fois le processus de configuration complété avec succès, tous les courriels envoyés à cette adresse courriel entraînent la création ou la mise à jour des éléments de travail. Le processus comprend les étapes suivantes* :
- Configuration du fichier de configuration du moniteur courriel (placé à un endroit précis)
- Saisie et vérification des paramètres de courriel
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 pertinent dans le fichier de paramètres d’application (AppSettings.config). Cependant, si des services Azure DevOps sont impliqués, la machine de l’utilisateur devrait avoir une adresse IP active que les services Azure DevOps peuvent utiliser pour accéder ou communiquer. Cette adresse IP devrait être ajoutée dans le fichier de configuration AppSettings. Le processus pour le réaliser est expliqué en étapes suivantes :
- Allez dans le dossier d’installation de MR Services (MR Agent) (surligné dans l’image) et ouvrez le Paramètres de l’application fichier de configuration dans un éditeur de texte.
Le ApplicationURL est automatiquement réglé vers la machine locale.
Changez la valeur (pour les services Azure DevOps seulement) pour l’adresse IP active de votre machine, y compris le port concerné.
*Contactez votre administrateur réseau pour obtenir l’adresse IP en temps réel et les informations sur les ports- Sauvegardez et fermez le fichier de configuration.
Configurations de synchronisation dans le fichier APPSETTING
Au bas du fichier de configuration AppSettings, trois configurations de timing sont disponibles pour les utilisateurs.
AbonnementCalendrier
- Fonctionne pour toutes les composantes des services MR
- Utilisé pour vérifier les nouveaux projets/collections
- La valeur par défaut « 30 »* représente le nombre de minutes, après quoi les services MR (agent MR) scannent les nouveaux projets. Les utilisateurs peuvent configurer la valeur (en minutes) selon leurs besoins.
*Cette valeur peut aussi être configurée à l’aide du Panneau d’administration.
ApplyAllSchedule
- Fonctionne seulement pour l’ID personnalisé
- Utilisé pour appliquer un identifiant personnalisé sur les éléments de travail nouvellement créés
- La valeur par défaut « 30 » représente le nombre de minutes, après quoi les services MR (agent MR) scannent les nouveaux éléments de travail et y appliquent des identifiants personnalisés. Les utilisateurs peuvent configurer la valeur (en minutes) selon leurs besoins.
EmailCheckSchedule
- Fonctionne seulement pour Email Monitor
- Ça servait à vérifier si un nouveau courriel était arrivé d’où les éléments de travail pouvaient être créés ou mis à jour
- La valeur par défaut « 15 » représente le nombre de minutes, après quoi les services MR (agent MR) scannent les courriels. Les utilisateurs peuvent configurer la valeur (en minutes) selon leurs besoins.
Configuration du moniteur de courriel
Pour que l’Email Monitor fonctionne correctement, les utilisateurs doivent créer manuellement les éléments suivants :
- Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (auquel le moniteur de courriel doit s’appliquer).
Le dossier serveur concerné devrait aussi inclure le fichier config.xml contenant toutes les configurations. La hiérarchie des fichiers et des dossiers devrait apparaître comme indiqué ci-dessous à l’aide du motif de texte et de l’image pertinente :
* Note : pour les versions actuelles d’Email Monitor, la hiérarchie s’arrête au dossier serveur, et place le fichier dans ce dossier serveur. Cependant, pour les versions futures, la hiérarchie remonterait jusqu’au dossier de l’organisation (comme pour d’autres composants des services MR (MR Agent)). Veuillez consulter votre administrateur ou contacter les Exigences modernes si toute incertitude persiste à ce sujet.
Comme décrit dans l’image ci-dessus, un fichier Config.xml exemple est placé dans le dossier EmailMonitor .
- Créez un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit s’appliquer) à cet endroit.
- Entrez dans le dossier nouvellement créé et copiez le XML (mentionné plus tôt) dans ce dossier, c’est-à-dire Dossier avec le nom du serveur Azure DevOps (TFS).
- Ce fichier contient le plan pour la configuration désirée.
Configuration du fichier XML du moniteur de courriel
- Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
- Définir la valeur de la ServerURL Étiquette selon les exigences, par exemple :
- De même, on définit la valeur pour Collection Url (y compris le DefaultProject)
IMPORTANT
– Les valeurs pour les deux ServerURL et Collection Url doit correspondre à la structure de dossiers décrite précédemment.
– S’assurer 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. - Fournir la valeur pour AdminEmail. Cette adresse courriel est utilisée comme atténuation, au cas où la fonctionnalité désirée ne pourrait pas être atteinte avec l’adresse définie dans Courriel tag (expliqué à l’étape suivante).
Note : Un seul courriel administrateur peut exister dans le fichier de configuration.
- “Courriel" est l’étiquette principale dans ce fichier qui définit où le courriel sera envoyé. Les courriels envoyés à cette adresse serviraient à créer les types de travaux désirés. Configurez la Courriel Étiquette au besoin
- Courriel: Fournir l’adresse courriel cible où le courriel doit être livré pour la création ou la mise à jour des éléments de travail. Si certains critères ne correspondent pas aux valeurs souhaitées, le courriel d’avertissement sera envoyé à la Courriel administratif défini ci-dessus.
Note : Plusieurs adresses courriel peuvent être définies dans le fichier de configuration.
- Type d’article de travail : Définissez le type d’élément de travail souhaité à créer. Dans l’exemple suivant CatégorieRéférence représente le type de catégorie interne des éléments de travail. Plusieurs valeurs dans cette étiquette signifient que le type de travail pertinent sera créé selon le modèle de projet d’équipe. Par exemple, si le projet d’équipe utilise le modèle CMMI, alors le courriel créerait un élément de travail d’exigence. De même, pour un projet axé sur Agile, une histoire utilisateur serait créée et pour un projet basé sur Scrum, un élément de backlog de projet serait créé.
- FieldReference="System.Title » : Indique quel serait le titre de l’objet à créer. L’exemple suivant montre que l’objet du courriel deviendrait 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” signifie que pour les éléments de travail existants, le champ Titre ne serait pas mis à jour.
- FieldReference="System.Description »: Indiquer où placer l’information provenant des courriels entrants (c’est-à-dire dans quelle propriété/champ se trouve l’article). L’exemple suivant utilise le Description champ pour cette fin.
- 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 partie ultérieure de ce champ indique la composition du champ de 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>
- Corps du courriel ajouté dans une nouvelle ligne
- La finale FieldReference="System.History » est utilisé pour les courriels de discussion qui arrivent après la création d’un élément de travail. Au lieu d’écraser le Description les informations courriel suivantes sont stockées dans le Commentaires Champ (appelé en interne Histoire). La composition de la Histoire Le champ est plus ou moins le même à partir de Description Domaine mentionné plus haut. Il est conseillé aux utilisateurs de conserver les paramètres originaux de cette balise.
- Après avoir complété avec succès le fichier de configuration, sauvegardez et fermez le fichier.
- Courriel: Fournir l’adresse courriel cible où le courriel doit être livré pour la création ou la mise à jour des éléments de travail. Si certains critères ne correspondent pas aux valeurs souhaitées, le courriel d’avertissement sera envoyé à la Courriel administratif défini ci-dessus.
Déploiement du moniteur de courriel
Le moniteur de courriel peut être déployé en configurant les paramètres pertinents sous le panneau d’administration. Ces paramètres peuvent être consultés via l’onglet Services.
La section Services du panneau d’administration comporte actuellement deux onglets : Décors & Moniteur de courriels
L’onglet Paramètres traite de 1) Authentification utilisateur/Enregistrement d’organisation 2) Numérisation de nouveaux projets.
Email Monitor gère toutes les options liées aux courriels discutées plus tôt dans la section ligne de commande.
Configuration des options du moniteur de courriel
- L’onglet Surveillance des courriels, dans la section Services, est utilisé pour configurer les paramètres du courriel.
- Les options sont accessibles en cliquant sur l’onglet Surveillance des courriels, comme illustré dans l’image suivante.
- Si l’utilisateur n’a pas enregistré son organisation (en fournissant les détails requis dans le sous-onglet Paramètres), alors en cliquant sur le sous-onglet Surveillance des courriels, l’utilisateur est renvoyé dans le sous-onglet Paramètres, à moins que l’information souhaitée ne soit saisie.
- Les paramètres du moniteur de courriel sont divisés en sections, chaque section servant à configurer un réglage particulier.
- Tous les réglages nécessaires sont configurés une seule fois. Les utilisateurs ne peuvent pas configurer certains paramètres et en laisser d’autres en attente.
- La première section sert à configurer le projet par défaut et l’adresse courriel d’administration.
- La deuxième section sert à configurer l’adresse courriel qui sera utilisée pour la surveillance des courriels.
Cliquer sur Adresse courriel d’inscription ouvrirait une fenêtre contextuelle où les paramètres réseau du courriel (par exemple SSL, POP3, IMAP, etc.) peuvent être configurés.
- La troisième section sert aux paramètres (qui serviront à) d’extraire le contenu de l’élément de travail à partir des courriels envoyés à l’adresse courriel enregistrée.
Cliquer sur le bouton Enregistrer les modifications après avoir configuré tous les réglages, le moniteur des courriels s’ouvrait.
Articles connexes
Contacter le support
Contacter le support
Le panneau d’administration de Modern Requirements4DevOps
Dans cet article, nous expliquons comment utiliser le panneau d’administration Modern Requirements4DevOps pour activer et désactiver certaines fonctionnalités dans chaque module MR4DevOps.
Continuer la lectureActivation de Modern Requirements4DevOps
Dans cet article, nous couvrons les étapes simples nécessaires pour que les équipes activent Modern Requirements4DevOps, tant dans nos versions embarquées qu’autonomes.
Continuer la lecture
