Dans cet article, nous allons vous présenter quelques-unes des principales nouveautés apportées à certains de nos modules ainsi que des améliorations apportées aux outils de Modern Requirements, pour vous faciliter la tâche.
Lire la suite
Dans cet article, nous allons vous montrer comment certaines entreprises parviennent à surmonter tous les défis liés au développement de produits grâce à une solution simple de gestion des exigences : Modern Requirements4DevOps.
Lire la suite
La fonctionnalité Email Monitor permet de créer des éléments de travail dans votre projet Azure DevOps via un canal qui n'est pas natif d'Azure DevOps. En d'autres termes, elle vous permet de communiquer avec votre projet par e-mail. Les équipes se retrouvent souvent confrontées à des situations où elles échangent des e-mails concernant des exigences, des demandes de modification ou des bogues qui doivent être créés, et elles parviennent souvent à utiliser ces e-mails pour aboutir à une exigence définitive qui doit être ajoutée à leur projet.
Grâce à la fonctionnalité « Email Monitor », votre équipe peut désormais transformer directement ces communications externes en tâches.
Pour découvrir les cas d'utilisation et la procédure de configuration d'Email Monitor, veuillez regarder la vidéo.
Vous pouvez accéder à la page de configuration d'Email Monitor en vous rendant dans Collection/Paramètres d'administration – Extension Modern Requirement4DevOps – Services – Email Monitor.
En activant la fonctionnalité « Email Monitor » dans le panneau d'extension Modern Requirements4DevOps, vous pouvez définir une adresse e-mail de surveillance capable d'intercepter et de créer tout élément de travail qui lui est envoyé par e-mail. Étant donné que le système tentera de capturer tous les e-mails envoyés à cette adresse, il est recommandé de l'utiliser exclusivement dans le cadre de la fonctionnalité « Email Monitor ».
Vous devez également fournir une adresse e-mail d'administrateur au cas où le système ne parviendrait pas à reconnaître les e-mails ; une notification sera alors envoyée à cette adresse.
Vous pouvez indiquer les types d'éléments de travail que vous souhaitez créer dans votre projet à partir de ces e-mails capturés.
Les objets des e-mails envoyés à l'adresse Monitor Email seront toujours repris dans les titres des tâches à créer.
« Projet d'équipe (par défaut) » vous permet de choisir le projet par défaut auquel vous souhaitez ajouter les éléments de travail.
Les options « Création d'extension » et « Mise à jour d'extension » vous permettent de définir à quel moment vous souhaitez ajouter l'exigence au projet.
Pour le champ « Description » :
Si la case « Créer un élément de travail » est cochée, cela signifie que le système utilisera l'e-mail initial pour créer un nouvel élément de travail et que le corps de l'e-mail deviendra la description de cet élément.
Si l'option « Ajouter lors de la mise à jour » est cochée, cela signifie que la description actuelle de l'élément de travail créé sera remplacée par les réponses ultérieures concernant ce même élément de travail.
Pour le domaine de l'histoire:
Si l'option « Ajouter lors de la création » est cochée, cela signifie que le corps du courriel initial sera associé à la section « Discussion » de l'élément de travail créé.
Si l'option « Ajouter à la mise à jour » est cochée, tous les échanges de messages concernant le même élément de travail seront ajoutés à la section « Discussion ».
Les champs « Nom de l'expéditeur », « E-mail de l'expéditeur » et « Corps du message » vous permettent de définir le contenu que vous souhaitez ajouter dans la section « Description » ou « Discussion » correspondante.
Le cas d'utilisation le plus courant de la fonctionnalité « Email Monitor » est le suivant :
Je dirige une grande entreprise et j'aimerais que tous les membres de mon équipe signalent les bugs qu'ils détectent dans mon logiciel dans mon projet Azure DevOps.
Une fois Email Monitor entièrement configuré avec l'adresse bugs@myorganization.com, toute personne concernée peut simplement envoyer un e-mail à bugs@myorganization.com pour que je puisse demander la création d'un ticket de bug dans mon projet.
Parallèlement, l'e-mail à l'origine de la création du bug est également envoyé aux personnes concernées par ce projet. Les membres concernés peuvent désormais participer à la discussion relative à cet élément de travail par e-mail, et tous les échanges par e-mail seront ajoutés aux propriétés « Discussion » de cet élément de travail au sein de votre projet.
Cette fonctionnalité unique permet à des personnes extérieures de contribuer à la réussite de votre projet sans avoir besoin d'un accès complet à votre projet Azure DevOps. Les intervenants externes peuvent désormais participer aux discussions relatives à un élément de travail, sans que vous ayez à leur accorder un accès à votre projet.
Ajouter des tâches à des projets autres que le projet par défaut
Si l'expéditeur n'indique pas de nom de projet spécifique dans le corps de l'e-mail, l'e-mail mappé sera ajouté au projet par défaut. Si les expéditeurs souhaitent ajouter l'exigence à un autre projet de la même collection, ils devront inclure [ProjectName=GCD] dans le corps de l'e-mail (GCD est un exemple de nom de projet).
Plusieurs types d'éléments de travail
Nous comprenons que les parties prenantes de votre projet puissent souhaiter ajouter plusieurs types d'éléments de travail à l'aide d'Email Monitor. C'est tout à fait possible ! Il vous suffit de sélectionner plusieurs types d'éléments de travail. Par exemple, je sélectionne ici « User Story » en plus de « Bug ». Lorsque votre équipe envoie des e-mails à la boîte de réception du moniteur, elle peut utiliser [WIT=bug] ou [WIT=user story] dans le corps de l'e-mail pour préciser le type d'élément de travail auquel l'exigence créée doit correspondre. Si le type de tâche n'est pas spécifié dans le corps de l'e-mail, le système tentera de mapper l'e-mail au type de tâche correspondant à la catégorie de tâches que vous avez sélectionnée dans la section « Catégorie de tâches ».
Ajouter du contenu supplémentaire à un élément de travail existant
Une fois que le système a enregistré l'e-mail initial, toutes les réponses ultérieures peuvent, par défaut, être ajoutées en tant que discussions relatives au même élément de travail. De plus, les expéditeurs peuvent ajouter [wiid=1997] (1997 étant un exemple d'identifiant d'élément de travail) dans le corps de l'e-mail pour ajouter du nouveau contenu à l'élément de travail existant concerné.
Bien sûr, vous pouvez utiliser plusieurs de ces commandes spéciales dans un e-mail, selon vos besoins.
Cette fonctionnalité vous permet de surveiller les éléments de travail qui répondent à certaines conditions préalables. Lorsque ces éléments de travail changent, la fonctionnalité de surveillance marque tous les éléments de travail associés comme suspects.
L'User Story 1 vient d'être mise en état « Terminé ». Si le Suspect Link peut être configuré pour déclencher une alerte en cas de modification des User Stories en état « Terminé » (par exemple, une modification d'un champ tel que « Description »).
Cela signifie que si le champ « Description » de l'User Story 1 est modifié à l'avenir, toutes les exigences qui y sont associées seront marquées d'un indicateur « Dirty ».
Cela permet à votre équipe de détecter facilement si une exigence répondant à un certain ensemble de critères (que vous définissez) subit une modification. Une fois identifiées, les tâches configurées qui y sont directement liées seront signalées par le statut « Modifié/Suspect ».
Pour reprendre notre exemple, si le champ « Description » de l'User Story 1 venait à changer, nous pourrions marquer d'un indicateur « Dirty » tous les cas de test directement liés qui pourraient devoir être modifiés afin de tester les nouveaux critères.
Les indicateurs d'erreur activés sur ces cas de test prendraient la forme d'une balise de tâche.
Les balises s'affichent dans l'éditeur d'éléments de travail standard d'Azure DevOps. Vous pouvez également personnaliser les options de colonnes dans le module Éléments de travail et backlogs afin d'afficher un groupe d'éléments de travail dont certains peuvent être marqués par l'indicateur « Dirty ».
Lorsque le tag « Dirty Flag » est activé sur des éléments de travail, ce tag inclut à la fois l'identifiant et la révision de l'élément de travail modifié, ce qui permet à votre équipe d'identifier facilement quelle exigence a été modifiée et a déclenché la fonctionnalité « Dirty Tag / Suspect Link ».
Les balises « Dirty Flag » peuvent être supprimées manuellement une fois que les parties prenantes concernées ont examiné l'impact et procédé aux mises à jour nécessaires. Nous recommandons, dans ce cas, d'ajouter un commentaire indiquant que la balise « Dirty Flag » a été supprimée, soit parce que les mises à jour nécessaires ont été effectuées, soit parce qu'aucune mise à jour n'est requise.
Pour plus de détails et pour connaître la procédure de configuration de Dirty Flag/Suspect Link, veuillez regarder la vidéo.
Modern Requirements4DevOps permet d'ajouter des identifiants personnalisés aux éléments de travail. Cette fonctionnalité vise à rendre les champs des éléments de travail plus lisibles et plus reconnaissables. Par exemple, « PX-REQ-00001 » pour le premier élément de travail relatif aux exigences du projet X.
Notre fonctionnalité « Identifiant personnalisé » offre les mêmes avantages, auxquels s'ajoutent ceux liés à l'utilisation de l'identifiant personnalisé dans le module « Requêtes ».
Les identifiants personnalisés peuvent être configurés comme une propriété personnalisée associée à chacun de vos éléments de travail. Les identifiants personnalisés ne sont pas destinés à remplacer l'identifiant de l'élément de travail, mais à le compléter.
La propriété « Custom ID » permet d'identifier facilement plusieurs informations essentielles relatives à un élément de travail donné, le tout dans un seul champ. Elle s'avère également être un outil extrêmement utile pour identifier la source d'une exigence dans le cadre de requêtes inter-projets.
En vous permettant de regrouper les informations dans un seul champ, vous rendez un élément de travail plus accessible aux utilisateurs moins impliqués. La fonctionnalité « ID personnalisé » respecte les directives suivantes :
Un code unique peut être attribué aux éléments de travail en fonction de leur type. Par exemple, le code d'un élément de travail de type « Exigence » pourrait être REQ, celui d'un élément de travail de type « User story » pourrait être US, et celui d'un élément de travail de type « Bug » pourrait être BG.
Vous pouvez définir le numéro de départ à partir duquel vos types d'éléments de travail seront numérotés par incréments. Par exemple, vous pouvez choisir que la numérotation des identifiants personnalisés des User Stories commence à 1 ou à 10 000, et l'identifiant personnalisé de chaque User Story sera alors incrémenté à partir de ce numéro.
Vous pouvez également ajouter un préfixe de projet facultatif à tout identifiant personnalisé. Par exemple, un nom de projet tel que « Projet X » pourrait se voir attribuer le préfixe PX.
Enfin, vous pouvez choisir d'inclure le champ « Portée » de n'importe quel élément de travail. Le numéro d'identification n'est pas répété dans la portée ; la portée peut être « Équipe », « Projet » ou « Collection ». La portée garantit que l'identifiant personnalisé sera unique au sein de cette portée.
En reprenant l'exemple présenté dans la directive ci-dessus, l'identifiant personnalisé du premier élément de travail « Exigence » (00001) du projet X serait « PX-REQ-00001 » – qui correspond à la concaténation du préfixe du projet, du code de type d'élément de travail et du numéro.
Pour plus de détails et pour connaître la procédure de configuration de l'identifiant personnalisé, veuillez regarder la vidéo.
Convivialité, cycles courts, possibilité de définir des exigences en ligne, rapports de conformité et réduction des retouches en développement. Ce ne sont là que quelques-uns des termes utilisés par nos clients pour décrire les capacités de plusieurs modules de l'application Modern Requirements4DevOps. De nouvelles fonctionnalités et améliorations ont été apportées à ces modules dans notre version 2020.
Nous allons vous présenter ici quelques-unes des principales nouveautés apportées à certains de nos modules dans Modern Requirements, ainsi que des améliorations apportées aux outils pour vous faciliter la tâche. Les modules que nous allons vous présenter sont les suivants :
1. Gestion des droits : Vous nous l'avez demandé, et nous vous avons écoutés. Vous pouvez désormais gérer les accès des utilisateurs. Un utilisateur (qui doit disposer des droits d'administrateur de collection/projet) peut désormais gérer les accès des utilisateurs aux deux modules de Modern Requirements4DevOps, ainsi qu'aux fonctionnalités de chaque module. La configuration de ces autorisations est un jeu d'enfant… Voici les trois étapes pour définir les autorisations :
Voici ce que vous verrez :
Depuis cet écran, vous pourrez définir lesautorisations pourles *Groupes et/oules *Équipes (situées dans le panneau de gauche). Il existe deux façons de définir ces autorisations : soit dans les « *Paramètres communs », soit individuellement dans les « *Modules Modern Requirements4DevOps » (situés dans le panneau de droite de l'onglet Autorisations). Vous pouvez y définir les autorisations pour les fonctionnalités de chaque module.
Les options de droits d'accès disponibles sont les suivantes :
À l'heure actuelle, la gestion des droits est prise en charge pour trois modules : Smart Docs,Baseline etReporting.
Pour plus d'informations sur les nouveautés de la gestion des droits et ses fonctionnalités, veuillez consulter la vidéo.
2. Améliorations apportées au module « Review » : le module « Review » vous permet de communiquer, d'examiner et de valider des éléments au sein de l'environnement du projet, ainsi que de faciliter les modifications si nécessaire. Des améliorations ont été apportées au module « Review ». Voici une liste de quelques-unes des nouvelles fonctionnalités :
Droits en lecture seule pour les personnes ne participant pas à la révision: grâce à cette amélioration, vous pouvez désormais configurer des droits permettant aux personnes ne participant pas à la révision de consulter les détails de celle-ci en mode lecture seule.
Utilisateurs non participants :utilisateurs qui ne sont ni l'approbateur ni le réviseur.
Génération automatique en masse des rapports d'audit des révisions : cette amélioration vous permettra de générer en une seule fois, depuis le panneau d'administration, les rapports d'audit de toutes les révisions d'un projet, soit en masse, soit projet par projet.
Vous pouvez sélectionner ici un ou plusieurs projets et fournir des informations détaillées afin de générer automatiquement les rapports d'audit de leurs révisions existantes
Format des rapports d'audit – Word/PDF : le système vous permet désormais de choisir le format dans lequel vous souhaitez générer les rapports d'audit. Vous pouvez choisir entre la version Word et la version PDF.
Le rapport d'audit des validations a pour objectif de fournir des informations détaillées sur toutes les tâches d'une révision. Il présente un état complet indiquant qui a approuvé ou rejeté les tâches de révision, ainsi que les commentaires et les décisions correspondants.
Pour plus d'informations sur les nouveautés de la gestion des avis et ses fonctionnalités, veuillez consulter la vidéo.
3. Améliorations apportées à Smart Docs : Smart Docs est un outil qui fait le lien entre la gestion des documents et celle de l'information en permettant de rédiger des spécifications dans une interface de document en ligne. De nouvelles fonctionnalités ont été ajoutées à Smart Docs ; en voici quelques-unes parmi les plus importantes :
Prise en charge du mode plein écran : pour une meilleure expérience utilisateur et un affichage plus grand, vous pouvez désormais consulter les Smart Docs en mode plein écran. Cela vous offre une meilleure visibilité lors de la création de vos cahiers des charges en ligne.
Mise à jour de l'interface utilisateur du panneau de droite :
Mise à jour concernant l'héritage des propriétés du parent : cette mise à jour fait en sorte que, par défaut, la case à cocher permettant d'hériter des propriétés du work item parent dans le work item enfant apparaisse désormais « décochée ».
Remarque: si aucune propriété n'est sélectionnée dans le menu déroulant, aucune propriété ne sera transmise à l'élément de travail enfant.
Pour plus d'informations sur les nouveautés de Smart Docs et ses fonctionnalités, veuillez consulter la vidéo.
4. Améliorations apportées à Smart Reports : Smart Report permet aux utilisateurs de mettre en forme leurs rapports en fonction de la structure des tâches. Il est accessible depuis de nombreux modules ADO et Modern Requirements4DevOps. Voici une liste de certaines des améliorations apportées au module Smart Report :
Importer un modèle Word contenant des macros : Smart Report vous permet désormais d'importer et d'exécuter des documents Word contenant des macros (.docm) ainsi que des modèles Word contenant des macros (.dotm) dans Smart Report via la fonction « Importer un modèle Word ». Cette fonctionnalité rendra l'importation de modèles Word encore plus simple et intuitive.
Conserver la sélection du dernier modèle Word téléchargé : Devinez quoi… Smart rReport est désormais encore plus intelligent : il conserve désormais la dernière sélection que vous avez effectuée lors du téléchargement de votre modèle Word.
Conservation de la sélection de la dernière partie Smart Part: Eh bien, nous ne nous sommes pas contentés de mémoriser la dernière sélection pour le modèle de texte… Des améliorations ont été apportées : le système conserve désormais également la sélection de votre dernière partie Smart Report Part. C'est vraiment une aubaine pour les créateurs de rapports.
Pour plus d'informations sur les nouveautés de Smart Reports et ses fonctionnalités, veuillez consulter la vidéo.
5. Améliorations apportées à Baseline : Baseline vous permet de créer un instantané de vos exigences à un moment donné afin de mieux les contrôler et d'en suivre les modifications. Voici comment cela améliorera encore davantage votre expérience de travail :
Conservation de la sélection de l'élément de travail lors du changement d'onglet : le système mémorise désormais la dernière sélection d'élément de travail lorsque vous naviguez entre les différents onglets d'une baseline. Qu'est-ce que cela signifie ? Eh bien, lorsque vous travaillez sur une baseline (en particulier une baseline volumineuse), si vous passez de l'onglet « Comparer » ou « Détails » à l'onglet « Afficher » et que vous avez oublié sur quel élément de travail vous travailliez… Ne vous inquiétez plus, car le système s'en souviendra pour vous.
ID de comparaison dans la comparaison de lignes de base : des améliorations ont été apportées afin que vous puissiez désormais afficher les révisions des éléments de travail uniquement lorsque ces derniers existent dans les deux lignes de base comparées. Par exemple : si un élément de travail n'existe pas dans l'une des lignes de base, aucun ID de révision ne s'affichera ; à la place, le caractère « - » apparaîtra dans la colonne « Rev.ID » ou « Comp.Rev.ID ». Cette règle s'appliquera également dans le rapport de différences.
Pour plus d'informations sur les nouveautés de Baseline et ses fonctionnalités, veuillez consulter la vidéo.
6. MatCal (Nouveau) : Une nouvelle fonctionnalité a été ajoutée à Modern Requirements pour permettre l'exécution d'expressions mathématiques et logiques. Ça vous semble intéressant ? Eh bien, nous, on est ravis. Voici pourquoi :
Ce que vous devez faire : transmettez vos formules à un membre de l'équipe Modern Requirements Customer Success, et nous nous ferons un plaisir de les configurer pour vous.
Pour plus d'informations sur MatCal et ses fonctionnalités, veuillez consulter la vidéo.
Nous sommes ravis de vous annoncer que « Modern Requirements4DevOps 2020 » est désormais disponible au téléchargement !
Azure DevOps est une plateforme exceptionnelle qui offre une source unique de vérité.
Pour de nombreuses équipes, cette affirmation suffit à elle seule à les inciter à envisager d'utiliser la plateforme ALM leader mondial pour la gestion de leurs exigences. La possibilité de relier les tâches de développement aux exigences, et celles-ci aux cas de test, est une opportunité difficile à laisser passer.
Mais que faire si vous n'avez pas besoin de toutes les fonctionnalités d'une plateforme ALM complète ?
Et si vous aviez simplement besoin d'une solution pour gérer vos exigences ?
Vous pouvez exploiter toutes les fonctionnalités avancées de Modern Requirements4DevOps pour transformer votre projet Azure DevOps en une solution complète de gestion des exigences. L'une de ces fonctionnalités est la possibilité de réutiliser des exigences dans différents projets, collections et serveurs à l'aide de l'outil de réutilisation de Modern Requirements4DevOps.
Vous souhaitez réutiliser des spécifications ?
Vous êtes au bon endroit.
Ce que vous apprendrez dans ce bref article :
Lorsque l'on évoque les avantages de la réutilisation des exigences, il y a un point qu'il convient d'aborder en premier lieu.
La question qui m'est le plus souvent posée par les équipes matérielles est la suivante : « En quoi cela pourrait-il bien profiter à des équipes qui ne travaillent pas dans le domaine logiciel ? »
Avant de commencer, précisons que la réutilisation des exigences ne concerne pas uniquement les équipes de développement logiciel.
La réutilisation des spécifications est un sujet qui suscite souvent l'intérêt.
En effet, dans l'économie mondiale, on constate que les entreprises se concentrent sur des domaines ou des secteurs spécifiques au sein de certaines industries. Cela les amène à développer des produits dans un domaine précis ou autour d'une solution donnée, et à se concentrer exclusivement sur les quelques domaines dans lesquels elles peuvent vraiment exceller.
Cela signifie que, lorsque vous développez des projets, des solutions ou des systèmes, une équipe peut souvent réutiliser des éléments d'un projet antérieur. C'est là que la réutilisation des exigences entre en jeu.
En permettant à une équipe de réutiliser ces exigences dans le projet suivant, celle-ci peut réduire la charge de travail nécessaire au démarrage d'un nouveau projet.
Pour certaines personnes, cela va peut-être déjà de soi.
Ce qui n'est peut-être pas évident, cependant, c'est que la réutilisation peut également constituer un excellent moyen de gérer les exigences dont la portée dépasse le cadre du projet. Cela inclut les exigences non fonctionnelles ou les risques qui doivent être pris en compte au niveau de l'ensemble de l'entreprise. Cela permettrait même à votre équipe de réutiliser des exigences dont l'objectif est strictement réglementaire ou axé sur la conformité. Cette fonctionnalité peut s'étendre aussi bien aux équipes logicielles qu'aux équipes matérielles et peut même aider les équipes produit dédiées à un composant physique ou à un livrable.
La réutilisation des exigences par référence est un moyen rapide d'intégrer des exigences existantes à votre projet en créant simplement des liens vers celles-ci. Cela vous permet d'accéder directement à ces éléments de travail et de consulter l'ensemble du contenu, des liens et des pièces jointes associés sans avoir à les copier au sein d'un même projet ou d'un projet à l'autre.
Dans Azure DevOps, les fonctionnalités permettant de copier des exigences ou d'autres éléments de travail d'un projet à un autre sont très limitées. Mais lorsque vous intégrez Modern Requirements4DevOps à votre environnement Azure DevOps, la réutilisation des exigences atteint son plein potentiel.
Lorsqu'on aborde la réutilisation des exigences par copie, trois grandes approches doivent être prises en compte.
Après avoir visionné les vidéos ci-dessus, il apparaît clairement que l'outil Modern Requirements4DevOps Reuse est efficace pour la réutilisation des exigences.
Il offre un contrôle total sur les exigences que vous choisissez de réutiliser, vous permet de les personnaliser et de les relier à l'élément de travail d'origine.
Cela signifie que, quelle que soit la destination de vos spécifications, vous pouvez les envoyer à l'aide de l'outil Modern Requirements4DevOps Reuse. Il existe toutefois plusieurs façons d'utiliser cet outil de manière plus efficace.
La première mention notable concerne l'association de l'outil de réutilisation avec l'outil « Modern Requirements4DevOps Baseline ».
Qu'est-ce qu'une version de référence ?
De nombreuses équipes utilisent des versions de référence pour leurs exigences sans même s'en rendre compte.
Une version de référence est un instantané des éléments de travail à un moment donné.
De nombreuses équipes utilisent simplement les versions des documents Microsoft Word comme version de référence.
Lorsqu'il s'agit de consigner les exigences à un moment donné, la fonctionnalité Modern Requirements4DevOps présente de nombreux avantages par rapport à l'approche traditionnelle utilisant Microsoft Word. Grâce aux « baselines » de Modern Requirements4DevOps, vous pouvez consigner un ensemble de tâches telles qu'elles se présentaient à la date de votre choix.
Cela signifie que si vous souhaitez consigner vos exigences telles qu'elles étaient il y a deux semaines, vous pouvez facilement créer une version de référence pour ces exigences à cette date. Cela met directement en évidence les avantages de l'outil de réutilisation ajouté par Modern Requirements4DevOps.
En associant l'outil « Réutilisation » à notre référence, vous pouvez non seulement sélectionner l'ensemble des exigences que vous souhaitez réutiliser, mais aussi choisir la version de ces exigences. Cela vous permet de réutiliser la version la plus pertinente et la mieux adaptée de vos exigences dans votre prochain projet.
Il convient également de mentionner l'importance d'utiliser efficacement les opérations de préfixation, de postfixation et autres lors de la réutilisation des exigences.
Lorsque vous réutilisez des exigences, l'outil Modern Requirements4DevOps Reuse vous permet de personnaliser la manière dont les exigences réutilisées s'afficheront dans le projet de destination.
L'écran qui vous permet d'effectuer cette opération est présenté ci-dessous :
L'utilisation de cette fonctionnalité vous permettra d'ajouter facilement un préfixe ou un suffixe aux exigences une fois qu'elles auront atteint le projet de destination que vous avez choisi. Comme indiqué ci-dessus, vous pouvez également choisir d'envoyer ces exigences vers un chemin de domaine spécifique (comme le matériel ou les logiciels, par exemple), ou même vers une itération donnée, afin de décider du moment où elles seront traitées.
La fonctionnalité la plus couramment utilisée dans les options de champ est toutefois la possibilité d'ajouter une balise.
Souvent, lorsque vous transférez des exigences d'un projet à un autre, vous souhaitez pouvoir facilement identifier et suivre ces exigences dans le projet de destination. L'ajout d'une balise vous permettra de le faire.
Quel est le lien avec l'option « Source Work Item » ?
Cette option vous permet d'établir un lien entre le work item que vous réutilisez et celui que vous créez dans votre projet de destination.
Quel lien cela crée-t-il ?
Cela relie votre nouvel élément de travail de destination à votre élément de travail d'origine via le lien « Related » (Lié) ou tout autre type de lien que vous avez configuré dans l'espace d'administration.
Sur l'image ci-dessous, vous pouvez voir un cas de test que j'ai copié d'un projet à un autre, en utilisant à la fois le préfixe « CL- » et l'option « Link to source work item » (Lier à l'élément de travail source).
La fonctionnalité « Lier à l'élément de travail source » vous permet de retracer facilement l'origine des exigences. Si cette fonctionnalité offre de nombreux cas d'utilisation pour le transfert direct d'exigences d'un projet à un autre, ses applications plus avancées concernent plutôt le transfert d'exigences depuis une bibliothèque ou un référentiel vers un projet.
Baseline est un outil très utile, que vous souhaitiez réutiliser un seul élément de travail ou une longue liste d'éléments de travail issus de votre projet ou bibliothèque source. Dans Modern Requirements, vous pouvez créer des liens entre votre source et les éléments de travail copiés afin de pouvoir retracer l'origine de ces derniers.
Même s'il existe des liens entre eux, les éléments de travail copiés sont toujours considérés comme indépendants des éléments de travail sources, ce qui signifie que toute modification apportée aux éléments de travail copiés ou aux éléments de travail sources n'aura aucune incidence sur leur équivalent.
Vous vous demandez peut-être : comment synchroniser les modifications lorsque cela s'avère nécessaire ? Supposons que vous disposiez d'une bibliothèque dans laquelle tous vos éléments de travail relatifs aux spécifications de conception sont enregistrés, et que vous les ayez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certaines conceptions dans la bibliothèque et que vous souhaitez que toutes les spécifications de conception copiées soient synchronisées, il vous suffit d'utiliser la fonctionnalité Fusionner, qui se trouve sous « Références source copiées » ou « Références cible copiées » dans l'onglet Détails du module Références.
Baseline est un outil très utile, que vous souhaitiez réutiliser un seul élément de travail ou une longue liste d'éléments de travail issus de votre projet ou bibliothèque source. Dans Modern Requirements, vous pouvez créer des liens entre votre source et les éléments de travail copiés afin de pouvoir retracer l'origine de ces derniers.
Même s'il existe des liens entre eux, les éléments de travail copiés sont toujours considérés comme indépendants des éléments de travail sources, ce qui signifie que toute modification apportée aux éléments de travail copiés ou aux éléments de travail sources n'aura aucune incidence sur leur équivalent.
Vous vous demandez peut-être : comment synchroniser les modifications lorsque cela s'avère nécessaire ? Supposons que vous disposiez d'une bibliothèque dans laquelle tous vos éléments de travail relatifs aux spécifications de conception sont enregistrés, et que vous les ayez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certaines conceptions dans la bibliothèque et que vous souhaitez que toutes les spécifications de conception copiées soient synchronisées, il vous suffit d'utiliser la fonctionnalité Fusionner, qui se trouve sous « Références source copiées » ou « Références cible copiées » dans l'onglet Détails du module Références.
Vous vous souvenez de la définition d'une version de référence ? Il s'agit d'un instantané d'éléments de travail sélectionnés à un moment donné. Ainsi, quelles que soient les modifications apportées aux éléments de travail inclus dans la version de référence, l'instantané enregistré reste inchangé. Par conséquent, même si nous avons fusionné les versions de référence, les modifications s'appliquent aux dernières versions des éléments de travail, et non aux versions de référence elles-mêmes. Cela vous semble un peu difficile à comprendre ?
Nous vous invitons à regarder la vidéo de 5 minutes intitulée « Fusionner des lignes de base copiées ».
Essayez gratuitement Modern Requirements4DevOps dès aujourd'hui.
Nous vous offrons la possibilité de tester notre solution de gestion des exigences dans votre propre environnement Azure DevOps, ou dans un environnement que nous mettons à votre disposition et qui comprend des données d'exemple.
Dans cet article, nous présentons les fonctionnalités et les avantages du module FAQ.
Ce module a été conçu pour aider les équipes chargées de recueillir les exigences au début de leur processus de gestion des exigences. En créant des listes de questions, les équipes peuvent facilement consigner et réutiliser leurs connaissances du processus de collecte afin de poser les bonnes questions qui permettront d'obtenir les meilleures exigences.
Le module FAQ est un référentiel de listes de questions que votre équipe peut créer, modifier, adapter et utiliser pour recenser les besoins. En utilisant ce module pour constituer une base de connaissances pour votre équipe, vous avez l'assurance que chaque membre sera en mesure de communiquer efficacement avec les parties prenantes.
En élaborant la meilleure série de questions dans ce domaine, votre équipe peut s'assurer de toujours recueillir les meilleurs besoins possibles.
Le principal avantage de ce module est qu'il permet à votre équipe de constituer une base de connaissances pouvant être utilisée aussi bien par des analystes métier expérimentés que par ceux qui pourraient être amenés à recueillir des exigences dans un domaine qui leur est peu familier. Le module FAQ contient d'emblée plus de 3 000 questions couvrant de nombreux sujets différents.
Ces thèmes comprennent plusieurs modèles de conformité aux normes ISO, ainsi que des modèles portant sur des exigences non fonctionnelles telles que l'évolutivité, la réutilisabilité ou l'opérabilité, qui peuvent être utilisés pour la collecte des exigences.
Pour de nombreuses équipes, ce module remplacera les listes de questions sous Excel qu'elles utilisaient peut-être auparavant.
Afin de s'aligner sur les autres modules de la suite d'outils Modern Requirements, le module FAQ intègre ce qui était auparavant un processus isolé et le relie directement à votre projet. Cela signifie que vos équipes peuvent facilement ajouter des exigences à votre projet en répondant simplement aux questions de votre liste de FAQ.
L'intérêt de notre module FAQ peut se résumer en deux points simples.
En tirant parti des précieuses connaissances d'analystes métier expérimentés, vous pouvez créer des modèles de questions spécifiques à un domaine qui facilitent la structuration du processus de collecte des exigences. Ainsi, vous pouvez confier à n'importe quel analyste métier, quel que soit son niveau d'expérience, la tâche de rencontrer une partie prenante, tout en étant certain qu'il parviendra à définir des exigences complètes et exploitables.
Comme votre équipe n'a plus besoin de créer des modèles de questions ni de copier ensuite les exigences recueillies dans votre outil de gestion des exigences, elle peut avancer plus rapidement dans le processus de collecte des exigences. Cela signifie qu'elle consacre davantage de temps à affiner des exigences plus précises et moins de temps à copier-coller des user stories qui risquent de nécessiter des modifications supplémentaires.
Lorsque nous discutons avec les membres de notre communauté de leur utilisation du module FAQ, ils nous expliquent souvent comment ce module a permis de rationaliser leurs processus et de faciliter la gestion de la phase de collecte des informations dans le cadre de leurs projets.
Même les équipes qui n'ont pas pour habitude d'utiliser des listes de questions nous font savoir, une fois qu'elles ont rejoint notre communauté, à quel point elles apprécient de pouvoir rassembler les connaissances de tous les membres de leur équipe dans une liste cohérente.
Voici les cas d'utilisation que nous avons observés pour le module FAQ.
CAS D'UTILISATION 1
Mon équipe procède actuellement à la collecte des exigences dès le début, puis avance de manière itérative tout au long du projet. Nous utilisons actuellement Excel pendant la phase de collecte des exigences, mais cela nous oblige à recopier ensuite ces exigences dans l'outil de notre choix.
En tant qu'équipe chargée de recueillir les exigences dès le début du projet, nous avons là une occasion idéale d'utiliser une liste de questions spécialement conçue pour ce domaine. Cependant, recourir à Excel pour gérer cette liste de questions revient à se condamner à un long processus de copier-coller par la suite.
Les opérations de copier-coller sont généralement sources d'erreurs et prennent beaucoup de temps. C'est souvent au cours de ces opérations déjà longues qu'un membre de l'équipe se rend compte qu'il a omis une propriété d'un élément de travail pour laquelle il a besoin de l'avis des parties prenantes.
Dans ce cas, l'utilisation du module FAQ signifie que la liste de questions est déjà disponible dans votre projet Azure DevOps. Lorsque vous poserez votre question à votre partie prenante, vous pourrez y répondre dans votre liste de questions FAQ, ce qui créera automatiquement une exigence pour vous.
Vous pouvez alors ouvrir directement cette exigence et poser toutes les questions complémentaires qui vous viennent à l'esprit pendant que vous êtes encore en présence de votre partie prenante. Cela permet de gagner du temps et rend le processus de collecte d'exigences plus approfondi, tout en évitant à votre équipe de passer à côté d'occasions d'obtenir les bonnes informations au bon moment.
CAS D'UTILISATION 2
Mon équipe travaille dans un environnement soumis à des réglementations et nous devons nous assurer que nous mettons en place l'ensemble des mesures nécessaires pour rester en conformité et pouvoir faire l'objet d'un audit.
L'un des principaux atouts du module FAQ réside dans le fait que vous pouvez utiliser bon nombre de nos modèles prédéfinis liés à la conformité pour recenser les besoins. Ces modèles ont été élaborés en collaboration avec bon nombre de nos clients actuels, ainsi qu'en partenariat avec des experts reconnus dans ces domaines.
Dans ce cas, les équipes ayant accès au module FAQ peuvent s'adresser à des experts du domaine et à des consultants afin d'élaborer une liste de questions qui les aidera à définir toutes les exigences nécessaires à la conformité et au respect de la réglementation. Une fois créées, ces listes de questions peuvent être réutilisées dans plusieurs projets et déployées à maintes reprises.
Le module FAQ offre des avantages considérables aux équipes qui en sont à la phase de collecte des exigences de leur projet. Voici quelques exemples d'utilisation de ce module pour favoriser la réussite de votre projet.
Utilisez les modèles de listes de questions prédéfinis
Lorsque les utilisateurs ont besoin d'un modèle concernant les exigences non fonctionnelles ou les normes ISO, ils peuvent se lancer rapidement en utilisant l'un de nos modèles intégrés. Ces modèles contiennent déjà bon nombre des questions les plus importantes relatives à ces sujets. Les utilisateurs peuvent partir d'un modèle prédéfini, supprimer les questions qui ne sont pas pertinentes et/ou ajouter de nouvelles questions si nécessaire.
Créez vos propres modèles de listes de questions
Si l'un de nos modèles prédéfinis ne répond pas à vos besoins, vos équipes peuvent facilement créer des listes de questions à partir de zéro. En partant d'un modèle vierge, votre équipe peut facilement élaborer un ensemble complet de questions qui facilitent et optimisent le processus de recueil des exigences.
Une fois la liste de questions établie, elle peut être réutilisée dans différents projets pour vous aider lors de la phase de collecte d'informations ultérieure.
Créez des listes de questions destinées aux membres les moins expérimentés de votre équipe
En établissant des listes de questions, vous offrez un véritable guide à tout membre qui serait moins familier avec un domaine, une solution ou un système. Ces listes constituent alors un excellent outil pour accompagner les analystes métier débutants, ou les analystes métier expérimentés issus d’un autre domaine, pendant la phase de collecte des exigences. Les équipes comprennent que la qualité des questions que nous posons au début d’un projet se répercute directement sur la qualité des exigences que nous recueillons.
En créant des listes de questions à l'aide de notre module FAQ, vous vous assurez d'obtenir dès le départ les spécifications les plus précises possibles.
Dans cet article, nous présentons certaines des fonctionnalités supplémentaires disponibles dans l'édition Enterprise Plus de Modern Requirements4DevOps. Ces fonctionnalités sont appelées « MR Services ».
Lire la suite
Dans cet article, vous découvrirez comment documenter les exigences non fonctionnelles, dans le but de mieux comprendre ce qu'est la documentation et pourquoi nous élaborons des documents.
La documentation constitue un élément essentiel du processus de gestion des exigences. Un document a pour objectif de fournir des informations spécifiques sur un projet afin de les partager avec les parties prenantes. À l'instar de nombreux aspects de la gestion des exigences, la documentation n'est pas un processus standardisé. Les équipes abordent la documentation de différentes manières. La manière dont les documents sont mis en œuvre au sein d'un processus, le moment choisi et les types de documents utilisés varient d'une équipe à l'autre. Si la documentation fait toutefois partie de votre processus, vous créerez probablement divers types de documents et des révisions de ces documents tout au long du cycle de vie d'un projet.
TABLE DES MATIÈRES
L'objectif principal de la documentation est d'informer. Elle présente toutefois certains avantages indirects. Par exemple, elle permet de garantir la responsabilité. Les documents constituent un moyen simple de s'assurer que l'on respecte les exigences convenues. Du point de vue des parties prenantes, la documentation apporte une certaine sécurité, car ces documents servent de liste de contrôle pour les exigences convenues. Elle peut être utilisée pour vérifier si le travail n'a pas été achevé ou si ce qui est livré correspond bien à ce qui a été payé.
Un autre avantage de la documentation est qu'elle permet aux équipes de suivre l'évolution du périmètre des exigences tout au long du cycle de vie d'un projet. Au fil du temps, les exigences évoluent. Une exigence particulière, par exemple, peut se préciser au fur et à mesure que le projet avance. À mesure que les documents sont créés ou mis à jour au cours du projet, il est possible de comparer les exigences entre les différentes versions. Cela permet aux membres d'une équipe d'identifier les exigences qui s'écartent de leur périmètre initial.
Il n'existe pas de document standardisé spécialement conçu pour les exigences non fonctionnelles. Cela ne signifie toutefois pas que vous ne pouvez pas créer une documentation spécifique aux exigences non fonctionnelles dans le cadre de votre propre processus. En général, les exigences non fonctionnelles sont plutôt intégrées dans un type de document plus large.
Il existe plusieurs documents de spécifications conçus pour mettre en évidence des aspects spécifiques d'un projet. Par exemple, on peut élaborer des documents relatifs aux spécifications métier (BRD), aux spécifications techniques (TRD) et à de nombreux autres aspects de la gestion des spécifications.
En ce qui concerne le processus de documentation, les exigences non fonctionnelles sont généralement intégrées dans les documents relatifs aux exigences fonctionnelles (FRD), aux exigences du produit (PRD) et aux spécifications des exigences logicielles (SRS).
Examinons brièvement quelques-uns des types de documents mentionnés ci-dessus qui contiennent des exigences non fonctionnelles, afin de mieux comprendre pourquoi ces documents sont élaborés.
Le cahier des charges fonctionnels est un document officiel qui définit les exigences fonctionnelles d'une application. Il est généralement rédigé par un analyste métier à l'issue de plusieurs échanges avec les clients et les parties prenantes, dans le but de recenser les besoins. La rédaction du cahier des charges fonctionnels s'effectue sous la supervision du chef de projet.
Les exigences non fonctionnelles figurent généralement dans une section distincte du document de définition des exigences (FRD). Cette section suit généralement les exigences fonctionnelles et porte le titre « Exigences non fonctionnelles ». Cependant, dans certains documents, les exigences non fonctionnelles peuvent être classées par attributs du système (par exemple sous « Exigences opérationnelles ») ou répertoriées sous des termes tels que « Exigences non commerciales ».
Le cahier des charges du produit est généralement rédigé par le chef de projet. Il sert à indiquer aux équipes de test et de développement quelles fonctionnalités doivent figurer dans une version du produit.
Gardez à l'esprit la distinction entre les exigences fonctionnelles et non fonctionnelles. Les exigences non fonctionnelles ne définissent pas directement ce qu'un produit doit faire. Elles portent sur les caractéristiques du produit qui déterminent son ergonomie, ainsi que sur d'autres spécifications techniques qui contribuent à l'expérience utilisateur. Les documents d'exigences produit (PRD) sont détaillés. L'objectif de ces documents est de définir l'orientation générale du produit. C'est pourquoi les exigences fonctionnelles et non fonctionnelles sont traitées dans des sections distinctes du PRD.
Un cahier des charges système (SRS) est rédigé afin d'illustrer et de décrire les fonctionnalités et les comportements d'un logiciel ou d'un système. Dans la plupart des cas, ces documents sont rédigés par des architectes système ou des chefs de produit, qui sont des experts dans le domaine concerné. Toutefois, lors de la phase initiale de collecte des exigences, les chefs de produit travaillent en étroite collaboration avec les clients.
Les exigences non fonctionnelles figurent à nouveau dans une section distincte du cahier des charges du système.
Le véritable problème lié au processus de documentation dans la gestion des exigences réside dans le manque de normalisation. Certains types de documents sont plus courants que d’autres. Cependant, la structure et le contenu de ces documents varient d’une équipe à l’autre. De plus, les équipes ont toujours la possibilité d’aborder la documentation de manière ponctuelle. Comme mentionné précédemment, une équipe pourrait choisir de documenter les exigences non fonctionnelles dans son propre document spécifique.
L'absence de normalisation semble être un avantage qui offre une certaine souplesse dans le processus de documentation. Malheureusement, cette souplesse comporte certains inconvénients. L'absence de normalisation peut entraîner l'omission de certains éléments de travail. En ce qui concerne les exigences non fonctionnelles, cela peut nuire au succès d'un produit, car elles définissent l'expérience utilisateur de celui-ci.
Pour mieux comprendre ce concept, imaginez que vous ayez essayé deux produits similaires. Il y a de fortes chances que vous ayez préféré l'un des deux, même si les deux remplissaient parfaitement leur fonction. Cela s'explique très probablement par le fait que le produit qui vous a séduit offre une meilleure expérience utilisateur. L'expérience utilisateur repose sur des exigences non fonctionnelles. La définition d'exigences non fonctionnelles bien définies, mesurables et vérifiables permet aux équipes d'évaluer rapidement et de manière fiable la réussite de n'importe quel projet.
Le fait d'intégrer les exigences non fonctionnelles dans la documentation leur confère une plus grande visibilité, ce qui facilite leur examen et leur affinement. Cette visibilité peut également influencer la création et l'évolution des exigences fonctionnelles au sein de votre document.
L'outil Smart Docs de Modern Requirement permet aux utilisateurs de créer la structure de leurs documents d'exigences directement au sein de leur environnement Azure DevOps. Lors de la création d'un Smart Doc, les exigences, y compris les exigences non fonctionnelles, peuvent être insérées directement dans le Smart Doc à partir du backlog du projet. De plus, les exigences non fonctionnelles peuvent être rédigées à la volée lors de la création d'un Smart Doc.
Smart Docs est également doté d'un outil complet de gestion des versions qui permet aux utilisateurs de créer une version de leur Smart Doc à tout moment. Grâce à la gestion des versions, les modifications apportées aux éléments de travail, tels que les exigences non fonctionnelles, peuvent être suivies en comparant les versions et exportées sous forme de formulaires de modification.
La gestion des révisions est également intégrée à l'outil Smart Docs. Modern Requirements4DevOps offre une solution unique de révision des applications qui favorise la collaboration au sein de l'équipe pour examiner et réviser les éléments de travail. En lançant des révisions, les membres de l'équipe et les parties prenantes peuvent examiner de manière critique les éléments de travail. En ce qui concerne plus particulièrement les exigences non fonctionnelles, les révisions constituent un élément essentiel du processus de gestion, car ces éléments de travail peuvent servir à évaluer la réussite d'un projet. La possibilité d'effectuer des révisions de manière transparente parallèlement à la création de documents favorise un flux de travail solide axé sur l'élaboration d'exigences bien définies.
Le manque de standardisation au sein de votre processus de documentation vous pose-t-il problème ? Smart Docs apporte une solution à ce problème récurrent dans le secteur grâce à la possibilité de créer des modèles de documents réutilisables. À l'aide de l'outil Meta Template Designer, les utilisateurs de Smart Docs peuvent personnaliser la structure de leurs documents. En créant une structure sur mesure pour leur document, les utilisateurs peuvent décider quels éléments doivent y figurer et à quel endroit ils doivent apparaître. Des modèles de documents structurés et réutilisables garantissent la cohérence et favorisent l'efficacité (en réduisant les retouches sur les documents) au sein du processus de documentation de votre équipe.
Avec Modern Requirements4DevOps, vous pouvez créer des documents d'exigences directement depuis votre environnement Azure DevOps. Découvrez ce document d'exigences fonctionnelles créé avec Smart Docs !
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.
Essayez Modern Requirements dans le cloud ici.
End-to-end requirements management in Azure DevOps.
AI-powered assistance for DevOps workflows.
Autonomous AI agents for DevOps execution.
Real-time data sync across tools and systems.
