Qualité des exigences logicielles

La qualité des exigences est un sujet de discussion parmi les professionnels des exigences logicielles. Voici quatre points de vue réfléchis sur la qualité des exigences logicielles, c'est ce qui fait une bonne exigence ou un bon ensemble d'exigences.

Pourquoi la qualité des exigences est-elle importante ?

Il est souvent utile de voir les choses à l’envers. Demandez-vous quel est l’impact d’avoir de mauvaises exigences ? Ce graphique illustre le fait qu'il existe une augmentation non linéaire des retouches causée par des exigences médiocres.

Le coût des exigences logicielles de mauvaise qualité pour générer des retouches
Une comparaison de exigences qualité attributs selon différentes sources :

Notre point de vue

Nous recommandons quelque chose de très proche du IIBA BABOK comme suit

  • Clair: signification fonctionnelle sans ambiguïté.
  • Concis: ne contient aucun contenu superflu et inutile.
  • Orienté utilisateur: se concentre sur ce que l'utilisateur doit réaliser.
  • Complet: à la fois complets en interne (toutes les étapes fonctionnelles d'une exigence) et en tant qu'ensemble, tous les événements CRUD couverts
  • Cohérent : les noms d'utilisateur et d'objet sont cohérents dans un ensemble d'exigences
  • Mesurable: peut être dimensionné en points de fonction COSMIC
  • Testable: S'il est mesurable, il est généralement également testable.
  • Précieux : est nécessaire pour fournir les fonctionnalités utilisateur essentielles.
  • Sans conception: exclut « comment » il doit être mis en œuvre.
  • Unique : pas de fonctionnalité dupliquée dans l'ensemble des exigences

Et l'aperçu de l'IIBA sur la qualité des exigences dit ce qui suit :

Même si la qualité est en fin de compte déterminée par les besoins des parties prenantes qui utiliseront les exigences ou les conceptions, les exigences de qualité acceptables présentent bon nombre des caractéristiques suivantes »

  • Atomique: autonome et capable d’être compris indépendamment d’autres exigences ou conceptions.
  • Complet: suffisant pour guider les travaux ultérieurs et au niveau de détail approprié pour que les travaux puissent se poursuivre. Le niveau d'exhaustivité requis diffère en fonction de la perspective ou de la méthodologie, ainsi que du point du cycle de vie où l'exigence est examinée ou représentée.
  • Cohérent: aligné sur les besoins identifiés des parties prenantes et non incompatible avec d’autres exigences.
  • Concis: ne contient aucun contenu superflu et inutile.
  • Réalisable: raisonnable et possible dans le cadre du risque, du calendrier et du budget convenus, ou considéré comme suffisamment réalisable pour permettre une enquête plus approfondie au moyen d'expériences ou de prototypes.
  • Non ambigu: le besoin doit être clairement énoncé de manière à faire apparaître clairement si une solution répond ou non au besoin associé.
  • Testable: capable de vérifier que l'exigence ou la conception a été satisfaite. Les niveaux acceptables de vérification du respect dépendent du niveau d’abstraction de l’exigence ou de la conception.
  • Priorisé: classé, regroupé ou négocié en termes d'importance et de valeur par rapport à toutes les autres exigences.
  • Compréhensible: représenté en utilisant la terminologie courante du public.

La section 4.3 de la norme IEEE 830 fournit une liste des attributs de qualité souhaités d'une spécification logicielle, qui sont :

« Un SRS doit être :

  1.  Correct;
  2. Non ambigu;
  3. Complet;
  4. Cohérent;
  5. Classé en fonction de son importance et/ou de sa stabilité ;
  6. Vérifiable
  7.  Modifiable ;
  8. Traçable.

Caractéristiques des exigences testables Pour que les exigences soient considérées comme testables, elles devraient idéalement avoir toutes les caractéristiques suivantes : Présentation des tests basés sur les exigences 8

1. Déterministe : étant donné un état initial du système et un ensemble d’entrées, vous devez être capable de prédire exactement quelles seront les sorties.

2. Sans ambiguïté : tous les membres du projet doivent tirer le même sens des exigences ; sinon, ils sont ambigus.

3. Correct : Les relations entre les causes et les effets sont décrites correctement.

4. Complète : toutes les exigences sont incluses. Il n’y a aucune omission.

5. Non redondant : tout comme le modèle de données fournit un ensemble de données non redondant, les exigences doivent fournir un ensemble non redondant de fonctions et d'événements.

6. Se prête au contrôle des changements : les exigences, comme tous les autres livrables d'un projet, doivent être placées sous contrôle des changements.

7. Traçable : les exigences doivent être traçables les unes par rapport aux autres, aux objectifs, à la conception, aux cas de test et au code.

8. Lisible par tous les membres de l'équipe projet : Les parties prenantes du projet, y compris les utilisateurs, les développeurs et les testeurs, doivent chacune parvenir à la même compréhension des exigences.

9. Rédigées dans un style cohérent : les exigences doivent être rédigées dans un style cohérent pour les rendre plus faciles à comprendre.

10. Les règles de traitement reflètent des normes cohérentes : les règles de traitement doivent être rédigées de manière cohérente pour les rendre plus faciles à comprendre.

11. Explicite : les exigences ne doivent jamais être implicites.

12. Logiquement cohérent : il ne devrait y avoir aucune erreur logique dans les relations entre les causes et les effets.

13. Se prête à la réutilisation : les bonnes exigences peuvent être réutilisées sur des projets futurs.

14. Concret : les exigences doivent être rédigées de manière brève, avec le moins de mots possible.

15. Annoté en termes de criticité : toutes les exigences ne sont pas critiques. Chaque exigence doit indiquer le degré d’impact qu’un défaut aurait sur la production. De cette façon, la priorité de chaque exigence peut être déterminée et l'accent approprié mis sur le développement et le test de chaque exigence. Nous n’avons pas besoin du zéro défaut dans la plupart des systèmes. Nous avons besoin de tests suffisamment bons.

16. Faisable : si la conception du logiciel n'est pas capable de répondre aux exigences, alors celles-ci ne sont pas réalisables.

Extrait de l'aperçu du processus de test basé sur les exigences

L’acronyme « INVESTIR » peut vous rappeler que les bonnes histoires sont :

  • je - Indépendant
  • N – Négociable
  • V - Précieux
  • E – Estimable
  • S - Petit
  • T – Testable

Il n’existe pas de norme unique définissant ce qui constitue une exigence logicielle de bonne qualité. De plus, ce qui peut être considéré comme une bonne exigence pour logiciel d'application sera probablement différent d'un bon logiciel système exigence.

Attributs de qualité des exigences

Assurance qualité des exigences automatisées

Exigences des tests ScopeMaster. Comme SonarQube pour les exigences, ScopeMaster examine chaque exigence (ou user story) pour détecter l'intention fonctionnelle et évalue chaque exigence par rapport aux critères de qualité répertoriés ci-dessus. Il ne peut pas détecter tous les défauts, mais il peut en trouver environ 50%. Après avoir analysé les exigences individuellement, il les examine ensuite dans le contexte de l'ensemble d'exigences. Cela fournit des informations qui ne sont tout simplement pas possibles avec des outils tels que Jira et Azure DevOps, ScopeMaster interprète et analyse exigences, il ne se contente pas de les stocker. Cela vous libère du temps pour considérer d’autres aspects importants de vos besoins. Cela rend votre travail d’amélioration de la qualité des exigences plus rapide et plus facile. Il fait le gros du travail à votre place.

Exigences La qualité en un coup d'œil
Résultats des tests de la user story de connexion

Dans le tableau présenté, les colonnes signifient :

  1. Le niveau de qualité de l'exigence individuelle (avec une certaine considération du contexte) test pour plus de 350 mots, expressions et modèles linguistiques pour plus de clarté.
  2. Clair et fonctionnel Contient des déclarations sans ambiguïté sur la fonctionnalité (description des mouvements de données).
  3. Orienté utilisateur Un utilisateur est identifié comme le sujet de l'exigence, effectuant une action avec des données.
  4. Concis le rapport entre les mots et la taille fonctionnelle, dans des limites raisonnables
  5. Mesurable et testable Si une intention fonctionnelle est détectée, alors elle est mesurable et testable, encore une fois nous déterminons s'il y avait une intention fonctionnelle claire.
  6. Complet (dans l'ensemble) désigne les types d'objets identifiés dans cette exigence qui ont des actions CRUD complémentaires pour garantir un ensemble complet d'activités de maintenance dans l'ensemble des exigences.
  7. Complet (fonctionnalité enterrée) fonctionnalité détectée dans les notes/critères d’acceptation qui auraient dû figurer dans l’exigence elle-même.
  8. Avantages Y a-t-il eu un effort pour décrire les avantages ou la valeur de cette exigence?

Notation de qualité

ScopeMaster reconnaît que les exigences n'existent pas en elles-mêmes. Il comprend le contexte d'un ensemble d'exigences et ainsi il détermine des scores de qualité à deux niveaux :

  1. Score de qualité pour chacun exigence individuelle
  2. Score de qualité pour un ensemble d'exigences

ScopeMaster effectue des centaines de tests statiques et potentiellement des milliers de tests dynamiques sur chaque exigence et donne un retour immédiat à l'auteur. Alors toi apprendre à rédiger de meilleures exigences comme vous allez.

Notation de la qualité des exigences