SEG3501-module1-Ecriture

SEG 3501 - Module 1
Écrire de meilleures exigences
Basé sur du matériel de:
Ian Zimmerman, Telelogic (2001)
Ivy Hooks, Compliance Automation (1998)
Module 1: Écrire de meilleures exigences
2
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
Module 1: Écrire de meilleures exigences
3
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…
Module 1: Écrire de meilleures exigences
4
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é
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!
Module 1: Écrire de meilleures exigences
5
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
Module 1: Écrire de meilleures exigences
6
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
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)
Module 1: Écrire de meilleures exigences
8
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
Module 1: Écrire de meilleures exigences
9
Exemple
•Test: quoi versus comment…
X
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é.
Module 1: Écrire de meilleures exigences
10
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. 
Module 1: Écrire de meilleures exigences
11
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
Le système SimplEntrée doit être facile à utiliser et
demander un minimum de formation sauf pour le
mode professionnel
Module 1: Écrire de meilleures exigences
X
12
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.
Module 1: Écrire de meilleures exigences
13
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
Module 1: Écrire de meilleures exigences
14
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.
Module 1: Écrire de meilleures exigences
15
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.]
Module 1: Écrire de meilleures exigences
16
Spécification: Erreurs fréquentes
• Bruit
•Souhait irréaliste
• Silence
•Casse-tête
• Sur-spécification
•Terminologie incohérente
• Contradiction
•Rendre la vie des
développeurs difficile
―La présence de texte qui
n’apporte aucune information
pertinente.
―Texte qui définit un fonction
qui ne peut pas être
vérifiable.
―Répartition d’exigences au
sein de plusieurs documents,
avec références croisées.
―Une fonction qui n’est pas
discutée par aucun
document.
―Texte qui décrit une solution
plutôt que le problème.
―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.
Source: Steve Easterbrook, U. de Toronto
―Inventer et puis changer la
terminologie
―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!
Module 1: Écrire de meilleures exigences
17
Évaluez ces exigences
Suggérez des améliorations lorsque nécessaire.
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.
Module 1: Écrire de meilleures exigences
18
Évaluez ces exigences
Suggérez des améliorations lorsque nécessaire.
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.
Module 1: Écrire de meilleures exigences
19
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
Quelques outils d’analyse statique
d’exigences
• QuARS
― Quality Analyzer of Requirements Specification
http://www.sei.cmu.edu/publications/documents/05.report
s/05tr014.html
• ARM
― Automated Requirement Measurement Tool
http://www.stcsig.org/quality/newsletters/NL0603/NL06
03_Doc_Value-pf.html
• TIGER Pro
― Tool to Ingest and Elucidate Requirements
― http://www.therightrequirement.com/TigerPro/TigerPr
o.html
Module 1: Écrire de meilleures exigences
21