S.E.L

spécifications des exigences logicielles

La spécification des exigences logicielles (SEL) décrit ce que le système doit faire et dans quelles conditions il doit le faire.
Elle sert de contrat vérifiable entre parties prenantes (métier, dev, QA, ops), encadre la conception et facilite les tests d’acceptation.

Objectif : transformer un besoin flou en exigences claires, mesurables et traçables.

Tree swing Tree swing

L’image classique du “tree swing” illustre les malentendus possibles entre client, analyste, dev et test : chacun imagine une solution différente au même besoin, d’où l’importance d’un SEL précis.

Étapes d’analyse du problème

  1. Obtenir l’accord sur la définition du problèmeAligner tout le monde sur le problème réel à résoudre (pas la solution).

    Questions : Quel impact ? Observable/mesurable du problème sur les activités (coût, délai, qualité, risque…). Affecte qui ? Lister les parties prenantes impactées (rôles, équipes, systèmes). Comment sait-on que c’est résolu ? Indiquer la valeur attendue en cas de résolution (quelques bénéfices clés, indicateurs cibles)
  1. Comprendre les causes racinesÉviter de traiter les symptômes.

    Quelques méthodes : “5 pourquoi”, Ishikawa, analyse de données/incidents.

    🔗 Exemple diagramme d’Ishikawa (cause à effet)

  1. Identifier les utilisateurs et les parties prenantesSavoir qui est impacté, qui décide et qui opère.

    Livrables : carte des parties prenantes (intérêt/influence), acteurs/personas, RACI sommaire.
    Carte des parties prenantes par degrés : 1) Utilisateurs directs du produit, 2) Personnes/systèmes travaillant avec les résultats, 3) Acteurs qui installent, déploient ou supportent le système.

    Carte des parties prenantes par degrés : 1) Utilisateurs directs du produit, 2) Personnes/systèmes travaillant avec les résultats, 3) Acteurs qui installent, déploient ou supportent le système.

    Astuce : cette carte aide à ne pas oublier des profils clés (ex. support, conformité, systèmes voisins) et à couvrir leurs préoccupations dans le SEL.

  1. Définir les frontières de la solutionTracer le in/out et les interfaces externes.

    L’environnement : le système + ce qui interagit avec le système
  1. Identifier les contraintes imposées à la solutionLister les non-négociables (réglementaire, sécurité, techno, budget, délais).

Où chercher l’information et comment la recueillir

Objectif : transformer des informations brutes (verbatims, observations, documents) en exigences claires, mesurables et traçables dans le SEL.

Quelques techniques

Entretiens (semi-dirigés, 1:1 ou petits groupes)Quand : explorer besoins/contraintes, comprendre langage métier. Comment : questions ouvertes (“Pouvez-vous me montrer… ?”), reformulation, exemples concrets, éviter le jargon technique.
Observation / shadowingQuand : écart “ce qu’on dit” vs “ce qu’on fait”. Comment : observer une tâche, parcours actuel (*as-is*), chronométrer, noter exceptions/contournements, irritants mesurés,.
Ateliers collaboratifs (story mapping / event storming)Quand : aligner rapidement plusieurs profils. Comment : post-its “activités → étapes → détails”, valider le flux bout-à-bout.
Analyse documentaire & contraintesQuand : normes, politiques, contrats, conformité. Comment : extraire obligations, seuils, exceptions légales.
Questionnaires courtsQuand : sonder préférences/volumes à large échelle. Comment : questions fermées + 1 ouverte, limité à 5-10 min.
Prototypage papier / maquettes rapidesQuand : valider vocabulaire/flux sans coder. Comment : parcours cliquable minimal, tester 3 tâches clés.

Questions utiles

  • Montrez-moi comment vous faites aujourd’hui (étapes + outils).
  • Quand est-ce difficile ? (exemples récents, fréquence, impact)
  • Quand est-ce réussi ? (critères concrets d’un bon résultat)
  • Que doit éviter le système ? (risques, erreurs coûteuses)
Attention aux biais : éviter les “solutions prémâchées” (“vous voulez un chatbot ?”) ; rechercher d’abord le problème, les règles, les exemples, les seuils mesurables.
Flux itératif des exigences : analyser le problème, comprendre les besoins, définir le système, gérer le périmètre, affiner, gérer les changements

Workflow d’ingénierie des exigences : boucles d’itération & gestion du changement en parallèle

Exigences fonctionnelles vs non fonctionnelles

Les exigences non fonctionnelles désignent les attributs de qualité d’un système qui définissent ses performances plutôt que ses fonctions. Contrairement aux exigences fonctionnelles, qui spécifient les actions et les tâches qu’un système doit accomplir, les exigences non fonctionnelles se concentrent sur les caractéristiques globales et le comportement du système dans diverses conditions.

​

Fonctionnelles — le quoi

Ce que le système fait (capacités, règles métier, scénarios).
Elles décrivent les comportements observables du point de vue des utilisateurs/systèmes externes.

Catégories courantes & exemples

  • Interactions utilisateur : s’authentifier, créer un compte, rechercher un item, réserver, payer.
  • Règles métier : calculer des frais, appliquer des politiques, autoriser/refuser selon conditions.
  • Gestion des données : créer/lire/mettre à jour/supprimer (CRUD), importer/exporter.
  • Intégrations : envoyer un courriel/SMS, consommer une API tierce, webhooks.
  • Rapports & tableaux de bord : statistiques, historiques, export CSV/PDF.
  • Administration : gestion des rôles, configuration de politiques/paramètres.

Niveaux de granularité (pour bien structurer)

  • Épic → Feature → User Story → Tâches
  • Alternative/formalisme : Cas d’utilisation (Use Case) pour détailler un scénario clé.
→ → →

Épic

Un grand objectif métier couvrant plusieurs itérations (semaines / mois).

Ex. « Gérer le cycle complet réservation → prêt → retour des équipements. »

Feature

Une capacité métier cohérente qui apporte de la valeur en soi.

Ex. « Réservation en ligne des équipements. »

User Story

Une petite valeur utilisateur, livrable en quelques jours, testable via critères d’acceptation.

Ex. « En tant qu’étudiant, je veux réserver un appareil photo afin de le récupérer demain au comptoir. »

Tâches

Les actions techniques pour réaliser une story (dev, tests, doc, UI…).

Ex. « Créer endpoint POST /reservations », « Valider conflits de créneau », « Formulaire UI + validations ».

Formats recommandés

User Story (+ critères d’acceptation)

En tant que <acteur>, je veux <capacité> afin de <valeur>.
critères d’acceptation (Given/When/Then) : mesurables, observables.

Exemples d’exigences fonctionnelles

  • « Au paiement, si un article passe en rupture, le système empêche la commande et propose des alternatives. »
  • « Après confirmation, le système envoie un courriel avec le récapitulatif et le numéro de suivi. »
  • « Un patient peut prendre rendez-vous avec un praticien en choisissant un créneau disponible. »
  • « Le système empêche la double réservation d’un même praticien sur un même créneau. »
  • « Le système envoie un rappel 24 h avant le rendez-vous par SMS. »
  • « Le système génère un PDF de relevé mensuel accessible dans l’espace client. »
  • « L’enseignant peut annoter un PDF remis et publier une note avec commentaires. »
  • « L’utilisateur peut sélectionner des sièges numérotés ; le système bloque les sièges 10 minutes pendant le paiement. »

Non fonctionnelles — le comment/qualités

Il s’agit des qualités mesurables du système et contraintes globales. Elles sont généralement définies par :

  • Performance: décrit la vitesse à laquelle le système doit fonctionner dans des conditions normales et de pointe, telles que les temps de chargement des pages ou la vitesse de traitement.
  • Évolutivité: garantit que le système peut gérer la croissance de la demande des utilisateurs ou du volume de données sans perte de performances significative.
  • Convivialité: l’objectif est de rendre le système intuitif et convivial, en améliorant l’expérience utilisateur grâce à la conception et à l’accessibilité.
  • Fiabilité: garantit que le système fonctionne de manière cohérente et est disponible en cas de besoin, y compris la disponibilité du système et la tolérance aux erreurs.
  • Sécurité: spécifie les normes de sécurité, telles que le cryptage des données, les contrôles d’accès et les mesures visant à empêcher l’accès non autorisé ou les violations de données.

Exemples d’exigences non fonctionnelles

  • Performance & latence : p95 < 1,5 s ; p99 < 2,5 s ; ≥ 500 req/s soutenues.
  • Disponibilité & fiabilité : disponibilité 99,5 %/mois ; MTTR < 30 min ; RTO 30 min / RPO 5 min.
  • Scalabilité & capacité : tenir 3× la charge nominale par ajout d’instances ; files d’attente < 1 000 msgs.
  • Sécurité : 2FA pour admin ; chiffrement TLS 1.3 en transit, AES-256 au repos ; correctifs critiques < 7 j.
  • Résilience / tolérance aux pannes : retries avec backoff ; circuit breaker ; dégradation gracieuse documentée.
  • Maintenabilité & déployabilité : couverture tests ≥ 80 % ; déploiement < 15 min ; complexité cyclomatique moyenne < 10.
  • Observabilité : logs structurés (JSON) ; traces distribuées ; 10 métriques clés exposées (latence, erreurs, saturation…).
  • Compatibilité / portabilité : navigateurs N-2 ; images Docker multi-arch ; OS supportés listés.
  • UX & accessibilité : conformité WCAG 2.1 AA ; tâche clé en ≤ 3 clics ; focus visible clavier.
  • Conformité & données : RGPD ; rétention 365 jours ; anonymisation des PII dans les logs.
  • Interopérabilité / API : contrat OpenAPI versionné ; compat ascendante sur deux versions.
  • Coût / efficience : coût cloud mensuel ≤ 1 200 $ pour l’environnement prod.

Comment bien formuler une exigence non fonctionnelle

Structure utile : [Contexte] + [Métrique] + [Seuil] + [Période/Population] + [Méthode de mesure].

Toujours quantifier (+ contexte de test).

Exemple (phrase complète)
Lors d’une recherche sur le catalogue de 10 000 articles aux heures de pointe, le 95ᵉ percentile de la latence serveur doit être < 1,5 seconde sur une fenêtre glissante de 7 jours, mesuré par Prometheus sur l’endpoint /search.

Autre exemple

  • Vitesse de performance : le système doit traiter les demandes des utilisateurs dans un délai moyen de 2 secondes, même en cas de trafic utilisateur élevé.
  • Disponibilité du système : le système doit maintenir une disponibilité de 99.9 % pour garantir aux utilisateurs un accès cohérent.
  • Normes de sécurité : le système doit utiliser un cryptage 256 bits pour le stockage des données et se conformer aux réglementations en vigueur en matière de protection des données.

Qualité d’une exigence (checklist rapide)

  • Claire (univoque), nécessaire, testable, priorisée, traçable.
  • Éviter les termes vagues : remplacer “rapide”, “sécurisé” par des seuils mesurables.
  • 1 exigence = 1 idée ; critères d’acceptation observables.

Les contraintes — pense-bête (par catégories)

​
  • Contraintes financières / budgétaires ?
  • Considérations de tarification ?
  • Problèmes de licences (coûts, modèles, limites) ?
  • Politiques internes / externes qui impactent la solution ?
  • Problèmes interdépartementaux (gouvernance, responsabilités) ?
  • Choix technologiques imposés / interdits ?
  • Plateforme ou technologie existante à utiliser ?
  • Recours à des composants logiciels achetés (COTS) ?
  • La solution existe déjà partiellement dans nos systèmes ?
  • Compatibilité requise avec les solutions en place ?
  • OS / environnements à supporter ?
  • Contraintes environnementales ?
  • Obligations légales / réglementaires ?
  • Exigences de sécurité (organisationnelles/techniques) ?
  • Standards à suivre / certifs à obtenir ?
  • Échéancier imposé ?
  • Ressources (humaines/équipements) imposées ?
  • Possibilité de sous-traiter ?
  • Peut-on ajouter des ressources (temporairement / en permanence) ?

Exercice — rendre testables des exigences floues

Énoncé client
« Le client souhaite une application qui soit rapide, facile à utiliser, qui ne tombe jamais en panne, et surtout sécurisée. L’application devra aussi fonctionner sur les navigateurs les plus utilisés. »

À faire

  • Identifier les exigences mal formulées.
  • Reformuler chaque point en une exigence fonctionnelle ou non fonctionnelle claire et testable (avec métrique, seuil, contexte et, si pertinent, méthode de mesure).
Voir une proposition de correction
  • Rapide → « Le temps de réponse ne doit pas dépasser 2 secondes pour 95 % des requêtes sous une charge de 500 utilisateurs simultanés. »
  • Facile à utiliser → « L’interface doit respecter les normes WCAG 2.1 niveau AA et proposer une navigation en 3 clics maximum pour accéder aux fonctions principales. »
  • Ne tombe jamais en panne → « Le système doit garantir une disponibilité de 99,9 %/mois. »
  • Sécurisée → « Toutes les communications doivent être chiffrées en TLS 1.3 et les mots de passe stockés avec bcrypt. »
  • Navigateurs les plus utilisés → « L’application doit être compatible avec les deux dernières versions de Chrome, Firefox et Safari. »

Les composantes principales d’un SEL

  1. Méta & version — titre, auteur·e·s, version, historique des changements.
  2. Glossaire — termes métier et acronymes.
  3. Vision & contexte — problème, objectifs, parties prenantes.
  4. Portée (scope) — In/Out + hypothèses et risques majeurs.
  5. Exigences fonctionnelles — épics, user stories ou cas d’utilisation + critères d’acceptation.
  6. Exigences non fonctionnelles — qualités mesurées (perf, sécu, disponibilité, etc.).
  7. Vues/Modèles — Use Case Diagram, aperçu UML (classes/séquence) au besoin.
  8. Données & interfaces — objets métier clés, contrats API (OpenAPI/GraphQL), formats d’échange.
  9. Contraintes & dépendances — techno imposée, navigateurs cibles, normes, intégrations.
  10. Traçabilité — matrice Exigence ↔ UC/Story ↔ Test d’acceptation.
Details

Lecture guidée en classe — exemple de SEL
Nous analyserons ce rapport pour la structure d’un SEL, la formulation F/NF et la traçabilité.
Lien : http://www.info2.uqam.ca/~makarenkov_v/INM5151/sel_ete2015/SEL_Les_AS_Rapport.pdf

Exercice — analyse d'un cas et extraction d'informations pertinentes

Consigne
Téléchargez sur Moodle l’énoncé du cas « Application d’entraide pour la communauté étudiante ».
À partir de la description du cas fourni, vous devez extraire et rédiger une première version du SEL en vous concentrant sur les sections exigées uniquement.

À faire

  1. Identifier les parties prenantes (rôles et intérêts).

  2. Soutirer les exigences et les classer :

    • Fonctionnelles (F) — ce que le système fait.
    • Non fonctionnelles (NF) — qualités mesurables/contraintes globales.
    • Contraintes (C) — obligations externes (techno, accès, règles).

  3. Rédiger chaque exigence en bonne forme (univoque, testable, traçable).

Les solutions complètes seront discutées en classe (pas de correction révélée ici).