Modif : 2013-10-21 1 http://groups.google.ca/group/genspec Ingénierie des exigences Ingénierie des exigences (Requirements Engineering) (Requirements Engineering) Principes de base de GenSpec (la théorie derrière l'outil) Présentation faite périodiquement: (1) à Hydro- Québec; (2) à des Associations professionnelles ; (3) dans des Universités de la francophonie (sur place ou par vidéoconférence).
95
Embed
Ingénierie des exigences - Principes de base de GenSpec (la théorie derrière l'outil)
Présentation de la théorie derrière l'outil d'ingénierie des exigences (requirements engineering) GenSpec
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Ingénierie des exigencesIngénierie des exigences(Requirements Engineering)(Requirements Engineering)
Principes de basede GenSpec(la théorie derrière l'outil)
Présentation faite périodiquement:(1) à Hydro-Québec;(2) à des Associations professionnelles;(3) dans des Universités de la francophonie(sur place ou par vidéoconférence).
Présentation faite périodiquement:(1) à Hydro-Québec;(2) à des Associations professionnelles;(3) dans des Universités de la francophonie(sur place ou par vidéoconférence).
À 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 par l'unité Conception-Automatismes d'Hydro-Québec (HQ).
(Élicitation: Recherche des exigences par des entrevues, la consultation des documents existants, l'analyse de tâches, le développement de prototypes, de maquettes, ...)
Identifie ses documents de référence dans la section "Commentaires" du présent PowerPoint.
Domaine de l'IE – Contenu (suite)Domaine de l'IE – Contenu (suite)
Création: Début du processus: Apparition ou étude d'un
besoin, d'un problème, d'une opportunité, ...; Développement des exigences:
Élicitation: Recherche des exigences par des entrevues, la consultation des documents existants, l'analyse de tâches, le développement de prototypes, de maquettes, ...;
Analyse: Comparaison, Négociation, Filtrage, Complémentation, Caractérisation (incluant Priorisation), Structuration et Liaison des exigences;
Domaine de l'IE – ImportanceDomaine de l'IE – Importance(suite)(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
Domaine de l'IE – ImportanceDomaine de l'IE – Importance(suite)(suite)
Phases d'ingénierie Coût relatif de réparation d'une erreur
1) Ingénierie des exigences 1
2) Conception 5
3) Réalisation 10
4) Vérification et validation 20
5) Maintenance 200
- plus une erreur est introduite tôt et détectée tard,- plus une erreur est introduite tôt et détectée tard,plus elle est coûteuse à corriger -plus elle est coûteuse à corriger -
Domaine de l'IE – Principes de base – Domaine de l'IE – Principes de base – Généralités, tirées de la littérature (suite)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;
Domaine de l'IE – Principes de base – Domaine de l'IE – Principes de base – Généralités, tirées de la littérature (suite)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
Les exigences sont invérifiables, souvent en raison d'utilisation de termes vagues, à éviter dans tout énoncé d'exigence: à confirmer, à définir, acceptable, adapté, adéquat,
"Exigences des parties prenantes" Vs "Exigences des parties prenantes" Vs "Exigences système" (ou logiciel)"Exigences système" (ou logiciel)
Exigences des parties prenantes (ou exigences utilisateurs): Exigences exprimant le problème; Exigences de haut niveau, de l'organisation ou du client
(niveau d'abstraction plus élevé que les exigences système); Source pour développer les exigences système; Forme typique: "L'utilisateur doit être capable de ...".
Exigences système (ou logiciel): Exigences exprimant la solution, répondant aux
exigences des parties prenantes; Exigences souvent contractuelles; Portée/limites clairement définies: intrants/extrants
externes clairement définis (environnement détaillé); Forme typique: "Le système doit ...".
Théories sur le développement de Théories sur le développement de système – Cas d'utilisation (suite)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".
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.
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).
Directives ISO/CEI, Partie 2, Règles de structure et de rédaction des Normes internationales (document d'exigences), 2004 (http://www.iec.ch/tiss/iec/Directives%20ISO-CEI-Partie2-Ed5.pdf);
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
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.
Autres directives intéressantes: Ne spécifier que des exigences "vérifiables"; Éviter les répétitions, faire plutôt référence, pour:
réduire le risque d'erreurs et d'incohérences; ne pas allonger le document;
Utiliser strictement les formulations verbales suivantes: "doit" pour exprimer une exigence; "peut" pour exprimer une autorisation, une possibilité ou une
éventualité; "il convient de" pour exprimer une recommandation (ne pas utiliser
"devrait"); Rédiger les définitions conformément aux exigences suivantes:
une définition doit être telle qu'elle puisse être utilisée à la place du terme défini. Toute information complémentaire doit être donnée exclusivement sous forme d'exemples ou de notes;
une définition ne doit pas avoir la forme d'une exigence ni contenir d'exigence.
Formation 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 certainque la mort et les impôts"
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;
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
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.
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
NOTE – Cette présentation ne met aucune emphase sur les autres exigences non fonctionnelles, parce qu'elle se concentre sur les problèmes d'IE les plus importants vécus par l'unité Conception-Automatismes d'HQ.
(Autres exigences non fonctionnelles: exigences de performance, contraintes de conception; attributs [disponibilité, maintenabilité, sécurité, ...])
Remarques (suite): Structure de la spécification d'exigences système:
La structure de la spéc. d'exigences système, donnée en exemple dans la 1233 (annexe de la 1233), est très différente de celle recommandée par la 830;
Cependant, toute organisation se doit d'uniformiser ses documents, autant que possible, comme d'ailleurs le fait la norme MIL 498 (ex: SSS-DID vs SRS-DID);
C'est pourquoi l'Unité Conception – Automatismes d'HQ a choisi la même structure pour l'ensemble de ses spéc. d'exigences: la structure recommandée par la 830, jugée la plus intéressante.
Documents de la NASA, du DODDocuments de la NASA, du DODet du NAS 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
Documents de la NASA, du DODDocuments de la NASA, du DODet du NAS (suite)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).
Documents de la NASA, du DODDocuments de la NASA, du DODet du NAS (suite)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.
Documents de la NASA, du DODDocuments de la NASA, du DODet du NAS (suite)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;
Documents de la NASA, du DODDocuments de la NASA, du DODet du NAS (suite)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"
Documents de la NASA, du DODDocuments de la NASA, du DODet du NAS (suite)et du NAS (suite)
NAS (National Airspace System, aux Etats-Unis)
Human Factors Design Standard:Un autre bel exemple d'un document d'exigences de
qualité: Priorité d'exigence / Utilisation stricte des verbes
d'exigence (carré vide/plein pour should/shall); Un titre par exigence; Un seul paragraphe par exigence; Exigences simples, claires et concises; Identification de la source; Discussion (ou Exemple, Définition, Note, …).
Guides de rédaction des lois (suite)Guides de rédaction des lois (suite)
Exemple: Protocole de rédaction uniforme, harmonisation des lois au
Canada, 2006 (http://www.ulcc.ca/fr/us/index.cfm?sec=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.
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).
Suivant les principes énoncés sur la diapositive précédente, les exigences fonctionnelles sont liées aux intrants/extrants externes:
Réduit le risque d'exigences invérifiables, les intrants/extrants des exigences fonctionnelles étant accessibles de l'extérieur;
Réduit le risque d'exigences ne faisant pas abstraction des moyens de réalisation (ex: architecture du système), les intrants/extrants des exigences fonctionnelles ne pouvant être qu'externes;
Réduit le risque d'exigences incohérentes (intrant sans fonction ou extrant, extrant sans fonction ou intrant);
Réduit le risque d'exigences incomplètes (oublier des intrants, extrants, fonctions); Offre la possibilité de générer automatiquement une première ébauche des spécifications d'exigences
de composant, notamment à partir de données d'attribution des exigences aux composants.
Solution – Utilisation d'un outil: … Solution – Utilisation d'un outil: … GenSpecGenSpec
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.
Solution – Utilisation d'un outil: … Solution – Utilisation d'un outil: … GenSpec (suite)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.
Avantages de DOORSAvantages de DOORSsur GenSpecsur GenSpec
Disponible en version anglaise. Permet la définition des cas d'utilisation. Permet le multi-usagers à travers le web. Fonctions de traçabilité plus puissantes. Gestion multi-versions des exigences plus puissante. Support multi-formats (de documents importées ou liés, incluant diagrammes UML) plus puissant. Une même procédure d'essais peut être assignée à plusieurs exigences. Possibilité pour les utilisateurs de créer des "scripts" de vérifications des exigences. Outil d'aide convivial à l'importation de données. Fonctionne sur plusieurs plates-formes. Documentation riche. Grande quantité d'utilisateurs / groupes de discussion. Gestion de l'état des exigences (valide, attribuée, implémentée, testée, …), … par courriel Facilités d'ajout d'attributs aux exigences (ex: date livraison); et de tri, de fabrication de vue et de
génération de rapport. Possibilité de liaison d'exigences inter Documents-DOORS. Interopérabilités (avec autres outils commerciaux). Support disponible (pas seulement à travers un groupe de discussion).
Avantages de GenSpecAvantages de GenSpecsur DOORSsur 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