Création de modèles d'exigences non fonctionnelles

Validation des exigences par le client dans Azure DevOps

Création de modèles d'exigences non fonctionnelles

Erecueillir, rédiger et gérer les exigences non fonctionnelles (NFR)) peut s’avérer une tâche intimidante et chronophage. La plupart des personnes qui liront la phrase précédente seront sans doute d’accord 

La création d'un fichier NFR peut s'avérer une tâche difficile et la formulation d'exigences non fonctionnelles à la fois quantifiables et mesurables est un problème auquel de nombreuses équipes se heurtent.  

Élaborer des exigences non fonctionnelles de qualité en vaut toutefois la peine. 

Rapports personnalisables dans Azure DevOps

Les exigences non fonctionnelles permettent aux équipes d'évaluer la réussite d'un projet, d'un processus ou d'un système. Elles permettent à votre équipe de définir des critères mesurables grâce auxquels vous pouvez discuter, analyser et évaluer les différents aspects de votre projet. 

Compte tenu de l'importance des exigences non fonctionnelles (NFR) pour un projet, on constate souvent que les équipes se lancent dans des processus longs et complexes pour définir des NFR qui, au terme du projet, s'avèrent à peine significatives ou pertinentes.  

Aujourd'hui, nous allons changer cela. 

Dans cet article, nous abordons à la fois l'intérêt de créer des NFR, ainsi quecomment comment utiliser quelques outils simples outils et techniques pour réduire le temps nécessaire à la création . 

Pourquoi vaut-il la peine de définir des exigences non fonctionnelles ?

Les exigences non fonctionnelles fournissent à votre équipe tous les critères permettant de mesurer la réussite d'un produit, d'un projet, d'un système, d'un processus ou d'une application. Lorsqu'une exigence non fonctionnelle bien formulée est établie, l'équipe sera non seulement en mesure de déterminer si un projet est couronné de succès, mais aussi d'évaluer facilement dans quelle mesure il en est encore éloigné.  

Des exigences non fonctionnelles bien formulées peuvent contribuer de multiples façons à la réussite d'un projet, au-delà de leur simple rôle d'indicateur de réussite. Elles peuvent aider les équipes à cerner les objectifs généraux d'un projet, à aligner les résultats du projet sur les objectifs commerciaux, et bien plus encore.  

Il suffit de dire que des NFR de qualité peuvent grandement contribuer à la réussite d'un projet, ainsi qu'à la manière dont nous évaluons cette réussite. Mais cela ne signifie pas pour autant qu'ils soient faciles à gérer, à recueillir ou à rédiger.  

Voyons quelles sont les principales techniques utilisées aujourd'hui par les équipes pour définir plus rapidement de meilleures exigences non fonctionnelles.  

La technique principale pour définir plus rapidement de meilleures exigences non fonctionnelles : les modèles

Lorsqu'elles définissent des exigences non fonctionnelles, les équipes utilisent des modèles afin de créer ces tâches plus rapidement et avec une plus grande cohérence.

Par définition, un un modèle est tout ce qui sert de modèle que d’autres peuvent copier et réutiliser.  

En général, les modèles sont créés sous la forme d'un format prédéfini pour un document, un fichier ou simplement comme format permettant de créer n'importe quel NFR. Une fois mis en place, le format fourni par un modèle n'a pas besoin d'être recréé à chaque fois qu'il est nécessaire, et les utilisateurs peuvent simplement sélectionner un modèle et se mettre rapidement au travail.  

C'estC'est ce qui nous amène à l' avantage le plus évident. de l'utilisation des modèles modèles 

Les modèles permettent de gagner du temps et améliorent la cohérence! 

Lorsque les équipes commencent à construire un processus reproductible, elles se tournent souvent vers des modèlesafin afin de supprimer la nécessité de recréer sans cesse document ou fichier formats.Au lieu de cela, réutiliser les mêmes éléments d'un document, d'un fichier ou d'une structure comme modèle permet à votre équipe de réduire les retouches et de tirer parti des avantages d’une plus grande cohérence. 

Alors que le temps en économiséet et la cohérence sont améliorées sont excellentes avantages directs que les modèles offrent, il il y a beaucoup avantages indirects avantages indirects que les modèles offrent également 

Les avantages indirects des modèles d'exigences non fonctionnelles

Le principal avantage indirect lié à l'utilisation de modèles réside dans la possibilité de mettre en place une approche structurée et facile à suivre pour la création de fichiers, de documents et d'exigences.  

Grâce à une structure type, les utilisateurs qui travaillent sur un fichier ou un document donné peuvent plus facilement déterminer où saisir chaque élément d'information et quel format celui-ci doit respecter.  

Ce type d'orientation permet non seulement d'améliorer la précision du contenu en cours d'élaboration, mais aussi de réduire le temps nécessaire à la création des spécifications fonctionnelles non techniques (NFR), à la révision des documents et à la validation des exigences. Cela s'explique en partie par le fait que la mise à disposition d'un modèle favorise également la standardisation et facilite la prise en main de l'élément créé. 

Les modèles apportent une double simplification en ce qui concerne les éléments de travail NFR. La création de l'élément de travail est simplifiée, car il suffit de saisir les données dans les champs appropriés du modèle. De plus, une fois l'élément de travail créé, le modèle présente les informations sous une forme plus accessible.

 À mesure que le processus se simplifie, il devient également plus accessible. Cela signifie que les modèles facilitent également la création des exigences non fonctionnelles (NFR) et de leur documentation pour les analystes métier débutants ou moins expérimentés. 

Cette discussion sur les modèles pourrait toutefois commencer à susciter une certaine ambiguïté. 

S'agit-il d'utiliser des modèles pour les documents ?  

S'agit-il d'utiliser des modèles pour la création de rapports non financiers ? 

S'agit-il d'utiliser des modèles qui décrivent les caractéristiques d'un NFR ? 

Pour faire simple, oui. 

Un modèle d'exigences non fonctionnelles peut être utilisé dans n'importe lequel de ces domaines pour améliorer la rédaction, la collecte et la gestion de vos exigences non fonctionnelles. 

 
Un modèle de NFR peut servir à organiser et à gérer les NFR, à aider une équipe dans la création de documents, voire à élaborer les NFR proprement dites.  

 
Si vous cherchez une méthode simple pour définir des exigences non fonctionnelles de qualité, consultez notre article « Deux étapes simples pour définir des exigences non fonctionnelles », disponible ici ! 

Quelle que soit la manière dont votre équipe utilise les modèles pour définir les exigences non fonctionnelles, vous pouvez être assuré que cette démarche offre un retour sur investissement exceptionnel et peut être réalisée plus rapidement et plus facilement que jamais. 

Doter vos analystes métier de modèles de recueil d'informations

La définition des besoins, ou la collecte des exigences, n'a jamais été un processus simple.C'estpourtant une tâche à laquelle beaucoup de gens sont confrontéschaquejourdans leur travail.

Par exemple, si quelqu'un vous demande de créer ou de finaliser quelque chose, vous pourriez lui poser certaines questions. Que doit faire cet objet (exigence fonctionnelle) ? Et quelles doivent être ses caractéristiques en matière de sécurité, de convivialité ou d'accessibilité (exigences non fonctionnelles) ?  

Un analyste métier (BA) bien forméposera de la même manière des questions destinées à mettre en évidence les exigences fonctionnelles et non fonctionnelles nécessaires à tout projet, processus ou système. Les BA utilisent principalement les questions comme moyen d'interaction avec les parties prenantes. Grâce à ce type de collaboration étroite avec les parties prenantes, les BAcréent créent un espace qui aide les parties prenantes à exprimer ce qu’elles attendent de leur produit.  

Au cours d'une conversation avec un analyste commercial, unpartie prenante exprimera exprimera les fonctionnalités qu’il souhaite et ce que son produit doit faire (exigences fonctionnelles) ainsi que comment il souhaite que l'expérience utilisateur se présente (exigences non fonctionnelles).  

Licence’s utilisent souvent plusieurs techniques éprouvées techniques d'élicitation lorsqu'ils interagissent avec parties prenantes. Dau cours du processus de collecte certaines de ces techniques pourraient comprendre:: 

  • questionnaires 
  • carte mentale remue-méninges  
  • cas d'utilisation création 
  • création et révision de documents
  • et bien plus encore… 

Chacune de ces techniques a deux points communs.  

  1. Tout d'abord, elles servent toutes à définir les besoins.  
  1. Deuxièmement, chacune de ces techniques peut tirer parti de l'utilisation de modèles.

Voyons comment les questionnaires peuvent tirer parti de la création ou de l'utilisation de modèles. 

Nous savons que pourcerner correctement les besoins, il faut poser les bonnes questions.
C'est là que l'expertise d'unanalyste métier chevronnédevient unatout majeur,caril a déjà mené ce processus de cernage à de nombreuses reprises. Fort de son expérience, il estmieux àmême de savoirquellesquestions poser en fonction de secteurs, de produits ou de technologies spécifiques.  

Ces expériences et connaissances peuvent être facilement consignées à l'aide d'un modèle de questionnaire sur les exigences non fonctionnelles. Les analystes métier expérimentés peuvent compiler des listes de questions ou des modèles de questions bien pensés qui se concentreront sur des fonctions spécifiques (FR) ou des attributs du système (NFR), et guider guider l’ processus processus d'élicitation même s'ils ne sont pas directement impliqués 

Ces modèles de questionnaire peuvent ensuite apportent une structure et une cohérence au processus de collecte d’informations, garantir que les bonnes questions soient poséeset ainsi réduirede de réduire le risque que des questions importantes soient omises.   

Il existe de nombreux exemples où les modèles peuvent aider les équipes à tirer parti des connaissances dont elles disposent déjà en interne. 

Voyons d'autres exemples d'utilisation des modèles aujourd'hui dans différentes tâches de collecte d'informations et de rédaction ..  

Pourquoi les équipes ont-elles traditionnellement utilisé des tableaux comme modèles d'exigences ?

De nombreuses équipes continuent de mettre en œuvre exigences non fonctionnelles modèles sous forme de tableau pour rédiger et regrouper exigences. 

L'utilisation de tableaux découle généralement du besoin des utilisateurs d'organiser et de centraliser leurs exigences en un seul endroit.  Avant l'utilisation d'outils explicites de gestion des exigences, on utilisait utilisées pour définir définir les conventions de nommage et de numérotationpour faciliter le suivi et de retracer exigences, ainsi que en en proposant des champs pour un nombre illimité de propriétés. 

Tableaux ont historiquement fonctionnéaussi bien aussi bien que les modèles en tant que elles sont simples à organiser et facilitent la gestion le contenu du tableauLes tableaux ont traditionnellement l'avantage supplémentaire d'offrir une méthode pour exporter les informations à partir une table vers d'autres domaines tels que la création de documents.  

En quoi consiste cette méthode d'exportation ? Copier-coller.  

Pour les équipes qui utilisent des tableaux comme modèles, lesexigences sont généralement copiées-collées à partir de un tableau, puis sont ensuite insérées dans un document. En général, il faut copier-coller champ par champ champ dans un modèle conçu spécifiquement pour le document (un autre exemple d'utilisation de modèles !) 

Mais alors que les tableaux constituaient autrefois une solution efficace pour gérer exigences qui contenant divers champs, ils présentent aujourd’hui des inconvénients majeurs face aux outils de gestion des exigences (RM) dédiés. 

Les tableaux sont souvent des compilations disparates d'informations importantes et peuventsouvent être isolées des autres outils et processus. Osouvent cela se traduit souvent par des tables devenirune une étape supplémentaire dans votre processus de gestion des relations, et un élément supplémentaire dont quelqu’un doit assumer la responsabilité pour le gérer, le mettre à jour et l’entretenir.  

Mais cela n'est pas une fatalité.  

Grâce à l'extension « Excel Team » de Microsoft, les équipes peuvent facilement relier les tableaux qu'elles ont utilisés par le passé à leur projet Azure DevOps. Elles peuvent facilement associer chaque champ d'exigence, chaque propriété et chaque identifiant à l'élément de travail Azure DevOps créé dans leur projet. 

Mais en quoi Azure DevOps facilite-t-il la gestion des exigences non fonctionnelles ? 

Comment Azure DevOps gère-t-il les exigences non fonctionnelles ?

Tout d'abord, Azure DevOps est flexible.  

La plateforme ALM de Microsoft vous permet d'ajouter facilement à un projet tous les types de tâches dont votre équipe a besoin.  

Les exigences non fonctionnelles constituent l'un des types de tâches que vous pouvez ajouter à un projet.  

Qu'est-ce qu'un « élément de travail » »» ?  

Les éléments de travail constituent un modèle de création basé sur ADO pour le type d'exigence qu'ils représentent.  

En voici quelques exemples : les exigences fonctionnelles, les exigences de transition, les récits d'utilisateurs ou encore les exigences non fonctionnelles. Quelle que soit la taxonomie requise par votre projet, Azure DevOps la prendra en charge et chacun des éléments de travail que vous créerez disposera de son propre ensemble de propriétés, d'états et de relations, que vous pourrez sélectionner et personnaliser. 

Avec une exigence non fonctionnelle, vous pouvez configurer n'importe quel champs ou propriété dont votre équipe a besoinpour vous aider à la gestion de votre projet. Comme mentionné précédemment, il est facile de répertorier les exigences dont vous disposez déjà dans un tableau grâce à l' extension Excel de l'onglet Microsoft Teams [fournir le lien].  

Mais que peut-on faire avec les NFR une fois qu'ils sont dans Azure DevOps (ADO), et en quoi le fait de transférer la création des NFR vers ADO aide-t-il votre équipe ? 

Voyons voir quels sont les outils.  

Exigences modernes pour le DevOps : Smart Docs – Modèles de documents NFR personnalisables

La création de documents dépend des politiques, des processus, des attentes et des exigences des parties prenantes au sein d'une organisation, et peut même être conçue pour intégrer vos exigences non fonctionnelles. 

Les documents constituent un moyen simple d'assurer la responsabilité afin de au respect des exigences convenues pour un projet. Ils offrent un garantie de sécurité aux parties prenantes, car les documents peuvent servir de liste de contrôle pour les exigences convenues, ce qui peut facilement être recoupées pour déterminer si les parties prenantes obtiennent ce pour quoi elles ont payé ou si le travail n'a pas été achevé. 

Un autre avantage majeur d'une documentation adéquate réside dans le fait que les exigences évoluent souvent tout au long du cycle de vie d'un projet. Une exigence peut être définie plus clairement à un stade ultérieur, ou simplement évoluer d'une manière qui aboutit à une attentes différentes vis-à-vis de votre produit.  

Il est temps d'intégrer les documents relatifs aux exigences non fonctionnelles à votre processus. 

À mesure que les besoins évoluent, ào les attentes concernant votre projet. Cela signifie que les indicateurs de réussite de votre projet, c'est-à-dire les exigences non fonctionnelles, devront être réexaminés et modifiés.  

Grâce à notre module Smart Docs de la suite Modern Requirements4DevOps, un utilisateur peut facilement créer un cahier des charges entièrement gérable par versions directement à partir de son projet Azure DevOps. Cela signifie que les utilisateurs peuvent facilement apporter des modifications aux exigences et en assurer le suivi depuis une interface documentaire conviviale.  

De nouvelles exigences peuvent également être facilement créées dans votre projet depuis l' l'interface du document, ou vous pouvez choisir d’ insérer des exigences existantes directement dansvotre document. Cela signifie que vous pouvez facilement glisser-déposer vos exigences non fonctionnelles directement dans un document facilement exportable sans quitter Azure DevOps et sans avoir besoin de copier-coller.  

Poursuivons l' concept d'importation de vos NFR existants qui se trouvent dans des tables vers Azure DevOps, puis puis de voir comment vous pouvez convertir ces NFR en documents à l'aide de Modern Requirements.  

Commencez par importer dans Azure DevOps vos exigences non fonctionnelles à partir de votre tableau à l'aide de l'extension Microsoft Teams pour Excel. Il vous suffit ensuite de sélectionner toutes les exigences non fonctionnelles et de les glisser-déposer dans votre document.  

C'est aussi simple que ça.  

Mais supposons que vous souhaitiez désormais structurer un document de manière à ce que les exigences non fonctionnelles ne puissent être ajoutées que dans certaines sections spécifiques du document.  

Nous soutenons cela aussi ! 

Il existe un concepteur de modèles intégré directement au module Smart Docs, qui vous aide à définir les types d'éléments de travail sont autorisés et à quel endroit dans vos documentsCela signifie que toute personne créant un document, qu'il soit basé sur des NFR ou non, peut facilement respecter la structure fournie par votre modèle et créer une documentation cohérente. 

Exigences modernes pour le DevOps : Smart Docs – Modèles de documents NFR réutilisables

Les modèles de documents réutilisables constituent un atout pour toute équipe.  En fait, vous les utilisez probablement déjà aujourd'hui.  

Un modèle de document réutilisable fournit à votre équipe un document prérempli qui définit la structure que doit avoir le document final. Ce type de modèle aide les auteurs à déterminer facilement où placer certaines informations et quels éléments contextuels doivent figurer dans le document créé.  

Pensez à ce document Word que vous avez déjà sur votre bureau. Il comporte probablement déjà des espaces réservés pour des sections telles que « Introduction », « Portée » et « Objectifs », ainsi que pour les exigences spécifiques. Il s'agit d'un modèle de document réutilisable.  

La principale raison pour laquelle les modèles de documents sont utilisés estafin d'améliorer l'efficacité et de réduire les retouches au cours du processus de création .  

Heureusement pour les équipes qui utilisent actuellement plusieurs applications pour leurs processus de gestion des exigences et de documentation, il existe une solution qui permet de répondre à ces deux besoins : Modern Requirements avec Azure DevOps.  

Le modèles de documents que que vous créez avec Modern Requirements + Azure DevOps peuvent être configurés pour contenir n'importe quel champ ou propriétéque vous souhaitez afficher dans votre document. Vous pouvez enregistrer n'importe quel document en tant que modèle de document réutilisable, qui peut remplir automatiquement des champs tels que Introduction, Objectifs, Exigences NFR, et bien d’autres. 

En quelques clics seulement, vous pouvez créer des documents qui aideront votre équipe à se mettre rapidement au travail lors de la rédaction de tout type de documentation ! Cela signifie que votre équipe peut non seulement bénéficier du fait que vos documents et vos exigences se trouvent au même endroit, mais aussi gagner en efficacité, mettre en place une structure, améliorer la précision et assurer la cohérence au sein de votre processus de création de documents.   

Modern Requirements4DevOps : Module FAQ – Modèles de questionnaires personnalisables et réutilisables

Les exigences non fonctionnelles sont beaucoup plus abstraites que leurs équivalents fonctionnels.  

Cela rend plus difficile de les faire émerger, car vous ne vous contentez pas de désigner le système et de lui dire quoi faire, mais que vous posez plutôt des questions sur la manière dont le système devrait fonctionner et que vous utilisez des NFR pour représenter cela. 

Comme nous l'avons vu plus haut dans cet article, l'élaboration de NFR solides repose repose sur le fait de poser les bonnes questions.  

Donc, que faire si vous débutez dans la gestion des exigences ou si vous avez peu d'expérience ? Par où commencer ? MR4DevOps répond à cette situation grâce à notre module FAQ complet.  

La FAQ Le module FAQ est une série de modèles de questions ciblées portant sur des attributs spécifiques du système, classés selon les trois aspects principaux du produit : opérationnel, révisionnel et transitionnel.  

De plus, le module FAQ contient des modèles de questions permettant de recueillir les exigences non fonctionnelles (NFR) pour la conformité et de l'évaluation des risques basé sur développement de dispositifs médicaux. À mesure que les utilisateurs répondent aux questions de lamodèle, ils automatiquement créente une exigence non fonctionnelle directement dans le Backlog. 

Le modèles modèles de questionnaire inclus dans le module FAQ sont utiles aux analystes métier , quel que soit tous les niveaux d'expérience. Les analystes métier chevronnés peuvent modifier les listes existantes en y ajoutant leurs propres questions ou créer leur propre liste de questions à partir de zéroCe faisant, les analystes métier peuvent capitaliser leur expérience et leurs connaissances du processus de collecte d'informations et les transmettre aux autres membres de l'équipe.  

Exigences actuelles pour le DevOps : Smart Report – Modèles de rapports configurables

MR4DevOps apporte une excellente solution à l'une des principales lacunes d'ADO : l'absence d'un outil de reporting intégré.  

Lorsque vous utilisez des outils tels que FAQ ou Smart Docs pour rédiger et gérer vos exigences non fonctionnelles, Smart Report sera l'outil que vous utiliserez pour exporter vos exigences. Smart Report vous permet d'exporter vos exigences au format PDF, HTML ou Microsoft Word, où vous pouvez appliquer vos propres en-têtes et pieds de page prédéfinis et même une table des matières ou une page de titre.  

Vous souhaitez établir un rapport sur les exigences non fonctionnelles (NFR) de votre projet ?  

L'outil Smart Report est doté d'un concepteur de modèles concepteur de modèles. Le concepteur de modèles vous permet de créer et d'enregistrer modèles de rapports modèleen en fonction du type de tâche. Cela vous permet de créer un modèle de NFR unique qui affiche les propriétés et les champs d'un NFR que vous souhaitez inclure dans le rapport ; ces informations sont extraites directement de l'élément de travail ! 

Ce modèle peut être appliqué à n'importe quel ensemble de NFR sélectionnés ou obtenus via une requête, et utilisé chaque fois que votre processus de reporting l'exige. L'avantage de cet outil de reporting est qu'il vous permet de créer des rapports instantanés, structuréset cohérents. 

Ça vous tente de voir par vous-même ?

Modern Requirements4DevOps propose plusieurs solutions pour faciliter la collecte, la rédaction et la gestiondes exigences non fonctionnelles. 

Vous souhaitez en savoir plus sur la conception de modèles avec Modern Requirements ou découvrir d'autres outils susceptibles d'améliorer vos processus ? Réservez dès aujourd'hui une démonstration du produit !

Découvrez par vous-même comment notre boîte à outils « Modern Requirements » permet de transformer Azure DevOps de Microsoft, leader du secteur, en une solution unique de gestion des exigences applicatives.

Rendez-vous sur www.modernrequirements.com pour en savoir plus sur notre entreprise et nos produits.

Demandez une démonstration !

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

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

Un gain de temps avéré

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

Simplifier les procédures d'approbation

Réduction significative des délais de validation

Améliorer les performances

Amélioration de la productivité de 50 %

Réduire les retouches

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

Simplifier la mise en conformité

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

Configuration 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). 

Exigences en matière de création de contenu avec Requirements4DevOps

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 :

  1. Identifiant personnalisé
  2. Drapeau sale
  3. 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.

Authentification des utilisateurs des services MR

  1. 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.
  2. 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.

  3. 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.

  4. 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 :

  1. Saisissez la commande suivante dans CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin

  2. Une fois dans le répertoire bin, tapez la commande suivante : MRAgent

    Le menu des options s'affiche.

  3. Type 4 puis cliquez sur Entrée.
  4. 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 :

  1. Un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel l'ID personnalisé doit être appliqué).
  2. 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.

  1. Créez à cet emplacement un dossier portant le nom du serveur Azure DevOps (sur lequel le composant doit être appliqué).
  2. 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é).
  3. 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é

  1. Ouvrez le xml fichier dans le Bloc-notes ou n'importe quel éditeur de texte.
  2. 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.

  3. 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.
  4. 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 « \ »)
  5. 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.
  6. 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.
  7. «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.
    1. 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.
    2. 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
    3. 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.
  8. Une fois la configuration du fichier terminée, enregistrez-le puis fermez-le.

Attribution d'un identifiant personnalisé à des éléments de travail existants

  1. Tapez la commande suivante dans l'invite de commande : cd :\Program Files\Modern Requirements\MR-Agent\bin
  2. Une fois dans le répertoire bin, tapez la commande suivante : MRAgent

     

    Le menu des options s'affiche.

  3. Type 1 puis cliquez sur Entrée.
  4. Saisissez l'URL de l'organisation Azure DevOps (ou de la collection TFS).
  5. 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 :

  1. Un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le drapeau « Dirty » doit être appliqué).
  2. 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.

  1. Créez à cet emplacement un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit être appliqué).
  2. 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.
  3. 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 »

  1. Ouvrez le xml fichier dans le Bloc-notes ou n'importe quel éditeur de texte.
  2. 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.
  1. 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 «,».
  2. 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.
  3. 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 ».

  4. 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.
  5. 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* :

  1. Configuration du fichier de configuration du moniteur de messagerie (situé à un emplacement spécifique)
  2. 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 :

  3. 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.

  4. 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

  5. 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

  1. Fonctionne avec tous les composants de MR Services
  2. Permet de vérifier les nouveaux projets/collections
  3. 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

  1. Ne fonctionne qu'avec un identifiant personnalisé
  2. Permet d'attribuer un identifiant personnalisé aux éléments de travail nouvellement créés
  3. 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

  1. Fonctionne uniquement avec Email Monitor
  2. Permet de vérifier si un nouvel e-mail est arrivé, à partir duquel des tâches pourraient être créées ou mises à jour
  3. 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 :

  1. 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.

  1. Créez à cet emplacement un dossier portant le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit être appliqué).
  2. 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).
  3. Ce fichier contient le schéma de la configuration souhaitée.

Configuration du fichier XML du moniteur de messagerie

  1. Ouvrez le xml fichier dans le Bloc-notes ou n'importe quel éditeur de texte.
  2. Définissez la valeur de la URL du serveur ajouter une balise selon les besoins, par exemple :
  3. 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.
  4. 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.

  5. «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
    1. 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.

    2. 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éé.
    3. 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.
      1. OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
      2. OnUpdate=”false” Cela signifie que, pour les éléments de travail existants, le champ « Titre » ne serait pas mis à jour.
    4. 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.
      1. 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.
      2. 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.
    5. La dernière partie de ce champ indique la composition du champ « Description ». Les informations suivantes composeraient le champ « Description » :

      1. Sender Name shown inside <> e.g.
      2. Sender Email also shown inside <> e.g. <alice.ducas@steveandrews.com>
      3. Le corps de l'e-mail a été ajouté sur une nouvelle ligne
    6. 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.
    7. Une fois la configuration du fichier terminée, enregistrez-le puis fermez-le.

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

Assistance en cas d'incident

Bénéficiez d'une assistance en direct par téléphone, par e-mail ou via une visioconférence. Chaque demande d'assistance ne peut porter que sur un seul problème.

Assistance en cas d'incident

Vas-y !

Assistance par e-mail

Envoyez un e-mail à notre équipe d'assistance pour obtenir une réponse dans les meilleurs délais. En nous envoyant un e-mail, un ticket sera automatiquement créé pour vous !

Assistance par e-mail

Vas-y !

Soumettre une idée

Vous souhaitez tirer le meilleur parti de nos produits ? Vos suggestions nous aident à nous améliorer. Envoyez-nous une idée et nous étudierons la possibilité de l'ajouter à notre liste de projets en attente !

Soumettre une idée

Vas-y !

Soutien communautaire

Trouvez les réponses aux questions courantes ou envoyez une demande d'assistance via notre portail d'assistance communautaire.

Soutien communautaire

Vas-y !

Signaler un bug

Signalez-nous tout bug que vous avez repéré et nous nous empresserons de le corriger. Personne n'aime les bugs, et nous ne faisons pas exception.

Signaler un bug

Vas-y !

Contacter le service d'assistance

Assistance en cas d'incident

Bénéficiez d'une assistance en direct par téléphone, par e-mail ou via une visioconférence. Chaque demande d'assistance ne peut porter que sur un seul problème.

Assistance en cas d'incident

Vas-y !

Assistance par e-mail

Envoyez un e-mail à notre équipe d'assistance pour obtenir une réponse dans les meilleurs délais. En nous envoyant un e-mail, un ticket sera automatiquement créé pour vous !

Assistance par e-mail

Vas-y !

Soumettre une idée

Vous souhaitez tirer le meilleur parti de nos produits ? Vos suggestions nous aident à nous améliorer. Envoyez-nous une idée et nous étudierons la possibilité de l'ajouter à notre liste de projets en attente !

Soumettre une idée

Vas-y !

Soutien communautaire

Trouvez les réponses aux questions courantes ou envoyez une demande d'assistance via notre portail d'assistance communautaire.

Soutien communautaire

Vas-y !

Signaler un bug

Signalez-nous tout bug que vous avez repéré et nous nous empresserons de le corriger. Personne n'aime les bugs, et nous ne faisons pas exception.

Signaler un bug

Vas-y !