Qu'est-ce que la matrice de traçabilité des exigences (RTM) ?

Comme son nom l'indique, cette matrice est utilisée pour suivre et vérifier si les exigences actuelles du projet sont satisfaites. Un document utilisé pour corréler n'importe quel document à deux lignes de base, nécessitant des relations plusieurs à plusieurs, pour vérifier l'exhaustivité de cette relation est appelé un matrice de traçabilité des exigences .

Table des matières

• Matrice de traçabilité des exigences (RTM)
• Matrice de traçabilité des types d'exigences
  • 1. Traçabilité en amont
  • 2. Traçabilité en amont ou en arrière
  • 3. Traçabilité bidirectionnelle ou avant et arrière
• Paramètres inclus dans la matrice de traçabilité des exigences
• Importance de la matrice de traçabilité des exigences
• Exemple de matrice de traçabilité des exigences
• Couverture de test
• Types de spécifications d'exigences
  • 1. Document de spécification des exigences logicielles (SRS)
  • 2. Utiliser le document de cas
  • 3. Exigences commerciales
  • 4. Histoires d'utilisateurs
  • 5. Documents d'exigences du projet (PRD)
  • 6. Document de vérification des défauts
• L'utilité de la matrice de traçabilité des exigences à l'aide d'un exemple
  • 1. Mise en œuvre
  • 2. L'exigence est-elle nécessaire ?
  • 3. Interprétation de l'exigence
  • 4. Décisions de conception après la mise en œuvre de l'exigence
  • 5. Toutes les exigences attribuées
• Avantages de la couverture des tests et du RTM
• Défis pour tester la couverture
  • la communication
  • Prioriser les scénarios de test
  • Stratégie de test efficace
  • Mise en œuvre du processus
  • Disponibilité des ressources
• Derniers mots
• Articles recommandés

Matrice de traçabilité des exigences (RTM)

Un document qui capture toutes les exigences proposées par le client et trace les exigences dans un seul document en cartographiant et en suivant les cas de test avec les exigences de l'utilisateur est appelé une matrice de traçabilité des exigences.

Le document de matrice de traçabilité des exigences est livré à la fin du cycle de vie du développement logiciel.

L'objectif principal des documents est de vérifier que toutes les exigences des utilisateurs sont vérifiées à l'aide des cas de test et qu'aucune fonctionnalité n'est décochée pendant les tests logiciels.

La couverture de test à 100 % doit être au centre de tout engagement de test, c'est-à-dire que tout ce qui doit être testé doit être testé.

Matrice de traçabilité des types d'exigences

La traçabilité des exigences peut être globalement classée en trois composants principaux. Ils sont:

1. Traçabilité en amont

Cette matrice garantit que chaque exigence est appliquée au produit et est testée de manière approfondie.

Il vérifie également la direction du produit et s'assure qu'il progresse dans la direction souhaitée pour le bon logiciel/produit.

Les exigences sont mappées aux cas de test.

2. Traçabilité en amont ou en arrière

Cette matrice vérifie que les testeurs n'étendent pas la portée du projet en ajoutant du code, des tests, des éléments de conception ou d'autres travaux inutiles qui ne sont pas prédéfinis dans les exigences de l'utilisateur.

Il s'assure également que le produit actuel reste sur la bonne voie.

Les cas de test sont mappés aux exigences.

3. Traçabilité bidirectionnelle ou avant et arrière

Il s'assure que toutes les exigences des utilisateurs sont couvertes dans tous les cas de test et analyse les changements dans les exigences des utilisateurs causés par les défauts d'un produit et vice versa.

Paramètres inclus dans la matrice de traçabilité des exigences

L'équipe de test développant la matrice de traçabilité des exigences peut opter pour les outils de gestion de test disponibles en plus de conserver une feuille Excel séparément.

Trois paramètres sont inclus dans la feuille excel de RTM :

• ID d'exigence
• Type d'exigence et description
• Cas de test avec statut

Outre ce qui précède, la matrice de traçabilité des exigences peut également contenir :

• L'exigence est couverte en fonction du nombre de cas de test.
• État du test d'acceptation par l'utilisateur, s'il est effectué par l'utilisateur.
• Statut de conception et d'exécution pour des cas de test spécifiques.
• Les défauts associés et l'état actuel sont mentionnés.

Il ne serait pas faux de dire que RTM est un guichet unique pour toutes les activités de test.

Importance de la matrice de traçabilité des exigences

L'analyse approfondie des besoins de l'utilisateur et la génération de cas de test positifs et négatifs doivent être assurées en tenant compte de tous les scénarios ou cas de test possibles.

Alors, comment s'assurer qu'aucune exigence n'a été omise lors des tests ?

Le moyen le plus simple sera de tracer les exigences et leurs cas de test et scénarios de test correspondants de manière simplifiée.

Chaque testeur doit s'assurer que le produit livré est sans défaut et répond à toutes les exigences de l'utilisateur.

Pour atteindre cet objectif, les testeurs d'assurance qualité doivent bien comprendre les exigences et être capables de diviser les exigences en différents scénarios, puis de créer des cas de test sur ces scénarios.

Une fois les cas de test terminés, ils doivent être exécutés individuellement et des rapports de réussite et d'échec doivent également être générés.

Ici, la matrice de traçabilité des exigences apparaît.

La matrice n'est rien d'autre qu'une feuille de calcul typique contenant les exigences de l'utilisateur et tous les scénarios de test possibles, les cas de test et leurs états actuels respectifs de réussite ou d'échec.

En utilisant RTM, l'équipe de test comprendra mieux et tracera les différentes activités de test qui doivent être effectuées pour le logiciel ou le produit.

Exemple de matrice de traçabilité des exigences

Prenons un exemple de spécification d'exigence d'un utilisateur nécessitant un Définir un rappel dans un logiciel de gestion des tâches .

Ainsi, le Exigence commerciale (BR1) sera : Définir un bouton de rappel doit être disponible.

le scénario de test (TS1) pour l'exigence sera : Le bouton Définir le rappel est fourni.

Il y aura deux cas de test dans ce scénario :

Cas d'essai 1 (TS1.TC1): L'option Définir le rappel a été activée et fonctionne correctement.Cas d'essai 2 (TS1.TC2): L'option Définir le rappel a été désactivée avec succès.

Une fois les cas de test ci-dessus mis en œuvre, ils peuvent réussir ou échouer.

En cas d'échec, les défauts trouvés peuvent également être répertoriés et cartographiés avec l'exigence métier, le scénario de test et les cas de test.

Supposons que TS1.TC1 échoue, c'est-à-dire que l'utilisateur ne peut pas définir de rappel pour les tâches quotidiennes même si l'option est activée. Dans ce cas, le défaut peut être consigné dans la matrice de traçabilité des exigences.

Supposons que l'ID de défaut soit D1. Ensuite, cela sera également mappé avec BR1, TS1 et TS1.TC1.

Dans un format tabulaire, le RTM ressemblera un peu à ceci :

De même, d'autres lignes pour d'autres exigences métier, BR2, BR3 et autres, peuvent être ajoutées avec leurs cas de test, scénarios de test et défauts cartographiés.

Couverture de test

La couverture des tests est un terme qui définit les exigences des utilisateurs qui doivent être testées et vérifiées une fois les tests commencés.

Il vérifie si les cas de test sont correctement exécutés ou non, pour garantir l'exhaustivité de l'application logicielle avec des défauts minimes ou nuls.

La couverture de test à 100 % peut être obtenue en utilisant la traçabilité des exigences comme suit :

Les défauts internes doivent être mappés aux cas de test conçus.

Les défauts signalés par le client (CRD) doivent être mappés aux cas de test individuels.

Types de spécifications d'exigences

1. Document de spécification des exigences logicielles (SRS)

Il s'agit d'un document détaillé contenant tous les détails sur les exigences fonctionnelles et non fonctionnelles du client ou des parties prenantes.

SRS est le document de référence pour la conception et le développement d'applications logicielles.

2. Utiliser le document de cas

Le document de cas d'utilisation aide à la conception et à la mise en œuvre du logiciel en fonction des besoins de l'entreprise.

Il montre un flux de travail détaillé de la façon dont chaque tâche doit être effectuée.

Les interactions entre le système et l'utilisateur sont cartographiées dans le document de cas d'utilisation à l'aide d'acteurs et d'événements devant être exécutés pour atteindre l'objectif requis.

3. Exigences commerciales

Le Business Requirements Document (BRS) est une liste d'exigences de haut niveau qui contient minutieusement les exigences réelles des clients après une brève interaction avec le client.

Un analyste métier ou un architecte de projet est celui qui forme généralement ce document. SRS est dérivé de BRS.

4. Histoires d'utilisateurs

Dans le cas de la méthode de développement Agile, la user story est utilisée pour décrire diverses fonctionnalités logicielles du point de vue des utilisateurs finaux.

Ces histoires simplifient les besoins de l'utilisateur en définissant les différents types d'utilisateurs et leurs besoins pour quelle fonctionnalité et pourquoi.

Les histoires d'utilisateurs et le développement Agile sont la nouvelle tendance dans l'industrie du logiciel, et ils se tournent vers eux et les outils logiciels correspondants nécessaires pour enregistrer les besoins des utilisateurs.

5. Documents d'exigences du projet (PRD)

Un document de référence créé pour toute l'équipe du projet informant chaque membre du fonctionnement des produits est PRD.

Il y a quatre sections :

• But du produit
• caractéristiques du produit
• Critères de publication
• Budgétisation & Calendrier du projet

6. Document de vérification des défauts

L'équipe de test tient à jour un document contenant les détails relatifs aux défauts pour corriger et retester les défauts.

Ce document de vérification des défauts vérifie si les défauts ont été corrigés ou non ; ils sont retestés sur différents systèmes d'exploitation ou appareils ou avec différentes configurations système.

Si le projet comporte une phase fiable de correction et de vérification des défauts, le document de vérification des défauts est essentiel et utile.

L'utilité de la matrice de traçabilité des exigences à l'aide d'un exemple

Considérant la notification d'ensemble précédente dans le logiciel de gestion des tâches, voyons comment la matrice de traçabilité des exigences peut aider.

1. Mise en œuvre

Exigence: Implémentez le bouton Définir la notification dans l'application du gestionnaire de tâches.

Mise en œuvre: Une fois que l'utilisateur est connecté, l'icône de notification définie doit être visible et accessible sur le tableau de bord.

2. L'exigence est-elle nécessaire ?

Exigence: Implémentez le bouton Définir la notification pour des utilisateurs spécifiques uniquement.

Mise en œuvre: L'utilisateur peut choisir s'il souhaite ou non activer la notification pour ses tâches automatiquement ou manuellement ou pas du tout.

3. Interprétation de l'exigence

Exigence: Le bouton Définir la notification contient la date et l'heure de la notification à définir.

Mise en œuvre: Lorsqu'un utilisateur clique sur l'icône/le bouton Définir la notification, lequel doit être disponible ?

• Sélectionnez la tâche pour laquelle un rappel doit être défini.
• La date et l'heure peuvent être définies selon les besoins des utilisateurs.

4. Décisions de conception après la mise en œuvre de l'exigence

Exigence: Les tâches, supprimer, modifier, nouveau, paramètres, définir la notification, doivent être visibles et accessibles.

Mise en œuvre: Tous les éléments qui doivent être visibles doivent être disposés selon le cadre dans un format tabulaire.

5. Toutes les exigences attribuées

Exigence: L'option 'Notification muette' doit être fournie.

Mise en œuvre: Si l'option « Définir la notification » est disponible, la « Notification muette » devrait également être disponible et fonctionner avec précision. Si l'option 'notification muette' fonctionne correctement, toutes les notifications définies peuvent être facilement réinitialisées ou désactivées une fois les tâches terminées ou selon les besoins des utilisateurs.

Avantages de la couverture des tests et du RTM

• La matrice de traçabilité des exigences met en évidence les exigences manquantes et les incohérences dans le document. L'utilisateur doit obtenir ce qu'il a demandé sans fonctionnalités supplémentaires ou en moins.
• Les défauts globaux, l'exécution et l'état sont affichés du point de vue des besoins de l'entreprise.
• La couverture de test à 100 % est confirmée.
• L'impact de la révision et de la refonte des cas de test sur le travail de l'équipe d'assurance qualité est analysé et estimé à l'aide de RTM.
• La mise en œuvre des exigences des utilisateurs selon la priorité est essentielle. Les exigences prioritaires doivent être mises en œuvre en premier afin que le produit final puisse être expédié avec les exigences prioritaires et dans les délais.
• Les plans de test et les cas de test sont écrits avec précision pour vérifier que toutes les exigences de l'application sont satisfaites.
• Dans le cas d'une demande de changement d'un client, toutes les fonctionnalités associées peuvent être modifiées en conséquence sans que rien ne soit oublié.

Défis pour tester la couverture

la communication

En cas de modifications demandées par les parties prenantes, elles doivent être communiquées immédiatement aux équipes de développement et de test au cours des premières phases du cycle de développement et de test. S'il est retardé, du temps et des efforts inutiles sont nécessaires, ce qui retardera le projet et augmentera le coût.

Prioriser les scénarios de test

Les scénarios de test doivent être hiérarchisés en fonction des besoins des utilisateurs et livrés tels quels pour éviter tout retard. Il est impossible de mettre en œuvre tous les scénarios de test, il faut donc décider quels scénarios de test doivent être testés et dans quel ordre.

Stratégie de test efficace

La stratégie efficace pour la mise en œuvre de Test Coverage est celle qui assure une bonne qualité de l'application, qui sera maintenue sur un certain temps

Mise en œuvre du processus

Les facteurs tels que les compétences de l'équipe, les structures organisationnelles et les processus suivis, les expériences passées, l'infrastructure technique, la mise en œuvre, le temps et les ressources, les estimations de projet liées aux coûts et l'emplacement de l'équipe en fonction des fuseaux horaires doivent être pris en compte lors de la définition du processus de test.

De cette façon, l'équipe peut s'assurer que le processus se déroule sans heurts et que chaque individu du projet reste sur la même longueur d'onde.

Disponibilité des ressources

Les testeurs spécialisés dans un domaine spécifique et les outils de test utilisés par les testeurs sont les deux types de ressources nécessaires pour écrire et mettre en œuvre des scénarios et des scripts de test convaincants.

Ces ressources peuvent garantir une livraison à temps et une mise en œuvre adéquate de l'application pour l'utilisateur.

Derniers mots

RTM ou Requirement Traceability Matrix est un document unique dont l'objectif principal est de s'assurer qu'aucun cas de test et scénario de test ne sont omis. Chaque fonctionnalité est testée et couverte avec succès. A cet effet, les exigences du client sont cartographiées et tracées dans le document.

Le nombre de défauts détermine le type de test effectué. Si le nombre est élevé, cela signifie un test de qualité utile, et un nombre faible indique un test de qualité inadéquat.

Lorsqu'elle est effectuée de manière approfondie en planifiant à l'avance, la couverture des tests entraîne moins de tâches répétitives et moins de défauts dans les phases de test, ce qui entraîne un faible nombre de défauts.

Ainsi, un logiciel ou un produit est utile si le défaut est minimisé et la couverture de test est maximisée.

Articles recommandés

• Qu'est-ce qu'Unsecapp.exe et est-ce sûr ?
• 15 meilleurs outils et logiciels de diagramme UML
• [RÉSOLU] Windows ne peut pas accéder à l'erreur de périphérique, de chemin ou de fichier spécifié
• 16 correctifs pour Windows Update ne fonctionnant pas sous Windows
• 4 correctifs pour les paramètres AMD Radeon ne s'ouvriront pas
• Outil de capture d'écran Zoom : Trucs et astuces