Requirements Writing Pitfalls That Sabotage Projects (and How to Fix Them)
Avoid the most common requirements writing mistakes. A practical guide...
Version des exigences : Qu’est-ce que c’est, et quelle est son importance dans le développement de produits?
Listen to this blog
Pendant le développement d’un produit, les exigences ne restent jamais fixes longtemps. Le premier brouillon de la fonctionnalité ou de l’histoire utilisateur semblait clair, mais pouvait changer après un retour des clients, une mise à jour de conformité ou des tests.
Les vraies difficultés que nous avons remarquées en discutant avec nos clients, c’est que les équipes ont souvent du mal à gérer les attentes en mouvement et les différentes versions des mêmes exigences. Lorsque différents groupes suivent différentes versions d’exigences, la confusion grandit rapidement et la refonte devient courante.
La gestion des versions des exigences résout ces défis en enregistrant l’historique de tous les changements, y compris ce qui a été modifié, quand cela a été modifié et qui a apporté ces modifications.
Maintenant, comprenons ce qu’est le versionnement des exigences, quels problèmes il corrige, le cycle de vie du versionnement des exigences, et pourquoi le contrôle manuel des versions n’est pas suffisant.
Qu’est-ce que le versionnement des exigences?
Le versionnement des exigences est le processus de documentation et de suivi de chaque modification apportée aux spécifications du produit tout au long du développement. Au lieu de remplacer l’ancien texte des exigences, il enregistre chaque mise à jour comme un nouvel état et lui attribue un identifiant unique (V1.0, V1.2, V2.0, etc.), appelé numéro de version.
Enregistrements et pistes de gestion des versions :
- Quelles exigences ont été modifiées
- Qui a approuvé et apporté des changements
- Horodatage indiquant quand certains changements ont été effectués
- Pourquoi les changements arrivent
Cela permet aussi aux équipes de voir et de restaurer les versions précédentes si quelque chose tourne mal.
Grâce à cela, les équipes peuvent savoir exactement quelles étaient les exigences à chaque étape du développement et avoir accès aux exigences les plus récentes.
Lors du développement de produits dans des industries réglementées, qu’il s’agisse de logiciels pour la santé, des véhicules dans l’automobile ou de l’aviation dans l’aérospatiale, les équipes doivent prouver que les changements ont été examinés et approuvés. Le versionnement des exigences soutient cela en gardant l’historique, les approbations et les liens de trace prêts pour les audits.
Pourquoi le versionnement des exigences existe-t-il : les problèmes fondamentaux qu’il corrige
Considérons les scénarios ci-dessous pour comprendre l’importance de la gestion des versions des exigences :
- Le développeur développe une fonction de connexion en utilisant les exigences du mois dernier, tandis que la dernière mise à jour a modifié la logique de base. La fonction fonctionnait bien, mais elle n’a pas été acceptée, car la connexion avec un numéro de mobile n’était pas prise en charge. Cela s’est produit parce que le développeur n’avait aucune idée des exigences mises à jour.
- Les cas de test sont écrits à partir d’une version antérieure des exigences. Lors de la validation, des défauts apparaissent, non pas parce que le code est erroné, mais parce que les tests ne correspondent plus au comportement approuvé actuel.
- Un client se plaint qu’une fonctionnalité particulière ne fonctionne pas comme prévu. De plus, l’équipe n’a aucune idée de pourquoi les exigences ont changé ni qui les a modifiées. Cela peut entraîner une perte de confiance.
Pour éviter ce type de problèmes potentiels, les équipes doivent mettre en place un processus structuré de gestion des versions des exigences qui maintient l’historique, la propriété et l’alignement des versions sous contrôle.
Critères de référence vs. versions : quelle est la différence et pourquoi c’est important
Aspect | Version des exigences | Référence des exigences |
|---|---|---|
Objectif | Il tient une trace de la façon dont chaque élément de travail est modifié au cours du cycle de développement du produit. | Une référence est un instantané fixe et approuvé d’un ensemble d’exigences à un jalon précis. Il représente le point de référence convenu pour tous les membres de l’équipe. |
Portée | Chaque exigence peut avoir ses détails de version. | Couvre un ensemble complet d’exigences pour une sortie, une phase ou une étape d’approbation, pas seulement un seul élément. |
Lors de la création | Une version est généralement créée lorsque les exigences changent. Les outils modernes de gestion des exigences créent automatiquement une nouvelle version à chaque changement. Créé chaque fois qu’un changement est approuvé, comme une mise à jour logique, un ajout de contraintes ou une clarification qui affecte le comportement. | Créées aux points de contrôle formels, tels que :
|
Flexibilité du changement | Les versions continuent d’évoluer. De nouvelles versions peuvent être ajoutées tant que les règles de contrôle des changements sont respectées. | Une base est verrouillée. Toute modification nécessite un processus formel de changement et aboutit souvent à une nouvelle base de référence. |
Utilisation dans le travail quotidien | Ça aide à comprendre les dernières exigences. | À utiliser comme point de référence officiel pour ce qui doit être construit, testé ou livré dans une version spécifique. |
Importance de la conformité | Il offre une visibilité sur l’évolution des exigences aux équipes d’audit pour des raisons valables. | Démontre qu’un ensemble d’exigences contrôlées et approuvées existait à un moment donné, ce que de nombreuses normes attendent. |
Le cycle de vie du versionnement des exigences : de la demande de changement à la mise à jour contrôlée
Voyons maintenant comment fonctionne la version des exigences dans le développement de produits en temps réel :
- Création des exigences initiales : Les équipes produit définissent d’abord les exigences en fonction des besoins de l’entreprise et des utilisateurs, puis les stockent. Cela devient la première version (V 1.0) et sert de point de référence.
- Mises à jour itératives et suivi : Ensuite, lorsque des modifications sont demandées à l’utilisateur, à l’équipe de soutien à la clientèle ou aux parties prenantes, les exigences sont affinées et stockées sous forme de nouvelle version.
- Entretien de l’historique des versions des exigences : Chaque mise à jour est stockée avec un historique approprié afin que les équipes ne perdent pas de visibilité sur les versions antérieures. Il enregistre qui a apporté des changements et comment les exigences ont évolué.
- Création de la base : À des étapes clés, comme chaque sprint, un ensemble d’exigences est figé comme référence et fixé comme point de référence pour la prochaine version.
- Comparaison et restauration des versions : Les équipes peuvent comparer les versions requises pour voir ce qui a changé entre les versions ou les bases. Ils peuvent aussi restaurer à la version précédente. C’est très utile lors de l’analyse de l’impact du changement, de l’analyse des causes profondes et de la préparation du rapport d’audit.
À lire aussi : Meilleures pratiques pour le contrôle de versions
Pourquoi le contrôle manuel des versions échoue à mesure que les produits grandissent
Le contrôle de version manuel à l’aide de feuilles de calcul ou de documents peut fonctionner dans de petits projets, mais il s’effondre à mesure que le projet grandit. Dans l’approche manuelle, Teams crée différents fichiers pour chaque version, les nomme comme « final_V3_latest » et les partage avec les membres de l’équipe via des courriels ou des applications de clavardage.
Le principal problème avec cette approche est que personne ne sait quel dossier reflète les exigences finales et approuvées. Teams pourrait finir par implémenter l’ancienne version, ce qui entraînerait une refonte. Parfois, il peut arriver que les équipes modifient les exigences dans un document, tandis que les notes de conception, les tâches de développement et les cas de test restent obsolètes.
De plus, les équipes n’ont aucune idée de l’historique des changements lorsqu’elles choisissent une approche manuelle pour la gestion des exigences. À part ça, les méthodes manuelles nuisent aussi à la collaboration d’équipe. Deux membres de l’équipe peuvent éditer V 1.0 et créer deux copies différentes pour V 1.1. À cause de cela, des mises à jour importantes peuvent être manquées.
En bref, sans liens de trace automatisés et suivi des versions, comprendre l’impact devient lent et peu fiable, surtout lorsque des preuves de conformité sont nécessaires.
Dans la section suivante, nous verrons comment les outils de gestion des exigences peuvent aider à résoudre les problèmes mentionnés ci-dessus.
Comment Modern Requirements4DevOps rend la gestion des versions pratique et fiable
Les équipes de développement produit ont besoin de contrôle de version dans un outil où elles gèrent toutes les demandes. Modern Requirements4DevOps est un outil de gestion des exigences intégré à Azure DevOps qui fonctionne avec Azure DevOps et offre des capacités de versionnement et de référence dans votre espace de travail ADO.
Chaque fois qu’un membre de l’équipe modifie un élément de travail dans ADO, Modern Requirements4DevOps enregistre automatiquement le changement avec la personne qui l’a effectué et crée une nouvelle version de l’exigence. Ainsi, les équipes n’ont pas besoin de fournir des efforts manuels supplémentaires pour gérer différentes versions.
Le meilleur aspect d’utiliser Modern Requirements4DevOps avec Azure DevOps est que les équipes voient toujours la dernière version des exigences et les comparent avec les versions précédentes côte à côte lors de la révision. Si nécessaire, les utilisateurs peuvent aussi revenir en arrière en restaurant à la version précédente. De plus, la traçabilité intégrée dans Modern Requirements4DevOps permet aux utilisateurs de voir comment les changements affectent les éléments de travail connexes et peuvent aussi les mettre à jour.
L’outil est conçu pour fonctionner dans les industries réglementaires. Les équipes de conformité peuvent utiliser directement l’historique des changements ou des versions lors de la préparation des rapports d’audit, car il est important de documenter les changements.
Table des matières
Articles récents
DevSecOps Compliance Automation for Mission Systems: A Practical Guide for Government Programs
Government software teams spend more time proving compliance than building....
Modern Requirements Launches NextGen, A Rebuilt Requirements Management Platform Native to Azure DevOps
Modern Requirements, a leading provider of requirements management software for...
