«SEG 3501»

D. Amyot uOttawa

SEG 3501 - Module 1

Écrire de meilleures exigences

Basé sur du matériel de:Ian Zimmerman, Telelogic (2001)

Ivy Hooks, Compliance Automation (1998)

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 2

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 3

Martine ne peut pas écrire d’exigences…Elle ne sait pas quoi faire!

― On ne lui a pas enseigné à l’école― Elle ne sait pas écrire― Elle ne comprend pas le processus― Elle n’a pas les données nécessaires― Elle ne sait pas ce qu’elle veut

Elle ne comprend pas pourquoi!― Elle ne comprend pas l’impact― Elle ne comprend pas le changement― Elle croit que c’est « juste un document »

Elle préfèrerait faire autre chose!― Elle ne voit aucune récompense― Elle préfèrerait concevoir― Elle n’a pas assez de temps― Elle croit que le processus de

révision va découvrir les erreurs

Source: Compliance Automation, Inc., 1998

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 4

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 comment le faire.― Peut dépendre du niveau d’abstraction…

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 5

“Le système doit permettre à l’utilisateur d’accéderau solde de son compte en moins de 5 secondes.”

Définit le sujet

Définit un résultat positif Critère de qualité

Verbe doit ou peut

Exemple d’une bonne exigence utilisateur

Cette exigence identifie un sujet spécifique ainsi qu’un résultat attendu

dans un délai maximal donné et mesurable.

Votre défi consiste à définir le sujet, le résultat attendu, et la mesure de

succès pour chaque exigence!

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 6

“L’utilisateur Internet voit rapidement le solde dede son compte sur l’écran du portable.”

Pas d’exigence sur l’utilisateur

Critère de qualité vague Comment plutôt que Quoi

Pas de verbe doit ou peut

Exemple d’une mauvaise exigence utilisateur

«SEG 3501»

D. Amyot uOttawa

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.― MUST NOT or SHALL NOT: absolute prohibition― SHOULD or RECOMMENDED: think twice about

not doing it!― SHOULD NOT or NOT RECOMMENDED: think

twice about doing it!― MAY or OPTIONAL: truly optional

Module 1: Écrire de meilleures exigences 7

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 8

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)

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 9

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

«SEG 3501»

D. Amyot uOttawa

Exemple

•Test: quoi versus comment…

Le système doit utiliser Microsoft Outlook pour envoyerun courriel au client qui contient la confirmation d’achat.

Le système doit informer le clientque l’achat est confirmé.

X

Module 1: Écrire de meilleures exigences 10

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 11

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.

«SEG 3501»

D. Amyot uOttawa

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

Module 1: Écrire de meilleures exigences 12

Le système SimplEntrée doit être facile à utiliser et demander un minimum de formation sauf pour le

mode professionnel

X

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 13

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

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.

X

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 14

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

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 15

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.

Le système SimplEntrée peut être complètement adaptable à toute situation et souvent ne requiert pas de configuration.

X

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 16

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.

― Exemple: “Le logiciel doit être fiable” échouerait ce test.

[Source: Spencer Smith, McMaster U.]

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 17

• 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 et puis changer la terminologie

•Rendre la vie des développeurs difficile

―Demander au lecteur beaucoup d’efforts 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

Spécification: Erreurs fréquentes

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 18

Évaluez ces exigences

1. Le système d’acquisition permet la saisie et le traitement rapide, convivial, et efficace des commandes.

2. Factures et reçus doivent être faxés automatiquement la nuit, afin que les clients puissent les recevoir dès le matin.

3. Le système doit pouvoir être mis à jour d’un seul coup.

Suggérez des améliorations lorsque nécessaire.

«SEG 3501»

D. Amyot uOttawa

Module 1: Écrire de meilleures exigences 19

Évaluez ces exigences

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

2. L’interface utilisateur doit être simple à utiliser.

3. Les données de l’utilisateur doivent autant que possible être obtenues automatiquement de l’estimé T&M.

Suggérez des améliorations lorsque nécessaire.

«SEG 3501»

D. Amyot uOttawa

N’oubliez pas...

•Question clé: ―“Pourquoi?”

ou “Quel est le but de cette exigence?”

•Caractéristiques essentielles―Nécessaire―Réalisable―Vérifiable

Module 1: Écrire de meilleures exigences 20

«SEG 3501»

D. Amyot uOttawa

Quelques outils d’analyse statique d’exigences

•QuARS ― Quality Analyzer of Requirements Specification

http://www.sei.cmu.edu/publications/documents/05.reports/05tr014.html

•ARM― Automated Requirement Measurement Tool

http://www.stcsig.org/quality/newsletters/NL0603/NL0603_Doc_Value-pf.html

•TIGER Pro― Tool to Ingest and Elucidate Requirements― http://www.therightrequirement.com/TigerPro/TigerPro.ht

ml

Module 1: Écrire de meilleures exigences 21