Écrire de meilleures exigences SEG3501 Écrire de meilleures exigences Daniel Amyot, Université d’Ottawa Basé sur du matériel de: Ian Zimmerman, Telelogic (2001) Ivy Hooks, Compliance Automation (1998)

Aperçu de la présentation Directives pour l’écriture d’exigences Exemple d’une bonne exigence utilisateur Quelques lignes de conduite Tests et erreurs fréquentes Exercices de critique et de réécriture

Directives pour l’écriture d’exigences Chaque exigence doit être une phrase complète. Chaque exigence doit contenir un sujet et un prédicat: Sujet: système discuté, ou utilisateur (attention…) Prédicat: condition, action, ou résultat attendu Utilisation cohérente du verbe: doit (« shall ») pour exigences obligatoires peut (« should ») pour exigences optionnelles L’exigence doit contenir un critère de succès ou une autre indication mesurable de la qualité. L’exigence doit décrire ce qui doit être fait, et non (prématurément) comment le faire. Peut dépendre du niveau d’abstraction…

Exemple d’une bonne exigence utilisateur Définit le sujet Verbe doit ou peut “Le système doit permettre à l’utilisateur d’accéder au solde de son compte en moins de 5 secondes.” Définit un résultat positif Critère de qualité Votre défi consiste à définir le sujet, le résultat attendu, et la mesure de succès pour chaque exigence!

Exemple d’une mauvaise exigence utilisateur Pas d’exigence sur l’utilisateur Pas de verbe doit ou peut “L’utilisateur Internet voit rapidement le solde de de son compte sur l’écran du portable.” Critère de qualité vague Comment plutôt que Quoi

Normes pour les mots clés Certaines normes cherchent à standardiser l’utilisation des verbes et adjectifs clés dans leurs documents. Exemple: IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels MUST, REQUIRED or SHALL: mean that the definition is an absolute requirement of the spec. (doit) MUST NOT or SHALL NOT: absolute prohibition (ne doit pas) SHOULD or RECOMMENDED: think twice about not doing it! (devrait) SHOULD NOT or NOT RECOMMENDED: think twice about doing it! (ne devrait pas) MAY or OPTIONAL: truly optional (peut)

Qualités des exigences Selon IEEE-STD-830-1998 et autres, chacune des exigences: Doit être valide/nécessaire (une exigence réelle) Doit être réalisable (considérant les ressources disponibles) Doit être vérifiable /testable Doit être exprimée d’une façon claire, concise et cohérente Doit être non-ambiguë Devrait être uniquement identifiable Devrait avoir un bénéfice qui l’emporte sur les coûts qu’elle engendre Devrait être importante dans la solution du problème Devrait être en concordance avec les standards et pratiques Devrait mener à un système de qualité Ne devrait pas sur-contraindre le système Devrait être modifiable (car elle va évoluer)

Quelques lignes de conduite (1/4) Ne pas concevoir prématurément le système Indiquez plutôt ce que le système doit faire, et non comment le faire Signes de sur-spécification: utilisation de noms de composants, de matériaux, de champs du système… La conception prématurée peut mener à des coûts plus élevés en éliminant trop tôt des alternatives qui seraient plus efficaces. Ne pas mélanger différents types d’exigences Évitez de mélanger exigences utilisateur, système, et de processus

X Exemple Test: quoi versus comment… Le système doit utiliser Microsoft Outlook pour envoyer un courriel au client qui contient la confirmation d’achat. Le système doit informer le client que l’achat est confirmé.

Quelques lignes de conduite (2/4) Ne laissez pas de clauses échappatoires Pourraient mener à des problèmes de test Évitez si possible si, mais, sauf, excepté, à moins que/de, cependant Cependant, ces termes peuvent être utiles si d’énumérer tous les cas spécifiques est difficile. Évitez les ambiguïtés Évitez les définitions pauvres (seulement des exemples) L’utilisation des mots ou/et car ils peuvent porter à confusion (en l’absence de parenthèses)… Évitez les « etc. », « ainsi de suite », etc. 

X Exemple Évitez les termes vagues Plusieurs mots utilisés informellement pour indiquer des qualités sont trop vagues pour être vérifiés Par exemple: convivial, hautement versatile, flexible, autant que possible, approximativement, impact minimal X Le système SimplEntrée doit être facile à utiliser et demander un minimum de formation sauf pour le mode professionnel

Quelques lignes de conduite (3/4) N’écrivez pas d’exigences multiples Une exigence par phrase Évitez les conjonctions et, ou, avec, ainsi que Évitez les termes archaïques Évitez les références à des documents inaccessibles X Le module de Navigation de SimplEntrée doit contenir la commande et les communications, le traitement, les résultats et les rapports. Le module de Commande doit être intégré au système Intranet et les résultats emmagasinés dans le dossier client.

Quelques lignes de conduites (4/4) Évitez les termes spéculatifs Les exigences ne sont pas une liste de souhaits! Évites les généralisations vagues Signes de dangers: habituellement, généralement, souvent, normalement, typiquement Éviter d’inclure des suggestions ou possibilités. Des suggestions qui ne sont pas explicitement émises comme exigences sont invariablement ignorées par les développeurs Indiquées par des termes tels que: peut, pourrait, devrait, peut-être, probablement

X Exemple Évitez d’être irréalistes Ne demandez pas l’impossible! Termes symptomatiques: fiable à 100%, sécuritaire, gère toutes les erreurs, fonctionne sur toutes les plateformes. X Le système SimplEntrée peut être complètement adaptable à toute situation et souvent ne requiert pas de configuration.

Quelques tests simples… Test Quoi versus Comment Spécifie comment faire quelque chose au lieu de quoi faire (sur- spécification) Exemple: une exigence peut spécifier une équation différentielle qui doit être résolue, mais elle ne devrait pas mentionner qu’une approche Runge-Kutta de 4e ordre devrait être employée. Test Qu’est-ce qui est éliminé Est-ce que l’exigence prend une décision (si aucune alternative n’est éliminée, alors aucune décision n’a réellement été prise)? Exemple: une exigence particulière pourrait déjà être couverte par une exigence plus générale. Test par Négation Si la négation d’une exigence représente une vue que quelqu’un pourrait supporter, alors la décision originale est probablement significative. L’échec de ce test pourrait indiquer un but, mais pas encore une exigence, Exemple: “Le logiciel doit être fiable” échouerait ce test. [Source: Spencer Smith, McMaster U.]

Spécification: Erreurs fréquentes Bruit La présence de texte qui n’apporte aucune information pertinente. Silence Une fonction qui n’est pas discutée par aucun document. Sur-spécification Texte qui décrit une solution plutôt que le problème. Contradiction Texte qui décrit une fonction de plusieurs façons incompatibles. Ambiguïté Texte qui peut être interprété d’au moins deux façons. Souhait irréaliste Texte qui définit un fonction qui ne peut pas être vérifiable. Casse-tête Répartition d’exigences au sein de plusieurs documents, avec références croisées. Terminologie incohérente Inventer/changer la terminologie Rendre la vie des développeurs difficile Demander au lecteur un effort pour déchiffrer ce qui est demandé Écrire pour des lecteurs hostiles Il y en a moins que des lecteurs amis! Source: Steve Easterbrook, U. de Toronto

Patrons pour exigences fonctionnelles: Easy Approach to Requirements Syntax (EARS) A Ubiquitous requirement is continually active and takes the form The <system name> shall <system response> A State-driven requirement is active while some precondition remains true and takes the form WHILE <precondition> the <system name> shall <system response> An Event-driven requirement is activated when a triggering event is detected at the system boundary and takes the form WHEN <trigger> the <system name> shall <system response> An Option requirement is used for systems that include a particular feature and take the form WHERE <feature is included> the <system name> shall <system response> An Unwanted Behavior requirement defines the required system response to an unwanted external event and takes the form IF <trigger> THEN the <system name> shall <system response> The basic EARS patterns can be combined to build Complex requirements, for example WHILE <precondition> WHEN <trigger> the <system name> shall <system response>. A. Mavin et al., Listens Learned (8 Lessons Learned Applying EARS). RE’16, 276-282, IEEE CS, 2016

Évaluez ces exigences Suggérez des améliorations lorsque nécessaire. Le système d’acquisition permet la saisie et le traitement rapide, convivial, et efficace des commandes. Factures et reçus doivent être faxés automatiquement la nuit, afin que les clients puissent les recevoir dès le matin. Le système doit pouvoir être mis à jour d’un seul coup.

Évaluez ces exigences Suggérez des améliorations lorsque nécessaire. Le module d’Entrée des Commande doit être entièrement intégré au Système Intranet et les résultats doivent être emmagasinés dans l’enregistrement du client. L’interface utilisateur doit être simple à utiliser. Les données de l’utilisateur doivent autant que possible être obtenues automatiquement de l’estimé T&M.

Exemple d’outil: Respecify Respecify: Outil Web pour la rédaction d’exigences Utilise un langage naturel contraint pour guider le processus de rédaction d’exigences et spécifications Complétions, glossaire, synonymes/sémantique Wordnet, relations… Cohérence accrue! M. Ledger: A demonstration of Respecify: a requirements authoring tool harnessing CNL. RE 2017. IEEE CS, 472-473

Autre outil commercial: RAT Requirements Authoring Tool (RAT) https://www.reusecompany.com/authoring-tools Claims: Tools and plug-ins to assist you in the activity of writing requirements and other natural language texts. Performs Correctness and Consistency analysis on the fly Suggests controlled-vocabulary items based on a central knowledge base Fully integrated into your Requirements Management Tool and Modelling Tool

Caractéristiques essentielles N’oubliez pas... Question clé: “Pourquoi?” ou “Quel est le but de cette exigence?” Caractéristiques essentielles Nécessaire Réalisable Vérifiable