La spécification du système

Spécification du système, ingénierie des

exigences
Yann Pollet
Conservatoire National des Arts et Métiers
Chaire d ’intégration des systèmes
 La spécification du système

• Exigences utilisateurs et exigences systèmes

• Le processus de base
• Types d’exigence
• Modélisation du système
• Ingénierie des Exigences
 Place dans la cycle de vie du système

Études
Définition Réalisation Installation Opération Retrait
préalables

Opportunité
Maître Exploitation
Faisabilité
d ’ouvrage
Expression
de besoins Reprise Administration
Basculement
Survie des
Déploiement Maintenance données
Spécification Validation
Lancement Soutien Étude
Maître d’impact
d’œuvre Intégration Basculement
Conception
Évolutions Ré- Réutilisation
Réalisation ingénierie
constituants
Cycle de développement
 Une première vision de l’I.S.…
Domaine du besoin Domaine
Analyse du besoin du MOA
Finalité
nouveau besoin Besoins multiples,
contraintes
à satisfaire d ’exploitation
Problème
Cahier des charges Exigences initiales

Spécification Système Exigences système

Possibilités
Domaine technologiques, Exigences liées à
limitation, la réalisation
du MOE potentialités
Conception du Intégration du
IS = Démarche système système Le Système
méthodologique pour
spécifier, concevoir, Modèles du Architecture réalisé ou
système système modifié
faire évoluer, faire
développer, intégrer, Réalisation ou acquisition une solution au
valider un système des constituants problème
Domaine de la solution
 De la finalité à la spécification
Transformer la finalité en un problème bien posé:
– Spécifier ce que doit faire le système
– Avec quels niveaux d’exigences
– quelles contraintes il doit respecter
Parties prenantes intéressées, Finalité
environnement
Exigences initiales
Définition des besoins Besoins perçus
Contraintes
Parties prenantes Spec. économiques Compromis
CdCF
concernées par la Système (optimisation)
réalisation, contraintes
technologiques Possibilités
Spécification de la solution technologiques
technique Exigences système
 La spécification système
But: Définir ce que le système doit faire (et non
pas comment il doit le faire)
– Produire une « définition abstraite » du système
– Compromis avant engagement de réalisation
– Montrer au MOA comment les besoins seront pris
en compte
– Produire un référentiel pour le développement
– Produire la base nécessaire aux tests
 Liens exigences utilisateur et
exigences système

Spécification Réalisation
Cahier des charges Spécification Système
système
Exigence utilisateur Exigence système

Exigence utilisateur Exigence système

Exigence utilisateur Exigence système

Exigence utilisateur Exigence système

Exigence utilisateur Liens de traçabilité Exigence système Exigences

des parties
Exigence utilisateur Exigence système
prenantes
Exigence non retenues Exigence système réalisatrices

Référentiel des exigences Référentiel des exigences

initiales système
 Représentation des exigences
Diagrammes Arborescence Document

Spécification système
1 - Introduction
2 - Fonctions de service
2.1 Fonction A
2.2. Fonction B
texte texte texte
2.3. Fonction C

….

Classement des exigences

Modèles de différentes •catégories,
parties et/ou différents Document délivrable
aspects du système •fonctionnalités du système
•niveaux d’abstraction)
Liens horizontaux
 Le processus de spécification
Coût, Contraintes Standards
délaitechnologiques
Systèmes
existants
Sources d’exigences ….
Recueil des
exigences liées
à la réalisation
Modèles Exigences Document

Cahier des Analyse, Définition des Production (ou Validation, Ex

charges
modélisation exigences non mise à jour) du
fonctionnelles document Vérification
Concept de
système (MOE)
Spécification
Système

Référentiel
des
exigences
système
 Sources d’exigences côté MOE
Sources côté MOE
Attentes et
Contraintes techniques contraintes
Cahier des
Etat de l’art
charges Normes et standards
Sous-traiants

Contraintes de projet.
Contraintes industrielles Coûts et délais
Composants existants à réutiliser
Sources des
Méthodes de développement,
produits du marché (COTS)
exigences d’intégration, de test,
d’exploitation
Contraintes de production

Autres parties prenantes

Cycle de vie, exploitation, retrait
 Fonctions de service
Fonction de service
caractéristiques:
– Événement déclenchant la fonction (action humaine, modification
de l’environnement, …)
– Acteur bénéficiaire de la fonction (à qui cela rend-t-il service?
Dans quel but?)
– Flux d’entrée (M, E, I)
– Flux de sortie (M, E, I), action sur l’environnement (sur quoi la
fonction agit-elle?)
– Ce que fait la fonction (algorithme, sous-fonctions)
– Conditions dans lesquelles la fonction est activable
Bénéficiaire
Environnement Fonction de Environnement
Service
Flux d’entrée condition
Flux de sortie
 Quelques types de fonctions de
services
• Transformer flux
F.T.
flux

Événement
• Orchestrer

requête
• Informer réponse S

Condition,
• Réguler événement
R
réaction
 Autres types d’exigences
• Exigences de performance
• Structure de l’information manipulée et/ou mémorisée
par le système
• Comportement (dynamique), aspects temporels
• flux de contrôle, parallélisme ou concurrence
• Interactions avec les systèmes externes
• Contraintes et exigences non fonctionnelles
• Scénarios globaux de fonctionnement
 Exigences
Fonctionnalités Informations Dynamique et contrôle
Modes, états de
fonctionnement,
…

Arborescence
Flux de données Sémantique Contrôle
fonctionnelle
Fonctions
Parallélisme, topologie
Relations avec
l’environnement Système

Système
S2
S1
Structure
Contexte Contraintes
 Différents points de vue
Systèmes à logiciel Modèle de S
prépondérant contexte

Les concepts du
Modèle domaine
sémantique

Modèle Modèle
fonctionnel dynamique
Comment le système évolue
Ce que fait le système (comportement, état, modes,
(les transformations phases)
qu’il opère)

Ébauche
Élaboration de
d’Architecture modèles
 Carte sémantique de domaine
• Capturer la sémantique du domaine: acteurs, systèmes,
actions, entités physique, …
les objets du problème
• Formalisme Entités Relations Attributs (ERA)
Exemple du système de gestion des Urgences (extrait)
Patient < implique Accident
0..* 0..*
Identité Lieu 1..1
Age, sexe Date-heure

0..1
1..1 1..1
Affectation
Personnel Ambulance
médical 1..1
IsA IsA < a pour personnel
1..1
Opérateur Membre équipe < se compose Équipe
du système médicale 1..* 1..1 médicale
Carte sémantique de domaine
Ex: domaine d’un Guichet Automatique Bancaire (ATM)
 Carte sémantique
Ex : Un projet d’Intégration de Système
Analyse fonctionnelle interne
Décomposition hiérarchique des fonctions:
– but à atteindre
– fonction de service
– sous-fonction
–
arborescence fonctionnelle

But

Fonction 1 Fonction 2 Fonction 3

SF
 Architecture fonctionnelle
• Modèle fonctionnel du système (DFD : Digramme de Flux de
Données, Data Flow Diagram)
– Fonction
– Flux d’information
– Point de mémoire (Data Store): besoin en mémorisation

F1
F2
Information

F3
Data store
 Modélisation fonctionnelle
Différents formalismes:
– Diagramme de Flux (actigramme SADT)
– Modules fonctionnels (Diagramme de blocs
sysML)
– Analyse par des Cas d’utilisation
méthode retraits
carte
authentification effectués Ex: actigramme
code bon depuis n
code confidentiel authentifier jours SADT
l ’usager

ancien solde nouveau solde

traiter la
montant Requête de débit compte
transaction
montant à servir

fournir les espèces

espèces
espèces en stock A
3
 Modélisation fonctionnelle
• Décomposition des services en fonctions de service
• Analyse des différents services au niveau des interactions
avec l’environnement, des transformations opérées, des
flux d’entrée et de sortie
• Analyse fonctionnelle externe
• Pour chaque fonction de service:
– Conditions de déclenchement et de déclenchabilité (état, mode)
– Éléments de l’environnement mis en relation
– Flux échangés (information, matière, énergie)
– Scénarios
Autre
– Transformations réalisées système
Autre
– Niveau de service attendu (temps de réponse, capacités, système
disponibilité) avec marges de flexibilité F.S.
F.S.
 Les Cas d ’Utilisation
Formalisme des Cas d’utilisation: outil pour
identifier les besoins en interactions
environnement – système
Cas d’utilisation (Use case)=
– Unité d’interaction usager – système
– Fournissant un bénéfice à un usager, concourant à la finalité
– Premier niveau de structuration des besoins en services
• Centrés sur les utilisateurs
• Formalisme très simple
• Utiles pour la conception des tests de validation
• Formalisés par Ivar Jacobson
 Concepts de base
Acteur
• Rôle d’une personne ou d’une entité qui interagit
avec le système
•Nom exprimant ce rôle
• Personne physique → un ou plusieurs acteurs
•Acteur → une ou plusieurs personnes physiques
Cas d’utilisation
• Unité fonctionnelle de service (basée sur un bénéfice fourni)
• Détermine un contexte particulier d’interaction avec le système
•Use case = classe dont les instances sont des scénarios

Ex: G.A.B.
Cas: Retirer de l’argent
Scénario 1: retrait ok
Usager <<actor>>
Retirer de Scénario 2: solde
S.I. groupe insuffisant
l’argent bancaire
Scénario 3: trop de
retraits
Client Consulter
solde Scénario 4: carte volée
 Exemple: le GAB Acteur
secondaire
Nature de G.A.G.
l ’interaction
<<actor>>
Consulter
solde compte SI Banque
visualise
Retirer de
Le technicien
débite l ’agent éteint le
Client distributeur
avant de
ravitailler le
Mettre en coffre
Acteur marche /
arrêter Pré conditions
personne ou
système externe à ou règles
l ’origine d ’une
interaction avec le Ravitailler le
systèmes coffre
On ne peut Technicien
retirer de
l ’argent que
dans la limite Cas d ’utilisation
du stock objectif du système motivé par un
besoin
 Liens entre cas d ’utilisation
• Cas inclus ou utilisé: Relation A Includes B
le
comportement spécifié par le cas A intègre le
comportement spécifié par le cas B
• Cas étendus: Relation B Extends A. le comportement
spécifié par le cas B se substitue à celui de A dans
des contextes plus spécifiques ou exceptionnels
<<actor>>
Retirer de Retirer de SI Banque
l ’agent l ’agent

Usager <<uses>> <<extends>>

Lancer alerte
S’identifier carte volée
 Exemple : le GAB
Exigences:
1. Distribuer de l ’argent à tout porteur de carte de crédit
(carte Visa, ou carte de la banque) via un lecteur de
carte et un distributeur de billets
2. Consulter un solde de compte pour les clients porteurs
d ’une carte de la banque
3. Déposer du liquide pour les clients…
4. Déposer des chèques pour les clients …..
5. Il est nécessaire de recharger de temps à autre le
distributeur
 Exemple : diagramme de
contexte du GAB
0..1 1..1 <<actor>>
SA Visa
Porteur de CB
GAB Acteurs
secondaires
0..1
1..1
Client de la <<actor>>
banque
Acteurs
SI Banque
principaux 0..1

Porteur de CB

Note : « Porteur de CB » et Opérateur de

maintenance
« Client de la banque » sont
mutuellement exclusifs Client de la banque
 Exemple : cas d ’utilisation
<<actor>>
SI Banque

Porteur de CB <<actor>>
Visa Retirer de l ’argent SA Visa

Consulter un solde Recharger le distributeur

Client de la Récupérer les cartes

banque Déposer du liquide avalées Opérateur de
maintenance

Récupérer les chèques

Déposer des chèques déposés
 Cas d ’utilisation et scénarios
Scénario = série d ’événements ordonnés simulant
un comportement particulier du système
Pour chaque cas d ’utilisation, il existe un ou plusieurs scénarios
dont la description explicite le comportement du système dans la
situation donnée.

téléphoner
Appelant Appelé
communication directe
ligne occupée
sans réponse
communication par répondeur
ligne en dérangement
etc...
 Exemple de scénario (retirer des
espèces)
Système
usager
Insérer carte
Demander code Vérifier lisibilité

Entrer code
Demander montant Valider code

Entrer montant
Demander prendre carte Réaliser la transaction

Rendre carte
Prendre carte
Demander prendre billets

Délivrer billets
Demander prendre reçu
Formalisme:
Imprimer reçu digramme de séquence
Afficher écran accueil UML
 Modélisation
Développement d’un modèle du problème
• selon différentes:
– Modèle de contexte
relation du système avec son
environnement
– Modèle sémantique: concepts du domaine, relations
– Modèle fonctionnel
transformations opérées par le
système
– Modèle dynamique
évolutions dans le temps
• Différents formalismes et méthodes très différents:
SADT, SART, CORE, I*, UP (logiciel), …
• dépendant de:
– La nature du problème Ex: Temps Réel / S.I. d’entreprise
– Expertise disponible, choix organisation ou choix projet
– Méthodes et outils
 Modèle de contexte
• Système: boite noire avec:
– interfaces
ports d’entrées-sorties: IHM, API, réseau
de communication, interfaces physiques
– flux acteurs – système: Information, matière, énergie)
• Acteurs humains et autres systèmes
• Diagramme de blocs SysML, SADT, SA, …
Connecteur 1
clavier Transactions / réponses
Usager / demandes Liaison Ethernet S.I. banque
Information, messages
client erreur Connecteur 2
écran Automate Commandes,
Clavier écran
Carte bancaire informations
billets bancaire Ouverture
administration
magasin
billets
Administrateur

Ex: diagramme de bloc SysML Employé

 Modélisation dynamique
• Comportement dynamique des fonctions et
transitions entre état, modes et phases de vues
• Différents formalismes:
– Statecharts de Harel
– Diagrammes de séquence (UML) Attente
Arrêt

– Digrammes d’activité, EFFBD Insertion carte /

Carte invalide demander code
Attente code
En service Code erroné
Code bon/
demander montant

Arrêt Reprise Attente montant

Modes Etats Montant entré/
déclencher transaction
Maintenance Transaction
Ex: statechart Transaction refusée / Transaction ok /
erreur message
 Aspects temporels. Matrice
SAGACE évolution
niveaux temporels phases de vie
modes
S .
états
continu
fonctionnement

action fonctionnement évolution

1 fonctions 2 processus 3 scénarios
vision fonctions enchaînement des enchaînement des
fonctionnelle activités
correspondant aux les fonctions pour réaliser modes de
activités élémentaires de service fonctionnement
vues du
système 4 sous-système 5 sous-système de 6 sous-système
vision opérant commande auxiliaire
organique organes réalisant les organes de mise en organes assurant les
fonctions œuvre des activités changements de
configuration
7 conduite 8 gestion 9 anticipation
vision
décisionnelle consignes de adaptation des décisions d ’ordre
régulation des activités (transition stratégique
fonctions des phases de (changement de mode
fonctionnement) de fonctionnement)
Exigences s’appliquant à un système
Fourniture de services à l’environnement direct
Aptitudes et
contraintes sur le Système à faire
– Exigences fonctionnelles
ce que doit FAIRE le système
Fonction
de services (interactives, actives, réactives)
– Exigences non fonctionnelles
ce que doit ETRE le système

Ex en logiciel: FURPSE (Fonctionnality, Usability, Reliability,
Performance, Serviceability, Evolutivity) (ISO CEI 9126)

aptitudes

Performances globales, résistance à l’environnement (grandeurs
physiques), ….
– Contraintes de l’environnement direct (milieu physique, connexions,
…)
– Contraintes de l’environnement indirect

facteurs PESTEL (Politique, Economique, Social, Technologique,
Environnemental, Légal)
Exigences non fonctionnelles
• Propriétés, capacités que devra présenter la solution
qui restreignent les choix techniques
• Propriétés globales du système non réductible en
première analyse à des fonctions
• Exemples.
– Qualité
– Performances, qualité de service: grandeurs physiques
quantifiées
– Contraintes de l’environnement direct: milieu physique,
interfaces, sécurité (safety), testabilité, déploiement
– Contraintes de l’environnement indirect: facteurs
politiques, économiques, sociaux, technologiques,
environnemental, légaux
 Exigences de qualité et de
qualité de service
Modèle de MacCall (G.E. model): 3 perspectives:
– Opération du produit: caractéristiques à l’usage
– Révision du produit: capacité à évoluer
– Transition du produit: adaptabilité à de nouveaux
environnements
Maintenabilité
Flexibilité
Révision du
testabilité
produit

Rectitude
Opération Transition
Fiabilité
Efficacité du produit du produitPortabilité
Réutilisabilité
Intégrité
Interopérabilité
Utilisabilité
 Modèles FURPS et FURPS+
• Différents familles de facteurs (Robert Grady et
Rational Software):
– Fonctionnalité: capacités fonctionnelles, sécurité
– Utilisabilité: présentation, consistence des IHM, aide
contextualisée, documentation, aide à l’apprentissage
– Fiabilité: taux et sévérité des pannes, aptitude à la reprise
(recoverability), prédictabilité, précision, MTBF
– Performances: vitesse, efficacité, disponibilité, temps de réponse ,
temps de reprise, utilisation des ressources
– « Supportabilité »: testabilité, extensibilité, adaptablité,
maintenabilité, compatibilité, configurabilité, serviçabilité,
installabilité, aptitude à l’internationalisation
• Facteurs à détailler en sous-facteurs et indicateurs
spécifiques quantifiés
• Utilisable en expression d’exigences ou en
évaluation de produit
 Analyse des exigences : autres activités
• (première) Conception architecturale
– Estimation du coût
– Allocation des exigences logicielles /
matérielles
• Négociation des exigences
– Traitement des conflits entre exigences
– Cas d’exigences fonctionnelles et non
fonctionnelles incompatibles
– Recherche d’un consensus entre les parties
prenantes
 La spécification des exigences
• Documents de spécification:
– Document de Définition du Système (Concept
d’Opération): spécification de haut niveau du
point de vue du domaine
– Cahier des Charges Fonctionnel
– Spécifications des exigences Système
– Spécifications des exigences logicielles
(standard IEEE 830-98 et IEEE 1465 pour les
produits logiciels)
• Lien document texte - exigences semi-
formelles
Typologie et origine des
exigences systèmes
La validation des exigences
 La validation des exigences
• Deux aspects
– Vérification
• analyse menée correctement et justifiée
• Toutes les exigences initiales ont été traitées
– Validation
• le système spécifié correspond aux attentes des parties prenantes
• Différentes actions
– Revues de documents
– Maquettage des IHM, prototypage
– Revues des modèles
– Développement de parties applicatives en méthodes agiles
Ingénierie des Exigences
 Principes des exigences
• Spécification répondant au CdCF = formalise le
problème
Référentiel pour les activités futures de
conception du système (référentiel des exigences
système)
• Modèle prescriptif : reste en principe dans le strict
domaine du problème (≠ modèle constructif)
• Recherche de rigueur et de traçabilité

structuration en énoncés élémentaires = Exigences
 Types d’exigences
• Exigences de produit / de réalisation
– Produit: porte sur le système à faire (aptitude, interface, …)
– Réalisation: contrainte sur le développement (ex: choix
d’un progiciel, langage de programmation, mode de
vérification, …)
• Exigences fonctionnelles / non fonctionnelles
– Fonctionnelle: ce que doit faire le système
– Non fonctionnelle: contrainte, performance, qualité, …
• Exigences Système / logicielles
• Exigence quantitative / non quantitative
– Valeur, tolérance, précision, …
 Généralisation de la notion
d’exigence
Formulation en exigences :
– Expression de besoin des parties prenantes
– Spécification des exigences système
– Spécification des produits : sous-systèmes,
constituants, produits contributeurs (besoins du
MOE et réponses)
– Spécification des référentiels de chaque phase
de vie : conception, industrialisation,
production, mise en service, retrait
Transformations d’exigences (1)
Exigence système
Exigence dérivées

Allouées au logiciel X
Allouées au matériel Y
Allouée au sous-système
humain (lifeware)
Exigence induite
allocation
allocation allocation
C
Propriété émergente
A
B Système
à faire
 Transformations d’exigences (2)
• Exigence dérivée: décomposition d’une exigence
en exigences plus fines (« ET »)
• Exigence allouée: directement transférée à un sous-
système ou un constituant
• Exigence répartie: transformée en exigences sur
plusieurs constituants (Ex: poids d’un système)
• Exigence « émergentes »: porte sur une propriété
qui résultera de l’interaction entre plusieurs sous-
systèmes ou constituants
• Exigence induite: exigence ajoutée suite à un choix
de solution
 Classification des propriétés
d ’un système
Classification de Thomé

système
émergence émergence
transitive non transitive
Ex : fiabilité Ex : résonance
localisée dans répartie sur d ’un système
un sous- plusieurs sous-
système systèmes interactions
Ex : module Ex : poids d ’un
de traitement système embarqué
immergeante
Ex : inter-blocage

sous-système
 Définition et caractéristiques des
exigences
• Exigence = énoncé prescrivant une fonction, une
aptitude, une caractéristique, une limitation à laquelle
doit satisfaire un produit
• Caractéristiques de qualité (niveau élémentaire) :
– Unicité : une exigence ne traite que d’un sujet
– Précision : rigueur dans l’expression
– Non ambiguïté : ne permet qu’une seule interprétation
– Pure prescription : porte que le Quoi? Et non sur le Comment?
– Vérifiabilité, testabilité : à toute exigence peut être associée une
méthode permettant la vérification de son obtention
– Faisabilité : peut être satisfaite avec l’état de l’art technologique
– Réalisme : peut être satisfaite dans les contraintes du projet
• Caractéristiques (niveau global) :
– Cohérence : pas d’exigences contradictoires
– Complétude : pas de manques
 La chaîne des exigences (1)
Cahierdes
Cahier desCharges
Charges Validation
Système

Référentiel d’exigences initiales

Spécification du système
•Études, simulations, analyses,
estimations de coûts
Autres parties prenantes
Vérification
SpecSystème
Spec Système Système
Exigences induites
Référentiel
d’exigences système
Conception Validation sous-
Exigences allouées système ou
constituant
SpecSous-système
Spec
Spec Sous-système
Sous-système Exigences
techniques sous-
ou
ou
specconstituant
ouspec
spec constituant
constituant système ou Vérification
constituant sous-système ou
Exigences techniques sous-systèmes ou constituants constituant
 La chaîne des exigences (2)

Gestion des exigences

• Gestion de la chaîne des exigences depuis la finalité du système jusqu’aux

exigences détaillées de chacun des constituants
• Les référentiels d’exigence successifs sont élaborés, gérés, vérifiés
• Toute évolution, allocation, modification doit être tracée