Réutilisation des exigences

Réutilisation des exigences : un moyen efficace de faciliter la collecte des exigences

Découvrez comment réutiliser les exigences dans Azure DevOps

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 :

  1. Avantages de la réutilisation des exigences
  2. Les deux types d'exigences en matière de réutilisation
  3. Comment exploiter efficacement la réutilisation des exigences

Les avantages de la réutilisation des exigences

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.

 

Les deux types de réutilisation des exigences

Réutilisation des exigences par référence

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.

Réutilisation des exigences par référence

 

Réutilisation des exigences par copie

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.

Réutilisation des exigences par copie

 

Comment réutiliser efficacement les exigences

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. 

Comment fusionner des lignes de base copiées ?

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

Fusionner les lignes de base copiées

 

Vous souhaitez découvrir tout le potentiel de la réutilisation ?

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. 

Importation des exigences dans Azure DevOps

Importation des exigences dans Azure DevOps

Découvrez comment importer facilement des spécifications (et certains éléments) dans votre projet ADO

Lorsque vous migrez vers Azure DevOps, ou lorsque vous travaillez hors ligne sans être connecté à votre projet Azure DevOps existant, vous devez trouver un moyen d'importer vos nouvelles exigences dans Azure DevOps.

De nombreuses équipes sont confrontées au problème de l'intégration dans Azure DevOps des spécifications qu'elles ont créées dans Excel, Word ou d'autres outils. Heureusement, il existe plusieurs méthodes simples pour y parvenir sans avoir à ajouter une longue séance de copier-coller à votre processus ! 

Dans cet article, nous allons passer en revue plusieurs méthodes permettant d'importer des exigences.

L'une de ces options est gratuite, et certaines sont des fonctionnalités disponibles en ajoutant Modern Requirements4DevOps à votre projet Azure DevOps. 

Les thèmes abordés dans cet article sont les suivants :

  1. Importation de données depuis Microsoft Excel
  2. Importation de données depuis Microsoft Word
  3. Importation de diagrammes et de maquettes dans Azure DevOps

Importation de données depuis Microsoft Excel

Que vous disposiez de l'ensemble ou d'une partie de vos exigences existantes dans Excel, ou que vous souhaitiez exporter des exigences depuis un outil interne vers un fichier .csv, il existe un moyen gratuit d'importer vos exigences dans votre projet Azure DevOps. 

Il s'agit d'une solution gratuite, à condition que vous disposiez déjà d'Azure DevOps et d'Excel.

La première étape consiste à vérifier que vous disposez du complément Microsoft Excel intitulé « Team tab ».

Vous pouvez télécharger ce module complémentaire directement ici:

(Sur la page mentionnée ci-dessus, Azure DevOps Office® Integration 2019 figure dans la section « Autres outils, frameworks et composants redistribuables». )

Si vous avez cliqué sur le lien ci-dessus, vous pourrez activer l'onglet « Équipe » dans Excel. 

Une fois activée, cette extension vous permet de relier une feuille Excel directement à un projet donné au sein de votre organisation Azure DevOps. 

Une fois cette fonctionnalité activée, vous disposerez de deux fonctions principales :
1) Vous pourrez publier des exigences dansvotre projet à partir d'Excel
2) Vous pourrez exporter des exigences devotre projet versExcel

Cela signifie que vous pouvez modifier vos exigences depuis l'une ou l'autre des interfaces et synchroniser ces modifications avec votre projet. Par exemple, si vous importez des exigences dans Excel et y apportez des modifications, vous pouvez publier ces modifications pour les répercuter sur les exigences de votre projet. 

Une fois que vous avez exécuté le programme d'installation que vous avez téléchargé, vous êtes prêt à activer l'extension.

Activer l'onglet « Équipe» dans Excel :

  1. Ouvrir Excel
  2. Créer une feuille vierge 
  3. Cliquez sur Fichier
  4. Cliquez sur Options
  5. Cliquez sur « Compléments »
  6. Sélectionnez « Compléments COM » dans le menu déroulant situé vers le bas de la fenêtre
  7. Sélectionnez « Team Foundation Add-In », puis cliquez sur OK. 
Si vous rencontrez des difficultés avec cette procédure, cliquez sur ce lien.
 
Si l'onglet « Équipe » apparaît désormais dans Excel, vous êtes prêt à importer vos exigences ! 

Utilisation de l'onglet « Équipe » dans Excel

Dans cette vidéo, nous vous expliquons comment votre équipe peut utiliser les fonctionnalités d'importation offertes par le complément de l'onglet « Équipe » d'Excel.

Importation de données depuis Microsoft Word

La deuxième méthode pour importer des exigences dans votre projet consiste à utiliser Microsoft Word. 

Cette fonctionnalité est une « fonctionnalité en avant-première » disponible avec toute licence Enterprise Plus de Modern Requirements4DevOps. Cela signifie que tout utilisateur de votre organisation disposant d'une licence Enterprise Plus pourra accéder à la fonctionnalité d'importation de fichiers Word et l'utiliser. 

Si vous n'utilisez pas encore Modern Requirements4DevOps, vous pouvez tester cette fonctionnalité d'importation depuis Word en essayant Modern Requirements4DevOps dès aujourd'hui !

Essayez donc !

Alors, comment fonctionne l'importation depuis Word ? 

Avertissement : comme il s'agit d'une fonctionnalité en avant-première, il ne faut pas s'attendre à ce que ce soit la solution la plus élégante, et cela nécessitera généralement quelques connaissances en programmation. Mais rien de bien compliqué : si vous pouvez faire appel à un développeur familiarisé avec le XML (ou tout autre langage de script) pendant une vingtaine de minutes, tout devrait bien se passer.

L'importation depuis Word fonctionne à partir d'un document Word correctement 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. 

Prenons par exemple un cahier des charges que vous avez peut-être déjà au format Word.

Vous avez probablement rédigé votre introduction, votre aperçu, votre champ d'application et d'autres éléments contextuels en utilisant le style « Titre 1 ». 

Vous pourriez également inclure vos épopées, vos fonctionnalités et vos récits utilisateurs dans ce document.Votre document pourrait ressembler à ceci :

Titre 1 – Introduction
-> Paragraphe – C'estici que va tout le texte de l'introduction…

Titre 1 – Présentation
-> Paragraphe –Tout le texte de la présentation va ici…

Titre 1 – Champ d'application

-> Paragraphe –Tout le texte du champ d'application va ici…

Titre 1 – Exigences
-> Titre 2 – Nom de l'épopée
–> Titre 3 – Nom de la fonctionnalité
—> Titre 4 – Nom de l'histoire utilisateur
—-> Paragraphe – Description de l'histoire utilisateur ci-dessus

Votre document est peut-être un peu différent, mais ce n'est pas grave.Les principes que vous allez découvrir restent les mêmes. 

L'importation depuis Word nécessite un document (illustré ci-dessus) et un ensemble de règles (expliqué ci-dessous).

En général, un administrateur crée un ensemble de règles que votre équipe utilisera pour importer des documents, et cette opération ne doit être effectuée qu'une seule fois.Ainsi, si vous disposez déjà d'un document et que votre administrateur a créé un ensemble de règles, vous êtes prêt à commencer. 

Si votre administrateur doit créer un ensemble de règles, poursuivez votre lecture. 

La création d'un ensemble de règles est extrêmement simple et s'effectue en modifiant un fichier XML.
Le fichier XML que vous créez déterminera la manière dont l'outil d'importation Word analyse votre document pour :
1) Identifier les parties du document qui constituent des éléments de travail ?
2) Identifier les parties du document qui constituent les propriétés d'un élément de travail donné ?

Si vous suivez ce tutoriel en temps réel, il peut être utile de télécharger ce fichier de règles pour commencer et de regarder la vidéo suivante :

Utilisation de l'ensemble de règles d'exemple pour commencer

Dans cette vidéo, nous vous expliquons comment utiliser le fichier de règles type pour importer un document d'exigences simple. N'oubliez pas que la création d'un ensemble de règles est généralement une opération ponctuelle. 

Importation de diagrammes et de maquettes dans Azure DevOps

Les diagrammes, les maquettes et les modèles de cas d'utilisation peuvent constituer des outils extrêmement utiles pour la rédaction et la collecte des exigences. 

C'est pourquoi, grâce à Modern Requirements4DevOps, votre équipe peut facilement créer toutes ces visualisations directement depuis votre projet. Vous bénéficiez ainsi d'un modèle de « source unique de vérité » où tout est intégré à votre projet. 

Mais peut-être disposez-vous déjà de schémas et de maquettes que vous aimeriez ajouter à votre projet Azure DevOps et associer aux exigences. Est-il possible d'importer ces ressources ?

La réponse est oui.

Notre outil de maquette et notre outil de schéma vous permettront tous deux d'intégrer facilement des maquettes ou des schémas existants dans votre projet Azure DevOps. 

Pour ce faire, il vous suffit d'enregistrer votre ressource au format .png ou .jpeg à partir de l'outil de maquette ou de schéma de votre choix.
Vous pouvez ensuite importer la ressource que vous avez créée soit dans l'outil de simulation Modern Requirements4DevOp (maquettes),soit dansl'outil de schéma (schémas). 

Vous vous demandez peut-être : « Mais si nous les téléchargeons au format .png ou .jpeg, comment pourrons-nous modifier nos schémas et nos maquettes ? » Eh bien, vous ne pourrez pas. Mais il y a tout de même une bonne raison de procéder ainsi. 

Si vous souhaitez relier un seul diagramme à 25 exigences sans utiliser Modern Requirements, vous devrez ouvrir chacune des 25 exigences et les relier individuellement. 

Lorsque vous mettrez à jour votre diagramme ultérieurement, vous devrez rouvrir les 25 exigences et modifier la pièce jointe. 

Avec Modern Requirements4DevOps, vous pouvez toutefois créer un élément de travail « Diagramme » auquel vous pouvez associer directement toutes vos exigences nécessaires via le panneau de droite. Cela signifie que vous pourrez regrouper tous vos diagrammes en un seul endroit et, lorsque l'un d'entre eux devra être mis à jour, vous pourrez facilement y ajouter votre nouvelle image et associer votre pièce jointe à cet élément de travail unique. 

Conclusion

Dans cet article, nous avons présenté trois méthodes différentes pour importer à la fois les exigences et leurs ressources dans votre projet Azure DevOps. 

Vous pouvez importer des spécifications depuis Excel ou Word, ou encore importer vos schémas et maquettes existants. 

Si vous souhaitez utiliser Modern Requirements4DevOps pour optimiser votre processus de gestion des exigences, n'hésitez pas à essayer notre produit ici !

Durée de lecture : 10 minutes

Le module FAQ

Le module FAQ

La solution pour la collecte initiale des besoins

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.

Qu'est-ce que le module FAQ ?

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.

Quels sont les avantages du module FAQ ?

L'intérêt de notre module FAQ peut se résumer en deux points simples.

  • Le module FAQ permet de définir des exigences plus précises en guidant le processus de collecte des exigences, ce qui augmente les chances de réussite du projet.
  • Le module FAQ réduit le temps consacré à la collecte d'informations tout au long de votre projet, ce qui permet à votre équipe de se mettre plus rapidement au travail.

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.

Quels sont les cas d'utilisation du module FAQ ?

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.

 

Comment utiliser efficacement le module FAQ ?

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.

Durée de lecture : 5 minutes

Exigences modernes 2019 : mise à jour n° 2

Notes de mise à jour

Modern Requirements4DevOps 2019 - Mise à jour n° 2

Bienvenue dans la mise à jour 2 de Modern Requirements4DevOps 2019! De nombreuses améliorations et nouveautés ont été ajoutées dans cette version. Vous trouverez ci-dessous une version commentée des notes de mise à jour, destinée à guider les utilisateurs tout au long de la mise à jour vers Modern Requirements4DevOps. 

Généralités

Un tout nouvel outil a été ajouté à Modern Requirements pour vous aider à répondre à vos besoins en matière de traçabilité et de gestion de projet. L'outil MR Artifact!

L'outil « MR Artifact Tool » est accessible depuis le menu contextuel de n'importe quel élément de travail. Cet outil répertorie tous les artefacts Modern Requirements auxquels l'élément de travail est associé ! Les utilisateurs peuvent désormais voir rapidement quels artefacts Modern Requirements utilisent l'élément de travail sélectionné.  

Cet outil permet actuellement de suivre les éléments de travail contenus dans les Smart Docs, les révisions et les versions de référence.

L'outil de comparaison, qui sert à comparer directement les différentes versions d'un élément de travail, a été, faute d'un meilleur terme, révisé !

Les identifiants de révision sont désormais davantage différenciés grâce à de nouvelles propriétés. Ces nouvelles propriétés sont « Dernière approbation » et « Dernière révision ». Elles s'appliquent aux révisions des éléments de travail qui ont fait l'objet d'une révision au cours de leur cycle de vie.

Ces propriétés s'afficheront à côté de l'identifiant de révision dans le menu déroulant de l'outil de comparaison.

Lorsque vous utilisez l'outil de comparaison, celui-ci affiche automatiquement une révision par défaut dans le menu déroulant. Lorsque vous ouvrez ce menu, les éléments « Dernière approbation » et « Dernière révision » apparaissent respectivement en haut de la liste. Ils sont suivis des autres révisions, classées par ordre décroissant (de la plus récente à la plus ancienne). 

Lorsque l'outil de comparaison est lancé, le menu déroulant de gauche affiche toujours la révision pertinente de l'élément de travail. Lorsqu'il est ouvert à partir du backlog, ce champ contient la dernière révision. Lorsqu'il est lancé à partir d'une revue, ce champ affiche par défaut la révision de l'élément de travail qui a été incluse dans la revue. Lorsqu'il est accessible à partir d'une baseline, ce champ affiche la révision de l'élément de travail telle qu'elle était au moment de la création de la baseline.

Le menu déroulant de droite correspond au champ de comparaison des révisions. Si l'élément de travail a fait l'objet d'une révision, ce champ affiche par défaut la dernière révision approuvée.

S'il n'existe aucune révision approuvée, ce champ affichera par défaut la dernière révision révisée.

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

L'outil de comparaison est accessible à partir d'un élément de travail nouvellement créé. Cependant, en l'absence de révisions, le menu déroulant de droite sera à nouveau vide.

Lorsque vous lancez l'outil de comparaison à partir de l'onglet « Comparer les versions de référence », celui-ci fonctionne différemment. La comparaison n'est plus automatique, car c'est l'utilisateur qui compare manuellement l'élément de travail entre deux versions de référence. Les menus déroulants de l'outil s'affichent alors par défaut sur la révision de l'élément de travail incluse dans chaque version de référence comparée.

Lorsqu'il utilise l'outil de comparaison, l'utilisateur peut interagir avec l'un ou l'autre des menus déroulants et effectuer n'importe quelle comparaison entre les révisions.

Documents intelligents

Smart Docs a élargi ses fonctionnalités grâce à l'ajout de trois nouvelles fonctionnalités…

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

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

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

Dans le modèle de processus, certains champs peuvent être définis comme étant en lecture seule. Smart Editor traitera également ces champs comme étant en lecture seule.

Exigences actuelles : l'interaction des parties prenantes avec Smart Docs s'est encore améliorée grâce à l'ajout d'une option permettant d'ouvrir des tâches. Auparavant, les parties prenantes ne pouvaient pas ouvrir de tâches ; désormais, elles le peuvent !

Lorsque cette option est activée, les parties prenantes invitées à rejoindre le projet pourront ouvrir les éléments dans l'éditeur standard d'Azure DevOps.

Les parties prenantes peuvent accéder à cette fonctionnalité depuis les onglets « Document » et « Comparer » de Smart Docs.

D'autres améliorations ont été apportées aux fonctionnalités actuelles du module Smart Docs.

Le Meta Template Designer permet désormais aux utilisateurs de mettre à jour les modèles de document enregistrés. Auparavant, cette fonctionnalité ne s'appliquait qu'aux méta-modèles ; désormais, les modèles de document peuvent également être mis à jour !

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

Les fonctionnalités comprennent :

  • Modifier la hiérarchie des éléments de travail
  • Renommer les modèles
  • Supprimer les modèles
  • Cloner des modèles ; créer une version unique d'un modèle à modifier

Les modifications apportées aux modèles de document peuvent être appliquées à tous les Smart Docs utilisant ce modèle. Une fois les modifications effectuées, il suffit à l'utilisateur d'utiliser la fonction « Mettre à jour tous les modèles » dans la barre d'outils Smart Docs.

Une modification importante a été apportée à l'apparence de Smart Docs.

L'habillage du texte et des images a été amélioré dans Smart Docs : toutes les données incluses s'affichent désormais correctement sur la ligne suivante.

Il s'agit d'un changement purement esthétique. Toutefois, ce changement devrait considérablement améliorer la lisibilité et la façon dont l'utilisateur perçoit visuellement le document final.

Les titres, les champs HTML, les images de grande taille et les tableaux de Smart Docs bénéficieront tous de cette amélioration.  

Gestion des avis

Le module de gestion des évaluations a également été enrichi de nouvelles fonctionnalités très pratiques.

En tant qu'initiateur d'une révision, vous pourrez désormais soumettre des commentaires sans avoir besoin d'être réviseur – un initiateur de révision est en effet réviseur par défaut.

Deux nouveaux types de rapports d'audit ont été ajoutés au module de gestion des révisions.

Rapport d'audit de conformité:

Le rapport contient tous les détails relatifs aux actions d'approbation appliquées aux éléments de travail lors de la révision

  • Les détails indiqueront notamment si un élément de travail a été approuvé ou rejeté, ainsi que le profil de l'utilisateur concerné, les commentaires de réponse, les actions de révision, les commentaires supplémentaires et les éléments de travail associés.

Rapport des résultats de l'évaluation :

Le rapport contient tous les détails des actions de révision appliquées aux éléments de travail concernés par la révision

  • Les détails indiqueront notamment si un élément de travail a été examiné et par quel profil d'utilisateur, ainsi que les commentaires de réponse, les actions de révision, les commentaires supplémentaires et les éléments de travail associés.

Il convient de noter que le rapport d'audit de révision actuel sera rebaptisé « rapport d'audit historique ».

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

Le module de gestion des révisions a bénéficié de plusieurs améliorations au niveau de ses fonctionnalités principales.

La manière dont Modern Requirements gère les métadonnées des révisions a été entièrement repensée. Lorsque vous créez une révision, les métadonnées correspondantes sont désormais enregistrées dans votre dépôt (système de contrôle de version).

Les métadonnées des évaluations étaient auparavant stockées dans le champ HTML d'un élément de travail de type « Demande de commentaires ».

La mise à jour 2 a également apporté des modifications au processus opérationnel de gestion des révisions.

L'ancien processus de création des révisions était lent et comportait de nombreux liens ; trois liens étaient créés pour chaque élément de travail inclus dans une révision.

Dans la mise à jour 2, lorsqu'une révision est créée, aucun lien ne sera plus établi entre les demandes de commentaires et les éléments de travail inclus dans la révision.  

De plus, le système ne créera plus de tâche de réponse aux commentaires lorsqu'un utilisateur soumet une réponse à une révision (approbation/soumission de la révision).

Ce nouveau processus est plus efficace et ne contient aucun lien, ce qui permet de contourner la limite de 1 000 liens par élément de travail imposée par Azure DevOps.  

De plus, l'automatisation a été améliorée pour la réalisation des actions courantes dans le cadre des révisions.

Lorsque vous utilisez la fonctionnalité « Lier un élément de travail » pour associer un élément de travail à une approbation ou à un rejet, le lien est établi directement avec l'élément de travail que l'utilisateur est en train d'examiner.

Les commentaires saisis dans l'onglet « Détails » seront automatiquement ajoutés à la tâche « Demande de commentaires », accompagnés des informations de profil de l'auteur du commentaire.

Une fois l'évaluation terminée, un commentaire sera ajouté à la tâche « Demande de commentaires », accompagné des informations de profil du participant.

Une fois les révisions clôturées, aucune autre action ne peut être effectuée en matière d'approbation ou de commentaire. Cela empêchera les parties prenantes de la révision d'ajouter des commentaires supplémentaires ou de lier des tâches à la révision clôturée.

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

  • Lorsqu'on lance une révision à partir de Smart Docs, la section des tâches ne s'affiche plus
  • Lors de la prévisualisation d'une révision, la liste des tâches sélectionnées ne s'affichera plus
  • Le corps d'un e-mail généré lors d'une révision ne contiendra plus la liste des tâches sélectionnées

Référence

Le module Baseline a vu ses capacités renforcées grâce à l'ajout de nouvelles fonctionnalités permettant d'améliorer le suivi et la gestion de vos tâches.

Lorsqu'ils comparent des états de référence, les utilisateurs peuvent désormais définir quels types de liens spécifiques déclenchent un indicateur de modification. Auparavant, ils avaient uniquement la possibilité de désactiver ce déclencheur ou de l'appliquer à tous les types de liens. Cette configuration est accessible depuis le panneau d'administration.

Les rapports de différences ont été améliorés afin de n'afficher que les champs configurés comme déclencheurs d'indicateurs de modification. Auparavant, l'interface utilisateur de l'outil de comparaison et les rapports de différences n'étaient pas synchronisés.

Grâce à l'ajout de la fonctionnalité permettant de suivre les modifications de type de lien entre les versions de référence, les rapports de différences offriront désormais la possibilité de signaler ces modifications. 

L'outil « Copy/Reuse Baseline » a également vu ses fonctionnalités améliorées.

Le système copiera automatiquement le chemin d'accès à la zone/itération du projet source et l'appliquera aux éléments de travail copiés si des valeurs identiques existent dans le projet cible.

Comme le montre cet exemple, lors de la copie d'un élément de travail, son chemin d'itération est copié depuis le projet source et défini dans le projet cible.

Rapport intelligent

Comme dans les versions précédentes de l'outil Smart Report, les utilisateurs peuvent importer et appliquer des modèles Word à leurs rapports. La mise à jour 2 permet désormais d'hériter de la mise en forme Word lorsque les rapports Smart Report sont exportés vers Microsoft Word et qu'un modèle Word est appliqué.

À partir du modèle, Smart Reports reprendra la mise en forme des titres, la taille de la police, le texte souligné ou en gras, la couleur de la police, l'indentation et l'alignement.

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

Panneau d'administration

Des améliorations ont également été apportées au traitement des données relatives aux exigences modernes.

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

Pour utiliser cette fonctionnalité, ajoutez les identifiants d'un utilisateur au niveau de la collection dans l'onglet « Général » du panneau d'administration Modern Requirement4DevOps.

Si les identifiants n'ont pas été fournis, un message d'avertissement s'affichera.

Les données relatives aux exigences modernes seront synchronisées à la fois avec GIT et avec le système de contrôle de version Team Foundation.

Évolutivité

Modern Requirements est conscient que les projets de nos clients sont appelés à évoluer, et que leur logiciel de gestion des exigences doit s'adapter à cette évolution.

Les performances en termes de débit de Modern Requirements4DevOps ont été considérablement optimisées. La mise à jour 2 permet désormais de prendre en charge de grands volumes de données dans les modules traitant un nombre important de tâches. La prise en charge des données volumineuses a été ajoutée aux modules Gestion des révisions, Référence et Rapport intelligent.

Les analyses et les rapports intelligents peuvent désormais être créés avec un maximum de 10 000 éléments de travail.

Les utilisateurs peuvent désormais créer des références comprenant jusqu'à 100 000 éléments de travail.  

Parmi les autres améliorations apportées au débit dans la version de référence, on peut citer :

Copier des éléments de travail

  • 5 000 tâches dans Azure DevOps Server
  • 2 000 tâches dans Azure DevOps Service

Rapports de différences

  • 10 000 tâches dans Azure DevOps Server
  • 3 000 tâches dans Azure DevOps

Annuler les tâches

  • Cette opération peut être effectuée sur 10 000 éléments de travail

Les opérations impliquant de grands volumes de données peuvent parfois prendre beaucoup de temps. Modern Requirements sait que votre temps est précieux et a déjà mis en place des fonctionnalités visant à améliorer l'efficacité.

Les opérations chronophages ne vous ralentissent plus. Elles s'exécutent désormais en arrière-plan et les utilisateurs ont la possibilité d'être informés par e-mail une fois celles-ci terminées.

Cette fonctionnalité a été intégrée au module de gestion des révisions et est disponible lors de l'utilisation de la fonction « Approuver/Rejeter tout » sur de grands ensembles d'éléments de travail. Le système détectera automatiquement si l'opération doit prendre plus d'une minute et en informera l'utilisateur.

Cette fonctionnalité prend également en charge le Smart Report. Si la génération du Smart Report ne s'effectue pas immédiatement, un processus en arrière-plan sera lancé. En ce qui concerne le Smart Report, les e-mails de notification contiendront des liens permettant à l'utilisateur d'enregistrer son rapport au format Word ou PDF.

Corrections de bogues

La fonctionnalité et l'expérience utilisateur sont des éléments essentiels de la philosophie de conception de Modern Requirements.

Plusieurs bogues ont été identifiés et corrigés dans le cadre de la mise à jour 2. Consultez la liste complète des corrections de bogues ou lisez les notes de mise à jour ici.

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

Validation des exigences par le client dans Azure DevOps

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

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

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

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

Rapports personnalisables dans Azure DevOps

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

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

Aujourd'hui, nous allons changer cela. 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Pour faire simple, oui. 

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

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

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

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

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

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

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

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

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

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

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

Chacune de ces techniques a deux points communs.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mais cela n'est pas une fatalité.  

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

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

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

Tout d'abord, Azure DevOps est flexible.  

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

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

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

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

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

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

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

Voyons voir quels sont les outils.  

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

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

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

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

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

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

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

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

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

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

C'est aussi simple que ça.  

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

Nous soutenons cela aussi ! 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Demandez une démonstration !

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

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

Un gain de temps avéré

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

Simplifier les procédures d'approbation

Réduction significative des délais de validation

Améliorer les performances

Amélioration de la productivité de 50 %

Réduire les retouches

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

Simplifier la mise en conformité

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

Rédaction de documents relatifs aux exigences non fonctionnelles

Validation des exigences par le client dans Azure DevOps

Rédaction de documents relatifs aux exigences non fonctionnelles

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.

Qu'est-ce qu'un cahier des charges non fonctionnels ?

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. 

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

 

Types de documents

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.

Cahier des charges fonctionnels (FRD)

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

  • Il s'agit essentiellement d'un « contrat » entre le développeur du produit ou du système et le client
  • Les développeurs sont tenus de respecter les exigences énoncées dans le document
  • Met en évidence la valeur du produit ou du système au regard des objectifs et des processus de l'entreprise
  • Cela ne laisse aucune place à des interprétations qui ne seraient pas explicitement mentionnées
  • Ce que l'application doit faire, et NON comment elle fonctionne
  • Aucune référence à des technologies spécifiques

Cahier des charges du produit (PRD)

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.

  • Définit l'objectif, les caractéristiques, les fonctionnalités et le fonctionnement d'un produit
  • Définit les profils d'utilisateurs, les objectifs et les tâches
  • Coordonne les activités des équipes produit en matière de vente, de marketing et d'assistance
  • Les fonctionnalités du produit décrites dans ce document sont illustrées par des cas d'utilisation
  • Constitue le document de référence sur lequel se fonde une autorisation

Spécification des exigences du système (SRS)

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.

  • Décrit les fonctionnalités dont le produit doit disposer pour répondre à tous les besoins des parties prenantes, de l'entreprise et des utilisateurs
  • Sert de référence à toutes les équipes impliquées dans le développement
  • Fournir une base pour l'estimation des coûts, des risques et du calendrier de développement
  • Conçu pour évaluer les besoins avant les phases de conception plus spécifiques du système, dans le but de réduire les retouches
  • Contient des informations essentielles concernant : le développement, l'assurance qualité, l'exploitation et la maintenance.
  • Sert de liste de contrôle pour le développement ; aide à prendre des décisions éclairées concernant le cycle de vie du produit (la nécessité de modifier les exigences existantes pour répondre aux besoins des utilisateurs ou à d'autres besoins)
  • Éviter l'échec d'un projet

Pourquoi inclure des exigences non fonctionnelles dans les documents ?

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.

Comment la solution « Modern Requirements4DevOps » peut-elle aider à gérer les exigences non fonctionnelles au sein des documents ?

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. 

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

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.