Utilisation de MatCal pour effectuer des calculs mathématiques et logiques dans la gestion moderne des exigences

Utilisation de MatCal pour effectuer des calculs mathématiques et logiques dans la gestion moderne des exigences

Qu’est-ce que MatCal?

MatCal est une fonctionnalité de Modern Requirement4DevOps utilisée pour effectuer des expressions mathématiques et logiques sur des éléments de travail.

Pourquoi nous avons besoin de MatCal en gestion des exigences

Pour gérer les relations entre les propriétés des objets de travail de façon plus intelligente! Cela élimine les efforts manuels liés au calcul en dehors de l’environnement du projet et évite les risques d’introduire des résultats de calcul incorrects dans vos projets.

Voyons un exemple simple ici pour illustrer une relation entre les propriétés des objets de travail.

La valeur métier et la priorité sont des propriétés de la caractéristique de l’élément de travail.  Normalement, une grande valeur d’affaires mène à une haute priorité.

Avec la bonne configuration, MatCal pourrait vous aider à gérer la relation en attribuant automatiquement une valeur de priorité basée sur l’entrée de la valeur d’affaires .

Scénarios d’utilisation dans l’industrie

Scénario 1 : Niveau d’intégrité de sécurité automobile (ASIL) selon ISO 26262

Scénario 2 : La cote de risque est automatiquement attribuée selon le score de gravité et le score d’occurrence

Scénario 3 : La cote de priorité est automatiquement attribuée selon le score de sévérité et le score de vraisemblance

Veuillez regarder la vidéo pour des scénarios d’utilisation supplémentaires et des tutoriels sur MatCal!

Temps de lecture : 10 minutes

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 :

  1. Importation des exigences depuis Microsoft Excel
  2. Importation des exigences à partir de Microsoft Word
  3. 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 :

  1. Ouvrir Excel
  2. Créez une feuille vierge 
  3. Cliquez sur Fichier
  4. Cliquez sur les options
  5. Cliquez sur les modules complémentaires
  6. Choisissez les modules complémentaires COM dans le menu déroulant près du bas de la fenêtre
  7. 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!

Essayez-le!

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!

Temps de lecture : 10 minutes

Exigences modernes 2019 : Mise à jour 2

Notes de sortie

Exigences modernes 4DevOps 2019 - Mise à jour 2

Bienvenue à Modern Requirements4DevOps 2019 Mise à jour 2! De nombreuses améliorations ont été ajoutées dans cette version. Voici une version annotée des notes de version pour aider les utilisateurs à suivre la mise à jour de Modern Requirements4DevOps. 

Généralités

Un tout nouvel outil a été ajouté à Modern Requirements pour vous aider dans vos besoins en traçabilité et gestion de projet. L’outil d’artefacts MR!

L’outil d’artéfact MR est accessible depuis le menu contextuel de n’importe quel élément de travail. Cet outil répertorie tous les artefacts des Exigences Modernes auxquels l’élément de travail est associé! Désormais, les utilisateurs peuvent accéder rapidement aux artéfacts des Exigences Modernes qui utilisent l’élément de travail sélectionné.  

Cet outil peut actuellement retracer les éléments de travail contenus dans les Smart Docs, les Revues et les Références.

L’outil de comparaison, utilisé pour la comparaison directe entre les révisions des éléments du travail, a, faute d’un meilleur travail, été révisé!

Les RevisionIDs sont maintenant davantage délimités par de nouvelles propriétés. Les nouvelles propriétés sont approuvées en dernier moment et en dernier examen. Ces propriétés s’appliqueront aux révisions des éléments de travail qui ont fait l’objet d’un examen au cours de leur cycle de vie.

Ces propriétés seront affichées à côté de l’ID de révision dans le menu déroulant de l’outil de comparaison.

Lors de l’utilisation de l’outil de comparaison, l’outil remplit automatiquement une révision par défaut dans le menu déroulant. Lorsqu’un menu déroulant s’ouvre, les éléments d’œuvre Dernière Approuvée et Dernière Révision seront respectivement affichés en haut de la liste. Elles seront suivies des autres révisions indiquées par ordre décroissant (de la plus récente à la plus ancienne). 

Lorsque l’outil de comparaison est invoqué, le menu déroulant de gauche affichera toujours la révision pertinente de l’élément de travail. Lorsqu’il est ouvert depuis le Backlog, ce champ sera rempli avec la dernière révision. Lorsqu’il est lancé à partir d’une révision, ce champ sera par défaut vers la révision de l’élément de travail inclus dans la révision. Si elle est accessible depuis une ligne de base, ce champ affichera la révision de l’élément de travail tel qu’il était au moment de la création de la baseline.

Le menu déroulant de droite est le champ de comparaison des révisions . Si l’élément de travail a fait l’objet d’une révision, ce champ sera par défaut la Dernière révision approuvée .

Si une révision approuvée n’existe pas, ce champ sera automatiquement la Dernière version révisée .

Si le menu déroulant de gauche revient par défaut à la dernière révision approuvée d’un élément de travail, le menu déroulant de droite restera vide.

L’outil de comparaison est accessible à partir d’un nouvel élément de travail créé. Cependant, sans aucune révision, le menu déroulant de droite sera de nouveau vide.

Lorsque l’on invoque l’outil de comparaison depuis l’onglet Comparer la ligne de base , l’outil fonctionne différemment. La comparaison n’est plus automatique , car l’utilisateur compare manuellement l’élément de travail entre deux lignes de base. Les menus déroulants à l’intérieur de l’outil seront plutôt dirigés par défaut vers la révision de l’élément de travail inclus dans chaque ligne de base comparée.

En utilisant l’outil de comparaison, l’utilisateur peut interagir avec l’un ou l’autre menu déroulant et effectuer toute comparaison entre les révisions.

Smart Docs

Smart Docs a amélioré ses fonctionnalités avec l’ajout de trois nouvelles fonctionnalités...

Les éléments de travail des enfants créés dans Smart Docs peuvent maintenant automatiquement hériter des propriétés de leur parent!

Le Meta Template Designer de Smart Docs permet maintenant aux utilisateurs de configurer des éléments de travail avec des champs héritables. Lors de la création d’un élément de travail sous-nom/enfant à la volée à partir d’un nœud parent, les valeurs des champs configurés peuvent être héritées du parent. Cette règle ne s’applique pas lors de l’insertion d’éléments de travail existants.  

Smart Editor a également introduit une nouvelle fonctionnalité avec des champs en lecture seule.

Les champs individuels peuvent être définis comme en lecture seule dans le modèle de procédé. Smart Editor traitera également ces champs comme en lecture seule.

Exigences modernes L’interaction des parties prenantes avec les Smart Docs s’est encore améliorée avec l’introduction de l’option d’ouvrir l’élément de travail. Auparavant, les parties prenantes ne pouvaient pas ouvrir les postes de travail – maintenant ils le peuvent!

Une fois activés, les parties prenantes invitées au projet pourront ouvrir des éléments dans l’éditeur standard d’Azure DevOps.

Les parties prenantes peuvent accéder à cette fonctionnalité à partir des onglets Document et Compare de Smart Docs.

Des améliorations supplémentaires ont été apportées aux fonctionnalités actuelles du module Smart Docs.

Le Meta Template Designer permet maintenant aux utilisateurs de mettre à jour les modèles de documents sauvegardés. Auparavant, cette fonctionnalité ne s’appliquait qu’aux méta-modèles; Maintenant, les modèles de documents peuvent aussi être mis à jour!

Cela permet aux utilisateurs d’apporter des modifications à la volée à n’importe lequel de leurs modèles de documents.

Les fonctionnalités incluent :

  • Changer la hiérarchie des éléments de travail
  • Renommer les modèles
  • Supprimer les modèles
  • Modèles de clones; créer une version unique du modèle à modifier

Les modifications apportées aux modèles de documents peuvent être appliquées à tous les Smart Docs à l’aide du modèle. Après les modifications, l’utilisateur doit simplement utiliser la fonction « Mettre à jour tous les modèles » dans la barre d’outils Smart Docs.

Un changement majeur a été apporté à la forme esthétique de Smart Docs.

L’enveloppage de texte et d’image ont été améliorés dans Smart Docs, car toutes les données incluses seront désormais correctement enroulées sur la ligne successive.

C’est un changement purement esthétique. Cependant, ce changement devrait grandement améliorer la lisibilité et la façon dont une personne consommera visuellement le document de sortie.

Le titre de Smart Docs, les champs HTML, les grandes images et les tableaux bénéficieront tous de cette amélioration.  

Gestion de la revue

Des ajouts très fonctionnels ont également été apportés au module de gestion des révisions.

En tant qu’initiateur d’évaluation, vous pourrez désormais soumettre des commentaires sans avoir besoin d’être un évaluateur – un initiateur d’évaluation est un évaluateur par défaut.

Deux nouveaux types de rapports d’audit ont été ajoutés au module de gestion des examens.

Rapport d’audit d’approbation :

Le rapport inclut tous les détails des actions d’approbation appliquées aux éléments de travail de l’examen

  • Les détails incluront si un élément de travail a été approuvé ou rejeté, ainsi que par quel profil d’utilisateur, commentaire de réponse, action de révision, commentaires supplémentaires et éléments liés ajoutés.

Rapport des résultats de la revue :

Rapport Inclut tous les détails des actions d’examen appliquées aux éléments de travail de l’examen

  • Les détails incluront si un élément de travail est examiné et par quel profil utilisateur, commentaire de réponse, action de révision, commentaires additionnels et éléments liés ajoutés.

Il convient de noter que le rapport d’audit d’examen existant sera renommé Rapport d’audit hérité.

 Les utilisateurs ont toujours accès à l’option Rapport d’audit hérité.

Le module de gestion des révisions a reçu plusieurs améliorations à sa fonctionnalité principale.

La façon dont Modern Requirements gère les métadonnées d’évaluation a été complètement remaniée. Lors de la création d’une critique, les métadonnées correspondantes seront maintenant sauvegardées dans votre dépôt (contrôle de sources).

Les métadonnées de révision étaient auparavant stockées dans le champ HTML d’un élément de travail de demande de rétroaction .

La mise à jour 2 a également apporté des changements au processus opérationnel de gestion de la révision.

Le processus précédent de création d’évaluations était lent et chargé de liens; Trois liens étaient créés pour chaque élément inclus dans une critique.

Dans la mise à jour 2, lorsqu’une évaluation est créée, les liens ne seront plus créés entre les demandes de rétroaction et les éléments de travail inclus dans l’évaluation.  

De plus, un élément de travail de Réponse de rétroaction ne sera plus créé par le système lorsqu’un utilisateur fournit une réponse à la révision (approbation/soumission d’évaluation).

Le nouveau processus est plus efficace et sans liens pour atténuer la restriction d’Azure DevOps de 1000 liens par élément de travail.  

De plus, l’automatisation a été améliorée lors de l’exécution d’actions courantes dans les évaluations.

Lors de l’utilisation de la fonction de lien entre l’élément d’œuvre afin de lier un élément d’œuvre à une approbation ou un refus, le lien sera créé directement vers l’élément d’œuvre que l’utilisateur examine actuellement.

Les commentaires fournis dans l’onglet Détails seront automatiquement ajoutés à l’élément de travail Demande de rétroaction avec les informations de profil de l’auteur du commentaire.

À la fin d’une révision, un commentaire sera ajouté à l’élément de travail Demande de rétroaction avec les informations de profil du participant.

Lorsque les évaluations sont closes, aucune autre mesure ne peut être prise pour l’approbation et les commentaires. Cela empêchera les parties prenantes de l’évaluation d’ajouter des commentaires supplémentaires ou de lier les éléments de travail à l’évaluation fermée.

Des modifications ont également été apportées pour mettre à jour l’interface utilisateur du formulaire contextuel de demande de révision .

  • Lors de l’initiation d’une révision à partir de Smart Docs, la section des éléments de travail ne sera plus affichée
  • Lors de la présentation d’une critique, la liste des éléments sélectionnés n’apparaîtra plus
  • Le corps d’un courriel généré lors d’une évaluation ne contiendra plus la liste des éléments de travail sélectionnés

Référence

Le module Baseline a amélioré ses capacités avec l’ajout de nouvelles fonctionnalités pour améliorer la trace et la gestion de vos éléments de travail.

Lors de la comparaison des lignes de base, les utilisateurs peuvent maintenant configurer quels types de liens individuels déclenchent un indicateur de changement. Auparavant, les utilisateurs n’avaient l’option que de désactiver le déclencheur ou de l’appliquer à tous les types de liens. Cette configuration se trouve dans le panneau d’administration.

Les rapports de différence ont été améliorés pour n’afficher que les champs configurés comme déclencheurs pour les indicateurs de changement. Auparavant, l’interface de l’outil de comparaison et les rapports de différence n’étaient pas synchronisés.

Avec l’inclusion du suivi des changements de type de lien entre les références, les rapports de différence incluront la possibilité de rapporter les changements de type de lien. 

L’outil Copy/Reuse Baseline a également reçu un certain renforcement de ses fonctionnalités.

Le système copiera automatiquement la zone/le chemin d’itération du projet source et le définira sur les éléments de travail copiés si des valeurs identiques existent dans le projet cible.

Comme on le voit dans cet exemple, à mesure que l’élément de travail est copié, le chemin d’itération de l’élément est copié du projet source et placé dans la cible.

Rapport intelligent

Comme pour les versions précédentes de l’Outil de rapport intelligent, les utilisateurs peuvent télécharger et appliquer des modèles Word à leurs rapports. La mise à jour 2 introduit la possibilité d’hériter du style de Word lorsque les rapports intelligents sont exportés vers Microsoft Word et qu’un modèle Word est appliqué.

À partir du modèle, les Smart Reports hériteront du style pour les titres, la taille de la police, le texte souligné ou en gras, la couleur de la police, l’indentation et l’alignement.

Cette option se trouve dans le menu déroulant « Fiche de style ».

Panneau d’administration

Des améliorations ont également été apportées concernant la manière dont les données Modern Requirements sont traitées.

Les données Modern Requirements seront désormais automatiquement synchronisées avec le contrôle de version Azure DevOps Server (TFS) pour les déploiements de compilations à connexion unique.

Pour utiliser cette capacité, ajoutez les identifiants d’un utilisateur au niveau Collection dans l’onglet Général du panneau d’administration Modern Requirement4DevOps.

Si les identifiants n’ont pas été fournis, l’utilisateur recevra un message de notification.

Les données Modern Requirements se synchroniseront à la fois avec GIT et Team Foundation Version Control.

Évolutivité

Modern Requirements reconnaît que les projets de nos clients s’étendront, et que leur logiciel de gestion des exigences devrait évoluer avec eux.

La performance du débit moderne de Requirements4DevOps a été grandement optimisée. La mise à jour 2 introduit la capacité de supporter de grands ensembles de données dans des modules à forte concentration d’items. Le support de grandes données a été ajouté à la gestion des revues, à la ligne de base et au rapport intelligent.

Les évaluations et rapports intelligents peuvent maintenant être créés avec un maximum de 10 000 éléments de travail.

Les utilisateurs peuvent maintenant créer des lignes de base comprenant jusqu’à 100 000 éléments de travail.  

D’autres améliorations du débit pour les fonctionnalités de Baseline incluent :

Objets de travail de copie

  • 5 000 éléments de travail dans Azure DevOps Server
  • 2,000 items de travail dans Azure DevOps Service

Rapports de différences

  • 10 000 items de travail dans Azure DevOps Server
  • 3,000 items de travail dans Azure DevOps Service

Éléments de travail de retour en arrière

  • Peut effectuer cette opération sur 10 000 travaux

Réaliser des opérations en utilisant de grands ensembles de données peut parfois prendre du temps. Modern Requirements reconnaît que votre temps est précieux et a déjà mis en place des fonctionnalités pour améliorer l’efficacité.

Les opérations longues ne vous ralentissent plus. Ces opérations sont maintenant effectuées en arrière-plan et offrent aux utilisateurs la possibilité d’être avisés par courriel une fois terminées.

Cette fonctionnalité a été intégrée au module de gestion des revues et est disponible lors de la réalisation de la fonction Approuver/Rejeter tout sur de grands ensembles de tâches. Le système identifiera automatiquement quand l’opération prendra plus d’une minute et en informera l’utilisateur.

Smart Report est également pris en charge par cette fonctionnalité. Si la génération du Smart Report ne se produit pas instantanément, un processus en arrière-plan sera lancé. Concernant Smart Report, les courriels de notification contiennent des liens permettant à l’utilisateur d’enregistrer son rapport de sortie dans Word ou PDF.

Corrections de bogues

La fonctionnalité et l’expérience utilisateur sont des éléments fondamentaux de la philosophie de conception des exigences modernes.

Plusieurs bogues ont été corrigés et corrigés avec la sortie de la mise à jour 2. Consultez la liste complète des corrections de bogues ou lisez les notes de version ici.

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

Approbation client des exigences dans Azure DevOps

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

L’obtentionélectronique, la création et la gestion des exigences non fonctionnelles (NFR) peuvent être une tâche intimidante et chronophage. La plupart des gens qui ont lu la phrase précédente seront probablement d’accord.  

La création de NFR peut être une tâche difficile et créer des exigences non fonctionnelles à la fois quantifiables et mesurables est un problème avec lequel beaucoup d’équipes ont eu du mal.  

Créer de grandes exigences non fonctionnelles vaut cependant l’effort. 

Rapports personnalisables dans Azure DevOps

Les exigences non fonctionnelles offrent aux équipes un moyen d’évaluer le succès d’un projet, d’un processus ou d’un système. Ils permettent à votre équipe de capturer des moyens mesurables par lesquels vous pouvez discuter, analyser et évaluer les différents attributs de votre projet. 

En raison de la valeur que les NFR apportent à un projet, on voit souvent des équipes s’engager dans des processus longs et complexes pour créer des NFR qui sont à peine significatifs ou pertinents à la fin du projet. 

Aujourd’hui, on va changer ça. 

Dans cet article, nous abordons à la fois la valeur de la création de NFR, ainsi que lafaçon dont vous pouvez utiliser des outils et techniques simples pour réduire le temps nécessaire à une création de NFR de qualité. 

Pourquoi les exigences non fonctionnelles valent-elles la peine d’être développées?

Les exigences non fonctionnelles fournissent à votre équipe toutes les mesures de réussite d’un produit, d’un projet, d’un système, d’un processus ou d’une application. Lorsqu’une bonne exigence non fonctionnelle est créée, une équipe pourra non seulement identifier si un projet est un succès, mais aussi facilement déterminer à quel point un projet pourrait être loin de réussir.  

De grandes exigences non fonctionnelles peuvent être déterminantes pour le succès d’un projet de plusieurs façons, en plus d’être une mesure de réussite. Les NFR peuvent aider les équipes à comprendre les objectifs globaux d’un projet, à aligner les résultats du projet avec les objectifs d’affaires, et bien plus encore. 

Il suffit de dire que des NFR de qualité peuvent grandement contribuer au succès des projets, ainsi qu’à la façon dont nous évaluons ce succès. Mais cela ne veut pas dire qu’ils sont faciles à gérer, à extraire ou à rédiger.  

Jetons un coup d’œil à la technique principale que les équipes utilisent aujourd’hui pour développer plus rapidement de meilleures exigences non fonctionnelles.  

La technique principale pour construire plus rapidement de meilleures exigences non fonctionnelles - les modèles

Lorsqu’elles créent des exigences non fonctionnelles, les équipes mettent en œuvre des modèles afin de créer ces tâches plus rapidement et plus cohérentes.

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

Typiquement, les modèles sont créés comme un format prédéfini pour un document, un fichier, ou simplement le format que chaque NFR peut utiliser. Une fois implémenté, 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 afficher un modèle et commencer rapidement. 

Celanous amène aux avantages   les plus évidentsd’utiliser des modèles d’exigences non fonctionnels.  

Les modèles font gagner du temps et augmentent la cohérence! 

Lorsque les équipes commencent à construire un processus reproductible, elles se tournent souvent vers des modèles pour éliminer le besoin de recréer constamment des formes de documents ou de fichiers. Au lieu de cela, réutiliser les mêmes éléments d’un document, d’un fichier ou d’une structure sous forme de modèle permet à votre équipe de réduire la refonte et de profiter des avantages d’une plus grande cohérence. 

Bien que le temps économisé et l’augmentation de la constance soient d’excellents avantages directs que les modèles apportent, il  ya aussi beaucoup d’avantages indirects moins évidents que les modèles apportent.  

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

Le plus grand avantage indirect de l’utilisation de modèles est la possibilité de créer une approche structurée et simple à suivre pour construire des fichiers, des documents et des exigences.  

En fournissant une structure modèlée, les utilisateurs qui interagissent avec un fichier ou un document donné ont plus de facilité à identifier où entrer chaque information spécifique et à quel format cette information doit se conformer.  

Ce type d’orientation améliore non seulement la précision du contenu sur lequel on travaille, mais réduit aussi le temps requis pour la création du NFR, la révision des documents et l’approbation des exigences. Cela s’explique en partie par le fait que fournir un modèle augmente aussi la standardisation et la familiarité avec l’élément créé. 

Les modèles créent un double niveau de simplicité en ce qui concerne les tâches NFR. La construction de l’élément de travail est simplifiée puisque les données doivent simplement être saisies dans les champs corrects du modèle. De plus, le modèle présente l’information de façon plus accessible une fois l’élément de travail construit.

 À mesure que le processus devient plus simple, il devient aussi plus accessible.  Cela signifie que les modèles facilitent aussi la création des NFR et de leur documentation pour les nouveaux ou moins familiers analystes d’affaires. 

Cependant, cette discussion sur les modèles commençait peut-être déjà à donner un sentiment d’ambiguïté. 

Parle-t-on d’utiliser des modèles pour les documents?  

Est-ce qu’on parle d’utiliser des modèles pour la création de NFR? 

Parlons-nous d’utiliser des modèles qui décrivent les propriétés d’un NFR? 

Pour faire simple, oui. 

Un modèle d’exigences non fonctionnelles pourrait être utilisé dans n’importe lequel de ces domaines pour renforcer votre création, élicitation et gestion des exigences non fonctionnelles. 

 
Un modèle NFR peut être utilisé pour organiser et gérer les NFR, aider une équipe à la création de documents, ou même dans la construction réelle des NFR.  

 
Si vous cherchez une méthode simple pour construire des NFR de haute qualité, consultez notre article « Deux étapes simples pour créer des exigences non fonctionnelles » disponible ici! 

Quelle que soit la façon dont votre équipe utilise les modèles pour créer des NFR, vous pouvez être assuré que créer des exigences non fonctionnelles rapporte un rendement incroyable et peut se faire plus rapidement et plus facilement que jamais. 

Équiper correctement vos BA avec des modèles d’élicitation

L’obtention des exigences, ou la collecte des exigences, n’a jamais été un processus simple. Cependant, c’est quelque chose que beaucoup de gens rencontrent chaque jour au travail.  
 
Par exemple, si quelqu’un vous demande de construire ou de compléter quelque chose, vous pourriez poser des questions. Qu’est-ce que cet appareil devrait faire (exigence fonctionnelle), et comment cela devrait-il être en termes de sécurité, d’ergonomie ou d’accessibilité (exigence non fonctionnelle)? 

Un analyste d’affaires (BA) bien préparé posera également des questions conçues pour identifier les exigences fonctionnelles et non fonctionnelles nécessaires de 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 BA créent un forum qui aide les parties prenantes à exprimer ce qu’elles attendent de leur produit.  

Lors d’une conversation avec un assistant de travail, unutilisateur S exprimera les fonctionnalités qu’il souhaite et ce que son produit devrait faire (exigences fonctionnelles) ainsi que la façon dont il souhaite que l’expérience utilisateur se ressente (exigences non fonctionnelles).  

Les BAs utilisent souvent plusieurs techniques d’épreuve éprouvées lorsqu’ils interagissent avec les parties prenantes.  En ce qui concerne le processus d’élicitation, certaines de ces techniques peuvent inclurepar exemple : 

  • Questionnaires 
  • Remue-méninges sur une carte mentale  
  • Création de cas d’utilisation  
  • Création et révision de documents
  • et plus encore... 

Chacune de ces techniques a deux points communs. 

  1. Premièrement, ils servent tous à susciter des exigences. 
  1. Deuxièmement, chacune de ces techniques peut tirer parti de l’utilisation des gabarits.

Réfléchissons à la façon dont les questionnaires peuvent bénéficier de devenir, ou d’utiliser, des modèles. 

Nous savons que pour obtenir les bonnes exigences, il faut poser les bonnes questions.  
C’est là que la connaissance d’un BAv-éteran devient un atout majeur,  puisqu’ils ont traversé le processus d’élicitation à de nombreuses reprises. Ils bénéficient de l’expérience et savent peut-être mieux quelles questions poser en lien avec des industries, produits ou technologies spécifiques.  

Cette expérience et ces connaissances peuvent être facilement capturées avec un modèle de questionnaire d’exigence non fonctionnel. Les assistants 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 passivement le processus d’élection de l’équipe même s’ils ne sont pas directement impliqués.  

Ces modèles de questionnaires peuvent alors fournir structure et cohérence au processus d’élection,  s’assurer que les bonnes questions sont posées, et aussi réduire la probabilité que des questions importantes soient manquées.   

Il existe de nombreux exemples où les modèles peuvent aider les équipes à bénéficier des connaissances qu’elles possèdent déjà au sein de leur équipe. 

Voyons d’autres exemples de la façon dont les modèles sont utilisés aujourd’hui dans différentes tâches d’elicitation et d’authoring.  

Pourquoi les équipes ont historiquement utilisé des tables comme modèles d’exigences

De nombreuses équipes continuent d’implémenter  des modèles d’exigences non fonctionnelles sous forme de tableau pour les exigences des auteurs et de la maison. 

L’utilisation des tables découle généralement des besoins des utilisateurs d’organiser et de maintenir leurs besoins en un seul endroit.  Avant l’utilisation d’outils explicites de gestion des exigences, les tables servaient à définir les conventions de nommage et de numérotation, à suivre et tracer les exigences, ainsi qu’à fournir des champs pour un certain nombre de propriétés. 

Les tables ont historiquement bien fonctionné comme modèles car elles sont simples à organiser et facilitent la gestion du contenu à l’intérieur de la table. Les tables ont traditionnellement eu l’avantage supplémentaire d’offrir une approche permettant d’exporter l’information d’un tableau vers d’autres domaines comme la création de documents.  

C’est quoi cette approche d’exportation? Copier-coller.  

Pour les équipes qui utilisent des tableaux comme modèles, les exigences r sont généralement copiées-collées à partir d’une table puis insérées dans un document. Typiquement, l’exigence consiste à copier-coller champ par champ dans un modèle conçu spécifiquement pour le document (un autre exemple de modélisation!).  

Mais alors que les tables étaient autrefois une solution robuste pour gérer des besoins contenant une variété de domaines, elles présentent des inconvénients importants dans le monde actuel des outils de gestion de données explicites. 

Les tables sont souvent des compilations déconnectées d’informations importantes et peuvent être isolées d’autres outils et processus. Cela fait en sorte que les tables deviennent une étape supplémentaire dans votre processus de gestion de données, et un atout supplémentaire dont quelqu’un doit prendre possession pour gérer, mettre à jour et maintenir.  

Mais ce n’est pas obligé d’être le cas. 

Avec l’extension d’onglet Excel Team de Microsoft, les équipes peuvent facilement connecter les tables qu’elles ont utilisées auparavant avec leur projet Azure DevOps. Ils peuvent facilement mapper chaque champ d’exigence, propriété et identifiant à l’élément de travail Azure DevOps créé dans leur projet. 

Mais comment Azure DevOps aide-t-il avec les NFR? 

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

Premièrement, Azure DevOps est flexible. 

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

Les exigences non fonctionnelles ne sont qu’un des types d’éléments de travail que vous pouvez ajouter à un projet.  

Qu’est-ce qu’un « type d’élément de travail »?  

Les éléments de travail sont un modèle d’écriture basé sur ADO pour le type d’exigence qu’ils représentent. 

Quelques exemples sont les exigences fonctionnelles, les exigences de transition, les histoires d’utilisateur, ou même 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éez aura son propre ensemble de propriétés, états et relations qui pourront être choisis et personnalisés. 

Avec une exigence non fonctionnelle, vous pouvez configurer tous les champs ou propriétés dont votre équipe a besoin pour aider à la gestion de votre projet. Comme mentionné précédemment, mapper les exigences que vous avez déjà dans un tableau est simple avec l’onglet Microsoft Teams extension Excel [fournir le lien].  

Mais que peut-on faire avec les NFR une fois qu’ils sont dans Azure DevOps (ADO), et comment la migration de la création de NFR vers ADO aide-t-elle votre équipe? 

Regardons les outils. 

Exigences modernes4DevOps : Smart Docs – Modèles de documents NFR personnalisables

La création de documents dépend des politiques, processus, attentes et exigences de l’organisation, et peut même être conçue pour répondre à vos besoins non fonctionnels. 

Les documents offrent un moyen simple de créer une responsabilité pour satisfaire aux exigences convenues pour un projet. Ils offrent un certain niveau de sécurité aux parties prenantes, car les documents peuvent servir de liste de vérification pour les exigences convenues, qui peuvent facilement être recoupées pour déterminer si les parties prenantes reçoivent ce pour quoi elles ont payé ou si le travail n’a pas été terminé. 

Un autre avantage majeur d’une documentation adéquate est que les exigences évoluent souvent tout au long du cycle de vie d’un projet. Une exigence peut devenir plus clairement définie plus tard dans sa vie, ou simplement évoluer d’une manière qui donne une attente différente pour votre produit.  

Mettez en file l’ajout de documents d’exigence non fonctionnels à votre processus. 

À mesure que les exigences évoluent, les attentes pour votre projet évoluent également. Cela signifie que les indicateurs de réussite de votre projet, c’est-à-dire les exigences non fonctionnelles, devront être révisés et modifiés.  

Grâce à notre module Smart Docs de la suite Modern Requirements4DevOps, un utilisateur peut facilement construire un document d’exigences entièrement versionable directement à partir de son projet Azure DevOps. Cela signifie que les utilisateurs peuvent facilement apporter et suivre des modifications des exigences à partir d’une interface de document conviviale. 

De nouvelles exigences peuvent aussi être facilement créées dans votre projet à partir de l’interface d’un document, ou vous pouvez choisir d’insérer directement les exigences existantes dans votre 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.  

Élargissons l’idée d’importer vos NFR existants qui vivent dans les tables dans Azure DevOps, puis expliquons comment transformer ces NFR en documents en utilisant Modern Requirements.  

D’abord, vous importez dans Azure DevOps vos exigences non fonctionnelles à partir de votre table en utilisant l’extension d’onglet Microsoft Team pour Excel. Ensuite, il suffit d’interroger toutes les exigences non fonctionnelles et de les glisser/déposer dans votre document. 

C’est aussi simple que ça. 

Mais disons que vous voulez maintenant ajouter de la structure à un document pour que les exigences non fonctionnelles ne puissent être ajoutées que dans des zones spécifiques du document. 

Nous soutenons ça aussi! 

Il y a un concepteur de modèles intégré directement dans le module Smart Docs, qui vous aide à déterminer quels types d’éléments de travail sont autorisés et où dans vos documents. Cela signifie que toute personne créant un document, basé sur le NFR ou non, peut facilement suivre la structure offerte par votre modèle et créer une documentation cohérente. 

Exigences modernes4DevOps : Smart Docs – Modèles de documents NFR réutilisables

Les modèles de documents réutilisables sont 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 déjà rempli qui explique à quoi un document devrait ressembler. Ce type de modèle aide les auteurs à déterminer facilement où les informations spécifiques doivent être placées et quels éléments contextuels doivent composer le document créé. 

Pense à ce document Word que tu as déjà sur ton bureau. Il y a probablement déjà un endroit réservé pour des choses comme les introductions, la portée, les objectifs, ainsi que l’endroit où vous devriez placer des exigences spécifiques. C’est un modèle de document réutilisable. 

La principale raison pour laquelle les modèles de documents sont utilisés est d’augmenter l’efficacité et de réduire les remaniements dans le processus de fabrication des documents .  

Heureusement pour les équipes qui utilisent actuellement plusieurs applications pour leurs processus de RM et de documentation, il existe une solution qui peut être utilisée pour les deux. Exigences modernes avec Azure DevOps. 

Le Les modèles de documents réutilisables que vous créez avec Modern Requirements + Azure DevOps peuvent être configurés pour contenir n’importe quel champ ou propriétéy que vous devez afficher dans votre document. Vous pouvez sauvegarder n’importe quel document sous forme de modèle réutilisable, ce qui peut automatiquement remplir des champs comme Introduction, Objectifs, Exigences NFR, et plus encore. 

Vous pouvez créer des documents en seulement quelques clics, ce qui aidera votre équipe à démarrer rapidement lors de la création de toute forme de documentation! Cela signifie que votre équipe peut bénéficier non seulement du fait que vos documents et exigences cohabitent le même espace, mais aussi augmenter l’efficacité, créer de la structure, accroître la précision et assurer la cohérence dans votre processus de création de documents.   

Exigences modernes4DevOps : Module FAQ – Modèles de questionnaires personnalisables et réutilisables

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

Cela les rend plus difficiles à dessiner, car vous ne vous contentez pas de pointer le système et de lui dire quoi faire, vous posez plutôt des questions sur la façon dont le système devrait être et utilisez les NFR pour le représenter. 

Comme discuté plus tôt dans cet article, construire des NFR solides repose sur la pose les bonnes questions.  

Alors, que faire si vous êtes nouveau en gestion des exigences ou que vous avez peu d’expérience? Par où commencer? MR4DevOps répond à cette situation avec notre module FAQ complet.  

Le module FAQ est une série de modèles de questions ciblées visant 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 pour l’obtention du NFR en vue de la conformité  et du développement de dispositifs médicaux basés sur les risques . Au fur et à mesure que les utilisateurs répondent aux questions du modèle, ils créentautomatiquement une exigence non fonctionnelle directement dans le Backlog. 

Les modèles de questionnaires inclus dans le module FAQ sont bénéfiques pour les étudiants en licence ayant tous les niveaux d’expérience. Les BA vétérans peuvent modifier des listes existantes en ajoutant leurs propres questions ou en créant leur propre liste de questions à partir de zéro. Ce faisant, les BA peuvent recueillir leur expérience et leurs connaissances du processus d’élicitation et les transmettre aux autres membres de l’équipe.  

Exigences modernes4DevOps : Smart Report – Modèles de rapports configurables

MR4DevOps offre une excellente solution à l’un des principaux oublis d’ADO; l’absence d’un outil de rapport intégré. 

Lorsque vous utilisez des outils comme FAQ ou Smart Docs pour créer et gérer vos besoins non fonctionnels, Smart Report sera l’outil que vous utiliserez pour produire vos besoins. Smart Report vous permet d’afficher les exigences sous forme de PDF, HTML ou Microsoft Word, où vous pouvez appliquer votre propre en-tête/pied de page préconçu, voire une table des matières ou une page de titre.  

Vous souhaitez faire un rapport pour les NFR de votre projet?  

L’outil Smart Report est équipé d’un concepteur avancé de modèles de rapports. Le concepteur de modèles vous permet de créer et sauvegarder des modèles de rapports personnalisés selon le type d’élément de travail. Cela vous permet de créer un modèle NFR unique qui montre les propriétés et champs d’un NFR que vous souhaitez inclure dans le rapport; cette information est directement tirée de l’élément de travail! 

Ce modèle peut être appliqué à n’importe quel groupe de NFR sélectionnés ou interrogés et utilisé chaque fois que votre processus de rapport vous exige. L’avantage de cet outil de rapport est qu’il vous permet de créer des rapports d’exigences instantanés, structurés et cohérents. 

Vous souhaitez voir par vous-même?

Modern Requirements4DevOps propose plusieurs solutions pour aider à l’élection, à la création età la gestion des exigences non fonctionnelles.

Aimeriez-vous jeter un coup d’œil plus approfondi à la conception de modèles avec Modern Requirements ou souhaitez-vous découvrir quels autres outils peuvent améliorer votre processus? Réservez une démonstration de produit dès aujourd’hui!

Découvrez par vous-même comment notre boîte à outils Exigences modernes peut renforcer le DevOps Azure de Microsoft en une seule solution 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 de l’UAT

Réduction de 50% des efforts de l’UAT

Économie de temps éprouvée

80% de gain de temps sur la création d’une analyse de traces

Approbations simplifiées

Réduction significative des délais d’approbation

Augmenter la performance

50% des besoins d’amélioration de la productivité

Réduction de la refonte

Réduction de 10 fois dans la refonte du développement

Simplifier la conformité

Réduction de 40% des efforts de rapport sur la conformité

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

Exigences d’auteur avec Modern Requirements4DevOps

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 :

  1. ID personnalisé
  2. Drapeau Sale
  3. 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

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

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

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

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

  2. Une fois dans le répertoire bin, entrez la commande suivante : MONSIEUR

    Le menu des options s’affiche.

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

  1. Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel l’ID personnalisé est requis).
  2. 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.

  1. Créez un dossier nommé d’après le nom du serveur Azure DevOps (sur quel composant doit s’appliquer) à cet endroit.
  2. 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).
  3. 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

  1. Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
  2. 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.

  3. 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.
  4. 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 '\')
  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. 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.
  7. 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.
    1. 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.
    2. 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
    3. 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.
  8. 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

  1. Entrez la commande suivante sur CMD : cd :\Program Files\Modern Requirements\MR-Agent\bin
  2. Une fois dans le répertoire bin, entrez la commande suivante : MONSIEUR

     

    Le menu des options s’affiche.

  3. Type 1 et cliquez sur Entrée.
  4. Entrez la valeur URL d’organisation Azure DevOps (ou TFS Collection).
  5. 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 :

  1. Un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le Dirty Flag doit s’appliquer).
  2. 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.

  1. Créez un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit s’appliquer) à cet endroit.
  2. 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).
  3. 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

  1. Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
  2. 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.
  1. 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.
  2. 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.
  3. 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.

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

  1. Configuration du fichier de configuration du moniteur courriel (placé à un endroit précis)
  2. 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 :

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

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

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

  1. Fonctionne pour toutes les composantes des services MR
  2. Utilisé pour vérifier les nouveaux projets/collections
  3. 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

  1. Fonctionne seulement pour l’ID personnalisé
  2. Utilisé pour appliquer un identifiant personnalisé sur les éléments de travail nouvellement créés
  3. 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

  1. Fonctionne seulement pour Email Monitor
  2. Ça servait à vérifier si un nouveau courriel était arrivé d’où les éléments de travail pouvaient être créés ou mis à jour
  3. 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 :

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

  1. Créez un dossier nommé d’après le nom du serveur Azure DevOps (TFS) (sur lequel le composant doit s’appliquer) à cet endroit.
  2. 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).
  3. Ce fichier contient le plan pour la configuration désirée.

Configuration du fichier XML du moniteur de courriel

  1. Ouvre le XML fichier dans le bloc-notes ou dans n’importe quel éditeur de texte.
  2. Définir la valeur de la ServerURL Étiquette selon les exigences, par exemple :
  3. 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.
  4. 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.

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

    2. 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éé.
    3. 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.
      1. OnCreate= ”true” means that the title would be set from the email’s subject only for new Work Items.
      2. OnUpdate=”false” signifie que pour les éléments de travail existants, le champ Titre ne serait pas mis à jour.
    4. 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.
      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 partie ultérieure de ce champ indique la composition du champ de 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. Corps du courriel ajouté dans une nouvelle ligne
    6. 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.
    7. Après avoir complété avec succès le fichier de configuration, sauvegardez et fermez le fichier.

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

Soutien aux incidents

Recevez du soutien en direct par téléphone, courriel ou rencontre web. Chaque demande de soutien en cas d’incident peut couvrir un enjeu particulier.

Soutien aux incidents

Vas-y maintenant!

Soutien par courriel

Envoyez un courriel à notre équipe de soutien pour obtenir la réponse la plus rapide. En nous envoyant un courriel, un billet sera créé automatiquement pour vous!

Soutien par courriel

Vas-y maintenant!

Soumettre une idée

Vous voulez plus de nos produits? Les suggestions nous rendent meilleurs. Soumettez une idée et nous ajouterons de l’enquête à notre arriéré!

Soumettre une idée

Vas-y maintenant!

Soutien communautaire

Trouvez des réponses aux questions courantes ou soumettez un billet sur notre portail de soutien communautaire.

Soutien communautaire

Vas-y maintenant!

Signaler un bogue

Faites-nous savoir si vous avez trouvé un bogue et nous en ferons une priorité pour le corriger. Personne n’aime les insectes — et nous ne faisons pas exception.

Signaler un bogue

Vas-y maintenant!

Contacter le support

Soutien aux incidents

Recevez du soutien en direct par téléphone, courriel ou rencontre web. Chaque demande de soutien en cas d’incident peut couvrir un enjeu particulier.

Soutien aux incidents

Vas-y maintenant!

Soutien par courriel

Envoyez un courriel à notre équipe de soutien pour obtenir la réponse la plus rapide. En nous envoyant un courriel, un billet sera créé automatiquement pour vous!

Soutien par courriel

Vas-y maintenant!

Soumettre une idée

Vous voulez plus de nos produits? Les suggestions nous rendent meilleurs. Soumettez une idée et nous ajouterons de l’enquête à notre arriéré!

Soumettre une idée

Vas-y maintenant!

Soutien communautaire

Trouvez des réponses aux questions courantes ou soumettez un billet sur notre portail de soutien communautaire.

Soutien communautaire

Vas-y maintenant!

Signaler un bogue

Faites-nous savoir si vous avez trouvé un bogue et nous en ferons une priorité pour le corriger. Personne n’aime les insectes — et nous ne faisons pas exception.

Signaler un bogue

Vas-y maintenant!