Transcript Bonnes pratiques pour le génie des exigences

02/02/2014
Bonnes pratiques pour le génie
des exigences
Hafedh Mili
Copyright 2014
Un processus de génie des exigences
• Phase initiale: développement
Elicitation
Analyse
Clarifier
Spécification
compléter
Validation
Re-écrire
Re-évaluer
Confirmer et corriger
• Phase récurrente: gestion des exigences
2/2/2014
Hafedh Mili – Copyright 2014
2
1
02/02/2014
Génie des exigences et cycle de
développement
• Les étapes du génie des exigences sont les
mêmes, indépendemment du cycle de vie
• La répartition de l’effort dépend du cycle de
vie
2/2/2014
Hafedh Mili – Copyright 2014
3
Bonnes pratique de génie des
exigences
• Pas de “silver bullet”: il n’y a pas de processus ou
de notation magique qui permettra de livrer
systématiquement des exigences de bonne
qualité
• Plutôt, un ensemble de pratiques éprouvées dans
des projets différents et des circonstances
différentes recensées par des praticiens
expérimentés dans le domaine
– [Sommerville & Sawyer, 1997], [Hofmann & Lehner,
2001], [Gottesdiener 2005], [IIBA, 2009]
2/2/2014
Hafedh Mili – Copyright 2014
4
2
02/02/2014
Bonne pratiques de génie des
exigences
• Wieger a identifié une cinquante de pratiques
pertinentes à différentes activités du génie
des exigences
• Il faut en adapter l’utilisation au projet en
question (nature du projet, taille, risque,
règlementations pertinentes, etc.)
2/2/2014
Hafedh Mili – Copyright 2014
5
Bonnes pratiques en génie des
exigences
2/2/2014
Hafedh Mili – Copyright 2014
6
3
02/02/2014
Pratiques pour l’élicitation
•
Définir la vision et la portée du projet
– Ceci donne les exigences d’affaires, qui servent de point de référence pour
évaluer les autres exigences (chapitre 5).
•
Identifier les classes d’usagers et leurs caractéristriques
– Pour éviter d’oublier des exigences. Caractériser par tâches et compétences,
style de travail, etc. (ch 6).
•
Sélectionner un ‘product champion’ dans chaque classe
– Représentant de la classe d’usagers don’t il fait partie, mais aussi décideur
pour cette classe (ch 6).
•
Organiser des ‘focus groups’ avec des usagers typiques pour éliciter
exigences
– Surtout pour des logiciels commerciaux. Des personnes ayant utilisé des
produits similaires (ou antérieurs) (ch 7).
•
Travailler avec des représentants de classes d’usagers pour éliciter les
exigences
– Explorer les tâches qu’ils doivent accomplir, et documenter le comportement
du système sous la forme de ‘user stories’, cas d’utilisation, ou scénarios (ch 8)
2/2/2014
Hafedh Mili – Copyright 2014
7
Pratiques pour l’éclicitation (suite)
• Identifier le événements et réponses système
– Lister les événements externes que le système va recevoir, et les
réponses attendues. Les événements externes peuvent être de 3
types: 1) signaux, reçus d’équipements externes, 2) événements
temporels (e.g. timer), et 3) événements métiers (business events), qui
déclenchent des cas d’utilisation (ch 12)
• Tenir des entrevues d’élicitation
– Entrevues un à un, ou avec un petit groupe, pour ne pas mobiliser tout
le monde (ch 7)
• Organiser des ateliers d’élicitation
– Plus formels, avec usagers et clients, souvent pour passer à travers un
draft et résoudre des conflits (ch 7)
• Observer des utilisateurs typiques (ou ciblés) dans leur travail
– Cela permettra d’identifier ou mieux cerner leurs besoins. Approprié
pour une nouvelle application aux fonctionnalités inédites (ch 7)
2/2/2014
Hafedh Mili – Copyright 2014
8
4
02/02/2014
Pratiques pour l’élicitation (suite)
• Distribuer des questionnaires
– Une façon de sonder de grands groupes. La qualité des réponses
dépend de la qualité des questions. Peut permettre de se concentrer
sur une piste (ch 7)
• Analyser des documents existants
– Documentation de systèmes existants, documents d’exigences, veille
auprès de compétiteurs, etc. Ch 7.
• Examiner les ‘problem reports’ ou demandes de features
– Pour les produits ‘techniques’, cela se trouve dans des
environnements tels JIRA, etc.
• Réutiliser des documents d’exigences existants
– Soit une version antérieure du logiciel, ou un logiciel semblable, ou
opérant dans le même domaine. Tout peut être réutilisé (classes
d’usagers, fonctionnalités, contraintes, reglementation, règles
d’affaires, etc.) ch 18.
2/2/2014
Hafedh Mili – Copyright 2014
9
Bonnes pratiques pour l’analyse
• Objectifs de l’analyse: arriver à des exigences de qualité et niveau
de détails suffisants pour
– Permettre aux gestionnaires de projets de faire des plans réalistes
– Permettre aux développeurs de procéder à la conception, au
développement, et aux tests
• Tâches de l’analyse
–
–
–
–
Détailler les exigences de haut niveau
Négocier les priorités
Évaluer la faisabilité
Construire des prototypes
• Fournir différentes vues des exigences
– Identifier des problèmes qu’une seule vue ne permettrait pas de voir
– S’assurer d’une même compréhension des exigences par les parties
prenantes
2/2/2014
Hafedh Mili – Copyright 2014
10
5
02/02/2014
Bonnes pratiques pour l’analyse (suite)
• Modéliser l’environnement de l’application
– Via un diagramme de contexte, montrer les frontières du système et
ses interfaces externes avec ses usagers et d’autres systèmes (ch 5)
• Créer des prototypes fonctionnels et des maquettes (ch 15)
– Utile pour l’implantation de fonctionnalités inédites / novatrices
– “I will know what I want when I see it”
• Analyser la faisabilité des exigences
– L’analyste doit travailler avec les développeurs pour vérifier si une
exigence est réalisable à un coût et une performance acceptable dans
l’environnement actuel
• Prioriser les exigences (ch 16)
– Dans l’absolu: quoi laisser tomber si le temps et l’argent manque
– Dans le temps: planifier le contenu des différentes release
• (note: versioning and internationalisation …)
2/2/2014
Hafedh Mili – Copyright 2014
11
Bonnes pratiques pour l’analyse (suite)
• Créer le dictionnaire de données (ch 13)
– Tout fait référence aux données
– S’assurer que tout le monde parle de la même chose
• Modéliser les exigences (ch 5, 12, 13)
– Représenter les exigences de façon visuelle (DFD, modèles de
données, modèles comportementaux)
• Analyser les interfaces entre votre système et le monde
externe (ch 10)
– Il faut bien comprendre ces intefaces (documenter) pour
s’assurer de l’intégrabilité du système résultant
• Allouer les exigences aux sous-systèmes (ch 26)
– Dans le cas de systèmes complexes impliquant logiciel, matériel,
humain
2/2/2014
Hafedh Mili – Copyright 2014
12
6
02/02/2014
Bonnes pratiques pour la spécification
• Objectifs de la spécification d’exigences
– Documenter les divers types d’exigences de manière cohérente,
accessible, et compréhensible par les principales parties
prenantes
• Le ‘format’ des spécifications
– Documents livrables
– Reposoir électronique
• Documents livrables
Type d’exigence
Document livrable
Exigences d’affaires
Document de vision et de portée
ConOps (IEEE STD
du logiciel
1362-1998)
User stories et Cas d’utilisation
Exigences usagers
SEL (IEEE Std 830Exigences fonctionnelles et nonLe SEL ou un outil de gestion des
1998)
fonctionnelles
détaillées
exigences
2/2/2014
Hafedh Mili – Copyright 2014
13
Bonnes pratiques pour la spécification (suite)
• Concevoir/adapter/adopter un gabarit pour
documenter vos exigences
– Normes IEEE
– Versions simplifiées dans ch 5, 8 (use case) et 10 (SRS)
• Identifier la sources des diverses exigences (ch 27)
– D’où vient une exigence? (sa justification)
– Qui consulter en cas de demande de changement
• Identifier chaque exigence de façon unique (ch 10)
– L’étiquetage doit être compréhensible / mnémonique
– Doit permettre les ajouts, modifications, et retraits de
façon flexible
2/2/2014
Hafedh Mili – Copyright 2014
14
7
02/02/2014
Bonnes pratiques pour la spécification (suite)
• Enregistrer les règles d’affaires (ch 9 et ABRD)
– Normes
– Règlementations (gouvernementale, ordres et associations
professionnels, internationales)
– Politiques de l’entreprise
– Les traiter comme capital entreprise
• Spécifier les exigences non-fonctionnelles
– Types d’exigences (ch 14)
• Utilisability
• Performance, fiabilité, portabilité, modifiabilité
• Conformité avec normes internes de développement
– Les documenter de façon précise et quantifiable
2/2/2014
Hafedh Mili – Copyright 2014
15
Bonnes pratiques pour la validation
• Réviser les exigences (ch 17)
– Inspection par une équipe représentative des principales
parties prenantes (client, usager, développeur)
• Tester les exigences
– Écrire des scénarios de tests pour les diverses
fonctionnalités
• S’assurer que chaque fonctionnalité a un test correspondant
• S’assurer que chaque comportement exhibé/attendu durant le test
est spécifié quelque part
– Vérifier avec l’usager que le comportement souhaité est le
bon
– Test-Driven Development: les tests sont les exigences
2/2/2014
Hafedh Mili – Copyright 2014
16
8
02/02/2014
Bonnes pratiques pour la validation (suite)
• Définir des critères d’acceptation
– Comment vérifier que le produit livré répond aux attentes
– Critères possibles:
•
•
•
•
•
•
Passage de tests fonctionnels précis
Atteinte de KPI
Métriques de performance
Métriques de issue tracking
Mise en place de formation et de ‘roll-out’ officiel
Etc.
• Simuler les exigences
– Certaines spécifications d’exigences logicielles peuvent
être simulées via des outils spécialisés
– Une alternative au prototypage
2/2/2014
Hafedh Mili – Copyright 2014
17
Bonnes pratiques pour la gestion des
exigences
• Une fois tout le monde a donné son accord sur
les exigences, on commence à les modifier 
• Principe 2 du développement agile:
– Welcome changing requirements, even late in
development. Agile processes harness change for the
customer's competitive advantage
• Gestion des exigences: gérer de façon
méthodique et contrôlée les changements
inévitables dans les exigences
2/2/2014
Hafedh Mili – Copyright 2014
18
9
02/02/2014
Bonnes pratriques pour la gestion des
exigences (suite)
• Mettre en place un processus de contrôle de changements
dans les exigences (ch 28)
– D’où peuvent venir les demandes de changements?
– Comment évaluer les changements proposés?
– Critères décisionnels pour accepter ou prioriser les
changements proposés
– Qui décide (change control board)
• Effectuer une analyse d’impact des changements (ch 28)
– Évaluer les changements proposés pour estimer l’impact qu’ils
auront sur le projet
– Se servir de la matrice de traceabilité des exigences pour
identifier les autres artéfacts qui sont affectés/doivent être
changés
2/2/2014
Hafedh Mili – Copyright 2014
19
Bonnes pratriques pour la gestion des
exigences (suite)
• Établir des baselines et des versions de contrôle des
exigences
– Baseline: version ayant fait l’objet d’un accord formel
– Versions de contrôle: versions subséquentes cohérentes
modifiées de façon méthodique
• Maintenir un historique des changements d’exigences
– Les changements faits à une exigence donnée: avoir les
différentes versions, leurs dates de changements, auteurs, etc.
– Peut être géré par un CVS ou un outil de gestion d’exigences
• Faire le suivi de chaque exigence individuellement (ch 27)
– Établir une BD d’exigences, où l’on surveille, pour chaque
exigence qui affecte l’implantation, son état (par ex. proposée,
approuvée, implémentée, vérifiée, retirée, reportée, etc.)
2/2/2014
Hafedh Mili – Copyright 2014
20
10
02/02/2014
Bonnes pratriques pour la gestion des
exigences (suite)
• Faire le suivi des exigences problématiques
– Des problèmes peuvent être identifiés dans les exigences (manque de
précision, contradiction, invraisemblance, etc.)
– S’assurer d’en faire le suivi pour ne pas les oublier/pour progresser
– Issue tracking: 1) des listes (action lists), ou 2) des ‘issue tracking tool’
(e.g. JIRA)
• Maintenir une matrice de traceabilité des exigences
– Une matrice qui fait le lien entre les exigences, et les différents
artifacts logiciels
– Permet de, a) évaluer l’avancement dans la réalisation de l’exigence, et
b) faire l’étude d’impact des changements d’exigences
• Utiliser un outil de gestion d’exigences (ch 30)
– Permettent de centralise et d’automatiser plusieurs pratiques
mentionnées ci-haut
2/2/2014
Hafedh Mili – Copyright 2014
21
Bonnes pratiques: gest. connaissances
autour du génie d’exigences
• Former les analystes d’affaires en génie des exigences
– Voir chapitre 4
• Former les parties prenantes sur le génie des exigences
– Clarifier les rôles et attentes de part et d’autres dans le
génie des exigences
• Former les développeurs sur le domaine d’application
– Promeut meilleure compréhension des exigences
• Définir, documenter, et disséminer un processus de
gestion d’exigences
– Meilleure qualité, de façon plus systématique
• Maintenir un glossaire des termes du métier
– Définitions, synonymes, acronymes, etc.
2/2/2014
Hafedh Mili – Copyright 2014
22
11
02/02/2014
Bonnes pratiques en gestion de projets
• Choisir le bon cycle de développement pour votre projet
– Étudier, adopter, et adapter, selon type de projet, et pratiques de
l’organisation,
• Planifier l’approche aux exigences (processus, timing, etc.)
• Estimer l’effort requis pour les exigences (ch 19)
– Pour garantir la disponibilité des ressources nécessaires
– Pour mieux planifier le projet …
• … Baser le plan du projet sur les exigences
– Le plan initial sera nécessairement approximatif
– Prévoir de réviser le plan au fur et à mesure que les exigences se
clarifient
• Identifier les décideurs pour des exigences/classes d’exigences
particulières
– En cas de conflit, il nous faut une personne/ressource de référence
2/2/2014
Hafedh Mili – Copyright 2014
23
Bonnes pratiques en gestion de projet
• Renégocier les engagements du projet quand les exigences
changent
– Il faut avoir une bonne idée de l’impact des changements (voir
pratiques plus haut)
– Ne pas jouer à l’héros/demander aux développeurs de l’être
• Analyser, documenter, et gérer les risques liés aux exigences (ch 32)
– Exigences floues, ou certaines exigences ne seront connues que plus
tard, ou révisées suite à …
• Mesurer l’effort dépensé en exigences
– Pour devenir plus efficace
– Pour mieux estimer la prochaine fois
• Faire (et revoir) les leçons apprises des autres projets concernant es
exigences
– Tout projet doit avoir un post-mortem dont le but est de dégager les
leçons apprises du projet en cours
2/2/2014
Hafedh Mili – Copyright 2014
24
12
02/02/2014
Mise en place des bonnes pratiques
• Beaucoup de sens commun
• Les pratiques ont différentes valeurs ajoutées
• Certaines pratiques sont plus difficiles que
d’autres à instituer
• =>
• Se concentrer sur celles qui apportent le plus de
valeur d’abord
• Au fur et à mesure que l’organisation « mature »
sa pratique d’exigences, incorporer les autres
bonnes pratiques
2/2/2014
Hafedh Mili – Copyright 2014
25
13