Ingénierie des exigences - Principes de base de GenSpec (la théorie derrière l'outil)

Modif : 2013-10-21 1http://groups.google.ca/group/genspec
Ingénierie des exigences
(Requirements Engineering)
Principes de base
de GenSpec
(la théorie derrière l'outil)

Modif : 2013-10-21http://groups.google.ca/group/genspec2
Deux conférences internationales,
annuelles, spécifiquement en
Ingénierie des exigences (IE):
http://www.refsq.org
http://requirements-engineering.org

Introduction
 But:
 Préparation à la présentation de GenSpec
 Plan:
 Domaine de l’IE
 Problèmes courants
 Solution: adoption de principes de base de l'IE, et
utilisation d'un outil (… GenSpec)

Pour les articles principaux sur GenSpec, voir:
Dans la revue Direction informatique:
http://www.directioninformatique.com/savoir-exiger/7492
Dans la revue canadienne de l’IEEE, page 13:
http://www.ewh.ieee.org/reg/7/canrev/cr51/cr51.pdf
Pour d’autres informations sur l’ingénierie des exigences et GenSpec
(autres articles, travaux, discussions, …), voir:
Exigences de qualité des systèmes / logiciels:
http://fr.slideshare.net/PierrePi/exigences-de-qualit-de-systme-logiciel
Autres:
https://www.google.ca/search?q=genspec+exigences+logiciel+OR+outil+-Gratuit-
Correcteur+-bugzilla+-Outil-De-Gestion-Des-Exigences-Gratuit+-bayshore+-morlot+-
Telecharger-Logiciel-Ireb-Gratuit+-GenSpec-SA+-GenSpec-LLC+-repo-genspec+-GenSpec-
4200+-genspec-ltd-trinidad+-gs4001+-capteur

Introduction (suite)
 Portée:
 S'applique:
 À l'IE de tout produit ou service, de tout système, sous-système
ou autre composant
 Non seulement entre nous, fournisseur, et nos clients, mais
aussi entre nous, client, et nos fournisseurs
 NOTES:
 Ne met aucune emphase sur l'activité Élicitation, du processus
d'IE, parce qu'elle se concentre sur les problèmes d'IE les plus
importants vécus dans l’unité « Conception Automatismes » de
notre entreprise
(Élicitation: Recherche des exigences par des entrevues, la consultation
des documents existants, l'analyse de tâches, le développement de
prototypes, de maquettes, ...)
 Identifie ses documents de référence dans la section
« Commentaires » du présent PowerPoint

Domaine de l'IE
 Contexte
 Contenu
 Importance
 Principes de base

Domaine de l'IE – Contexte
 L’IE est une activité du processus de fourniture et du
processus d’acquisition
 Elle fait un lien entre le client et le fournisseur
 Ses intrants sont les besoins ou exigences brutes
spécifiés par le client
 Ses extrants sont les documents d’exigences:
spécification, cahier des charges, devis, contrat, appel
d’offres, norme, ...

Domaine de l'IE – Contenu
Ingénierie des exigences
Développement
des exigences
Gestion des
exigences
Élicitation Analyse Spécification Validation
Larry Boldt, Trends in Requirements Engineering
People-Process-Technology, Technology Builders, Inc., 2001
Création

Domaine de l'IE – Contenu (suite)
 Création:
 Début du processus: Apparition ou étude d'un
besoin, d'un problème, d'une opportunité, ...
 Développement des exigences:
 Élicitation: Recherche des exigences par des
entrevues, la consultation des documents
existants, l'analyse de tâches, le
développement de prototypes, de maquettes,
...
 Analyse: Comparaison, Négociation, Filtrage,
Complémentation, Caractérisation (incluant
Priorisation), Structuration et Liaison des
exigences

Domaine de l'IE – Contenu (suite)
 Développement des exigences (suite):
 Spécification: Documentation des exigences
 Validation: Vérification et Validation des
exigences
 Gestion des exigences:
 Implantation et Suivi de la traçabilité des
exigences
 Gestion des modifications / versions
d’exigences
(aussi appelée Gestion de la configuration)

Domaine de l'IE – Importance
 Problèmes majeurs si négligée:
 Augmentation des coûts et délais de réalisation
 Diminution de la qualité
 Base de l'entente client-fournisseur
 Base de fourniture et d’acquisition:
 Base de réalisation
 Base de vérification, de validation et d’acceptation par
le client
 Base de documentation

(suite)
 Selon le « Standish Group » (http://www.standishgroup.com/),
un des plus importants cabinets d'études
technologiques, les erreurs d'exigences sont:
 Les plus coûteuses
 Un des principaux facteurs de difficulté ou
d'échec des projets d'ingénierie logicielle

(suite)
Phase d'ingénierie Coût relatif de réparation
d'une erreur
1) Exigences 1
2) Conception 5
3) Réalisation 10
4) Essais 20
5) Maintenance 200
- plus une erreur est introduite tôt et détectée tard,
plus elle est coûteuse à corriger -

Domaine de l'IE – Principes de base –
Généralités, tirées de la littérature
 Exigences de boîte noire
 Exigences pour clients et
fournisseurs
 Exigences structurées
(… modifiables)
 Exigences simples
(... concises, non ambiguës)
 Exigences identifiables
 Exigences retraçables
 Exigences priorisées
 Exigences vérifiables
 Exigences exactes
 Exigences cohérentes
(sans contradiction, et homogènes)
 Exigences faisables
 Exigences nécessaires
 Exigences uniques
(non redondantes)
 Exigences individuelles
 Exigences complètes
 Exigences réutilisables

Généralités, tirées de la littérature (suite)
 Exigences d'interface:
 Exigences d’intrants et extrants externes: données
requises en entrée, requises en sortie, but, provenance
et destination
 Exigences de format des données échangées, intrants
et extrants externes, incluant leur unité, plage et
précision
 Exigences de synchronisation de ces échanges

Généralités, tirées de la littérature (suite)
 Exigences fonctionnelles:
 De façon générale:
 « Ce que le système doit faire »
 De façon plus précise:
 « Ce que le système doit faire à partir des intrants externes
pour supporter les extrants externes »
 Remarques:
 Relations requises entre les intrants externes
et les extrants externes
 Exigences fonctionnelles vérifiables, les Intrants et Extrants
étant externes, accessibles aux Vérificateurs

Généralités … – Traçabilité

Erreurs détectées par Traçabilité

Traçabilité Vs Coût
 Traçabilité: Couteux ?
 Oui, mais seulement si implémentée après
coup
 Avantages:
 Réduit le risque d'erreurs coûteuses
 Réduit les coûts de maintenance ...
 Analogie:
 Modularité logicielle: Coûteux ?
 Oui, mais seulement si implémentée après coup

Niveaux d'exigence

Lien entre Niveaux d'exigence
(conforme aux normes ISO/CEI/IEEE 12207, IEEE 830, IEEE 1233 et MIL 498)

Remarques
 Principe « Exigences de boîte noire » respecté
 Séparation claire entre Exigences et Conception
 Exigences plus stables que Conception (Conception
varient plus dans le temps, en raison de l'obsolescence
des technologies)
 Quelques avantages de cette séparation:
 Exigences réutilisables pour autres Conceptions,
notamment quand la technologie devient obsolète
 Exigences réutilisables pour aider à la pérennité des
connaissances (départs à la retraite …), parce que
documentées et relativement stables
 Documentation de conception plus facile, moins
coûteuse, à modifier, parce qu'isolée
 Séparation de paradigmes d'ingénieries bien différents
 Correspond à ce qui est enseigné, et normalisé

Problèmes courants
 Les exigences sont coûteuses à développer et à
gérer
 Les exigences sont incompréhensibles
 Les exigences sont incorrectes (inexactes, incomplètes,
incohérentes ou invérifiables)

Problèmes courants – Exigences
coûteuses
 Le budget est sous-évalué
 Les exigences incluent les moyens de réalisation*
 Les exigences sont mal structurées
 Les exigences d’interfaces sont instables
 Le formatage manuel n’est pas normalisé
 Les exigences sont incompréhensibles ou incorrectes
* Problème le plus important et difficile à corriger,
dû à un manque de formation en IE ?

coûteuses (suite)
 Les exigences incluent les moyens de réalisation
 Exemple:
 Besoin: Gestion des alarmes
 L'analyste, souvent un Concepteur/Programmeur dans son
paradigme de « Concepteur », voit deux fonctions:
 Acquisition des alarmes
 Signalisation des alarmes à l'utilisateur
 Exigences découlantes, incorrectes:
 Exig#1: Sur réception d'une alarme, le système doit la
mettre en file d'attente
 Exig#2: Le système doit signaler à l'utilisateur les alarmes
présentes en file d'attente
 Exigence correcte: Sur réception d'une alarme, le système doit
la signaler à l'utilisateur
 NOTE – Les exigences relatives au temps minimum requis
pour l'affichage des alarmes ou au traitement des avalanches
d'alarmes sont plutôt couvertes par les exigences de
performance

incompréhensibles
 Les exigences sont mal structurées (… non
graduelles*)
 Les exigences sont ambiguës
 Les exigences sont difficilement retraçables
* Problème le plus important et difficile à corriger,
dû à un manque de formation en rédaction technique ?

incorrectes
 Les exigences sont inexactes
 Les exigences sont incomplètes
 Les exigences sont incohérentes
 Les exigences sont invérifiables

incorrectes (suite)
 Les exigences sont incomplètes (principal facteur d’échec des projets TI
selon le Standish Group), souvent parce qu’elles ne couvrent pas
tous les « Types d’exigences »*:
 Types Interfaces externes (Types Exigences d’intrants, extrants, paramètres,
formats, synchronisation (règles d’échanges), …)
 Types Fonctions (Types Exigences d’évaluation, calcul, sélection, fournitures,
actions, …)
 Types Performances (Types Exigences de capacités, temps de réponses,
délais, …)
 Types Contraintes de conception (Types Exigences de respect de
limites matériels/logiciels, respect de l’environnement, respect de normes, …)
 Types Attributs (Types Exigences de facilité d’utilisation, sécurité, fiabilité,
maintenabilité, transférabilité, … ; voir: http://fr.slideshare.net/PierrePi/exigences-de-qualit-de-
systme-logiciel)
* Pour un éventail plus complet des « Types d’exigences », avec énoncé d’exigence par
défaut, voir: http://fr.slideshare.net/PierrePi/normalisation-des-exigences-44832196

incorrectes (suite)
 Les exigences sont invérifiables, souvent parce qu’elles
utilisent des termes vagues, à éviter dans tout énoncé
d'exigence:
 acceptable, adapté, adéquat, agile, approprié,
approximatif, assez, aussitôt, autant que possible,
beaucoup, bien, bon, certain, complexe, complexifier,
compliqué, convivial, correct, critique, de manière non
exhaustive, différent, divers, efficace, efficient, environ,
près de, ergonomique, essentiel, état de l'art, et/ou,
etc., et ainsi de suite, extrême, faciliter, flexible, grand,
grave, habituel, immédiat, intuitif, le mieux possible,
longtemps, majeur, mauvais, maximiser, mineur,
minimiser, moins, nécessaire, n'importe quel, optimiser,
parfois, périodique, petit, peu, peut-être, plus, plusieurs,
possible, précis, presque, quasi, quelques, rapide,
règles de l'art, requis, satisfait, simple, souvent,
suffisant, trop, typique, valable, varié, véloce, versatile,
…

incorrectes (suite)
 Les exigences sont invérifiables, aussi, notamment parce
qu’elles réfèrent à des intrants / extrants internes
 Exemple:
 Besoin: Gestion des alarmes
 L'analyste, souvent un Concepteur/Programmeur dans son
paradigme de « Concepteur », voit deux fonctions:
 Acquisition des alarmes
 Signalisation des alarmes à l'utilisateur
 Exigences découlantes, invérifiables (individuellement):
 Exig#1: Sur réception d'une alarme, le système doit la
mettre en file d'attente
 Exig#2: Le système doit signaler à l'utilisateur les alarmes
présentes en file d'attente
 Invérifiables parce qu'on ne peut les vérifier de l'extérieur;
exige d'entrer dans la « boîte noire », pour voir la file d'attente
 Exigence vérifiable: Sur réception d'une alarme, le système
doit la signaler à l'utilisateur

Solution
 Base de développement
 Détail:
 Allocation d’un budget suffisant
 Adoption de principes de base
 Utilisation d'un outil: … GenSpec

Solution – Base de développement
 Théories sur le développement de système
 Normes internationales (ISO/CEI/IEEE 12207, IEEE 830,
IEEE 1233, …)
 Documents de la NASA, du DOD et du NAS
 Guides de rédaction des lois, les exigences
étant souvent contractuelles, assujetties à une
interprétation légale

Théories sur le développement de système –
Environnement (aussi appelé Contexte)
 Schéma type d'environnement, parce qu'il est important de définir les
frontières du système à développer, les limites des exigences à couvrir
 Remarque: simplicité du schéma, se limite au message à communiquer; trop
souvent, ce schéma est encombré d'informations non pertinentes

Théories sur le développement de système –
Cas d'utilisation
Cas d'utilisation: 1) Source d'exigences; 2) Document distinct du doc. d'exigences

« Exigences des parties prenantes » Vs
« Exigences système » (ou logiciel)
 Exigences des parties prenantes (ou exigences
utilisateurs):
 Exigences exprimant le problème
 Exigences de haut niveau, de l'organisation ou du client
(niveau d'abstraction plus élevé que les exigences système)
 Source pour développer les exigences système
 Forme typique: « L'utilisateur doit être capable de ... »
 Exigences système (ou logiciel):
 Exigences exprimant la solution, répondant aux
exigences des parties prenantes
 Exigences souvent contractuelles
 Portée/limites clairement définies: intrants/extrants
externes clairement définis (environnement détaillé)
 Forme typique: « Le système doit ... »

Théories sur le développement de
système – Cas d'utilisation (suite)
 Cas d'utilisation exclus de la Spécification
d'exigences (carré => document distinct)
 Avantage:
 Réduit le risque d'incohérences dans la spécification
(contrat): contradictions, dans la même spécification,
entre Cas d'utilisation et Exigences, dues à des
erreurs de mise à jour:
 sur une incohérence, le fournisseur peut choisir la
moins coûteuse à implémenter
 il aura l'excuse: « C'est un problème de Spécification !
La corriger et donner du temps et de l'argent
supplémentaire pour faire corriger le logiciel »

système – Cas d'utilisation (suite)
 Deux méthodes d'IE:
 1ère: Cas d'utilisation détaillés
(Scénarios détaillés)
 2ème: Énoncés d'exigence
(« Le système doit … »)
 Choix: selon le contexte
 Attention, ne pas faire le travail en double; si
combinées, une méthode doit compléter l'autre
 Approche recommandée: démarrer avec la 1ère
et poursuivre avec la 2ème

système – Processus
 Des modifications sont apportées aux exigences pendant tout le processus de
développement (voir « Requirements » et « Change Mgmt » ci-dessus)
 Donc, dès le départ, prévoir des ressources (personnes, temps, argent) pour
effectuer ces modifications, tout au long du processus de développement
 Et faire l'IE de façon à faciliter ces modifications

système – Effort

système – Origine des erreurs

Normes internationales – ISO/CEI/IEEE
12207
 ISO/CEI/IEEE 12207: « Traitement de l'information,
Ingénierie du logiciel,
Processus du cycle de vie du logiciel »
 Dernière version: 1995 pour ISO/CEI, 1998 pour IEEE
 1995/1998, … obsolète ?
 aucune norme plus récente, couvrant le cycle de vie du
logiciel, ne peut la remplacer
 est utilisé par les militaires aux États-Unis, à la place de
la norme MIL 498 obsolète
 Intéressante autant pour sa forme (rigoureuse et bien
structurée) que pour son contenu (processus du cycle de vie du
logiciel)

Normes internationales – ISO 12207

12207 (suite)
 Bel exemple d'un document d'exigences de qualité:
 Vue d'ensemble avant vue détaillée
 Présentation des groupes d'exigences (liste)
 Un seul paragraphe par exigence
 Exigences simples, claires et concises
 Bien structuré / équilibré: exigences toutes au même
niveau de profondeur dans la structure du document
(niveau 4)
 Utilisation stricte des verbes:
 le verbe « devoir » est utilisé pour exprimer une obligation
 le futur exprime une déclaration d’intention
 l’expression « il convient de » exprime une recommandation
 le verbe « pouvoir » exprime une liberté d’action

12207 (suite)
 Format très limité, pour la présentation des exigences:
 Un seul paragraphe
 Possibilité d'une liste d'éléments
 Possibilité d'une note (et c'est tout !)
 Trop contraignant selon certains
 Pourtant, ces limites ont été respectées par l'équipe de
rédaction de la 12207
 … « Ce qui se conçoit bien s'énonce clairement et
les mots pour le dire arrivent aisément » (Nicolas Boileau)

Normes internationales – Directives
ISO/CEI

ISO/CEI (suite)
 Directives ISO/CEI, Partie 2,
Règles de structure et de rédaction des Normes
internationales (document d'exigences), 2004
(http://isotc.iso.org/livelink/livelink?func=ll&objId=4230454&objAction=browse&sort=subt
ype)
 Généralité: rédiger le document d'exigences de façon à ce
qu'il puisse être compris par des personnes qualifiées qui
n'ont pas pris part à son élaboration
 Homogénéité:
 Rédiger de façon analogue des exigences analogues,
et de façon identique des exigences identiques
 Utiliser le même terme pour désigner une notion
déterminée (un sens => un seul terme)
 Attribuer une seule signification à chaque terme choisi
(un terme => un seul sens)

ISO/CEI (suite)
 Remarques:
 Va à l'encontre de ce qu'on a appris, les règles de rédaction
littéraire: varier le style, les mots, utiliser des synonymes, …
 Avantages de l'homogénéité:
 Facilite/accélère l'écriture, la lecture et la compréhension;
 réduit le risque d'ambigüité
 réduit la quantité de texte requis (aide à la concision)
 Exemple:
 pour les exigences suivantes:
 Exig#1: À l'interface avec le C/D, l'UCD doit recevoir les alarmes de déglaçage
 Exig#2: À l'interface avec l'utilisateur, l'UCD doit fournir les alarmes de
déglaçage reçues du C/D sans tenir compte de l'état d'inhibition de ces alarmes
à l'UCD
 respectant les principes mentionnés
(un sens => un seul terme; un terme => un seul sens):
 le texte « reçues du C/D sans tenir compte de l'état d'inhibition de ces alarmes à
l'UCD » est inutile, parce que redondant
 parce qu'il s'agit du même terme, alarmes de déglaçage, utilisé dans ces deux
exigences, c'est qu'il s'agit exactement de la même donnée
 l'Exig#2 devrait être réécrite comme suit, pour les avantages de la concision
sans nuire à la clarté
À l'interface avec l'utilisateur, l'UCD doit fournir les alarmes de déglaçage

ISO/CEI (suite)
 Autres directives intéressantes:
 Ne spécifier que des exigences « vérifiables »
 Éviter les répétitions, faire plutôt référence, pour:
 réduire le risque d'erreurs et d'incohérences
 ne pas allonger le document
 Utiliser strictement les formulations verbales suivantes:
 « doit » pour exprimer une exigence
 « peut » pour exprimer une autorisation, une possibilité ou une
éventualité
 « il convient de » pour exprimer une recommandation (ne pas utiliser
« devrait »)
 Rédiger les définitions conformément aux exigences suivantes:
 une définition doit être telle qu'elle puisse être utilisée à la place du
terme défini. Toute information complémentaire doit être donnée
exclusivement sous forme d'exemples ou de notes
 une définition ne doit pas avoir la forme d'une exigence ni contenir
d'exigence

Formation à la Rédaction technique:
« l'Information Mapping »

Formation à la Rédaction technique:
« l'Information Mapping » (suite)

Normes internationales – IEEE Std 830
 IEEE Std 830: « Pratique recommandée par IEEE
pour la préparation de spécifications d’exigences de
logiciel »
 Dernière version: 1998
 Portée:
 se limite à la spécification
 exclut l'activité Élicitation, de laquelle découlent les
exigences
 1998, … obsolète ?
 aucune norme plus récente, couvrant la spécification
logiciel, ne peut la remplacer
 n'a pas véritablement changé depuis plusieurs années,
même après plusieurs révisions (indépendant de l'évolution de
la technologie)

(suite)
 Formation mutuelle:
 Le Client doit former le Fournisseur sur le domaine du problème
 Le Fournisseur doit former le Client sur le domaine de la solution, en
particulier sur l'IE (boite noire, …)
 Caractéristiques d'exigences bien rédigées:
 Exactes
 Non ambiguës
 Complètes
 Cohérentes
 Priorisées
 Vérifiables
 Modifiables
 Retraçables
« Le changement des exigences est aussi certain
que la mort et les impôts »

(suite)
 Modifiables: éviter la redondance
 Redondance:
 Avantage: facilite la lecture
 Désavantage: augmente le risque d'incohérences
 Recommandation: éviter la redondance
 Conclusion:
Privilégier « Facilité de modification »
sur « Facilité de lecture »
 Pourquoi ? … l'impact sur les coûts et délais
 NOTE – La « Facilité de lecture », ce n'est pas la « Clarté »;
les exigences doivent être aussi claires que possible

(suite)
 Plan type d’une spéc
 1 Introduction
 1.1 Objet
 1.2 Portée
 1.3 Définitions, acronymes et abréviations
 1.4 Références
 1.5 Vue d'ensemble
 2 Description générale
 2.1 Environnement
 2.2 Fonctions
 2.3 Caractéristiques des utilisateurs
 2.4 Contraintes
 2.5 Hypothèses et dépendances
 3 Exigences spécifiques

(suite)
 3 Exigences spécifiques
 3.1 Exigences des interfaces externes
 3.1.1 Interfaces avec les utilisateurs
 3.1.2 Interfaces avec le matériel
 3.1.3 Interfaces avec les logiciels
 3.1.4 Interfaces de communication
 3.2 Exigences fonctionnelles
 3.2.1 Mode 1
 3.2.1.1 Exigence fonctionnelle 1.1
 3.2.1.n Exigence fonctionnelle 1.n
 3.2.2 Mode 2
 3.2.m Mode m
 3.2.m.1 Exigence fonctionnelle m.1
 3.2.m.n Exigence fonctionnelle m.n
 3.3 Exigences de performance
 3.4 Contraintes de conception
 3.5 Attributs
 3.6 Autres exigences

(suite)
 Pourquoi « Exigences spécifiques » et non « Exigences »
?
 Parce que devrait se limiter aux exigences spécifiques
au système: les exigences génériques devraient se
trouver ailleurs, dans une autre spéc
 Remarque: Interface avant Fonction, l'extérieur avant
l'intérieur
 Avantages:
 Présentation naturelle de l'extérieur (les interfaces externes) vers
l'intérieur (les fonctions); les exigences d'interfaces externes, c'est
la définition du contexte, de l'environnement détaillé
 Le chapitre 3.1 joue aussi le rôle d'un glossaire: définition de
tous les intrants/extrants, avec leur but (conformément à la norme),
qui n'auront pas à être redéfinis par la suite
 Va simplifier la suite

(suite)
 3.1 Exigences des interfaces externes
 Description détaillée de tous les intrants et les extrants du
logiciel
 Devrait compléter plutôt que répéter la description des interfaces
de 2.0 Description générale
 Devrait inclure aussi bien le contenu que la forme:
 Nom de l'élément (nom de chaque intrant/extrant)
 But (de chaque intrant/extrant)
 Provenance des intrants ou destination des extrants
 Échelle, degré de précision et/ou degré de tolérance acceptables
 Unités de mesure
 Synchronisation (des échanges des intrants/extrants)
 Rapports avec les autres intrants/extrants
 Format et organisation des écrans
 Format et organisation des fenêtres
 Format des données
 Format des commandes
 Messages de fin

(suite)
 3.2 Exigences fonctionnelles
 Définition des actions que doit exécuter le logiciel pour la réception
des intrants, leur traitement et la génération des extrants
 Remarques:
 Liaison implicite des Intrants / Extrants des Interfaces externes
avec les Fonctions (par l'utilisation des mêmes termes pour
l'identification des intrants / extrants concernés)
 Liaison explicite préférable
 Nombreux avantages:
 Réduit le risque d'exigences invérifiables, les intrants/extrants des
exigences fonctionnelles étant accessibles de l'extérieur
 Réduit le risque d'exigences ne faisant pas abstraction des moyens de
réalisation (ex: architecture du système), les intrants/extrants des exigences
fonctionnelles ne pouvant être qu'externes
 Réduit le risque d'exigences incohérentes (intrant sans fonction ou extrant
associé, extrant sans fonction ou intrant associé)
 Réduit le risque d'exigences incomplètes (oublier des intrants, extrants,
fonctions)
 Offre la possibilité de générer automatiquement une première ébauche
des spécifications d'exigences de composant, notamment à partir de
données d'attribution des exigences aux composants
 Source d'un extrant peut être non seulement une fonction mais
aussi un Intrant

Boîte noire
Système
externe
# 2
Système
externe
# 1
Système
externe
# n
(suite)
 Illustration de la logique de la structure recommandée par la 830
 Approche simple et systématique (voir la suite)

Exig.
Intrant # 2
Exig.
Intrant # 3
Exig.
Intrant # n
Exig.
Extrant # 2
Exig.
Extrant # n
Boîte noire
Exig.
Intrants
spécifiques
d’interface
Exig.
Extrants
spécifiques
d’interface
Exigences des interfaces externes
Exig.
Intrant # 1
(avec but) Système
externe
# 2
Système
externe
# 1
Système
externe
# n
Exig.
Extrant # 1
(avec but)
(suite)
 Remarques:
 Schéma d'environnement détaillé
 Intrants/extrants spécifiques d'interface, c'est, par exemple, la commande de
fermeture d'une fenêtre Windows

Exig.
Intrant # 2
Exig.
Intrant # 3
Exig.
Intrant # n
Exig.
Extrant # 2
Exig.
Extrant # n
Boîte noire
Exig.
Intrants
spécifiques
d’interface
Exig.
Extrants
spécifiques
d’interface
Exigences des interfaces externes
Exigence fonctionnelle # 1
Exigence fonctionnelle # 2
Exigence fonctionnelle # n
Autres exigences
Exig.
Intrant # 1
(avec but) Système
externe
# 2
Système
externe
# 1
Système
externe
# n
Exig.
Extrant # 1
(avec but)
(suite)
 Remarques:
 Tout extrant à une interface externe peut être affecté par plusieurs exigences
fonctionnelles
 Tout extrant à une interface externe peut être utilisé comme intrant à une exigence
fonctionnelle

(suite)
 Exemple simple (respectant la norme):
 3.1. Exigences des interfaces externes:
 3.1.1. Interface avec l'exploitant
 Exigence # 13: Le système doit être capable de fournir la valeur
de la Puissance réelle de la centrale (PRC). Priorité: essentielle;
Source: [3] 2.2, [6] 5.2.4; …
 ...
 3.1.5. Interface avec les appareils
 Exigence # 45: Le système doit être capable de recevoir la valeur
de la Puissance réelle de chaque groupe turbine-alternateur
(PRGTA). Priorité: essentielle; Source: [6] 5.2.4; …
 ...
 3.2. Exigences fonctionnelles
 3.2.5. Calcul des puissances
 Exigence # 28: Le système doit calculer PRC selon la formule
suivante: PRC = ∑ PRGTA. Priorité: essentielle; Source: [6] 5.2.4;
…
 ...

Pour des exemples complets
de spécifications
respectant la norme 830 de IEEE,
voir:
http://groups.google.ca/group/genspec

(suite)
 NOTE – Cette présentation ne met aucune emphase sur les autres
exigences non fonctionnelles, parce qu'elle se concentre sur les
problèmes d'IE les plus importants vécus par l'unité Conception-
Automatismes d'HQ
(Autres exigences non fonctionnelles: exigences de performance, contraintes de
conception; attributs [disponibilité, maintenabilité, sécurité, ...])

 Remarques:
 Les exigences présentées au client et celles présentées au
fournisseur (communauté technique) sont les mêmes
 En revanche, leur format de présentation à l'un et à l'autre peut
être différent
 IEEE Std 1233: « Guide de l'IEEE pour le développement de la
spécification d’exigences de système »

(suite)
 Remarques (suite):
 Structure de la spécification d'exigences système:
 La structure de la spéc. d'exigences système,
donnée en exemple dans la 1233 (annexe de la 1233),
est très différente de celle recommandée par la 830
 Cependant, toute organisation se doit d'uniformiser
ses documents, autant que possible, comme
d'ailleurs le fait la norme MIL 498 (ex: SSS-DID vs SRS-
DID)
 C'est pourquoi l'Unité Conception – Automatismes
d'HQ a choisi la même structure pour l'ensemble de
ses spéc. d'exigences: la structure recommandée
par la 830, jugée la plus intéressante

Documents de la NASA, du DOD
et du NAS
 Exemple de spéc. de la NASA: … Telemetry Collection
and Formatting
 301 The flight software shall collect incoming data from individual telemetry sources
in the form of CCSDS telemetry packets
 301.1 The flight software shall insure that memory, table, and event buffer dumps do not
flood the downlink or over utilize the onboard CPU
 301.2 The flight software shall be able to selectively discard incoming data according to a
ground-controlled filtering scheme. The ground shall be able to specify that every n'th
packet be telemetered for a given packet application ID. The ground shall be able to
specify that either all or none of a specified packet be telemetered
 301.3 The flight software shall be capable of transmitting the data in any onboard telemetry
packet to the ground in real-time
 301.4 CCSDS packets shall consist of a primary header, a secondary header, and
application data
 301.4.1 The CCSDS Packet Secondary Header shall contain a time code with the first bit set to
zero to indicate that this is a non-standard CCSDS secondary header
 301.4.2 The CCSDS packet application data shall contain variable length data fields even within a
specific application ID
 301.4.3 The flight software shall support CCSDS source-internal segmentation
 301.4.4 The flight software shall support telemetry packets of 8 to 3700 bytes in total length
(CCSDS length + 7)

et du NAS (suite)
 Exemple de spéc. de la NASA (suite):
 Beaucoup d'articles et d'exemples sur Internet
 Remarques:
 Numéro d'exigence
 Utilisation systématique du verbe « devoir »
 Un seul paragraphe par exigence
 Exigences simples, claires et concises
 Présentation hiérarchique des exigences
 avantages:
 réduit le risque d'oublier des exigences (aide à tout couvrir)
 réduit le risque de redondance/incohérence, de répéter la même
exigence sans/avec erreur
 réduit le risque d'incompréhension: présentation petit à petit de la vue
d'ensemble à la vue détaillée
 facilite la traçabilité (exigences parents – exigences enfants)

et du NAS (suite)
 Article de la NASA, et du DOD: … Statement Structuring
 Poorly structured individual requirement statements will result in
confusing specifications that are prone to incorrect interpretations.
The following is such a statement:
 3.1 The XYZ system shall provide variance/comparative information
that is timely, itemized in sufficient detail so that important individual
variances are not obscured by other variances, pinpoints the source of
each variance, and indicates the area of investigation that will
maximize overall benefits
 This specification can more easily be understood if structured as
follows:
 3.1 The XYZ system shall provide variance/comparative information
 3.1.1 Variance/comparative information shall be timely
 3.1.2 Variance/comparative information shall be itemized in
sufficient detail to do the following:
 3.1.2.1 Prevent important individual variances from being obscured by other
variances
 3.1.2.2 Pinpoint the source of each variance
 3.1.2.3 Indicate the area of investigation that will maximize overall benefits

et du NAS (suite)
 DOD, MIL Std 498: « Military standard, Software
development and Documentation », 1994
(http://www.abelia.com/498pdf/roadmap.pdf; norme obsolète, mais
quand même très intéressante, riche de connaissances et
d'expériences [remplacée par la 12207, moins riche ...]):
 Normes pour SES (SSS) et SEL (SRS) quasi
identiques:
 Structure SES identique à la structure SEL
 logique: exigences de boîte noire à tous les niveaux
 Normes SES / SEL distinctes de Norme SEI
(IRS):
 Exigences d'interface dans des documents dédiés

et du NAS (suite)
 Exigences d'interface dans des documents dédiés:
 Désavantage:
 Difficulté de lecture, parce que loin des fonctions: formats
des transactions/fenêtres décrits dans un document, la SEI,
et fonctions associées décrites dans un autre document, la
SES/SEL
 Avantages:
 Exigences d'interface plus faciles à uniformiser, parce que
centralisées; c'est important, en particulier pour une IPM, que
ces exigences soit uniformes. Exemple: Bouton « Ok »
toujours à droite en bas, dans toutes les fenêtres
 Exigences plus facilement modifiables, parce que
centralisées
 Charge de travail importante isolée, pouvant être mise en
œuvre par une même personne, aidant à l'uniformisation
 Remarque:
 Respecte le principe de Privilégier « Facilité de
modification » sur « Facilité de lecture »

et du NAS (suite)
 Diagramme / Cycle en « V » associé à la 498,
pour montrer les niveaux d'exigences
 Avantage d'une telle vision
(exigences à tous les niveaux):
 Beaucoup d'IE, formant beaucoup de spécialistes
dans un domaine de première importance, l'IE
 À tout moment dans le cycle en « V » (par itération),
advenant un manque de ressources internes, il est
possible, très rapidement, de:
 fournir le document d'exigences (contrat)
correspondant à un fournisseur
 produire le cahier d'essais correspondant pour
vérification et acceptation/refus complet, partiel ou
conditionnel du livrable du fournisseur

et du NAS (suite)
 NAS (National Airspace System, aux Etats-Unis)
 Human Factors Design Standard (http://hf.tc.faa.gov/hfds/):

et du NAS (suite)
 NAS (National Airspace System, aux Etats-Unis)
 Human Factors Design Standard:
 Un autre bel exemple d'un document d'exigences de
qualité:
 Priorité d'exigence / Utilisation stricte des verbes
d'exigence (carré vide/plein pour should/shall)
 Un titre par exigence
 Un seul paragraphe par exigence
 Exigences simples, claires et concises
 Identification de la source
 Discussion (ou Exemple, Définition, Note, …)

Guides de rédaction des lois
 L'humanité a plusieurs centaines d'années
d'expérience en développement et gestion
rigoureuse des lois
 beaucoup plus qu'en IE
 On peut assurément en tirer plusieurs principes
intéressants pour l'IE

Guides de rédaction des lois (suite)
 Exemple:
 Protocole de rédaction uniforme, Canada, 2013
(http://www.ulcc.ca/fr/lois-uniformes-nouvelle-structure/conventions-de-la-
redaction/547-josetta-1-fr-fr/lois-uniformes/conventions-de-la-redaction/67-
protocole-de-redaction-uniforme 6)
1. Composition logique: Le texte de loi est organisé de façon logique. Le respect
de la progression normale des idées fait partie de la composition logique. Il
convient de procéder du général au particulier et de présenter par exemple
dans leur ordre chronologique les étapes d'une procédure judiciaire ou d'une
demande adressée à une administration ou en émanant
2. Style: Le texte de loi est d'un style simple, clair et concis et comporte le degré
de précision nécessaire
3. Teneur de la définition: La définition ne doit pas comporter d'élément de fond
4. Sens naturels: La définition ne doit pas donner aux termes définis des sens
artificiels
5. Renvois internes: Il convient de faire un usage parcimonieux des renvois
internes. Les renvois internes multiples sont inutiles dans un texte de
composition logique
6. Langage courant: En règle générale, la rédaction du texte de loi se fait en
langage courant, tant sur le plan lexical que sur le plan syntaxique. L'emploi de
termes techniques se limite aux cas où la précision l'exige
7. Uniformité: (1) Le terme défini ne s'emploie pas, dans le même texte de loi,
dans une autre acception. (2) Il convient de ne pas exprimer la même notion,
dans un texte de loi, par des termes différents
8. …

Solution – Allocation d’un budget
suffisant
La solution consiste d’abord à s’assurer de
l’allocation d’un budget suffisant: le budget alloué
à l’IE représente généralement de 15 à 30% du
budget total de développement, excluant la
maintenance

Solution – Adoption de principes de
base
 Suivre les principes de base tirées de la littérature (boite
noire, …), mais surtout:
 Fixer les limites par un schéma d'environnement (IEEE,
Wiegers)
 Structurer les exigences de façon hiérarchique (NASA;
facilite compréhension)
 Limiter chaque exigence à un paragraphe (CEI, NASA,
NAS; simple, claire et concise)
 Référer aux exigences sources (IEEE; … claire, exacte et
retraçable)
 Utiliser des renvois plutôt que la redondance (CEI, IEEE;
… modifiables)
 Relier les exigences dépendantes par des renvois et,
pour chacun, en donner la raison (… modifiables)
 Respecter rigoureusement les règles de rédaction
technique (CEI; uniformiser, éviter synonymes, …)

Exigences modifiables
 Suivant les principes énoncés sur la diapositive précédente, les exigences peuvent être
vues comme un simple empilement de briques – exigence simple, claire et concise,
encapsulée – interreliées
 Assurément, cela facilite l’ajout, le retrait et la modification d’exigences, et réduit le
risque d’incohérences
 En effet, quand vient le temps de modifier/retirer une exigence, il suffit de revoir
exclusivement les exigences reliées: liens implicites enfant-enfant (exigences sœurs), lien
implicite parent-enfant, liens intrant-extrant-fonction, et autres liens (renvois)

Solution – Adoption de principes de
base
 Suivre les principes suivants (suite):
 Spécifier les interfaces avant les fonctions (au moins les
intrants/extrants requis; IEEE 830; composition logique, de l'extérieur vers
l'intérieur; facilite compréhension)
 Relier les fonctions avec les interfaces (IEEE 830; réduit
incohérences, exigences incomplètes)
 S’assurer de couvrir tous les types d’exigence (IEEE 830 ;
exigences complètes)
 Spécifier les interfaces dans des documents dédiés
(DOD; … modifiables)
 ...
 Limiter les énumérations (loi de Miller, « Information Mapping »; facilite
compréhension)
 …

Exigences vérifiables
 Suivant les principes énoncés sur la diapositive précédente, les exigences fonctionnelles sont liées
aux intrants/extrants externes:
 Réduit le risque d'exigences invérifiables, les intrants/extrants des exigences fonctionnelles
étant accessibles de l'extérieur
 Réduit le risque d'exigences ne faisant pas abstraction des moyens de réalisation (ex: architecture
du système), les intrants/extrants des exigences fonctionnelles ne pouvant être qu'externes
 Réduit le risque d'exigences incohérentes (intrant sans fonction ou extrant, extrant sans fonction ou
intrant)
 Réduit le risque d'exigences incomplètes (oublier des intrants, extrants, fonctions)
 Offre la possibilité de générer automatiquement une première ébauche des spécifications d'exigences
de composant, notamment à partir de données d'attribution des exigences aux composants

Solution – Utilisation d'un outil: …
GenSpec
 Principes lourds à suivre avec un traitement de
texte:
 En général: lourds à suivre avec rigueur;
principes rapidement laissés de côté
 En particulier: lourd à suivre, le principe
d’utilisation des renvois. L’utilisation de renvois
est problématique avec un traitement de texte
(MsWord): séquence de commandes lourdes, et
pertes de renvois

GenSpec (suite)
 Solution: utilisation d'un outil spécialisé, commercial ou
maison (aussi appelé Outil propriétaire)
 Plusieurs outils commerciaux disponibles: DOORS,
Analyst Pro, Rational RequisitePro, IRqA, System
Architect, …
 Avantages: outils commerciaux puissants, offrant
notamment des facilités de traçabilité des exigences, de
conception et même de génération de code logiciel
 Désavantages: en général, outils commerciaux
complexes, coûteux, courbe d'apprentissage longue, outils
peu flexibles quant aux formats des documents générés
(anglais, …), ou non axés sur les principes présentés

DOORS (semble être le plus utilisé)

GenSpec (suite)
 HQ a développé son propre outil:
 GenSpec:
 Allège le suivi des principes
 Par rapport à un traitement de texte, réduit:
 les coûts, notamment par des automatisations
 la quantité d'erreurs, notamment par des vérifications
automatiques
 Est:
 en amélioration continue depuis 2001
 disponible à tous, gratuitement, à l'extérieur comme à
l'intérieur d'HQ
 le sujet d'un groupe de discussion sur Internet,
permettant le partage …

GenSpec

Avantages de DOORS
sur GenSpec
 Disponible en version anglaise
 Permet la définition des cas d'utilisation
 Permet le multi-usagers à travers le web
 Fonctions de traçabilité plus puissantes
 Gestion multi-versions des exigences plus puissante
 Support multi-formats (de documents importées ou liés, incluant diagrammes UML) plus puissant
 Une même procédure d'essais peut être assignée à plusieurs exigences
 Possibilité pour les utilisateurs de créer des « scripts » de vérifications des exigences
 Outil d'aide convivial à l'importation de données
 Fonctionne sur plusieurs plates-formes
 Documentation riche
 Grande quantité d'utilisateurs / groupes de discussion
 Gestion de l'état des exigences (valide, attribuée, implémentée, testée, …), … par courriel
 Facilités d'ajout d'attributs aux exigences (ex: date livraison); et de tri, de fabrication de vue et de
génération de rapport
 Possibilité de liaison d'exigences inter Documents-DOORS
 Interopérabilités (avec autres outils commerciaux)
 Support disponible (pas seulement à travers un groupe de discussion)

Avantages de GenSpec
sur DOORS
 Options de formatage des documents générés (n'est pas la force de DOORS; DOORS surtout fait pour de la
gestion d'exigences directement dans une BD par une interface web; avec DOORS, c'est « compliqué » de générer
des documents d'envergure faciles à lire et bien formatés, pour le client et le fournisseur)
 Coût (DOORS est assez dispendieux [6000$/pers+2000$/pers/an, incluant le logiciel facilitant le formatage des doc
d'exigences]; et peu de ses fonctionnalités sont généralement utilisées)
 Courbe d'apprentissage plus courte (prise en main: 2 jours; aucune formation requise)
 Suit rigoureusement et de façon plus détaillée la norme 830 de IEEE
 Outil de normalisation des exigences: génère automatiquement un texte d'exigence par défaut selon
le type d’exigence sélectionné – texte et type paramétrables –, et prévient l'utilisation de synonymes
 Outil d'aide à la composition logique: dès qu'un nouveau concept/terme est introduit, dans le
document d'exigences, il est automatiquement présenté/défini (option de la fonction Glossaire)
 Outil de liaison des exigences plus puissant, les types de lien et leur gestion étant prédéfinis
 Contrôle et vérifications automatiques des exigences, intégrés (dans DOORS, il faut les créer au moyen de
scripts; peu d'utilisateurs de DOORS font de telles vérifications au moyen de scripts, demandant trop d'énergie)
 Outil plus facilement modifiable (pour HQ, parce qu'elle en possède le code)
 Outil en français (DOORS et sa documentation, non disponibles en français; support très peu disponible en
français)

Avantages de GenSpec
sur DOORS (suite)
GenSpec,
davantage intéressant
pour le Développement des exigences
DOORS,
pour la Gestion des exigences

Conclusion
 Plusieurs problèmes importants en IE
 Compte tenu de l’importance de l'IE, il est
souhaitable que ces problèmes soient résolus
 Solution:
 Suivi de principes de l'IE
 Utilisation d'un outil spécialisé … GenSpec:
facilite ce suivi, avec toute la rigueur requise

Suite:
Présentation détaillée de GenSpec
(http://www.slideshare.net/PierrePi/ingnierie-des-exigences-prsentation-de-genspec-presentation)

Ingénierie des exigences - Principes de base de GenSpec (la théorie derrière l'outil)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Ingénierie des exigences - Principes de base de GenSpec (la théorie derrière l'outil)

Similaire à Ingénierie des exigences - Principes de base de GenSpec (la théorie derrière l'outil) (20)

Ingénierie des exigences - Principes de base de GenSpec (la théorie derrière l'outil)

Notes de l'éditeur