SlideShare une entreprise Scribd logo
1  sur  96
Télécharger pour lire hors ligne
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
Modif : 2013-10-21http://groups.google.ca/group/genspec3
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
Modif : 2013-10-21http://groups.google.ca/group/genspec4
Modif : 2013-10-21http://groups.google.ca/group/genspec5
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
Modif : 2013-10-21http://groups.google.ca/group/genspec6
Domaine de l'IE
 Contexte
 Contenu
 Importance
 Principes de base
Modif : 2013-10-21http://groups.google.ca/group/genspec7
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, ...
Modif : 2013-10-21http://groups.google.ca/group/genspec8
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
Modif : 2013-10-21http://groups.google.ca/group/genspec9
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
Modif : 2013-10-21http://groups.google.ca/group/genspec10
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec11
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
Modif : 2013-10-21http://groups.google.ca/group/genspec12
Domaine de l'IE – Importance
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec13
Modif : 2013-10-21http://groups.google.ca/group/genspec14
Domaine de l'IE – Importance
(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 -
Modif : 2013-10-21http://groups.google.ca/group/genspec15
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
Modif : 2013-10-21http://groups.google.ca/group/genspec16
Domaine de l'IE – Principes de base –
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
Modif : 2013-10-21http://groups.google.ca/group/genspec17
Domaine de l'IE – Principes de base –
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
Modif : 2013-10-21http://groups.google.ca/group/genspec18
Domaine de l'IE – Principes de base –
Généralités … – Traçabilité
Modif : 2013-10-21http://groups.google.ca/group/genspec19
Erreurs détectées par Traçabilité
Modif : 2013-10-21http://groups.google.ca/group/genspec20
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
Modif : 2013-10-21http://groups.google.ca/group/genspec21
Niveaux d'exigence
Modif : 2013-10-21http://groups.google.ca/group/genspec22
Lien entre Niveaux d'exigence
(conforme aux normes ISO/CEI/IEEE 12207, IEEE 830, IEEE 1233 et MIL 498)
Modif : 2013-10-21http://groups.google.ca/group/genspec23
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é
Modif : 2013-10-21http://groups.google.ca/group/genspec24
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec25
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 ?
Modif : 2013-10-21http://groups.google.ca/group/genspec26
Problèmes courants – Exigences
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
Modif : 2013-10-21http://groups.google.ca/group/genspec27
Problèmes courants – Exigences
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 ?
Modif : 2013-10-21http://groups.google.ca/group/genspec28
Problèmes courants – Exigences
incorrectes
 Les exigences sont inexactes
 Les exigences sont incomplètes
 Les exigences sont incohérentes
 Les exigences sont invérifiables
Modif : 2013-10-21http://groups.google.ca/group/genspec29
Problèmes courants – Exigences
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
Modif : 2013-10-21http://groups.google.ca/group/genspec30
Problèmes courants – Exigences
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,
…
Modif : 2013-10-21http://groups.google.ca/group/genspec31
Problèmes courants – Exigences
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
Modif : 2013-10-21http://groups.google.ca/group/genspec32
Solution
 Base de développement
 Détail:
 Allocation d’un budget suffisant
 Adoption de principes de base
 Utilisation d'un outil: … GenSpec
Modif : 2013-10-21http://groups.google.ca/group/genspec33
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
Modif : 2013-10-21http://groups.google.ca/group/genspec34
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
Modif : 2013-10-21http://groups.google.ca/group/genspec35
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
Modif : 2013-10-21http://groups.google.ca/group/genspec36
« 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 ... »
Modif : 2013-10-21http://groups.google.ca/group/genspec37
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 »
Modif : 2013-10-21http://groups.google.ca/group/genspec38
Modif : 2013-10-21http://groups.google.ca/group/genspec39
Théories sur le développement de
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
Modif : 2013-10-21http://groups.google.ca/group/genspec40
Théories sur le développement de
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
Modif : 2013-10-21http://groups.google.ca/group/genspec41
Théories sur le développement de
système – Effort
Modif : 2013-10-21http://groups.google.ca/group/genspec42
Théories sur le développement de
système – Origine des erreurs
Modif : 2013-10-21http://groups.google.ca/group/genspec43
Modif : 2013-10-21http://groups.google.ca/group/genspec44
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec45
Normes internationales – ISO 12207
Modif : 2013-10-21http://groups.google.ca/group/genspec46
Normes internationales – ISO/CEI/IEEE
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
Modif : 2013-10-21http://groups.google.ca/group/genspec47
Normes internationales – ISO/CEI/IEEE
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec48
Normes internationales – Directives
ISO/CEI
Modif : 2013-10-21http://groups.google.ca/group/genspec49
Normes internationales – Directives
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec50
Normes internationales – Directives
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
Modif : 2013-10-21http://groups.google.ca/group/genspec51
Normes internationales – Directives
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
Modif : 2013-10-21http://groups.google.ca/group/genspec52
Formation à la Rédaction technique:
« l'Information Mapping »
Modif : 2013-10-21http://groups.google.ca/group/genspec53
Formation à la Rédaction technique:
« l'Information Mapping » (suite)
Modif : 2013-10-21http://groups.google.ca/group/genspec54
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec55
Normes internationales – IEEE Std 830
(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 »
Modif : 2013-10-21http://groups.google.ca/group/genspec56
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec57
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec58
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec59
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec60
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec61
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec62
Boîte noire
Système
externe
# 2
Système
externe
# 1
Système
externe
# n
Normes internationales – IEEE Std 830
(suite)
 Illustration de la logique de la structure recommandée par la 830
 Approche simple et systématique (voir la suite)
Modif : 2013-10-21http://groups.google.ca/group/genspec63
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)
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec64
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)
Normes internationales – IEEE Std 830
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec65
Normes internationales – IEEE Std 830
(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;
…
 ...
Modif : 2013-10-21http://groups.google.ca/group/genspec66
Pour des exemples complets
de spécifications
respectant la norme 830 de IEEE,
voir:
http://groups.google.ca/group/genspec
Modif : 2013-10-21http://groups.google.ca/group/genspec67
Normes internationales – IEEE Std 830
(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é, ...])
Modif : 2013-10-21http://groups.google.ca/group/genspec68
Normes internationales – IEEE Std 1233
 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 »
Modif : 2013-10-21http://groups.google.ca/group/genspec69
Normes internationales – IEEE Std 1233
(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
Modif : 2013-10-21http://groups.google.ca/group/genspec70
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec71
Documents de la NASA, du DOD
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec72
Documents de la NASA, du DOD
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
Modif : 2013-10-21http://groups.google.ca/group/genspec73
Documents de la NASA, du DOD
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
Modif : 2013-10-21http://groups.google.ca/group/genspec74
Documents de la NASA, du DOD
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 »
Modif : 2013-10-21http://groups.google.ca/group/genspec75
Modif : 2013-10-21http://groups.google.ca/group/genspec76
Modif : 2013-10-21http://groups.google.ca/group/genspec77
Documents de la NASA, du DOD
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
Modif : 2013-10-21http://groups.google.ca/group/genspec78
Documents de la NASA, du DOD
et du NAS (suite)
 NAS (National Airspace System, aux Etats-Unis)
 Human Factors Design Standard (http://hf.tc.faa.gov/hfds/):
Modif : 2013-10-21http://groups.google.ca/group/genspec79
Documents de la NASA, du DOD
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, …)
Modif : 2013-10-21http://groups.google.ca/group/genspec80
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
Modif : 2013-10-21http://groups.google.ca/group/genspec81
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. …
Modif : 2013-10-21http://groups.google.ca/group/genspec82
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
Modif : 2013-10-21http://groups.google.ca/group/genspec83
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, …)
Modif : 2013-10-21http://groups.google.ca/group/genspec84
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec85
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)
 …
Modif : 2013-10-21http://groups.google.ca/group/genspec86
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
Modif : 2013-10-21http://groups.google.ca/group/genspec87
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
Modif : 2013-10-21http://groups.google.ca/group/genspec88
Solution – Utilisation d'un outil: …
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
Modif : 2013-10-21http://groups.google.ca/group/genspec89
DOORS (semble être le plus utilisé)
Modif : 2013-10-21http://groups.google.ca/group/genspec90
Solution – Utilisation d'un outil: …
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 …
Modif : 2013-10-21http://groups.google.ca/group/genspec91
GenSpec
Modif : 2013-10-21http://groups.google.ca/group/genspec92
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec93
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)
Modif : 2013-10-21http://groups.google.ca/group/genspec94
Avantages de GenSpec
sur DOORS (suite)
GenSpec,
davantage intéressant
pour le Développement des exigences
DOORS,
pour la Gestion des exigences
Modif : 2013-10-21http://groups.google.ca/group/genspec95
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
Modif : 2013-10-21http://groups.google.ca/group/genspec96
Suite:
Présentation détaillée de GenSpec
(http://www.slideshare.net/PierrePi/ingnierie-des-exigences-prsentation-de-genspec-presentation)

Contenu connexe

Tendances

présentation soutenance PFE.ppt
présentation soutenance PFE.pptprésentation soutenance PFE.ppt
présentation soutenance PFE.ppt
Mohamed Ben Bouzid
 
Rapport de Stage PFE 2016 ELAAMRANI OMAR
Rapport de Stage PFE 2016 ELAAMRANI OMARRapport de Stage PFE 2016 ELAAMRANI OMAR
Rapport de Stage PFE 2016 ELAAMRANI OMAR
Omar EL Aamrani
 

Tendances (20)

Cahier des charges modèle gratuit - préparez votre projet web facilement !
Cahier des charges modèle gratuit - préparez votre projet web facilement !Cahier des charges modèle gratuit - préparez votre projet web facilement !
Cahier des charges modèle gratuit - préparez votre projet web facilement !
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
 
jeu maintenance totale
jeu maintenance totalejeu maintenance totale
jeu maintenance totale
 
Analyse de processus et workflow
Analyse de processus et workflowAnalyse de processus et workflow
Analyse de processus et workflow
 
Présentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clientsPrésentation PFE: Système de gestion des réclamations et interventions clients
Présentation PFE: Système de gestion des réclamations et interventions clients
 
La méthode amdec
La méthode amdecLa méthode amdec
La méthode amdec
 
présentation soutenance PFE.ppt
présentation soutenance PFE.pptprésentation soutenance PFE.ppt
présentation soutenance PFE.ppt
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
Gestion de la qualite
Gestion de la qualiteGestion de la qualite
Gestion de la qualite
 
Ingénierie du test 0.9
Ingénierie du test 0.9Ingénierie du test 0.9
Ingénierie du test 0.9
 
Rapport de Stage PFE 2016 ELAAMRANI OMAR
Rapport de Stage PFE 2016 ELAAMRANI OMARRapport de Stage PFE 2016 ELAAMRANI OMAR
Rapport de Stage PFE 2016 ELAAMRANI OMAR
 
Rapport PFE faten_chalbi
Rapport PFE faten_chalbiRapport PFE faten_chalbi
Rapport PFE faten_chalbi
 
Rapport de projet de fin d'année
Rapport de projet de fin d'année Rapport de projet de fin d'année
Rapport de projet de fin d'année
 
Génie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architecturesGénie Logiciels : Introduction aux architectures
Génie Logiciels : Introduction aux architectures
 
Exercices uml-corrige
Exercices uml-corrigeExercices uml-corrige
Exercices uml-corrige
 
Présentation projet de fin d'étude
Présentation projet de fin d'étudePrésentation projet de fin d'étude
Présentation projet de fin d'étude
 
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed AmineRapport de stage de perfectionnement - Mahmoudi Mohamed Amine
Rapport de stage de perfectionnement - Mahmoudi Mohamed Amine
 
Présentation PFE
Présentation PFEPrésentation PFE
Présentation PFE
 
CV de Fatma CHIHAOUI
CV de Fatma CHIHAOUICV de Fatma CHIHAOUI
CV de Fatma CHIHAOUI
 
Gestion de projet : les acteurs
Gestion de projet : les acteursGestion de projet : les acteurs
Gestion de projet : les acteurs
 

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

SDLC-MFO-gestion de la documentation projet
SDLC-MFO-gestion de la documentation projetSDLC-MFO-gestion de la documentation projet
SDLC-MFO-gestion de la documentation projet
LDEDSI
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
linasafaa
 
Mise en place d’un moteur de recherche et de recommandation de documents text...
Mise en place d’un moteur de recherche et de recommandation de documents text...Mise en place d’un moteur de recherche et de recommandation de documents text...
Mise en place d’un moteur de recherche et de recommandation de documents text...
AbdeslamAMRANE3
 
2.presentation merise
2.presentation merise2.presentation merise
2.presentation merise
shaheenyaar
 
Démarche mise en place de référentiel d'architecture
Démarche mise en place de référentiel d'architectureDémarche mise en place de référentiel d'architecture
Démarche mise en place de référentiel d'architecture
Mouhsine LAKHDISSI
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
Rabia AZIZA
 

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

Thesis+of+nesrine+abdelkafi.ppt
Thesis+of+nesrine+abdelkafi.pptThesis+of+nesrine+abdelkafi.ppt
Thesis+of+nesrine+abdelkafi.ppt
 
CV REBAI Hamida
CV REBAI HamidaCV REBAI Hamida
CV REBAI Hamida
 
SDLC-MFO-gestion de la documentation projet
SDLC-MFO-gestion de la documentation projetSDLC-MFO-gestion de la documentation projet
SDLC-MFO-gestion de la documentation projet
 
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptxChapitre 1 - Introcution & cycles de développement - Etudiant.pptx
Chapitre 1 - Introcution & cycles de développement - Etudiant.pptx
 
Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]Mappingobjetrelationnel[1]
Mappingobjetrelationnel[1]
 
Discovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data VirtualizationDiscovery Session France: Atelier découverte de la Data Virtualization
Discovery Session France: Atelier découverte de la Data Virtualization
 
André MORASSUT - GMIN30F
André MORASSUT - GMIN30FAndré MORASSUT - GMIN30F
André MORASSUT - GMIN30F
 
Mise en place d’un moteur de recherche et de recommandation de documents text...
Mise en place d’un moteur de recherche et de recommandation de documents text...Mise en place d’un moteur de recherche et de recommandation de documents text...
Mise en place d’un moteur de recherche et de recommandation de documents text...
 
2.presentation merise
2.presentation merise2.presentation merise
2.presentation merise
 
NightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous DeliveryNightClazz Build Tools & Continuous Delivery
NightClazz Build Tools & Continuous Delivery
 
Diapo PFE
Diapo PFEDiapo PFE
Diapo PFE
 
templates.iafactory, guide de prise en main
templates.iafactory, guide de prise en maintemplates.iafactory, guide de prise en main
templates.iafactory, guide de prise en main
 
Créer et intégrer son thème PrestaShop
Créer et intégrer son thème PrestaShopCréer et intégrer son thème PrestaShop
Créer et intégrer son thème PrestaShop
 
Introduction module IHM Polytech Sophia Dept Info SI3
Introduction module IHM Polytech Sophia Dept Info SI3Introduction module IHM Polytech Sophia Dept Info SI3
Introduction module IHM Polytech Sophia Dept Info SI3
 
Projet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type WikiProjet Confluence - Une base de données de type Wiki
Projet Confluence - Une base de données de type Wiki
 
Démarche mise en place de référentiel d'architecture
Démarche mise en place de référentiel d'architectureDémarche mise en place de référentiel d'architecture
Démarche mise en place de référentiel d'architecture
 
Cycles de vie d'un logiciel
Cycles de vie d'un logicielCycles de vie d'un logiciel
Cycles de vie d'un logiciel
 
X-2E Analysis - FR
X-2E Analysis - FRX-2E Analysis - FR
X-2E Analysis - FR
 
ASFA - Organisation et Méthodologie du projet COLSA
ASFA - Organisation et Méthodologie du projet COLSAASFA - Organisation et Méthodologie du projet COLSA
ASFA - Organisation et Méthodologie du projet COLSA
 
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
Comment récupérer un projet Web pourri ... et réussir à travailler dessus.
 

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

  • 1. 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)
  • 2. 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
  • 3. Modif : 2013-10-21http://groups.google.ca/group/genspec3 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)
  • 4. 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 Modif : 2013-10-21http://groups.google.ca/group/genspec4
  • 5. Modif : 2013-10-21http://groups.google.ca/group/genspec5 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
  • 6. Modif : 2013-10-21http://groups.google.ca/group/genspec6 Domaine de l'IE  Contexte  Contenu  Importance  Principes de base
  • 7. Modif : 2013-10-21http://groups.google.ca/group/genspec7 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, ...
  • 8. Modif : 2013-10-21http://groups.google.ca/group/genspec8 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
  • 9. Modif : 2013-10-21http://groups.google.ca/group/genspec9 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
  • 10. Modif : 2013-10-21http://groups.google.ca/group/genspec10 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)
  • 11. Modif : 2013-10-21http://groups.google.ca/group/genspec11 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
  • 12. Modif : 2013-10-21http://groups.google.ca/group/genspec12 Domaine de l'IE – Importance (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
  • 14. Modif : 2013-10-21http://groups.google.ca/group/genspec14 Domaine de l'IE – Importance (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 -
  • 15. Modif : 2013-10-21http://groups.google.ca/group/genspec15 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
  • 16. Modif : 2013-10-21http://groups.google.ca/group/genspec16 Domaine de l'IE – Principes de base – 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
  • 17. Modif : 2013-10-21http://groups.google.ca/group/genspec17 Domaine de l'IE – Principes de base – 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
  • 18. Modif : 2013-10-21http://groups.google.ca/group/genspec18 Domaine de l'IE – Principes de base – Généralités … – Traçabilité
  • 20. Modif : 2013-10-21http://groups.google.ca/group/genspec20 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
  • 22. Modif : 2013-10-21http://groups.google.ca/group/genspec22 Lien entre Niveaux d'exigence (conforme aux normes ISO/CEI/IEEE 12207, IEEE 830, IEEE 1233 et MIL 498)
  • 23. Modif : 2013-10-21http://groups.google.ca/group/genspec23 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é
  • 24. Modif : 2013-10-21http://groups.google.ca/group/genspec24 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)
  • 25. Modif : 2013-10-21http://groups.google.ca/group/genspec25 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 ?
  • 26. Modif : 2013-10-21http://groups.google.ca/group/genspec26 Problèmes courants – Exigences 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
  • 27. Modif : 2013-10-21http://groups.google.ca/group/genspec27 Problèmes courants – Exigences 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 ?
  • 28. Modif : 2013-10-21http://groups.google.ca/group/genspec28 Problèmes courants – Exigences incorrectes  Les exigences sont inexactes  Les exigences sont incomplètes  Les exigences sont incohérentes  Les exigences sont invérifiables
  • 29. Modif : 2013-10-21http://groups.google.ca/group/genspec29 Problèmes courants – Exigences 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
  • 30. Modif : 2013-10-21http://groups.google.ca/group/genspec30 Problèmes courants – Exigences 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, …
  • 31. Modif : 2013-10-21http://groups.google.ca/group/genspec31 Problèmes courants – Exigences 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
  • 32. Modif : 2013-10-21http://groups.google.ca/group/genspec32 Solution  Base de développement  Détail:  Allocation d’un budget suffisant  Adoption de principes de base  Utilisation d'un outil: … GenSpec
  • 33. Modif : 2013-10-21http://groups.google.ca/group/genspec33 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
  • 34. Modif : 2013-10-21http://groups.google.ca/group/genspec34 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
  • 35. Modif : 2013-10-21http://groups.google.ca/group/genspec35 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
  • 36. Modif : 2013-10-21http://groups.google.ca/group/genspec36 « 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 ... »
  • 37. Modif : 2013-10-21http://groups.google.ca/group/genspec37 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 »
  • 39. Modif : 2013-10-21http://groups.google.ca/group/genspec39 Théories sur le développement de 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
  • 40. Modif : 2013-10-21http://groups.google.ca/group/genspec40 Théories sur le développement de 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
  • 41. Modif : 2013-10-21http://groups.google.ca/group/genspec41 Théories sur le développement de système – Effort
  • 42. Modif : 2013-10-21http://groups.google.ca/group/genspec42 Théories sur le développement de système – Origine des erreurs
  • 44. Modif : 2013-10-21http://groups.google.ca/group/genspec44 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)
  • 46. Modif : 2013-10-21http://groups.google.ca/group/genspec46 Normes internationales – ISO/CEI/IEEE 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
  • 47. Modif : 2013-10-21http://groups.google.ca/group/genspec47 Normes internationales – ISO/CEI/IEEE 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)
  • 49. Modif : 2013-10-21http://groups.google.ca/group/genspec49 Normes internationales – Directives 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)
  • 50. Modif : 2013-10-21http://groups.google.ca/group/genspec50 Normes internationales – Directives 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
  • 51. Modif : 2013-10-21http://groups.google.ca/group/genspec51 Normes internationales – Directives 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
  • 52. Modif : 2013-10-21http://groups.google.ca/group/genspec52 Formation à la Rédaction technique: « l'Information Mapping »
  • 53. Modif : 2013-10-21http://groups.google.ca/group/genspec53 Formation à la Rédaction technique: « l'Information Mapping » (suite)
  • 54. Modif : 2013-10-21http://groups.google.ca/group/genspec54 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)
  • 55. Modif : 2013-10-21http://groups.google.ca/group/genspec55 Normes internationales – IEEE Std 830 (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 »
  • 56. Modif : 2013-10-21http://groups.google.ca/group/genspec56 Normes internationales – IEEE Std 830 (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
  • 57. Modif : 2013-10-21http://groups.google.ca/group/genspec57 Normes internationales – IEEE Std 830 (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
  • 58. Modif : 2013-10-21http://groups.google.ca/group/genspec58 Normes internationales – IEEE Std 830 (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
  • 59. Modif : 2013-10-21http://groups.google.ca/group/genspec59 Normes internationales – IEEE Std 830 (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
  • 60. Modif : 2013-10-21http://groups.google.ca/group/genspec60 Normes internationales – IEEE Std 830 (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
  • 61. Modif : 2013-10-21http://groups.google.ca/group/genspec61 Normes internationales – IEEE Std 830 (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
  • 62. Modif : 2013-10-21http://groups.google.ca/group/genspec62 Boîte noire Système externe # 2 Système externe # 1 Système externe # n Normes internationales – IEEE Std 830 (suite)  Illustration de la logique de la structure recommandée par la 830  Approche simple et systématique (voir la suite)
  • 63. Modif : 2013-10-21http://groups.google.ca/group/genspec63 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) Normes internationales – IEEE Std 830 (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
  • 64. Modif : 2013-10-21http://groups.google.ca/group/genspec64 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) Normes internationales – IEEE Std 830 (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
  • 65. Modif : 2013-10-21http://groups.google.ca/group/genspec65 Normes internationales – IEEE Std 830 (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; …  ...
  • 66. Modif : 2013-10-21http://groups.google.ca/group/genspec66 Pour des exemples complets de spécifications respectant la norme 830 de IEEE, voir: http://groups.google.ca/group/genspec
  • 67. Modif : 2013-10-21http://groups.google.ca/group/genspec67 Normes internationales – IEEE Std 830 (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é, ...])
  • 68. Modif : 2013-10-21http://groups.google.ca/group/genspec68 Normes internationales – IEEE Std 1233  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 »
  • 69. Modif : 2013-10-21http://groups.google.ca/group/genspec69 Normes internationales – IEEE Std 1233 (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
  • 70. Modif : 2013-10-21http://groups.google.ca/group/genspec70 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)
  • 71. Modif : 2013-10-21http://groups.google.ca/group/genspec71 Documents de la NASA, du DOD 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)
  • 72. Modif : 2013-10-21http://groups.google.ca/group/genspec72 Documents de la NASA, du DOD 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
  • 73. Modif : 2013-10-21http://groups.google.ca/group/genspec73 Documents de la NASA, du DOD 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
  • 74. Modif : 2013-10-21http://groups.google.ca/group/genspec74 Documents de la NASA, du DOD 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 »
  • 77. Modif : 2013-10-21http://groups.google.ca/group/genspec77 Documents de la NASA, du DOD 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
  • 78. Modif : 2013-10-21http://groups.google.ca/group/genspec78 Documents de la NASA, du DOD et du NAS (suite)  NAS (National Airspace System, aux Etats-Unis)  Human Factors Design Standard (http://hf.tc.faa.gov/hfds/):
  • 79. Modif : 2013-10-21http://groups.google.ca/group/genspec79 Documents de la NASA, du DOD 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, …)
  • 80. Modif : 2013-10-21http://groups.google.ca/group/genspec80 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
  • 81. Modif : 2013-10-21http://groups.google.ca/group/genspec81 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. …
  • 82. Modif : 2013-10-21http://groups.google.ca/group/genspec82 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
  • 83. Modif : 2013-10-21http://groups.google.ca/group/genspec83 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, …)
  • 84. Modif : 2013-10-21http://groups.google.ca/group/genspec84 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)
  • 85. Modif : 2013-10-21http://groups.google.ca/group/genspec85 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)  …
  • 86. Modif : 2013-10-21http://groups.google.ca/group/genspec86 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
  • 87. Modif : 2013-10-21http://groups.google.ca/group/genspec87 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
  • 88. Modif : 2013-10-21http://groups.google.ca/group/genspec88 Solution – Utilisation d'un outil: … 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
  • 90. Modif : 2013-10-21http://groups.google.ca/group/genspec90 Solution – Utilisation d'un outil: … 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 …
  • 92. Modif : 2013-10-21http://groups.google.ca/group/genspec92 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)
  • 93. Modif : 2013-10-21http://groups.google.ca/group/genspec93 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)
  • 94. Modif : 2013-10-21http://groups.google.ca/group/genspec94 Avantages de GenSpec sur DOORS (suite) GenSpec, davantage intéressant pour le Développement des exigences DOORS, pour la Gestion des exigences
  • 95. Modif : 2013-10-21http://groups.google.ca/group/genspec95 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
  • 96. Modif : 2013-10-21http://groups.google.ca/group/genspec96 Suite: Présentation détaillée de GenSpec (http://www.slideshare.net/PierrePi/ingnierie-des-exigences-prsentation-de-genspec-presentation)

Notes de l'éditeur

  1. Élicitation: activité du processus d'IE. Réf: "http://www.cs.uta.fi/~cszhzh/teaching/TKOPS301/L2.pdf" (de "http://www.cs.uta.fi/~cszhzh/teaching/TKOPS301_04.htm").
  2. UCA (Diapositive surtout pour l'Unité Conception-Automatismes d'HQ (UCA), peu formée en IE)
  3. UCA
  4. Réf: 1- Daniel Amyot: http://www.site.uottawa.ca/~damyot/seg3601/notes/SEG3601-module1.ppt, de http://www.site.uottawa.ca/~damyot/seg3601/ 2- Zheying Zhang: http://www.cs.uta.fi/~cszhzh/teaching/TKOPS301/L2.pdf, de http://www.cs.uta.fi/~cszhzh/teaching/TKOPS301_04.htm 3- Steve Easterbrook: http://www.cs.toronto.edu/~sme/CSC2106S/index.html
  5. UCA Problèmes majeurs si négligée: L’IE est une activité très importante du processus de fourniture et d’acquisition. À tel point que, si elle est négligée, plusieurs besoins du client ne sont jamais compris par le fournisseur ou ne le sont qu’après ou peu avant la livraison. Il en découle les problèmes majeurs suivants: - augmentation des coûts et délais de réalisation: la compréhension d’un besoin après ou peu avant la livraison implique souvent de recommencer la réalisation, au moins en partie; - diminution de la qualité: l’incompréhension d’un besoin implique que le produit (ou service) ne répondra pas à ce besoin; et la compréhension d’un besoin après ou peu avant la livraison implique souvent que le produit ne répondra pas à ce besoin ou ne sera que sommairement corrigé pour y répondre le mieux possible. Base de l'entente client-fournisseur: L’IE est une activité non seulement importante mais aussi essentielle à la fourniture et à l’acquisition. En effet, les exigences sont la base de l’entente client-fournisseur. Base de fourniture et d’acquisition: De surcroît, elles sont la base de la fourniture et de l’acquisition: base de réalisation; base de vérification et d’acceptation par le client; base de documentation.
  6. UCA
  7. UCA Réf: http://www.standishgroup.com/ Données tirées du dernier rapport d'étude gratuit du Standish Group, celui de 1995.
  8. UCA Réf: BOEHM
  9. exigences de boîte noire: les exigences doivent être spécifiées d’un point de vue extérieur au produit, donc en faisant abstraction des moyens de réalisation; exigences pour clients et fournisseurs: les exigences doivent être spécifiées de façon à être compréhensibles autant par le client que par le fournisseur - la terminologie du client doit être utilisée; exigences structurées: les exigences doivent être structurées de façon à faciliter leur compréhension et modification, et éviter leur répétition ou contradiction; exigences simples: les exigences doivent être simples, claires et concises; exigences identifiables: chacune des exigences doit être identifiable par un code ou un numéro de référence unique; exigences retraçables: la source de chacune des exigences doit être identifiée; exigences priorisées: les exigences doivent être priorisées, les unes par rapport aux autres.
  10. "Ce que le système doit faire à partir des intrants externes pour supporter les extrants externes" ? Explication: À peu près tous les analystes seraient d'accord pour dire que l'exigence suivante "Le système doit mettre à 1 le bit 3 de la variable interne Masque du module Acquisition" n'est pas une exigence fonctionnelle. Pourtant, elle correspond bien à "Ce que le système doit faire". Ces analystes diraient que cette exigence est de trop bas niveau. En revanche, beaucoup d'analystes diraient que l'exigence suivante "Le système doit acquérir et enregistrer les alarmes dans la base de données interne du système" EST une exigence fonctionnelle; elle correspond bien à "Ce que le système doit faire". Ces analystes diraient que, contrairement à la précédente, cette exigence n'est pas de trop bas niveau. Donc, ici, ce qui importe, c'est le "niveau" de l'exigence. Problème 1: ce "niveau" est subjectif; il dépend du jugement subjectif de l'analyste. Y aurait-t-il moyen d'être objectif ? Problème 2: ces deux exigences ne sont pas vérifiables de l'extérieur du système, leur extrant étant interne au système. Or, toute exigence se doit d'être vérifiable (notamment selon les normes 830 et 1233 de IEEE). Il est vrai qu'elles pourraient être vérifiables de l'intérieur du système, mais de telles exigences sont à éviter (notamment selon les normes 830 et 1233 de IEEE), pour plusieurs raisons ... Solution: adopter la définition suivante déduite de la norme 830 de IEEE, de son paragraphe 5.3.2; définition plus précise et aidant à corriger les problèmes mentionnés ci-dessus: Exigences fonctionnelles: "Ce que le système doit faire à partir des intrants externes pour supporter les extrants externes". Exemple: Le système doit calculer la valeur de la Puissance réelle de la centrale (PRC) selon la formule suivante: PRC = ∑ PRGTA [où PRC est un extrant externe et PRGTA (Puissance réelle de chaque groupe turbine-alternateur), des intrants externes]. De surcroît, il apparaît évident pour plusieurs analystes qu'une "exigence fonctionnelle système" doit être absolument spécifiée en fonction des "intrants système" et des "extrants système". La mention "système" implique qu'ils sont externes.
  11. Réf: http://www.csdn.net/subject/JeremyDick/publicseminar.pdf Le sous-système est un composant de premier niveau de décomposition du système.
  12. Remarque: Processus récursif. Un sous-système peut être: Logiciel; Matériel; Humain (désigné "Opération manuelle" dans la norme 12207). En effet, une exigence système peut être satisfaire par un Humain. EXEMPLE – À Hydro-Québec, la commande des disjoncteurs des centrales Hydroélectriques (situées dans le nord du Québec) faite à partir du Centre de conduite du réseau (CCR, situé à Montréal) se fait par un Humain: ce dernier fait un appel téléphonique et demande à l'opérateur au Centre de téléconduite (CT) de fermer ou ouvrir le disjoncteur désiré.
  13. UCA
  14. UCA Budget sous-évalué: trop souvent le budget initial alloué à l’IE est largement dépassé et le final, jugé trop élevé. Exigences incluant moyens de réalisation: les exigences ne font pas abstraction des moyens de réalisation. Lorsque survient un changement de ces moyens, l’IE doit être recommencée. Cela occasionne des coûts supplémentaires importants, en particulier lors d’un changement de technologie. EXEMPLE – En 1990, un système est développé et l’IE ne fait pas abstraction des moyens de réalisation. En 2000, les technologies utilisées sont obsolètes. Pour pallier ce problème, un nouveau système répondant aux mêmes besoins est développé: nouvelles technologies, nouvelle architecture. L’IE est alors recommencée, une charge de travail de plusieurs personnes-années; pourtant, les besoins n’ont pas changé, sauf exceptions. Exigences mal structurées: lorsque survient le moment de modifier une exigence, cela a des répercussions sur plusieurs autres exigences non clairement identifiées. Cela exige de revoir l’ensemble des exigences. Exigences d’interfaces instables: les exigences spécifiques aux interfaces externes varient continuellement. En effet, elles sont les plus instables, notamment celles variant le plus selon la technologie. Cela exige de revoir continuellement ces exigences. Formatage manuel non normalisé: le format de présentation de chacune des exigences n’est pas automatique ou formellement normalisé. Lorsque survient une modification de format d’une exigence, il faut revoir le format des autres, afin d’assurer l’uniformité et faciliter la lecture. Exigences incompréhensibles ou incorrectes: les exigences sont incompréhensibles ou incorrectes du point de vue du client ou du fournisseur. Cela exige de revoir les exigences à plusieurs reprises, constituant en effet une autre raison pour laquelle l’IE est une activité souvent coûteuse.
  15. UCA Exigences mal structurées: mal regroupées: certaines exigences semblent regroupées de façon arbitraire; non graduelles: plusieurs exigences ne sont pas présentées de façon graduelle, de la vue d’ensemble à la vue détaillée; cachées: plusieurs exigences sont « cachées » dans un même paragraphe, parmi d’autres informations complémentaires. En effet, elles ne sont pas clairement identifiées par un code, un numéro ou l’utilisation d’un verbe d’exigence tel « devoir ». Par conséquent, des exigences sont escamotées lors de la réalisation ou de la vérification. Exigences ambiguës: elles ont plusieurs interprétations possibles. Elles peuvent être claires pour le client mais ambiguës pour le fournisseur, ou inversement, le contexte du client étant différent de celui du fournisseur. EXEMPLE – « Le système doit permettre la télécommande » Pour le client HQ, dans le contexte d’un poste électrique, « télécommande » désigne une télécommande d’un appareil du poste effectuée de l’extérieur du poste. Pour le fournisseur, cela peut désigner en plus une télécommande de cet appareil effectuée de l’intérieur du poste. Exigences difficilement retraçables: il est difficile voire impossible de trouver l’exigence source de laquelle elles découlent, en particulier lorsque cette exigence source est spécifiée dans un autre document.
  16. UCA Exigences inexactes: le produit n’a pas à répondre à ces exigences du point de vue du client et du fournisseur. Elles proviennent généralement d’une incompréhension du besoin ou d’un problème de gestion des modifications d’exigences. Exigences incomplètes: elles ne couvrent pas tous les intrants et extrants requis, toutes les fonctions requises ou toutes autres caractéristiques telles les performances requises; ou elles ne sont pas priorisées, ne fournissement pas toutes les informations nécessaires à leur compréhension ou comportent l’expression « à déterminer ». Exigences incohérentes: elles se contredisent ou utilisent des termes différents pour exprimer la même notion. Exigences invérifiables: il n’existe aucune procédure acceptable permettant de les vérifier. Elles utilisent souvent des intrants ou extrants internes ou des mots imprécis tels que « habituel », « rapide » ou « convivial ». EXEMPLE – L’exigence suivante « Le système doit faire la somme des puissances consommées » n’est pas vérifiable si son extrant, cette somme, n’est pas disponible sur une interface externe tel un écran.
  17. UCA
  18. NAS: National Airspace System, aux États-Unis.
  19. Réf: Karl E. Wiegers, http://www.processimpact.com/process_assets/sample_requirements_documents.zip
  20. Réf: Karl E. Wiegers, http://www.processimpact.com/articles/reqtraps.html Montre le lien Cas d'utilisation Vs Spécification d'exigences.
  21. Réf: http://www.csdn.net/subject/JeremyDick/publicseminar.pdf
  22. Réf: http://www.cemmnt.co.uk/files/yRdB16xQ3mzbxiaHyb7M8mu2/Requirements%20Management%20Woodcock%20Telelogic.pdf Remarques: Stakeholder Requirements: Exigences des parties prenantes. Solution abstraite: Solution faisant abstraction des choix de conception: elle permet plusieurs conceptions possibles, notamment pour maximiser la compétitivité. Solution spécifique: Conception choisie et implémentée, parmi toutes celles possibles.
  23. Diapositive du cours "Analyse des besoins et gestion des exigences" du CRIM (Centre de Recherche Informatique de Montréal), conçu et présenté par M. Sylvain Ducharme. Contexte évident pour choisir la méthode d'IE par cas d'utilisation détaillés: si le client et le fournisseur maîtrisent bien la méthodologie, et davantage si le client et le fournisseur utilisent déjà des outils de support efficaces tels que ceux de Rational Rose. Problème courant avec cas d'utilisation: traçabilité imprécise avec essais, code et exigences client (plus imprécise qu'avec la méthode Énoncés d'exigence).
  24. Réf: http://www.ibm.com/developerworks/rational/library/sep05/rose/index.html "Le changement des exigences est aussi certain que la mort et les impôts"
  25. UCA Réf: http://lil.univ-littoral.fr/~toffolon/isi1.ppt (2004) Zelkowitz M. V. (Ed.) Advances in Computers 41-56 (1995-2002), Academic Press, 57-62, 64-65 (2003-5), 66-67 (2006, in preparation) Elsevier, Amsterdam. Montre que la Maintenance prend 67% de l'effort total (coût); il y a assurément un problème quelque part. Montre aussi que l'IE (définition des besoins) prend en moyenne près de 20% de l'effort total du développement (exclut Maintenance). La littérature recommande de 15 à 30%. On peut penser que: Le 15%, c'est pour un projet normalisé; Le 30%, c'est pour un projet totalement nouveau. CRIM enseigne "30%".
  26. UCA Réf: http://lil.univ-littoral.fr/~toffolon/isi1.ppt (2004) Tom DeMarco a publié en 2003 "Waltzing with Bears: Managing Risk on Software Projects" Montre que l'IE (définition des besoins) est la principale origine des erreurs en génie logiciel. 56%, c'est élevé; c'est assurément causé par un problème d'IE.
  27. UCA Réf: http://www.csdn.net/subject/JeremyDick/publicseminar.pdf
  28. http://www.google.ca/search?hl=fr&safe=off&as_qdr=all&q=%22ISO%2FIEC+12207%22+%22to+express+a+declaration+of+purpose+or+intent+by+one+party%2C%22+-ieeexplore-ieee-org+filetype%3Apdf&btnG=Rechercher&meta
  29. Partie 1, Procédures pour les travaux techniques: expose les procédures qui doivent être appliquées au sein de l'ISO et de la CEI dans l'exécution de leurs travaux techniques. Qualifiées: "Le document d'exigences doit être réalisé de façon à ce que tout client et tout concepteur puisse le comprendre". FAUX. Seuls les clients/concepteurs QUALIFIÉS doivent pouvoir le comprendre. Les clients doivent être qualifiés non seulement dans le domaine du problème mais aussi dans le domaine de la solution, en particulier sur l'IE (boîte noire, …). Quant aux concepteurs, ils doivent être qualifiés non seulement en conception mais aussi en IE (ex: ils doivent savoir que les exigences, c'est strictement les énoncés formulés avec un verbe d'exigence, tel "devoir").
  30. IEEE Std 830:1984/1993/1998, version française: https://www.google.ca/search?q=%22(R%C3%A9vision+de+la+norme+IEEE+830-1984)%22&cad=h IEEE Std 830:1998, version anglaise: https://www.google.ca/search?hl=fr&safe=off&as_qdr=all&q=%22IEEE+Std+830-1998%22+%22Keywords%3A+contract%2C%22+-ieeexplore-ieee-org+-www-enterra-us+filetype%3Apdf&btnG=Rechercher&meta=&gws_rd=ssl
  31. Particularités de la norme. "Modifiable" (facilement modifiable), négligé même si très important. On dit peu Comment faire pour que les exigences soient facilement modifiables. "Le changement des exigences est aussi certain que la mort et les impôts" tirée d'un cours d'Ingénierie des exigences de Daniel Amyot, Université d'Ottawa.
  32. Beaucoup moins coûteux sur un projet de demander aux lecteurs d'aller voir l'exigence 3 pages avant (ou dans un autre document) au moyen de renvoi, que de modifier un document difficile à modifier (une modification à un document difficile à modifier implique notamment de revoir la totalité de ce document pour s'assurer de sa cohérence, ce qui est coûteux). Remarque: l'idéal, c'est peut-être la redondance avec mise-à-jour automatique. Ex: "collage lié" (collage spécial) dans Word.
  33. Erreurs typiques (les + importantes en gras): Objet n'est pas l'Objet du document (devrait spécifier ce qui est l'objet du document et ce qui n'est pas l'objet du document) Porté n'est pas la Porté du système (devrait spécifier ce que le système fera et ce qu'il ne fera pas) Définitions … contient souvent des termes non utilisés par la spéc. (oubli de mise à jour) Références ne se limite pas aux documents auxquels la spéc fait explicitement référence Vue d'ensemble n'est pas la Vue d'ensemble du document (est souvent la vue d'ensemble du système; chapitre 2 est prévue pour ça) Exigences dans 2. Description générale Beaucoup d'informations non pertinentes dans 2 (devrait se limiter strictement aux informations ayant un impact sur les exigences ; le but du chapitre 2 est de faciliter la compréhension des exigences aux chapitre 3) Dans 2, fonctions souvent pas assez ou trop détaillées (ne doit pas être considérée comme étant une autre vue des exigences) Caractéristiques des utilisateurs ne se limitent pas aux niveaux d’instruction, expérience, connaissances techniques des utilisateurs (raisons qui justifient certaines des exigences énoncées au chapitre 3). Hypothèses et dépendances souvent incorrectes (devrait identifier des modifications éventuelles à l'environnement ou à des contraintes de conception, qui pourraient se répercuter sur les exigences; ex: le CT a été modifié pour fournir les MW par ligne de distribution)
  34. Remarques: Traduction littérale de la norme 830 de IEEE. Les exigences des interfaces externes, c'est d'abord la description DÉTAILLÉE de tous les intrants et de tous les extrants du logiciel. Le but de chaque intrant/extrant doit être donné. La provenance des intrants et destination des extrants doivent être données. Ces exigences couvrent tout type d'interface, autant Interface avec utilisateur (IPM) que Interface avec système externe.
  35. Exigences fonctionnelles: ... (Traduction littérale de la norme 830 de IEEE).
  36. Exigences d'interface et fonctionnelles bien séparées, dans des sections distinctes, les sections Exigences des interfaces externes et Exigences fonctionnelles; Exigences simples, claires et concises; Exigences individuellement vérifiables; Exigences individuellement identifiables par un numéro de référence unique; Utilisation systématique du verbe "devoir"; Formulation analogue pour les exigences analogues (les exigences d'intrants/extrants). Utilisation des mêmes termes (pas de synonymes) - dans l'exigence fonctionnelle, les noms d'intrants/extrants sont rigoureusement les mêmes que ceux dans les exigences des interfaces externes (aucune ambiguïté possible). NOTE – En faisant une recherche sur internet (Google) de "shall provide" et "shall receive" et "Software Requirements Specification" (ou "System Requirements Specification"), on remarque que cette façon de faire est courante.
  37. En français: https://www.google.ca/?gws_rd=ssl#q=%22Norme+IEEE+1233a-1998%22 NOTE - Pour la IEEE Std 830, il faut savoir que la version la plus récente, celle de 1998, est identique à celles de 1984 et 1993. En anglais: https://www.google.ca/search?hl=fr&safe=off&as_qdr=all&q=%22IEEE+Std+1233%22+%22Keywords%3A+requirement%22+-ieeexplore-ieee-org+filetype%3Apdf&btnG=Rechercher&meta=&gws_rd=ssl
  38. Réf: http://sunland.gsfc.nasa.gov/smex/wire/mission/cdhsw/wirrqtop.htm
  39. Réf: http://satc.gsfc.nasa.gov/support/STC_APR97/write/writert.htm http://www.stsc.hill.af.mil/crosstalk/1999/02/wilson.pdf
  40. SES: Spécification d'Exigences de Système SEL: Spécification d'Exigences de Logiciel.
  41. … 498, pour montrer: où s'insèrent les spécifications d'exigences, SSS, IRS et SRS, dans le processus de développement; que les exigences d'interface sont spécifiées dans un document distinct, la IRS.
  42. ... associé à la 498. Réf: Zero defect software, G. Gordon Schulmeyer (1990).
  43. Réf: 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 Principes intéressants pour l'IE: Composition logique: du général au particulier Style*: simple, clair et concis Teneur déf: jamais d'exigence "cachée" dans les définitions (ex: Déf. de "Commande": Envoie d'une commande de sélection, Réception d'une confirmation, Envoie d'une commande d'exécution, Réception d'une confirmation) Sens naturel: ne pas se servir des définitions pour donner des sens artificiels aux mots (ex: Déf. de "Commande", ci-dessus; ou déf. de "Télécommande" [commande effectuée à partir du Centre de téléconduite, à l'extérieur du poste] et "Commande à distance" [commande effectuée à partir de la Salle de commande, à l'intérieur du poste] utilisés dans la définition des besoins d'exploitation des postes et centrales d'HQ (BENEX)) Renvois internes: usage parcimonieux Langage courant: à utiliser Uniformité*: non utilisation de plusieurs définitions d'un terme et non utilisation de synonyme … * Aussi vu dans la littérature ou dans les normes d'IE ou de rédaction technique.
  44. UCA Réf: Requirements Engineering as a Success Factor in Software Projects, Hubert F. Hofmann, General Motors, Franz Lehner, University of Regensburg (http://www.das.ufsc.br/~romulo/discipli/cad-meto/requi.pdf). CRIM enseigne "30%". NOTE – Budget IE Composant exclut de ce 30%; plutôt inclut dans budget de Conception, si IE Système et IE Composant requises.
  45. Structurer les exigences de façon hiérarchique: (1) spécifier l’ensemble des exigences sous la forme d’un arbre hiérarchique: les exigences « enfant » sous les exigences « parent », les unes découlant des autres; (2) spécifier les exigences parent de façon à ce que chacune d’elles soit la synthèse de ses enfants. Cela aide à présenter les exigences de façon graduelle, systématiquement de la vue d’ensemble à la vue détaillée; (3) ordonner les exigences de façon à ce que les informations nécessaires à leur compréhension soient contenues dans l’exigence ou dans celles qui la précèdent. EXEMPLE – « Exigence 1 – TDT doit permettre de produire un document. Exigence 1.1 – TDT doit permettre d’imprimer le document. Exigence 1.1.1 – TDT doit offrir les choix suivants: a) Imprimer par une imprimante; b) Imprimer dans un fichier. ». Pour des exemples complets, voir les spécifications de la NASA [10] ou du Département de la Défense des États-Unis d’Amérique accessibles par Internet. Limiter chacune des exigences à un paragraphe: utiliser un seul paragraphe par exigence, si l’exigence peut être spécifiée dans un seul paragraphe simple, clair et concis; sinon, diviser l’exigence en plusieurs exigences « vérifiables », d’un seul paragraphe, si elle peut être ainsi divisée; sinon, référer à une annexe décrivant l’exigence. EXEMPLE – Voir la norme 12207 de ISO/CEI/IEEE [7]. NOTE – (1) La rédaction anglaise traditionnelle voulait même que l’exigence se compose d'une seule phrase [12]. (2) En plus d’être basées sur des normes internationales, les deux premières règles sont recommandées par une conférence de la NASA [9] et un article de la Défense des États-Unis d’Amérique [11]. Référer aux exigences sources: lorsqu’une exigence découle directement d’une autre spécifiée dans un autre document, y référer. Référer non seulement au document mais aussi au paragraphe spécifiant l’exigence. Cet autre document peut être une spécification, un courriel, un compte-rendu de réunion, etc.
  46. … (suite de diapositive précédente): Utiliser des renvois plutôt que la redondance: utiliser des renvois plutôt que la redondance d’informations si cette redondance est faite manuellement. Cela réduit le risque d’incohérences. En effet, une incohérence est souvent introduite dans un texte lors d’une modification d’une information redondante: la modification n’est pas effectuée partout où l’information apparaît. Relier les exigences: par des renvois, relier les exigences ayant des liens logiques, les exigences devant potentiellement être modifiées si l’une d’elles est modifiée. Cela exclut les liens parent-enfant (incluant enfant-enfant), puisqu’ils sont déjà présents dans la structure des exigences (voir 4.3.1). Dans tous les cas, spécifier la raison du renvoi. Cependant, dans tous les cas, faire un usage parcimonieux des renvois: les renvois internes multiples sont inutiles dans un texte de structure logique [12]; au besoin, restructurer. Respecter les règles de rédaction: respecter rigoureusement les règles fondamentales de rédaction technique [6], principalement les suivantes: utiliser le langage courant et n’utiliser des mots techniques que si la précision l’exige; faire des phrases simples, claires et concises; uniformiser les exigences: rédiger de façon analogue des exigences analogues et de façon identique des exigences identiques. NOTE – Cette règle implique notamment de (1) ne pas utiliser de synonymes, même pour les mots de liaison; et (2) utiliser systématiquement le même verbe pour spécifier une exigence, tel « devoir ».
  47. Spécifier les interfaces avant les fonctions: spécifier les exigences des interfaces externes avant les exigences fonctionnelles, pour les raisons suivantes: (1) il est naturel de présenter l’extérieur du produit (interfaces externes) avant d’entrer à l’intérieur (fonctions) et (2) les exigences des interfaces externes remplissent aussi le rôle de glossaire, définissant des termes, les intrants et extrants, qui n’auront pas à être redéfinis aux exigences fonctionnelles. Faire attention à spécifier ces exigences de façon graduelle, comme lors d’une présentation du produit pour la première fois. Relier les fonctions avec les interfaces: par des renvois, relier les exigences fonctionnelles aux exigences d'intrants et extrants concernés, et inversement. Cela aide (1) à couvrir toutes les exigences des interfaces externes et toutes les exigences fonctionnelles, et (2) à spécifier des exigences fonctionnelles vérifiables, faisant abstraction des moyens de réalisation, étant reliées à des intrants et extrants externes. Placer judicieusement les exigences: lorsqu’une exigence peut être placée dans deux sections distinctes, section « sujet # 1 » ou section « sujet # 2 », parce qu’elle traite à la fois du sujet # 1 et du sujet # 2, la placer dans la section ayant la plus grande probabilité d’être supprimée; cela réduit le risque d’incohérences advenant la suppression de cette section. EXEMPLE – L’exigence suivante « Si le système bascule en état Maintenance, il doit cesser la simulation » peut être placée dans deux sections distinctes, parce qu’elle traite à la fois de la maintenance et de la simulation: (1) dans une section « Maintenance » ou (2) dans une section « Simulation ». Si la probabilité de supprimer la section « Simulation » est plus élevée, cette exigence devrait être plutôt placée dans « Simulation ». Ainsi, advenant la suppression de « Simulation », il n’est pas requis de modifier la section « Maintenance ». Dans le cas contraire, c'est-à-dire si cette exigence était plutôt placée dans la section « Maintenance », il y aurait risque d’incohérences: oublier de retirer cette exigence de « Maintenance » advenant la suppression de « Simulation ». Ajouter des exigences de vérification: ajouter des exigences facilitant la vérification [8], tout en faisant abstraction des moyens de réalisation. Cela facilite, de surcroît, la simplification des exigences. En effet, lorsqu’une exigence est complexe, il suffit de (1) la séparer en deux exigences simples dont l’une utilise l’extrant de l’autre, et (2) ajouter une exigence de cet extrant sur une interface externe, pour faire, de toutes ces exigences, des exigences vérifiables. Ainsi, cette dernière exigence ajoutée facilite-t-elle non seulement la vérification mais aussi la simplification de l’exigence complexe. Spécifier les interfaces dans des documents dédiés: sauf s’il y a peu d’exigences, spécifier les exigences spécifiques aux interfaces externes, celles variant le plus selon la technologie, dans des documents dédiés. Cela facilite la modification des exigences.
  48. … (suite de diapositive précédente): Spécifier distinctement les fonctionnements anormaux: spécifier les exigences associées à un fonctionnement anormal dans une section distincte, pour les raisons suivantes: (1) une exigence ne traitant pas tous les cas est plus simple et (2) le lecteur, dans un premier temps, ne s’intéresse pas aux cas de fonctionnement anormal. Ajouter des notes d’informations complémentaires: si nécessaire, ajouter une note à une exigence, une courte remarque ou une annotation apportant un commentaire ou un éclaircissement sur le texte. Cette note ne doit, par contre, contenir aucune exigence, sauf dans le cas d’une note de figure ou de tableau [6]. Dans tous les cas, faire un usage parcimonieux des notes. Ajouter des notes de simplification: si, par souci de simplification, de clarté, une exigence ne tient pas compte d’un détail, utiliser une note pour indiquer le détail en question et renvoyer aux exigences traitant de ce détail. EXEMPLE – « NOTE – Les exigences suivantes sont spécifiées en considérant que le système est en mode Exploitation. Dans le cas contraire, voir réf. interne ci-après identifiée. » Lister les événements en annexe: si le produit peut signaler une grande variété d’événements, les lister en annexe et y spécifier, pour chacun d’eux, les conditions déclenchant leur apparition ou disparition; aux exigences des interfaces externes et aux exigences fonctionnelles, référer à cette annexe. Limiter les énumérations: limiter à dix la quantité d’éléments de toute énumération, y compris la quantité de sections ou de paragraphes d’un document ou d’une section; au besoin, restructurer. La règle de limitation des énumérations à 10 éléments vient d'une donnée psycho-cognitive de Miller qui a expérimenté que la mémoire de travail ne pouvait pas supporter plus de 7 (plus ou moins 2) éléments à la fois. Cette donnée a été reprise par Robert Horn, psychologue qui a conçu une méthode de structuration des informations dont la forme light est la méthode Imap (Information Mapping). Indiquer les exigences non applicables: si une exigence normalement applicable au produit (ex: selon une norme) est non applicable, conserver son code, numéro de référence ou titre et indiquer « Non applicable », assurant au lecteur que cette exigence n’a pas été oubliée. Sous une exigence non applicable, omettre les exigences qui, normalement, en découlent. …
  49. Pertes/déplacements accidentels de renvois principalement sur suppression/déplacement de paragraphes voisins.
  50. Réduit les coûts: automatisations, facilitation des modifications, facilitation de la réutilisation, … Facilite la lecture: présentation progressive, systématiquement de la vue d’ensemble à la vue détaillée; format normalisé; … Réduit la quantité d’erreurs: contrôle et vérifications automatique des exigences, … Respecte des normes internationales: IEC/IEEE/MIL; numéro de référence unique par exigence, …
  51. Une même procédure d'essais peut être assignée à plusieurs exigences (GenSpec le peut mais seulement avec des fichiers joints).
  52. UCA