Requirements Management in CMMI 20130211

gestion des exigences et
CMMI
Miguel Alabau – Orange

11 février 2013
Miguel Alabau
+33 608 020 723
miguel.alabau@orange.com
miguel.alabau@gmail.com
Orange – diffusion libre
chapitres
Exigences
CMMI
CMMI et gestion des exigences
Exemple
2 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013
presentation title 1
exigences
exigences: de nombreuses définitions
Ce qui est commandé par les circonstances, la Les exigences d'origine sont déduites :
nature, la satisfactions des besoins, des lois …. de l'expression du besoin établi par le donneur
(Larousse) d'ordre (oralement ou textuellement)
des contraintes internes (industrielles ou
Ce qui assure la manière et les conditions dans commerciales)
lesquelles un produit réalisera un objectif défini.
Leur qualité (structure, granularité, sémantique) est
Un énoncé qui traduit ou exprime un besoin, plus ou moins satisfaisante selon l'effort de
des contraintes. formalisation consenti en amont
Déclaration qui identifie une capacité, Elles sont analysées, éventuellement
caractéristique physique ou facteur qualité qui reformalisées, et revues avant d'être déclarées de
délimite le besoin d’un produit ou d’un REFERENCE (= exploitables par les phases
processus pour lequel une solution est ultérieures de développement)
recherchée. (norme IEEE 1220)
Condition ou capacité contractuelle, clairement
exprimée et vérifiable sans ambiguïté par le
demandeur
…
catégories d’exigences
exigences
exigences Sûreté de fonctionnement non fonctionnelles
fonctionnelles fiabilité, sécurité, disponibilité ...
Fonctions Performances
Système
Comportement
à réaliser Ergonomie
modes opératoires,
réactivité à l'environnement
Contraintes
Données Coûts, délais, évolutivité,
qualification, acceptation,
architecture
contraintes
gestion des exigences
Objectifs
Définir et documenter de manière précise et complète les exigences du client : une compréhension
commune des exigences doit être établie entre le client et le projet
Prendre en compte et suivre les exigences dans toutes les étapes du projet de façon à assurer leur respect,
leur traçabilité et informer le client sur l'état de leur prise en compte gérer les modifications
Résultats
Établir un communication permanente entre MOA et MOE pour
définir un accord sur les exigences
prendre en compte les nouvelles exigences
offrir une visibilité sur l'état d'avancement dans la prise en compte des exigences
contrôler et suivre les exigences
établir une référence : le Dossier des exigences
Du point de vue du MOE
contrôler et suivre les exigences
évaluer les impacts des évolutions des exigences
ingénierie des exigences
Exemple de processus selon l’AFIS
pratiques de base
Attribuer les responsabilités

Définir les ressources et financements
Former l'équipe projet aux activités de gestion des exigences
Recueillir les Identifier les exigences Suivre les exigences

besoins Définir les exigences* Prendre en compte les exigences*
Faire approuver les exigences* Gérer les changements
Assurer la traçabilité
Informer le client sur l'état de prise en
compte
Dossier des exigences : Matrices de traçabilité

exigences fonctionnelles
et non fonctionnelles
* : Activités minimales
identifier les exigences
Recenser les besoins et exigences du client => Dossier des exigences

Pour chaque exigence, on fournit: Description d’une exigence selon l’AFIS
Identificateur
une définition précise, concise et non ambiguë Énoncé
un moyen d'identification unique Type de vérification (test, observation, essai,…)
les besoins initiaux Catégorie (fonctionnelle, opérationnelle,
performance, accessibilité,…)
sa priorité
Criticité (faible, … forte)
les moyens de vérification associés Flexibilité (faible,… forte)
Maturité (origine, analysée, vérifiée, approuvée,
Libellé d'une exigence implémentée,…)
Une exigence doit s'énoncer selon une phrase simple de la forme

<Sujet> <Verbe> <Complément indiquant le QUOI>
Le logiciel doit permettre un accès sécurisé aux données du service d'annuaire
Le verbe décrit l'action attendue de l'exigence: il doit être précis

doit détermine une exigence contractuelle
devrait ou pourrait déterminent une recommandation parmi d'autres possibilités
identifier les exigences
Qualité des exigences

Exhaustives, claires, non interprétables, non redondantes, non contradictoires
Identifiables de façon unique dans tout le logiciel
Réalisables dans le respect des coûts et délais
Vérifiables ou qualifiables (critères d'acceptation)
Traçables
Méthodes de vérification
Une exigence doit être vérifiée selon une méthode (à coût défini) qui assure que le
logiciel réalise bien l'exigence
Les méthodes de vérifications reposent sur des:
Test vérifier les caractéristiques fonctionnelles mesurables
Démonstration vérifier les capacités opérationnelles observables
Analyse vérifier sur des preuves analytiques obtenues par calcul:
modélisation, simulation, prédiction…
Inspection examen visuel du code, de la documentation ...
suivre les exigences
Prise en compte des exigences dans les plans, produits de travail et activités logiciel
Gestion des modifications
l'impact des changements est évalué
les changements sont
documentés
négociés
planifiés
communiqués
suivis jusqu'à achèvement
Informer le client sur l'état de prise en compte des exigences
traçabilité des exigences
Apport de la traçabilité
Vérification de la couverture en produisant des matrices de couverture
Vérification de la pertinence des exigences produites
Vérification de la non sur-spécification du système
analyse du degré d'achèvement du projet
Connaissance de l'origine de l'exigence
Support à l'analyse d'impact de l'évolution d'une exigence sur le cycle de développement
Moyens à mettre en œuvre

L'application de la traçabilité requiert la mise en place de relations entre les différents objets du
système participant à la réalisation des exigences...
dans le but de
retrouver la localisation d'une exigence
retrouver l'historique d'une exigence
retrouver l'utilisation d'une exigence
mesures, documents standards
Mesures
Quantité d’effort du projet consacré à la gestion des exigences
Quantité d’effort supplémentaire dû aux modifications des exigences n'ayant pas fait l'objet d'une
renégociation avec le client
Quantité d’effort supplémentaire dû à une mauvaise compréhension des exigences
Modèles de documents et de fiches

Dossier d'expression du besoin (DEB)
Dossier des exigences
Matrice de traçabilité / Matrice de couverture
contexte agile
Les exigences sont exprimées sous forme de User Stories

Les User Stories sont stockées dans un Produc Backlog
La gestion du Product Backlog est du ressort du Product Owner (PO)
Le recueil et la gestion des exigences sont faits par le PO
Avant le démarrage du projet, le PO
Identifie les objectifs business auxquels le projet contribue (la vision), définit des objectifs opérationnels
pour le projet, et le découpage de chaque objectif opérationnel en Epics/Features/User Stories
regroupe les User Stories en paquets de fonctionnalités (Features) pour produire une roadmap produit
Chaque User Story qui va être développée dans le sprint courant comporte les tests d’acceptation et les
critères permettant à l’équipe des développeurs de savoir quand arrêter le développement de la User Story
En début d’itération, le PO présente à l’équipe de développement les User Stories de l’itération
Dès qu’une User Story est implémentée, le PO valide (tests d’acceptation) la User Story
En fin d’itération, une démonstration est faite des fonctionnalités développées dans l’itération
L’équipe de développement découpe chaque User Story du sprint courant en tâches

Chaque tâche est définie avec ses tests unitaires
Quand toutes les tâches d’une User Story sont terminées, y compris les tâches techniques (exemple:
intégration), la User Story passe dans l’état pour être validée par le PO
formalismes
Vision
POUR <cible d’usagers>
QUI <ont un besoin>
LE <Nom du produit> EST UN <Catégorie du produit>
QUI <bénéfice clef>
AU CONTRAIRE DE <concurrence>
NOTRE PRODUIT <élément différentiant>
User Story
DANS LE BUT DE <produire une certaine valeur>
EN TANT QUE <type d’utilisateur, rôle>
JE VEUX <faire quelque chose(= fonctionnalité)>
CMMI
CMMI permet d’industrialiser la façon de travailler des organisations
CMMI est un outillage à mettre en œuvre dans une démarche d’amélioration

CMMI adresse le développement et la fourniture de services, et le pilotage de la sous-traitance
Il concerne la gestion du travail et des activités techniques
CMMI n’impose pas un cycle de vie ni une façon de travailler
CMMI est en harmonie avec de nombreux standards (CobiT, ITIL, ISO 9001, … ) et avec les
démarches agiles (Scrum, Kanban, XP,…)
La mise en œuvre de CMMI produit des gains démontrés

Les exigences sur les processus s’appuient sur les bonnes pratiques du métier
Les mesures fournies par les entreprises qui utilisent CMMI depuis longtemps montrent qu’il y a un
réel ROI à implémenter les exigences CMMI
La préoccupation spécifique de CMMI en ce qui concerne le déploiement et l’institutionnalisation
accroît la maturité des organisations au regard de la qualité
La qualité devient inhérente au travail de tous les jours, pas quelque chose de surajouté
Comme toujours, il y a des conditions pour réussir

Le top management doit piloter les démarches d’amélioration et stimuler l’implication de chacun
Le management intermédiaire doit être associé à la définition des objectifs et à la construction des
plans d’amélioration
Les objectifs d’amélioration doivent être dérivés des objectifs de négoce ou du SI
Les objectifs d’amélioration doivent être réalistes
processus opérationnels et domaines de processus CMMI
Domaine de processus Processus opérationnel de

(PA -- Process Area) l’organisation
C’est un ensemble de pratiques C’est la mise en œuvre orchestrée
cohérentes pour couvrir un domaine d’un ensemble de pratiques
d’activités (gestion de configuration,
qualification, etc.) Le processus dit ce qu’on doit faire,
mais également quand et comment
Un domaine de processus ne dit pas
comment ni quand les pratiques
doivent être mises en oeuvre
Un domaine de processus est un ensemble d’incontournables
(exigences) que doit satisfaire un processus opérationnel
Dans l’entreprise, ce sont bien les processus opérationnels que

l’on met en oeuvre
CMMI & usages
Finalité Éléments de CMMI Utilisation possible
Exigences pour la mise en Objectifs et pratiques spécifiques Prise en compte des pratiques spécifiques CMMI dans la définition
œuvre d’activités des processus de l’organisation.
techniques ou de pilotage
(le quoi)
Exigences pour le Objectifs et pratiques génériques Déploiement des pratiques spécifiques CMMI dans les processus de
déploiement et l’organisation.
l’institutionnalisation des
Les objectifs et pratiques génériques peuvent s’appliquer à tout ensemble
activités techniques ou de d’activités (y compris un processus opérationnel) pour en garantir le
pilotage déploiement.
(le quoi)
Niveaux de maturité de l’organisation Mise en place guidée des exigences CMMI dans les processus de
(approche étagée) l’organisation, et déploiement
L’ordre dans lequel sont traités les domaines de processus est prédéfini
Niveaux d’aptitude des processus Mise en place libre des exigences CMMI dans les processus de
(approche continue) l’organisation, et déploiement
L’ordre dans lequel sont traités les domaines de processus est laissé au
choix de l’organisation
Lignes directrices pour Compléments du modèle: Ces éléments détaillent les bonnes pratiques et peuvent aider à
l’implémentation des éléments informatifs, notes, explications, l’implémentation des processus
pratiques exemples d’activités et de livrables, et
sous-pratiques
(le comment)
Méthode d’évaluation Méthode SCAMPI Mesure du déploiement des exigences CMMI dans l’organisation ,
formelle du déploiement selon des critères rigoureux et tendant à l’objectivité
approche étagée / approche continue

Démarche étagée
Les processus sont groupés par niveaux de maturité

La structure de chaque niveau est prédéfinie
Un niveau de maturité est atteint lorsque tous les
processus de ce niveau de maturité et ceux des
niveaux en-dessous atteignent tous leurs objectifs
Profil Démarche continue

d’achèvement
Requirem ents M anagem ent
Project Planning
Project Monitoring Profil cible On choisit un ou plusieurs processus

and Control
On définit un profil cible de niveaux d’aptitude

Supplier Agreem ent
M anagem ent
On évalue régulièrement => on établit des profils
M easurem ent and Analysis
d’achèvement
Process and Product

Chaque nouveau profil d’achèvement permet de
Quality Assurance bâtir ou rectifier les plans d’actions
Configuration M anagem ent
Capability Capability Capability Capability Capability

Level 1 Level 2 Level 3 Level 4 Level 5
niveaux de maturité d’une organisation
En amélioration continue - Niveau 5

L’organisation pilote l’amélioration des activités clés pour
l’atteinte des objectifs business
Géré quantitativement - Niveau 4

Les processus sont sous contrôle fin
On sait prédire de manière précise qu’une activité finira bien
Défini - Niveau 3
Les processus métiers sont maîtrisés et partagés par tous,
et ils répondent à des objectifs de l’organisation
Géré - Niveau 2
On sait piloter l’activité
Initial - Niveau 1
L’étoffe des héros
CMMI-SVC fournit des lignes directrices CMMI Model Foundation (CMF)

aux fournisseurs de services, aussi bien
constellations CMMI 1.3 externes qu’internes
Process Management
3 Organizational Process Focus (OPF)

constellation = modèle de processus + méthode d’évaluation + formations
3 Organizational Process Definition (OPD)
Services: domaines de processus spécifiques 3 Organizational Training (OT)
Project and Work Management 4 Organizational Process Performance (OPP)
2 Supplier Agreement Management (SAM) 5 Organizational Performance Management (OPM)
3 Capacity and Availability Management (CAM) Project Management (*)
3 Service Continuity (SCON) 2 Project Planning (PP / WP **)
Service Establishment and Delivery 2 Project Monitoring and Control (PMC / WMC **)
3 Incident Resolution and Prevention (IRP) 3 Integrated Project Management (IPM / IWM **)
2 Service Delivery (SD) Domaine de

CMMI-SVC 3 Risk Management (RSKM)
processus 4 Quantitative Project Management (QPM / QWM **)
3 Service System Development (SSD)
optionnel
2 Requirements Management (REQM)
3 Service System Transition (ST) (addition) CMMI Model Foundation
3 Strategic Service Management (STSM) (16 domaines de processus Support
communs) 2 Configuration Management (CM)
2 Process and Product Quality Assurance (PPQA)
2 Measurement and Analysis (MA)

Domaine de processus commun
CMMI-DEV CMMI-ACQ 3 Decision Analysis and Resolution (DAR)
5 Causal Analysis and Resolution (CAR)

Développement: domaines de processus
spécifiques Sous-traitance: domaines de processus spécifiques
Project Management Project Management
2 Supplier Agreement Management (SAM) 2 Agreement Management (AM)
Engineering 2 Solicitation and Supplier Agreement Development (SSAD)
3 Requirements Development (RD) Acquisition Engineering
3 Technical Solution (TS) CMMI-DEV fournit des lignes directrices 2 Acquisition Requirements Development (ARD)
3 Product Integration (PI) pour le suivi, la maîtrise et la gestion des CMMI-ACQ fournit des lignes 3 Acquisition Technical Management (ATM)
directrices pour suivre et
3 Verification (VER) processus du développement des 3 Acquisition Verification (AVER)
produits et services piloter la sous-traitance
3 Validation (VAL) 3 Acquisition Validation (AVAL)
(*) dans SVC: Project and Work Management (**) dans SVC: le mot « Project » est remplacé par « Work », donc PP, PMC, IPM & QPM deviennent WP, WMC, IWM & QWM
structure des domaines de processus CMMI domaine de
processus CMMI
Spécifiques: le métier Objectifs du processus
Objectifs spécifiques
Génériques: le pilotage du processus
Pratiques spécifiques
GG2 – institutionnaliser un GG3 – institutionnaliser un
processus géré processus défini
Le processus
On met en œuvre ce qu’il est commun à
faut pour que le processus l’organisation,
puisse se dérouler et on collecte
des mesures en
GP2.1-Establish an Organizational Policy vue de son
Établir et maintenir une directive organisationnelle traitant de la planification et de la mise en œuvre
du processus. amélioration
Les pratiques génériques sont GP2.2-Plan the Process
Établir et maintenir le plan pour la mise en œuvre du processus.
les mêmes pour tous les GP2.3-Provide Resources
GP3.1-Establish a Defined Process
Etablir et maintenir la description
domaines de processus. Fournir les ressources adéquates pour la mise en œuvre du processus, le développement des produits
du travail et la prestation des services couverts par le processus. d'un processus défini.
GP2.4-Assign Responsibility GP3.2-Collect Process Related
Assigner les responsabilités et l’autorité pour la mise en œuvre du processus, le développement des Experiences
La façon dont elles s’appliquent produits du travail et la prestation des services couverts par le processus.
GP2.5-Train People Collecter les produits du travail, les
dans chaque domaine de Former selon les besoins les personnes qui mettent en œuvre ou soutiennent le processus. mesures, les résultats du mesurage, et
GP2.6-Manage Configurations les données pour l'amélioration issus
processus varie. Gérer en configuration, au niveau approprié, les produits du travail du processus. de la planification et de la mise en
GP2.7-Identify and Involve Relevant Stakeholders oeuvre du processus dans le but de
Identifier et impliquer, tel que planifié, les parties prenantes concernées par le processus.
GP2.8-Monitor and Control the Process favoriser l'usage et l'amélioration
Ex: fournir les ressources Suivre et contrôler le processus vis-à-vis son plan de mise en œuvre et mener les actions correctives dans le futur des processus de
appropriées.
(GCL: outils de GCL, GP2.9-Objectively Evaluate Adherence
l'organisation et des actifs du
processus.
planification : outils de Évaluer de manière objective la conformité du processus à sa description, ses normes et ses
procédures et traiter les non-conformités détectées.
planification, …) GP2.10-Review Status with Higher Level Management
Passer en revue avec les responsables de niveau supérieur les activités, le statut et les résultats du
processus et résoudre les points soulevés.
un exemple de domaine de processus Processus CM

Configuration Management
gestion de configuration
SG1 – définir les SG2 – suivre et SG3 – garantir

référentiels contrôler les l’intégrité des
changements référentiels Génériques: le pilotage du processus
SP1.1 - Identify Configuration Items SP3.1-Establish Configuration Management Records

Identifier les articles de configuration, Établir et maintenir les enregistrements décrivant les articles de GG2 – institutionnaliser un GG3 – institutionnaliser un
les composants et les produits du travail configuration. processus géré processus défini
associés qui seront gérés en SP3.2-Perform Configuration Audits
configuration. Perform Configuration Audits Le processus
SP1.2 - Establish a Configuration Mener des audits de configuration pour maintenir l’intégrité des On met en œuvre ce qu’il est commun à
Management System référentiels de configuration. faut pour que le processus l’organisation,
Établir et maintenir un système de puisse se dérouler et on collecte
gestion de configuration et de gestion des mesures en
des changements pour contrôler les GP2.1-Establish an Organizational Policy vue de son
Établir et maintenir une directive organisationnelle traitant de la planification et de la mise en œuvre
produits du travail. du processus. amélioration
SP1.3 - Create or Release Baselines GP2.2-Plan the Process
Créer ou mettre à jour des référentiels Établir et maintenir le plan pour la mise en œuvre du processus. GP3.1-Establish a Defined Process
pour usage interne et pour livraison au GP2.3-Provide Resources Etablir et maintenir la description
Fournir les ressources adéquates pour la mise en œuvre du processus, le développement des produits
client. du travail et la prestation des services couverts par le processus. d'un processus défini.
GP2.4-Assign Responsibility GP3.2-Collect Process Related
Assigner les responsabilités et l’autorité pour la mise en œuvre du processus, le développement des Experiences
SP2.1-Track Change Requests produits du travail et la prestation des services couverts par le processus.
GP2.5-Train People Collecter les produits du travail, les
Suivre les demandes de changement aux
Former selon les besoins les personnes qui mettent en œuvre ou soutiennent le processus. mesures, les résultats du mesurage, et
articles de configuration.
GP2.6-Manage Configurations les données pour l'amélioration issus
SP2.2-Control Configuration Items Gérer en configuration, au niveau approprié, les produits du travail du processus. de la planification et de la mise en
Contrôler les changements aux articles de GP2.7-Identify and Involve Relevant Stakeholders
Identifier et impliquer, tel que planifié, les parties prenantes concernées par le processus. oeuvre du processus dans le but de
configuration.
Suivre et contrôler le processus vis-à-vis son plan de mise en œuvre et mener les actions correctives dans le futur des processus de
appropriées. l'organisation et des actifs du
GP2.9-Objectively Evaluate Adherence processus.
Évaluer de manière objective la conformité du processus à sa description, ses normes et ses
GP2.10-Review Status with Higher Level Management
un autre exemple de domaine de processus Processus REQM
Requirements Management
SG1 – Gérer les exigences
Génériques: le pilotage du processus
GG2 – institutionnaliser un GG3 – institutionnaliser un

processus géré processus défini
SP1.1 – Understand Requirements
Développer une compréhension commune des exigences Le processus
et de leur signification avec ceux qui les ont fournies. On met en œuvre ce qu’il est commun à
SP1.2 – Obtain commitment to Requirements faut pour que le processus l’organisation,
Obtenir des participants au projet leur engagement sur puisse se dérouler et on collecte
les exigences. des mesures en
SP1.3 – Manage Requirements Changes GP2.1-Establish an Organizational Policy vue de son
Gérer les modifications aux exigences au fur et à mesure Établir et maintenir une directive organisationnelle traitant de la planification et de la mise en œuvre
du processus. amélioration
de leur évolution en cours de projet. GP2.2-Plan the Process
SP1.4 – Maintain bidirectional traceability of Établir et maintenir le plan pour la mise en œuvre du processus. GP3.1-Establish a Defined Process
Requirements GP2.3-Provide Resources Etablir et maintenir la description
Maintenir une traçabilité bidirectionnelle entre les Fournir les ressources adéquates pour la mise en œuvre du processus, le développement des produits
du travail et la prestation des services couverts par le processus. d'un processus défini.
exigences et les produits d’activité. GP2.4-Assign Responsibility GP3.2-Collect Process Related
SP1.3 – Ensure Alignment Between Work Products Assigner les responsabilités et l’autorité pour la mise en œuvre du processus, le développement des Experiences
and Requirements produits du travail et la prestation des services couverts par le processus. Collecter les produits du travail, les
S’assurer que les plans de projet et les produits GP2.5-Train People
Former selon les besoins les personnes qui mettent en œuvre ou soutiennent le processus. mesures, les résultats du mesurage, et
d’activité demeurent alignés sur les exigences. GP2.6-Manage Configurations les données pour l'amélioration issus
Gérer en configuration, au niveau approprié, les produits du travail du processus. de la planification et de la mise en
GP2.7-Identify and Involve Relevant Stakeholders oeuvre du processus dans le but de
Identifier et impliquer, tel que planifié, les parties prenantes concernées par le processus.
Suivre et contrôler le processus vis-à-vis son plan de mise en œuvre et mener les actions correctives dans le futur des processus de
appropriées. l'organisation et des actifs du
GP2.9-Objectively Evaluate Adherence processus.
Évaluer de manière objective la conformité du processus à sa description, ses normes et ses
GP2.10-Review Status with Higher Level Management
CMMI et gestion des

exigences
la gestion des exigences dans le cycle de développement
Gestion de projet et du travail
Exigences produit et
composants du produit
Exigences produit et Plans Accord avec
REQM composants du produit PP SAM le fournisseur Sous-traitant
Gestion des Gestion de la relation
Planification de projet
exigences fournisseur
Exigences composants de produit, problèmes
Exigences produit et techniques, composants de produit terminés et
composants du produit revues et tests d’acceptation
Ingénierie
Alternatives de solutions
RD TS Composants Produit
Développement des Solution du produit PI Client
exigences Exigences technique Intégration
Exigences, Composants du produit, produits d’activité,

rapports de vérification et de validation
VER VAL
Vérification Validation
Besoins client
But de la gestion des exigences (REQM, SG 1 Gérer les exigences

Requirements Management) Les exigences sont gérées et les incohérences avec
les plans et les produits du travail sont identifiées
gérer les exigences des produits et composants (développement, maintenance, services, sous-
traitance)
de produit du projet SP 1.1 Comprendre les exigences
assurer l’alignement de ces exigences sur les SP 1.2 Obtenir l’engagement sur les exigences
plans et les produits d’activité du projet. SP 1.3 Gérer les modifications aux exigences
SP 1.4 Maintenir la traçabilité bidirectionnelle des
exigences
SP 1.5 Assurer l’alignement des produits du projet sur
Exemples de produits d’activité les exigences
Base de données
des exigences, leur état, l’impact pour les parties
prenantes
historique des modifications et décisions sur les
exigences
Backlog produit, user stories
Critères d’évaluation et d’acceptation
Fournisseurs d’exigences appropriés
Résultats d’analyse par rapport aux critères et accord
Matrice de traçabilité des exigences
Système de suivi des exigences
Documentation des incohérences
Source, condition, raison
le développement des exigences dans le cycle de développement
composants du produit
Exigences produit et Plans Accord avec
REQM composants du produit PP SAM le fournisseur Sous-traitant
Gestion des Gestion de la relation
Planification de projet
exigences fournisseur
Exigences composants de produit, problèmes
Exigences produit et techniques, composants de produit terminés et
composants du produit revues et tests d’acceptation
Ingénierie
Alternatives de solutions
RD TS Composants Produit
Développement des Solution du produit PI Client
exigences Exigences technique Intégration
Exigences, Composants du produit, produits d’activité,

rapports de vérification et de validation
VER VAL
Vérification Validation
Besoins client
développement des exigences
But du développement des exigences (RD, SG 1 Développer les exigences client

Requirements Development) Les Besoins, attentes, contraintes, et interfaces sont
rassemblés et traduits en exigences clients.
obtenir et expliciter, analyser et établir les SP 1.1 Expliciter les besoins
exigences client, produit et composants de SP 1.2 Transformer les besoins des parties prenantes
produit. en exigences client
SG 2 Développer les exigences produit

Les exigences client sont précisées et détaillées pour
développer les besoins des livrables et des
composants.
Exemples de produits d’activité SP 2.1 Établir les exigences produit et composants de
produit
Exigences client, contrainte sur la conduite V&V
SP 2.2 Allouer les exigences aux composants de
Exigences produit/composants, dérivées produit
Contraintes de conception, inter-relations SP 2.3 Identifier les exigences d’interface
Concepts d’emploi, cas d’utilisation, scénarios
Concepts sur SG 3 Analyser et valider les exigences
installation, exploitation, maintenance, retrait Les exigences sont analysées, validées et une
Architecture fonctionnelle, diagrammes d’activité, définition des fonctionnalités est développée .
analyse orientée objet SP 3.1 Établir des concepts d’emploi et des scénarios
…rapports, exigences clé, risques SP 3.2 Établir une définition des fonctionnalités
requises et des attributs de qualité
SP 3.3 Analyser les exigences
SP 3.4 Analyser les exigences pour assurer l’équilibre
SP 3.5 Valider les exigences
SG 1 Développer les exigences client

Les Besoins, attentes, contraintes, et interfaces sont rassemblés
et traduits en exigences clients.
SP 1.2
Transformer les
SP 1.1
besoins des
Expliciter les
parties prenantes
besoins
en exigences
client Exigences client
SP 1.1 Expliciter les besoins SP 1.2 Transformer les besoins des parties prenantes
Obtenir et expliciter les besoins, attentes, en exigences client
contraintes et interfaces des parties prenantes Transformer les besoins, attentes, contraintes et
pour toutes les phases du cycle de vie du produit. interfaces des parties prenantes en exigences client
priorisées.
Exemples de techniques
Démonstrations technologiques Exemples de preuves de l’activité
Enquête de marché Exigences client consolidées et matrice de traçabilité
Prototypes,modèles, beta tests … Contraintes client sur la mise en œuvre de la vérification
Questionnaires, interviews, … Contraintes clients sur la mise en œuvre de la validation
Demande de travail
SG 2 Développer les exigences produit

Les exigences client sont précisées et détaillées pour développer
les besoins des livrables et des composants.
SP 2.1 Établir
SP 2.2 Allouer SP 2.3
les exigences
les exigences Identifier les
produit et
composants exigences
composants
de produit d’interface
Exigences client de produit Besoins pour les livrables,
livrables,
leurs composants
et les interfaces internes
et externes
SP 2.1 Établir les exigences produit et SP 2.2 Allouer les exigences SP 2.3 Identifier les exigences
composants de produit composants de produit d’interface
Établir et maintenir les exigences produit Allouer les exigences pour chaque
et composants de produit, qui sont composant de produit.
basées sur les exigences client.
Exemples de preuves de l’activité
Exemples de preuves de l’activité Tableau d’allocation des exigences
Exigences dérivées Contraintes de conception
Besoins des livrables Specifications techniques
Besoins des composants des livrables Exigences dérivées et leurs relations
SG 3 Analyser et valider les exigences

Les exigences sont analysées, validées et une
définition des fonctionnalités est développée .
SP 3.4
SP 3.3 Analyser les
Analyser les exigences pour
exigences assurer
SP 3.2 Établir l’équilibre
une définition
SP 3.1 Établir
des
des concepts
fonctionnalités
d’emploi et des
requises et des
scénarios
Besoins pour les livrables,
livrables, attributs de
leurs composants qualité
et les interfaces internes SP 3.5 Valider
et externes les exigences
Besoins validés
Document de traçabilité
SP 3.1 Établir des concepts d’emploi SP 3.2 Établir une définition des SP 3.3 Analyser les exigences
et des scénarios fonctionnalités requises et des attributs de Analyser les exigences pour s’assurer qu’elles sont
Établir et maintenir des concepts qualité nécessaires et suffisantes.
d’emploi et des scénarios associés. Établir et maintenir une définition des SP 3.4 Analyser les exigences pour assurer l’équilibre
fonctionnalités requises et des attributs de qualité. Analyser les exigences pour équilibrer les besoins et
Exemples de preuves de l’activité contraintes des parties prenantes.
Concepts opérationnels Exemples de preuves de l’activité SP 3.5 Valider les exigences
Concepts d’installation, de Specifications techniques et fonctionnelles Valider les exigences pour s’assurer que le produit résultant
maintenance et de support Architecture fonctionnelle aura le comportement
Use case de haut niveau Diagrammes d’activités et Use cases prévu dans l’environnement de l’utilisateur final.
Analyses orientées objet et les services
identifiés
le flux des exigences est tracé finement dans le modèle
la gestion des exigences dans les services
Gestion du service
Exigences du service
Plans SAM Accord avec
REQM WP Gestion de la relation le fournisseur
Sous-traitant
Gestion des Exigences
Exigences de Plan de Planification du travail fournisseur
continuité continuité
Plans de
Analyse des
SCON ressources
l’activité Exigences composants de produit ou
Gestion de la service, problèmes techniques,
continuité du service composants de produit ou service
terminés et revues et tests d’acceptation
Plans de
WMC
Exigences Exigences de capacité CAM l’activité Pilotage de l’activité
standard du et de disponibilité
Gestion de la capacité
service
et de la disponibilité Contraintes sur les
ressources et seuils du
Exigences service révisés
du service SD
Fourniture du service Exigences
de service
STSM Exigences SSD Service
Gestion stratégique du service
validé Client
du service Développement du
service Contrat/SLA
Exigences
du service SST
Transition du service
Besoins stratégiques du service

Etablissement et fourniture du service
gestion de la sous-traitance
CMMI-DEV et CMMI-SVC : CMMI-ACQ :

1 domaine de processus (SAM) 6 domaines de processus spécifiques
SG 1 Établir les accords avec les fournisseurs ARD Acquisition Requirements Development
SP 1.1 Déterminer le type d’acquisition Solicitation and Supplier Agreement
SSAD
SP 1.2 Choisir des fournisseurs Development
SP 1.3 Établir des accords avec les fournisseurs AM Agreement Management
SG 2 Se conformer aux accords avec les fournisseurs ATM Acquisition Technical Management
SP 2.1 Exécuter l’accord avec le fournisseur
SP 2.2 Accepter le produit acquis
AVER Acquisition Verification
SP 2.3 S’assurer du transfert des produits AVAL Acquisition Validation
CMMI-DEV: RD CMMI-ACQ: ARD
SG 1 Develop Customer Requirements SG 1 Develop Customer Requirements

SP 1.1 Elicit Needs SP 1.1 Elicit Stakeholder Needs
SP 1.2 Transform Stakeholder Needs into Customer SP 1.2 Develop and Prioritize Customer Requirements
Requirements
SG 2 Develop Product Requirements SG 2 Develop Contractual Requirements

SP 2.1 Establish Product and Product Component SP 2.1 Establish Contractual Requirements
Requirements SP 2.2 Allocate Contractual Requirements
SP 2.2 Allocate Product Component Requirements
SP 2.3 Identify Interface Requirements
SG 3 Analyze and Validate Requirements SG 3 Analyze and Validate Requirements

SP 3.1 Establish Operational Concepts and Scenarios SP 3.1 Establish Operational Concepts and Scenarios
SP 3.2 Establish a Definition of Required Functionality and SP 3.2 Analyze Requirements
Quality Attributes SP 3.3 Analyze Requirements to Achieve Balance
SP 3.3 Analyze Requirements SP 3.4 Validate Requirements
SP 3.4 Analyze Requirements to Achieve Balance
SP 3.5 Validate Requirements
la gestion des exigences dans le cas de la sous-traitance

composants du produit Plans AM Accord avec
REQM PP Gestion de le fournisseur Sous-traitant
Gestion des
exigences Planification de projet l’accord fournisseur
Exigences produit et Exigences composants de

Plans
composants du produit produit, problèmes techniques,
composants de produit terminés
et revues et tests d’acceptation
ARD Exigences SSAD Accord avec le

ATM Client
Développement de fournisseur
Développement des
Suivi
exigences
l’appel d’offre et de technique
l’accord fournisseur
Exigences, Composants du
produit, produits d’activité, rapports
de vérification et de validation AVER
Vérification
AVAL
Validation
Besoins client
Développement et exécution de l’accord fournisseur
exemple
processus de gestion des exigences dans les
projets de développement du SI à Orange
le processus tel qu’en 2009

Project creation Project start
TLE T0 T1 T1a T1b T1c T3
Before project: STUDY Project definition Design Construction Verif & Val Stabilization
REQM SP 1.1 Requirements Management strategy elaboration

REQM GP2.2
REQM GP2.3
REQM GP2.4 Characterize Reqs REQM SP 1.3
REQM GP2.5 Management
Perform preparation tasks

REQM SP1.2 REQM SP 1.4 & P1.5
Review & validate Reqs
REQM GP2.7 Management strategy
REQM SP1.2 Definition of requirements Strategy review Requirements follow-up

REQM GP2.3 report
Identify requirements Establish traceability
Perform reviews of
Analyze requirements requirements
Inconsitencies
report
Management of requirements changes
Review Review
Requirements requirements Analyze & validate
requirements change Iterate if new
request requirements
Validate
requirements Integrate change in the change request
referential referential of requirements
Requirements
referential Construction of requirements management assessment
REQM SP 1.2
REQM SP 1.1 Collect elements for assessment Finalize assessment
(requirements part)
REQM GP2.6
REQM GP3.2 REQM GP5.2
GP2.8 , GP2.9, GP2.10
PO: Process Owner
DPO: Deputy Process Owner
RO: Operational Head
GP2.1 Site web institutionnel (connu de tous) qui contient:

La description du système qualité
Les relevés de décision
La description de la gestion des processus
L’identification des parties prenantes
La description détaillée de chaque processus
the world around PMC
RSKM
Le référentiel d’exigences est partagé
par tous les processus
PP
Project
Management
RD
IS Change
Management Solution Proposal
Updates (Requirements): Project assessment
(previous versions) Analysis, Design &
Project Management plan
Project assessment Construction
Referential of requirements Risks
TS
Specification book update
Referential of
requirements
Requirements
Management Referential of requirements
Specification book (for the
supplier) update REQM (test cases)
VER
Qualification
REQM GP2.6
Referential of
VAL
Referential of requirements
requirements
Acquisition
SAM SP1.3
Pilot
REQM
Configuration implementation
CM Management Maintenance & VER
Operability VAL
Support
REQM
REQM
questions ?
merci
annexes
les domaines de processus CMMI
Reference: CMMI 1.3 appendix D – Glossary
exigences: définitions CMMI
Exigence (requirement) (1) Condition ou capacité dont un utilisateur a besoin pour résoudre un problème ou atteindre un objectif. (2)
Condition ou capacité que doit posséder un produit, un service, un composant de produit ou un composant
de service pour remplir un accord fournisseur, se conformer à une norme, une spécifi cation ou tout autre
document imposé formellement. (3) Représentation documentée d’une condition ou d’une capacité comme
dans (1) ou dans (2). (Voir aussi « accord fournisseur ».)
Exigence client Résultat de l’explicitation, de la consolidation et de la résolution des conflits entre les besoins, attentes,
(customer requirement) contraintes et interfaces des parties prenantes concernées par le produit sous une forme acceptable par le
client. (Voir aussi « client ».)
Exigences composants Spécification complète d’un composant de produit ou de service, comprenant caractéristiques physiques,
de produit (product fonctionnelles et adéquation, performance et autres exigences.
component requirements)
Exigences contractuelles Résultat de l’analyse et de l’affi nement des exigences client, formant un ensemble d’exigences susceptible
(contractual d’être inclus dans un ou plusieurs ensembles de documents de sollicitation ou accords fournisseurs. (Voir
requirements) aussi « acquéreur », « exigence client » « accord fournisseur » et « ensemble de documents de sollicitation
».)
Exigences dérivées Exigences qui ne sont pas explicitement énoncées dans les exigences client, mais qui sont déduites (1) des
(derived requirements) exigences contextuelles (par exemple, normes, lois, politiques, usages et décisions de la hiérarchie) ou (2)
des exigences nécessaires pour spécifier un composant de produit ou de service.
Exigences non Exigences affectant l’acquisition ou le développement d’un produit ou d’un service, qui ne sont pas des
techniques (nontechnical propriétés du produit ou du service.
requirements)
Exigences produit Affi nement des exigences client dans le langage du développeur, transformant des exigences implicites en
(product requirements) exigences dérivées explicites. (Voir aussi « exigences dérivées » et « exigences composants de produit ».)
Exigences service Ensemble complet des exigences qui affectent la fourniture de services et le développement de systèmes de
(service requirements) service. (Voir aussi « système de service ».)
Exigences techniques Propriétés (attributs) de produits ou de services à acquérir ou à développer.
(technical requirements)
Reference: CMMI 1.3 appendix D – Glossary
exigences: définitions CMMI
Traçabilité (traceability) Association discernable entre deux ou plusieurs entités logiques telles que des exigences, des éléments de
système, des vérifications ou des tâches. (Voir aussi « traçabilité bidirectionnelle » et « traçabilité des
exigences ».)
Traçabilité Association entre deux ou plusieurs entités logiques, discernable dans les deux sens (autrement dit depuis et
bidirectionnelle vers une entité). (Voir aussi « traçabilité des exigences » et « traçabilité ».)
(bidirectional traceability)
Traçabilité des exigences Association discernable entre les exigences et les exigences, implémentations et vérifi cations apparentées. (Voir aussi
(requirements « traçabilité bidirectionnelle » et « traçabilité ».)
traceability)

Requirements Management in CMMI 20130211

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Requirements Management in CMMI 20130211

Transféré par

Droits d'auteur :

Formats disponibles

gestion des exigences et

Miguel Alabau – Orange

2 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

3 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

exigences: de nombreuses définitions

4 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

5 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

gestion des exigences

6 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

Exemple de processus selon l’AFIS

7 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

Attribuer les responsabilités

Recueillir les Identifier les exigences Suivre les exigences

Dossier des exigences : Matrices de traçabilité

Recenser les besoins et exigences du client => Dossier des exigences

Une exigence doit s'énoncer selon une phrase simple de la forme

Le verbe décrit l'action attendue de l'exigence: il doit être précis

9 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

identifier les exigences

Qualité des exigences

10 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

Informer le client sur l'état de prise en compte des exigences

11 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

traçabilité des exigences

Moyens à mettre en œuvre

12 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

Modèles de documents et de fiches

13 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

Les exigences sont exprimées sous forme de User Stories

L’équipe de développement découpe chaque User Story du sprint courant en tâches

14 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

15 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

16 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

CMMI est un outillage à mettre en œuvre dans une démarche d’amélioration

La mise en œuvre de CMMI produit des gains démontrés

Comme toujours, il y a des conditions pour réussir

17 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

processus opérationnels et domaines de processus CMMI

Domaine de processus Processus opérationnel de

Dans l’entreprise, ce sont bien les processus opérationnels que

18 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

19 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

approche étagée / approche continue

Les processus sont groupés par niveaux de maturité

Profil Démarche continue

Project Monitoring Profil cible On choisit un ou plusieurs processus

On définit un profil cible de niveaux d’aptitude

Process and Product

Capability Capability Capability Capability Capability

20 Gestion des exigences et CMMI Orange – diffusion libre 11/02/2013

En amélioration continue - Niveau 5

Géré quantitativement - Niveau 4

CMMI-SVC fournit des lignes directrices CMMI Model Foundation (CMF)

3 Organizational Process Focus (OPF)

Services: domaines de processus spécifiques 3 Organizational Training (OT)

Project and Work Management 4 Organizational Process Performance (OPP)

2 Supplier Agreement Management (SAM) 5 Organizational Performance Management (OPM)

3 Capacity and Availability Management (CAM) Project Management (*)

3 Service Continuity (SCON) 2 Project Planning (PP / WP **)

2 Service Delivery (SD) Domaine de

communs) 2 Configuration Management (CM)

2 Process and Product Quality Assurance (PPQA)

2 Measurement and Analysis (MA)

5 Causal Analysis and Resolution (CAR)