Utilisé pour les blogues qui ne figurent pas dans la bannière supérieure de la page de blog, ni dans la section des marques.
Apprenez à gérer efficacement les contrôles de conception des dispositifs médicaux avec Modern Requirements. Optimisez la conformité, les processus et les besoins réglementaires.
Continuer la lecture
Qu’est-ce que Modern Requirements4DevOps? Lisez la suite pour découvrir comment fonctionne Modern Requirements4DevOps — quels problèmes il peut vous aider à résoudre et qui l’utilise, ainsi qu’un aperçu de ses fonctionnalités, prix et intégrations.
Je vais aussi expliquer comment Modern Requirements4DevOps se compare à des outils similaires.
Lisez l’article complet sur Digital Project Manager.
Convivialité, temps de cycle courts, possibilité de rédiger des exigences en ligne, rapports de conformité et réduction des refontes de développement. Ce ne sont là que quelques-unes des expressions utilisées par nos clients pour décrire l’aptitude de plusieurs modules dans l’application Modern Requirements4DevOps. De nouvelles fonctionnalités et améliorations ont été apportées aux modules avec notre version 2020.
Ici, nous partagerons quelques points saillants de certains de nos modules dans Modern Requirements ainsi que quelques améliorations d’outils pour votre commodité. Les modules que nous allons présenter sont :
1. Gestion des droits : Vous avez demandé, et nous avons écouté. Vous pouvez maintenant gérer l’accès utilisateur. Un utilisateur (doit avoir des droits d’administrateur de collection/projet) peut maintenant gérer l’accès utilisateur aux deux modules de Modern Requirements4DevOps, ainsi qu’aux fonctionnalités de chaque module. Définir ces permissions, c’est aussi simple que de faire un-deux-trois... Étapes pour définir les permissions :
Voici ce que vous verrez :
Depuis cet écran, vous pourrez définir les permissions *Groupe et/ou *Équipe (situées dans le panneau de gauche). Il y a deux façons de définir les permissions, vous pouvez le faire soit dans « *Paramètres communs », soit dans « *Modern Requirements4DevOps Modules » individuellement (situé dans le panneau droit de l’onglet permissions). Ici, vous pouvez définir les permissions pour les fonctionnalités de chaque module.
Les options d’autorisation disponibles sont :
Actuellement, la gestion des droits est prise en charge pour trois modules : Smart Docs, Baseline et Reporting.
Pour plus de détails sur les nouveautés de la gestion des droits et de ses fonctionnalités, veuillez consulter la vidéo.
2. Améliorations de la révision : Le module d’évaluation vous permet de communiquer, d’examiner et d’approuver dans l’environnement du projet et de faciliter le changement au besoin. Des améliorations ont été apportées au module de Révision. Voici une liste de quelques-unes des nouvelles fonctionnalités :
Droits en lecture seule pour les non-participants à la révision : Avec cette amélioration, vous avez maintenant la possibilité de configurer des droits pour les non-participants afin qu’ils puissent consulter les détails de la révision en mode lecture seule.
Utilisateurs non participants : Des utilisateurs qui ne sont ni l’apponteur ni l’évaluateur.
Génération automatique en masse des rapports d’audit d’avis : Cette amélioration vous permettra de générer des rapports d’audit de toutes les évaluations d’un projet en même temps, en bloc ou par projet à partir du panneau d’administration.
Vous pouvez sélectionner des projets et fournir des détails ici pour générer automatiquement les rapports d’audit de leurs examens existants
Format des rapports d’audit – Word/PDF : Le système vous permet maintenant de choisir le format dans lequel vous souhaitez générer les rapports d’audit. Vous pouvez choisir soit la version Word, soit la version PDF.
Le but du rapport d’audit d’approbation est de fournir les détails de tous les éléments de travail dans une révision. Il fournit un statut complet concernant qui a approuvé ou rejeté les travaux d’évaluation ainsi que les commentaires et décisions
Pour plus de détails sur les nouveautés de la gestion des critiques et ses fonctionnalités, veuillez consulter la vidéo.
3. Améliorations de Smart Docs : Smart Docs est un outil qui comble le fossé entre la gestion des documents et de l’information en rédigeant les exigences dans une vue de document en ligne. De nouvelles fonctionnalités ont été ajoutées à Smart Docs, voici quelques points saillants :
Support plein écran : Pour offrir une meilleure expérience utilisateur et un écran plus grand, vous pouvez maintenant consulter Smart Docs en plein écran. Cela signifie une meilleure vue lors de la création de vos documents de demande en ligne.
Mise à jour de l’interface utilisateur du panneau droit :
Mise à jour des propriétés parentales : Il s’agit d’une mise à jour où, par défaut, la case à cocher pour hériter des propriétés de l’objet parent dans l’élément d’œuvre enfant sera affichée « non cochée ».
Note : Si aucune propriété n’est sélectionnée dans l’option déroulante, aucune propriété ne sera héritée dans l’élément de travail enfant.
Pour plus de détails sur les nouveautés de Smart Docs et ses fonctionnalités, veuillez consulter la vidéo.
4. Améliorations des rapports intelligents : Le rapport intelligent permet aux utilisateurs de formater leurs rapports selon la structure des éléments de travail. Il est accessible depuis plusieurs modules ADO et Modern Requirements4DevOps. Voici une liste de certaines des améliorations apportées au module Smart Report :
Téléverser un modèle Word activé par macros : Smart Report vous permet maintenant de téléverser et d’exécuter des fichiers Word compatibles macros (.docm) ainsi que des fichiers Macro-Enabled Word Template (.dotm) dans Smart Report via « Télécharger un modèle Word ». Cela rendra votre option conviviale de téléchargement de modèles Word encore plus facile.
Conservez la sélection du dernier modèle Word téléchargé : Devinez quoi... Smart rReport est maintenant devenu plus intelligent, il conservera maintenant la dernière sélection que vous avez faite en téléversant votre modèle Word.
Conserver la sélection de la dernière partie intelligente : Eh bien, on ne s’est pas arrêtés à se souvenir de la dernière sélection pour le modèle Word... Des améliorations ont été apportées et le système conservera désormais aussi la sélection de votre dernière partie Smart Report. Eh bien, c’est un succès pour les créateurs de rapports.
Pour plus de détails sur les nouveautés de Smart Reports et ses fonctionnalités, veuillez consulter la vidéo.
5. Améliorations de base : De base vous permet de prendre un instantané de vos besoins à un moment donné afin de mieux contrôler et de suivre les changements. Voici comment cela rendra votre expérience de travail encore meilleure :
Conservez la sélection d’éléments de travail lors du changement d’onglet : Le système se souviendra maintenant de la dernière sélection d’élément de travail lorsqu’il navigue entre différents onglets dans la ligne de base. Qu’est-ce que ça veut dire? Eh bien, en travaillant avec une ligne de base (surtout avec une grande), naviguez dans l’onglet Comparer ou Détails et revenez à l’onglet Vue si vous avez oublié avec quel élément de travail vous travailliez... Ne t’inquiète plus, parce que le système s’en souviendra pour toi.
ID de comparaison sur la comparaison de référence : Des améliorations ont été apportées pour que vous puissiez maintenant voir les révisions d’éléments de travail uniquement lorsque les éléments de travail 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 identifiant de révision ne sera affiché, mais « - » sera affiché dans Rev.ID ou Comp.Rev.ID colonne. Cette règle sera également appliquée dans le rapport de différence.
Pour plus de détails sur les nouveautés de Baseline et ses fonctionnalités, veuillez consulter la vidéo.
6. MatCal (Nouveau) : Une nouvelle fonctionnalité a été introduite dans Modern Requirements pour effectuer des expressions mathématiques et logiques. Ça a l’air excitant? Eh bien, nous sommes enthousiastes à ce sujet. Voici pourquoi :
Ce que vous devez faire : Fournissez vos formules à un membre de l’équipe de réussite client de Modern Requirements et nous serons heureux de les configurer en votre nom.
Pour plus de détails sur MatCal et ses fonctionnalités, veuillez consulter la vidéo.
Nous sommes ravis d’annoncer que Modern Requirements4DevOps 2020 est maintenant disponible en téléchargement!
La gestion des droits est une nouvelle fonctionnalité de la version MR2020 pour contrôler l’accès des utilisateurs. L’administrateur de projet peut accorder ou refuser à un groupe d’utilisateurs l’accès à un module MR et à ses fonctionnalités. Actuellement, la gestion des droits est disponible pour trois modules MR : Smart Docs, Baseline et Reporting.
Des permissions flexibles et personnalisables permettent aux équipes de projet de maintenir l’équilibre approprié entre collaboration et contrôle.
Chaque fois qu’un changement de permission a lieu ici, il aura un impact immédiat sur chaque équipe ou groupe d’utilisateurs à qui les permissions sont attribuées. Cela garantit que les paramètres de permissions peuvent être facilement mis à jour et maintenus au fur et à mesure que les projets progressent et que les équipes changent de rôle.
La gestion des droits est accessible depuis l’extension Modern Requirements4DevOps dans Paramètres du projet.
Les fonctionnalités disponibles pour lesquelles vous pouvez définir des permissions varient d’un module à l’autre.
Les caractéristiques de groupe disponibles sont les suivantes :
Il y a généralement trois types d’accès aux permissions à choisir pour chaque fonctionnalité de groupe :
« Permets »
« Nier »
« Non Réglé »
Teams/Groups peuvent automatiquement hériter des paramètres d’autorisation des Teams/Groups parent. Les paramètres des permissions modifiés explicitement dans les équipes/groupes enfants peuvent écraser les permissions héritées des équipes/groupes parents. Gardez en tête les règles suivantes :
Lorsque le même utilisateur existe dans plus d’une équipe/groupe, les règles suivantes s’appliquent :
MatCal est une fonctionnalité de Modern Requirement4DevOps utilisée pour effectuer des expressions mathématiques et logiques sur des éléments de travail.
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.
Business Value and Priority are properties of work item Feature. Normally, high Business Value leads to high Priority.
With the right configuration, MatCal could help you manage the relationship by automatically assigning Priority value based on the Business Value input.
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
Verification checks a product against its requirements; validation checks it...
A use case describes how a user interacts with a...
Traceability in Azure DevOps links work items to code and...
Azure DevOps est une plateforme incroyable qui offre une source unique de vérité.
Pour de nombreuses équipes, cette seule affirmation suffit à envisager d’utiliser la plateforme ALM leader mondiale pour la gestion des exigences. Pouvoir lier les tâches de développement aux exigences, et celles-ci aux cas de test, est difficile à manquer.
Mais que se passe-t-il si vous n’avez pas besoin de toutes les fonctionnalités d’une plateforme ALM complète?
Et si vous n’avez besoin que d’une solution pour vos besoins en gestion des exigences?
Vous pouvez utiliser toutes les fonctionnalités riches de Modern Requirements4DevOps pour transformer votre projet Azure DevOps en une solution complète de gestion des exigences. L’une de ces fonctionnalités est la possibilité de réutiliser les exigences à travers différents projets, collections et serveurs à l’aide de l’outil Modern Requirements4DevOps Reuse.
Vous cherchez à réutiliser les exigences?
Tu es au bon endroit.
Ce que vous apprendrez dans ce court article :
Quand on parle des avantages de la réutilisation des exigences, il y a une chose qui doit d’abord être abordée.
La question la plus fréquente que je reçois des équipes matérielles est : « Comment cela pourrait-il bénéficier aux équipes qui ne sont pas liées au logiciel? »
Donc, avant de commencer, la réutilisation des exigences ne concerne pas seulement les équipes logicielles.
La réutilisation des exigences est un sujet qui attire souvent l’attention des gens.
Cela s’explique par le fait que, dans l’économie mondiale, nous voyons des entreprises se concentrer sur un domaine ou des domaines donnés au sein de certaines industries. Cela conduit des entreprises à développer des produits dans un domaine précis, ou autour d’une solution donnée, et à vraiment cibler les quelques domaines dans lesquels elles peuvent vraiment réussir.
Cela signifie qu’en construisant des projets, des solutions ou des systèmes, une équipe peut souvent réutiliser des éléments d’un projet précédent. C’est là que la réutilisation des exigences entre en jeu.
En permettant à une équipe de réutiliser ces exigences dans le prochain projet, elle peut réduire les frais généraux nécessaires pour démarrer un nouveau projet.
Pour certaines personnes, cela peut déjà être évident.
Ce qui n’est peut-être pas évident, cependant, c’est que la réutilisation peut aussi être un excellent moyen de gérer des exigences qui dépassent le niveau du projet. Cela inclurait les exigences non fonctionnelles ou les risques qui doivent être considérés comme un mandat à l’échelle de l’entreprise. Cela irait même jusqu’à permettre à votre équipe de réutiliser des exigences dont le but est strictement réglementaire ou axé sur la conformité. Cette fonctionnalité peut être étendue aux équipes logicielles et matérielles et peut même aider les équipes de produit dédiées à un composant physique ou à un livrable.
Réutiliser les exigences par référence est un moyen rapide d’introduire les exigences existantes dans votre projet simplement en créant des liens avec elles. En faisant cela, vous pourriez avoir un accès direct à ces éléments de travail et revoir tout le contenu associé, les liens et les pièces jointes sans les copier réellement dans ou entre projets.
Dans Azure DevOps, il y a très peu de fonctionnalités pour copier les besoins ou autres tâches d’un projet à un autre. Mais lorsque vous ajoutez Modern Requirements4DevOps à votre environnement Azure DevOps, la réutilisation des exigences atteint son plein potentiel.
Lorsqu’on discute des exigences de réutilisation par copie, il y a trois approches principales à considérer.
Après avoir regardé les vidéos ci-dessus, il est évident que l’outil de réutilisation Modern Requirements4DevOps est efficace pour réutiliser les besoins.
Il offre un contrôle total sur les exigences que vous choisissez de réutiliser, vous permet d’appliquer des personnalisations à ces exigences et vous permet de lier les exigences à l’élément du travail source.
Cela signifie que, peu importe où vous souhaitez envoyer les exigences, vous pouvez le faire en utilisant l’outil Modern Requirements4DevOps Reuse. Mais il y a des façons d’utiliser l’outil de réutilisation plus efficacement.
La première mention notable est en associant l’outil de réutilisation à l’outil Modern Requirements4DevOps Baseline.
Qu’est-ce qu’une référence?
Beaucoup d’équipes utilisent des lignes de base d’exigences sans même s’en rendre compte.
Une référence est un instantané des éléments de travail à un moment donné.
Pour de nombreuses équipes, ils utilisent simplement des versions de documents Microsoft Word comme référence.
Lorsqu’on parle de capturer les besoins à un moment donné, il y a plusieurs raisons pour lesquelles la fonctionnalité Modern Requirements4DevOps est meilleure que l’approche traditionnelle de Microsoft Word. Avec Modern Requirements4DevOps Baselines, vous pouvez enregistrer un ensemble d’éléments de travail tels qu’ils étaient à la date de votre choix.
Cela signifie que si vous voulez enregistrer vos exigences telles qu’elles étaient il y a deux semaines, vous pouvez facilement créer une référence pour ces exigences à cette date. Cela se prête directement aux avantages de l’outil de réutilisation ajouté par Modern Requirements4DevOps.
En combinant l’outil de Réutilisation avec notre Baseline, vous pouvez non seulement choisir l’ensemble d’exigences que vous souhaitez réutiliser, mais aussi la version de ces exigences. Cela vous permet d’appliquer la meilleure et la plus appropriée version de vos besoins à votre prochain projet.
La prochaine mention notable est d’utiliser efficacement le préfixe / postfixe / et d’autres opérations lors de la réutilisation des exigences.
Lors de la réutilisation des exigences, l’outil Modern Requirements4DevOps Reuse vous permet de personnaliser la façon dont les exigences réutilisées apparaîtront dans leur projet de destination.
L’écran qui vous permet de faire cela peut être vu ci-dessous :
Utiliser la fonctionnalité ci-dessus vous permettra d’ajouter facilement un préfixe ou un postfixe aux exigences une fois qu’ils atteignent votre projet de destination choisi. Comme vu plus haut, vous pouvez aussi choisir d’envoyer ces exigences à un chemin de zone spécifique (comme le matériel ou le logiciel, par exemple), ou même dans une itération donnée afin de décider quand ces exigences seront prises en charge.
La fonctionnalité la plus couramment utilisée dans les options de champ, cependant, est la possibilité d’ajouter une balise.
Souvent, lorsque vous envoyez des exigences d’un projet à un autre, vous voulez pouvoir facilement identifier et retracer ces exigences dans votre projet de destination. Ajouter une étiquette vous permettra de le faire.
Quel est le lien avec l’option Source Work Item?
Cette option vous permet d’établir un lien entre l’élément de travail que vous réutilisez et celui que vous créez dans votre projet de destination.
Quel lien cela crée-t-il?
Il relie votre nouvel élément de travail de destination à votre œuvre original via le lien « Apparenté » ou tout type de lien que vous avez configuré dans la zone d’administration.
Dans l’image ci-dessous, vous pouvez voir un cas de test que j’ai copié d’un projet à l’autre, en utilisant à la fois le préfixe « CL- » et les options « Lien vers l’élément de travail source ».
Using the “Link to source work item” feature allows you to easily trace requirements back to where they were pulled from. While there are many use cases for this feature when moving requirements directly from project to project, this more advanced use cases are for when you are moving requirements from a library or repository into a project instead.
Baseline est un outil très utile, peu importe si vous voulez réutiliser un seul élément de travail ou une longue liste de travaux de votre projet ou bibliothèque source. Dans Exigences Modernes, vous pouviez créer des liens entre vos éléments d’œuvres sources et copiés afin de localiser l’origine de ces éléments copiés.
Bien qu’il y ait des liens entre les deux, les éléments de l’œuvre copiés sont toujours considérés comme indépendants des éléments de l’œuvre source, ce qui signifie que tout changement que vous faites aux éléments copiés ou à l’œuvre source n’affectera pas leur équivalent.
Vous pourriez demander : comment synchroniser les changements quand c’est nécessaire? Supposons que vous ayez une bibliothèque où tous vos éléments de conception sont sauvegardés, et que vous les avez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certains designs dans la bibliothèque et que vous voulez que toutes les spécifications de conception copiées soient synchronisées, vous pouvez simplement utiliser la fonctionnalité de fusion, qui se trouve sous Source/Copied Baseline(s) ou Target Copied Baseline(s) dans l’onglet Détails du module Baseline.
Baseline est un outil très utile, peu importe si vous voulez réutiliser un seul élément de travail ou une longue liste de travaux de votre projet ou bibliothèque source. Dans Exigences Modernes, vous pouviez créer des liens entre vos éléments d’œuvres sources et copiés afin de localiser l’origine de ces éléments copiés.
Bien qu’il y ait des liens entre les deux, les éléments de l’œuvre copiés sont toujours considérés comme indépendants des éléments de l’œuvre source, ce qui signifie que tout changement que vous faites aux éléments copiés ou à l’œuvre source n’affectera pas leur équivalent.
Vous pourriez demander : comment synchroniser les changements quand c’est nécessaire? Supposons que vous ayez une bibliothèque où tous vos éléments de conception sont sauvegardés, et que vous les avez réutilisés dans 5 projets différents. Si vous devez maintenant modifier certains designs dans la bibliothèque et que vous voulez que toutes les spécifications de conception copiées soient synchronisées, vous pouvez simplement utiliser la fonctionnalité de fusion, qui se trouve sous Source/Copied Baseline(s) ou Target Copied Baseline(s) dans l’onglet Détails du module Baseline.
Vous vous souvenez encore de la définition d’une référence? Un instantané des éléments de travail sélectionnés à un moment donné. Donc, peu importe les changements que nous avons apportés aux éléments de travail de base, l’instantané sauvegardé ne changera pas. Donc, même si on a fusionné les bases de base, les changements sont faits sur les dernières versions des éléments de travail, pas sur les bases elles-mêmes. Ça semble un peu difficile à comprendre?
Veuillez regarder la vidéo de 5 minutes Merge Copied Baselines.
Essayez Modern Requirements4DevOps gratuitement dès aujourd’hui.
Nous vous offrons la possibilité d’essayer notre solution de gestion des exigences dans votre propre environnement Azure DevOps, ou dans un environnement que nous fournissons incluant des données d’échantillons.
Verification checks a product against its requirements; validation checks it...
A use case describes how a user interacts with a...
Traceability in Azure DevOps links work items to code and...
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 :
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 :
Dans cette vidéo, nous expliquons comment votre équipe peut utiliser les capacités d’importation offertes par l’onglet Excel Team.
La deuxième façon d’importer les exigences dans votre projet est via Microsoft Word.
Cette fonctionnalité est une « fonctionnalité d’aperçu » disponible avec n’importe quelle licence Enterprise Plus Modern Requirements4DevOps. Cela signifie que tout utilisateur de votre organisation disposant d’une licence Enterprise Plus pourra accéder et utiliser la fonction d’importation de Word.
Si vous n’utilisez pas actuellement Modern Requirements4DevOps, vous pouvez essayer cette fonction d’importation de mots en essayant Modern Requirements4DevOps dès aujourd’hui!
Alors, comment fonctionne l’importation de mots?
Avertissement : En tant que fonction de prévisualisation, vous devez vous attendre à ce que ce ne soit pas la solution la plus jolie, et qu’il faudra généralement des connaissances en codage. Mais pas grand-chose – et si vous pouvez emprunter un développeur familier avec le xml (ou tout autre langage de script) pendant 20 minutes, vous devriez très bien vous en sortir.
L’importation de Word fonctionne en ayant un document Word bien formaté qui utilise différents titres pour représenter les différents éléments de travail / exigences et leurs propriétés dans votre document.
Par exemple, prenons un exemple de BRD que vous avez peut-être déjà au format Word.
Vous avez probablement vos éléments d’introduction, d’aperçu, de portée et d’autres éléments de contexte utilisant le style du titre 1.
Vous pourriez ensuite inclure vos Épopées, Fonctionnalités et Histoires d’utilisateur dans ce document également. Votre document pourrait ressembler à ceci :
Titre 1 – Introduction
-> paragraphe – Tout le texte de l’introduction va ici...
Titre 1 – Aperçu
-> paragraphe –Tout le texte du Résumé est ici...
Cap 1 – Portée
-> paragraphe – Tout le texte du Scope va ici...
Titre 1 – Exigences
-> Titre 2 – Nom d’Epic
–> Titre 3 – Nom de la caractéristique
—> Titre 4 – Nom de l’histoire utilisateur
—-> Paragraphe – Description de l’histoire utilisateur ci-dessus
Maintenant, votre document peut être un peu différent, mais ce n’est pas grave. Les principes que vous allez apprendre sont les mêmes.
L’importation de mots nécessite un document (illustré ci-dessus) et un ensemble de règles (expliqué ci-dessous).
Typiquement, un administrateur crée un ensemble de règles que votre équipe utilisera pour importer les documents, et cela ne devra être fait qu’une seule fois. Donc, si vous avez déjà créé un document et que votre administrateur a créé un système de règles, vous êtes prêt.
Si votre administrateur doit créer un ensemble de règles, lisez la suite.
Créer un ensemble de règles est incroyablement simple et se fait en modifiant un fichier XML.
Le fichier XML que vous créez déterminera comment l’outil d’importation de Word analyse votre document pour :
1) Quelles parties du document sont des éléments de travail?
2) Quelles parties du document sont des propriétés d’un élément de travail donné?
Si vous travaillez là-dessus en temps réel, il pourrait être utile de télécharger ce fichier de règles comme point de départ et de regarder la vidéo suivante :
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.
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.
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!
Dans cet article, nous abordons les caractéristiques et avantages du module FAQ.
Ce module a été conçu pour aider les équipes qui recueillent les exigences au début de leur processus de gestion des exigences. En créant des listes de questions, les équipes peuvent facilement capturer et réutiliser leurs connaissances du processus d’élection pour poser les bonnes questions qui répondent aux meilleures exigences.
Le module FAQ est un dépôt de listes de questions que votre équipe peut construire, modifier, modifier, modeler et utiliser pour obtenir des exigences. En utilisant le module FAQ pour bâtir une base de connaissances pour votre équipe, vous pouvez avoir confiance que chaque membre de l’équipe peut s’engager efficacement avec les parties prenantes.
En construisant le meilleur ensemble de questions dans ce domaine, votre équipe peut s’assurer d’obtenir toujours le meilleur ensemble d’exigences possible.
Le principal avantage de ce module est qu’il permet à votre équipe de bâtir une base de connaissances pouvant être utilisée à la fois par des BA expérimentés et par ceux qui pourraient avoir besoin d’obtenir des exigences dans un domaine inconnu. Le module FAQ est déjà rempli de plus de 3000 questions couvrant de nombreux sujets différents.
Ces sujets incluent plusieurs modèles de conformité ISO, ainsi que des modèles sur des sujets d’exigences non fonctionnelles tels que la scalabilité, la réutilisabilité ou l’opérabilité, qui peuvent être utilisés pour l’élicitation.
Pour de nombreuses équipes, ce module remplacera leurs listes de questions basées sur Excel qu’elles utilisaient auparavant.
Pour rester en ligne avec les autres modules de l’ensemble d’outils Exigences modernes, le module FAQ relie directement ce qui était auparavant un processus déconnecté à votre projet. Cela signifie que vos équipes peuvent facilement ajouter des exigences à votre projet simplement en fournissant des réponses aux questions de votre liste de questions FAQ.
La valeur de notre module FAQ peut être décrite en deux points simples.
En utilisant les connaissances précieuses des BA expérimentés, vous pouvez créer des modèles de questions spécifiques au domaine qui aident à structurer le processus d’élicitation. Cela signifie que vous pouvez envoyer n’importe quel analyste de recherche de n’importe quel niveau d’expérience dans une pièce avec un intervenant et avoir confiance qu’il créera des exigences complètes et applicables.
En n’ayant plus besoin de créer des modèles de questions puis de copier les exigences obtenues dans votre outil de gestion de données, votre équipe peut avancer plus rapidement dans le processus d’élicitation. Cela signifie plus de temps passé à itérer sur des exigences plus précises et moins de temps passé à copier-coller des histoires utilisateur qui auront probablement besoin de plus de travail.
Lorsque nous discutons avec notre communauté de leur utilisation du module FAQ, ils décrivent souvent les façons dont ce module a simplifié leur processus et facilité la navigation de la phase d’élection des projets.
Même avec des équipes qui n’utilisent traditionnellement pas de liste de questions, après avoir rejoint notre communauté, elles nous diront combien de valeur ajoutée elles voient à la capacité de regrouper les connaissances de tous les membres de leur équipe en une liste cohérente.
Voici les cas d’utilisation que nous avons vus pour le module FAQ.
CAS D’UTILISATION 1
Mon équipe recueille actuellement les besoins dès le départ et avance de façon itérative dans notre projet par la suite. Nous utilisons actuellement Excel pendant la phase de collecte des exigences, mais cela signifie que nous copions les exigences dans notre outil de prédilection par la suite.
En étant une équipe qui recueille les exigences dès le départ, cela offre une occasion parfaite d’utiliser une liste de questions conçue pour ce domaine. Mais utiliser Excel comme moyen de faciliter cette liste de questions est une recette pour un long processus de copier-coller plus tard.
Les processus de copier/coller sont généralement sujets aux erreurs et longs. C’est souvent, lors de ces processus déjà longs de copier/coller, qu’un membre de l’équipe reconnaît qu’il a oublié une propriété d’un poste de travail sur laquelle il a besoin de l’avis des parties prenantes.
Dans ce cas, utiliser le module FAQ signifie que vous aurez déjà la liste des questions dans votre projet Azure DevOps. Lorsque vous posez votre question à votre partie prenante, vous pourrez y répondre dans votre liste de questions FAQ, ce qui créera automatiquement une exigence pour vous.
Vous pouvez ensuite ouvrir cette exigence directement et poursuivre les questions de suivi que vous pourriez avoir pendant que vous êtes encore avec votre partie prenante. Cela fait gagner du temps et rend le processus d’électorat plus complet, tout en empêchant votre équipe de manquer des occasions d’obtenir la bonne information au bon moment.
CAS D’UTILISATION 2
Mon équipe travaille dans un domaine conforme/réglementé et nous devons nous assurer de construire l’ensemble complet des exigences pour rester conformes et auditables.
L’une des meilleures fonctionnalités du module FAQ est que vous pouvez utiliser plusieurs de nos modèles préconçus liés à la conformité pour obtenir des exigences. Nos modèles préconçus ont été créés en partenariat avec plusieurs de nos clients existants, ainsi que grâce à des partenariats avec des leaders d’opinion dans ces domaines.
Dans ce cas, les équipes ayant accès au module FAQ peuvent parler à des experts du domaine et des consultants et constituer la liste de questions qui les aidera à établir toutes les exigences nécessaires à la conformité et à la réglementation. Une fois créées, ces listes de questions peuvent être réutilisées dans plusieurs projets et déployées encore et encore.
Le module FAQ offre des avantages incroyables aux équipes dans la phase d’électtion de leur projet. Voici quelques façons d’utiliser le module pour faciliter la réussite de votre projet.
Utilisez les modèles de liste de questions préconstruits
Lorsque les utilisateurs ont besoin d’un modèle sur les exigences non fonctionnelles ou sur des sujets ISO, ils peuvent commencer rapidement en utilisant l’un de nos modèles intégrés. Ces modèles contiennent déjà plusieurs des questions les plus importantes sur ces sujets. Les utilisateurs peuvent commencer avec un modèle préconstruit et supprimer les questions non pertinentes et/ou ajouter de nouvelles questions nécessaires.
Créez vos propres modèles de liste de questions
Si l’un de nos modèles préconçus ne répond pas à vos besoins, les équipes peuvent facilement constituer des listes de questions à partir de zéro. En commençant par un modèle vierge, votre équipe peut facilement constituer un ensemble complet de questions qui rendent l’obtention des besoins un processus simple et plus efficace.
Une fois la liste de questions établie, elle peut être réutilisée entre les projets pour aider à la phase d’évinction ultérieure.
Créez des listes de questions pour des membres moins expérimentés de votre équipe
En constituant des listes de questions, vous offrez effectivement des conseils à tout membre qui pourrait être moins familier avec un domaine, une solution ou un système. Ces listes sont alors un excellent outil pour guider les nouveaux BA ou les BA expérimentés d’un autre domaine, durant la phase d’elicitation. Les équipes comprennent que la qualité des questions que nous posons au début d’un projet se reflète directement dans la qualité des exigences que nous suscitons.
En constituant des listes de questions avec notre module FAQ, vous pouvez vous assurer d’obtenir les meilleures exigences possibles dès la première fois.
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.
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é.
TABLE DES MATIÈRES
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.
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.
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.
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 :
Chacune de ces techniques a deux points communs.
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.
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?
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.
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.
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.
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.
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.
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.
Réduction de 50% des efforts de l’UAT
80% de gain de temps sur la création d’une analyse de traces
Réduction significative des délais d’approbation
50% des besoins d’amélioration de la productivité
Réduction de 10 fois dans la refonte du développement
Réduction de 40% des efforts de rapport sur la conformité
Dans cet article, vous explorerez la documentation des exigences non fonctionnelles dans le but de mieux comprendre ce qu’est la documentation et pourquoi nous construisons des documents.
La documentation est une partie importante du processus de gestion des exigences. Le but d’un document est de fournir des informations spécifiques sur un projet à partager avec les parties prenantes. Comme beaucoup d’aspects de la gestion des exigences, la documentation n’est pas un processus standardisé. Les équipes abordent la documentation de plusieurs façons. La façon, le moment et les documents qui sont mis en œuvre dans un processus varient d’une équipe à l’autre. Cependant, si la documentation fait partie de votre processus, vous créerez probablement une variété de types de documents et des révisions de ces documents tout au long de la durée de vie d’un projet.
TABLE DES MATIÈRES
Le but principal de la documentation est d’informer. Cependant, la documentation présente certains avantages indirects. Par exemple, la documentation assure la reddition de comptes. Les documents sont un moyen simple de créer une responsabilité pour vous-même afin de respecter les exigences convenues. Du point de vue des parties prenantes, la documentation ajoute un certain niveau de sécurité puisque ces documents servent de liste de vérification pour les exigences convenues. La documentation peut être utilisée pour vérifier si le travail n’a pas été terminé ou si le travail est livré ce pour quoi a été payé.
Un autre avantage de la documentation est qu’elle permet aux équipes de surveiller la portée des besoins tout au long de la durée d’un projet. Au fil de la durée de vie d’un projet, les exigences évoluent. Une exigence individuelle, par exemple, peut devenir plus clairement définie plus tard dans sa vie. Au fur et à mesure que les documents sont recréés ou mis à jour au cours du projet, les exigences peuvent être comparées entre les versions des documents. Cela permet aux membres d’une équipe d’identifier des exigences qui pourraient s’écarter de leur portée initiale.
Il n’existe pas de document standardisé conçu spécifiquement pour les exigences non fonctionnelles. Cependant, cela ne signifie pas que vous ne pouvez pas construire une documentation spécifique non fonctionnelle dans votre propre processus. À la place, les exigences non fonctionnelles sont généralement incluses dans un type de document plus vaste.
Plusieurs documents d’exigences existent, conçus pour mettre en valeur des détails précis d’un projet. Par exemple, des documents peuvent être créés pour les exigences d’affaires (BRD), les exigences techniques (TRD) et de nombreux autres aspects de la gestion des exigences.
En ce qui concerne le processus de documentation, les exigences non fonctionnelles sont généralement incluses dans les documents d’exigences fonctionnelles (FRD), les documents d’exigences produit (PRD) et les spécifications des exigences logicielles (SRS).
Jetons un coup d’œil de base à quelques-uns des types de documents mentionnés ci-dessus qui incluent des exigences non fonctionnelles afin de mieux comprendre pourquoi ces documents sont créés.
Le Document des exigences fonctionnelles est une déclaration formelle des exigences fonctionnelles d’une application. Un FRD est généralement établi par un analyste d’affaires basé sur plusieurs interactions avec les clients et les parties prenantes, dans le but d’obtenir des exigences. La création du FRD se fait sous la supervision du gestionnaire de projet.
Les exigences non fonctionnelles se trouvent généralement dans leur propre section dans un FRD. Cette section suit habituellement les exigences fonctionnelles et sera étiquetée « exigences non fonctionnelles ». Cependant, dans certains documents, les exigences non fonctionnelles peuvent être catégorisées selon les attributs du système (comme « exigences opérationnelles ») ou listées sous des termes comme « exigences non commerciales ».
Le document des exigences du produit est généralement rédigé par le gestionnaire de projet. Le PRD sert à communiquer aux équipes de test et de développement quelles fonctionnalités doivent être présentes dans une version produit.
Gardez en tête les différences entre les exigences fonctionnelles et non fonctionnelles. Les exigences non fonctionnelles ne dirigent pas un produit sur ce que le produit devrait faire. Ils traitent des attributs du produit qui déterminent la sensation d’un produit et d’autres spécifications techniques qui contribuent à l’expérience utilisateur. Les documents d’exigences produits sont détaillés. L’objectif de ces documents est de fournir l’orientation générale du produit. Par conséquent, les exigences fonctionnelles et non fonctionnelles sont abordées dans leurs propres sections d’un PRD.
Un document de spécifications des exigences système est créé pour illustrer et décrire les caractéristiques et comportements d’un logiciel ou d’un système. Dans la plupart des cas, les documents SRS sont rédigés par des architectes système ou des propriétaires de produit experts dans le domaine. Cependant, lors du processus initial de collecte des exigences, les Product Owners travaillent aux côtés des clients.
Les exigences non fonctionnelles se trouvent à nouveau dans leur propre section du document des spécifications des exigences système.
Le vrai problème avec le processus de documentation en gestion des exigences, c’est le manque de standardisation. 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 façon ponctuelle. Comme mentionné plus tôt, une équipe pourrait aborder la documentation des exigences non fonctionnelles dans son propre document spécifique.
L’absence de standardisation semble être un avantage qui offre de la flexibilité dans le processus de documentation. Malheureusement, cette flexibilité présente certains inconvénients. Le manque de standardisation peut entraîner la non-inclusion des éléments du 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 d’un produit.
Pour mettre cela en perspective, considérez une situation où vous avez essayé deux produits similaires. Il y a de fortes chances que vous ayez préféré l’un des deux produits, même si les deux ont rempli leurs fonctions prévues. C’est très probablement parce que le produit vers lequel vous avez attiré offre une meilleure expérience utilisateur. L’expérience utilisateur est motivée par des exigences non fonctionnelles. Créer des exigences non fonctionnelles, bien définies, mesurables et testables permet aux équipes de mesurer rapidement et de manière définitive le succès de n’importe quel projet.
En incluant des exigences non fonctionnelles dans la documentation, ces exigences offrent une plus grande visibilité pour être examinées et affinées. Cette visibilité peut aussi influencer la création et l’évolution des exigences fonctionnelles dans votre document.
L’outil Smart Docs de Modern Requirements permet aux utilisateurs de construire le cadre de leurs documents d’exigences directement dans 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 équipé d’un outil complet de gestion des versions qui permet aux utilisateurs de modifier leur Smart Doc à tout moment. Grâce à la gestion des versions, les modifications aux éléments de travail comme les exigences non fonctionnelles peuvent être suivies en comparant les versions et exportées sous forme de formulaires de changement.
La gestion des revues est également intégrée à l’outil Smart Docs. Modern Requirements4DevOps offre une solution unique d’évaluation d’applications qui favorise la collaboration au sein de l’équipe pour examiner et réviser les éléments de travail. En lançant des évaluations, les membres de l’équipe et les parties prenantes peuvent examiner de manière critique les tâches requises. En ce qui concerne spécifiquement les exigences non fonctionnelles, les examens sont un élément crucial du processus de gestion, car ces éléments peuvent servir à évaluer le succès d’un projet. Pouvoir effectuer des évaluations de façon fluide parallèlement à la création de documents favorise un flux de travail solide axé sur la création d’exigences bien définies.
Le manque de standardisation dans votre propre processus de documentation est-il problématique? Smart Docs offre une solution à ce problème à l’échelle de l’industrie en permettant de créer des modèles de documents réutilisables. Grâce à l’outil Meta Template Designer, les utilisateurs de Smart Docs peuvent personnaliser la structure de leurs documents. En construisant une structure personnalisée pour votre document, les utilisateurs peuvent décider quels éléments de travail peuvent être inclus et où ils peuvent apparaître dans leur document. Des modèles de documents structurés et réutilisables assurent la cohérence et favorisent l’efficacité (réduisant la refonte des documents) dans le processus de documentation de votre équipe.
Avec Modern Requirements4DevOps , vous pouvez créer des documents d’exigences directement à partir de votre environnement Azure DevOps. Consultez ce document d’exigences fonctionnelles construit avec Smart Docs!
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.
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.
