IREX - Les exigences logicielles : comment les définir ?

Comment savoir ce qu'un logiciel doit faire avant même de le construire ?

 · 7 min read

Les exigences logicielles : comment les définir ?

Comment savoir ce qu'un logiciel doit faire avant même de le construire ? Les exigences logicielles répondent à cette question fondamentale. Découvrez comment les définir, les structurer et les appliquer à travers le projet ACRA.



1. Introduction

Avant même d'écrire la première ligne de code, tout projet informatique sérieux commence par une question fondamentale : que doit faire exactement ce logiciel ? Cette question, apparemment simple, est en réalité au cœur de nombreux échecs de projets informatiques. Des études montrent régulièrement que la majorité des problèmes rencontrés lors du développement d'un logiciel ne proviennent pas d'un manque de compétences techniques, mais d'une mauvaise définition des besoins au départ.

C'est précisément pour répondre à ce défi que les exigences logicielles ont été introduites dans les méthodes de développement. Une exigence est une description précise et vérifiable de ce qu'un système doit être capable de faire ou de respecter. Elle constitue le point de départ de toute démarche de qualification logicielle.

Dans cet article, nous allons découvrir ce qu'est une exigence logicielle, comment la rédiger correctement et comment ce concept s'applique concrètement au projet ACRA, une plateforme d'observabilité et de supervision basée sur Prometheus, Zabbix, Grafana et Keycloak.

2. Qu'est-ce qu'une exigence logicielle ?

Une exigence logicielle est une description formelle d'un besoin que le système doit satisfaire. Elle exprime ce que le logiciel doit faire, dans quelles conditions et pour qui, sans nécessairement préciser comment il doit le faire techniquement.

Une exigence bien rédigée possède plusieurs caractéristiques essentielles. Elle est claire, c'est-à-dire compréhensible par toutes les parties prenantes du projet. Elle est vérifiable, ce qui signifie qu'il est possible de démontrer objectivement qu'elle est satisfaite ou non. Elle est réalisable, donc atteignable dans les contraintes du projet. Enfin, elle est traçable, ce qui permet de la relier directement à un ou plusieurs cas de test lors de la qualification.

2.1 Pourquoi les exigences sont indispensables ?

Sans exigences clairement définies, il est impossible de savoir si un logiciel est terminé. Un développeur peut estimer que sa fonctionnalité est correcte, tandis que l'utilisateur final attendait un comportement différent. Cette situation génère des livraisons non conformes, des corrections coûteuses et des délais non maîtrisés.

Les exigences apportent plusieurs bénéfices concrets :

  • définir précisément ce que le logiciel doit accomplir avant de le développer ;
  • fournir une base solide pour la rédaction des cas de test lors de la qualification ;
  • permettre de mesurer objectivement l'avancement du projet ;
  • faciliter la communication entre les équipes techniques et les utilisateurs ;
  • garantir que chaque fonctionnalité importante fait l'objet d'une validation avant la mise en production.
2.2 Les types d'exigences

Dans un projet informatique, on distingue généralement trois grandes catégories d'exigences.

Type d'exigence Question à laquelle elle répond Exemple
Fonctionnelle Que doit faire le système ? L'utilisateur doit pouvoir se connecter après authentification.
Sécurité Comment le système protège-t-il les données ? Tout accès non authentifié doit être refusé.
Exploitation Comment le système sera-t-il géré en production ? Un administrateur doit pouvoir ajouter un équipement sans redémarrer la plateforme.
2.3 Comment rédiger une exigence ?

La formulation la plus répandue pour rédiger une exigence logicielle est le format User Story, issu des méthodes agiles. Ce format suit une structure simple et naturelle :

En tant que [profil utilisateur], je veux pouvoir [action] afin de [bénéfice attendu].

Cette formulation place l'utilisateur au centre du besoin, décrit clairement l'objectif de la fonctionnalité et est compréhensible par toutes les parties prenantes, qu'elles soient techniques ou non. Voici un exemple concret :

En tant qu'administrateur système, je veux pouvoir accéder à l'interface de supervision via HTTPS afin de garantir la confidentialité des données échangées.

Cette exigence est claire, vérifiable et directement associable à un cas de test qui consistera à vérifier que l'accès en HTTP est redirigé vers HTTPS et qu'aucune erreur de certificat n'est signalée.

3. Illustration avec le projet ACRA

Le projet ACRA constitue un exemple concret et représentatif de la manière dont les exigences logicielles sont définies dans un projet de supervision et d'observabilité. Cette plateforme repose sur plusieurs composants interconnectés : Prometheus pour la collecte des métriques, Zabbix pour la supervision réseau SNMP, Grafana pour la visualisation, Keycloak pour la gestion centralisée des identités et Nginx comme reverse proxy sécurisé.

Définir les exigences d'ACRA ne consiste pas uniquement à lister les fonctionnalités. Il s'agit d'exprimer précisément ce que chaque composant doit être capable de faire, dans quelles conditions et pour quels profils d'utilisateurs, afin de garantir une plateforme fiable, sécurisée et exploitable au quotidien.

Dans TestLink, l'outil de gestion de tests utilisé pour qualifier ACRA, chaque exigence est documentée sous la forme d'une User Story et associée à un identifiant unique (REQ-001, REQ-002, etc.). Cette organisation garantit que chaque besoin identifié lors de la conception fera l'objet d'une validation rigoureuse avant la mise en production.

3.1 Les exigences fonctionnelles d'ACRA

Les exigences fonctionnelles d'ACRA décrivent les services que la plateforme doit rendre aux différents profils d'utilisateurs : administrateurs système, administrateurs réseau et administrateurs sécurité. Voici quelques exemples d'exigences fonctionnelles définies dans le projet :

REQ-002 — En tant qu'administrateur système, je veux pouvoir accéder à l'interface web Zabbix via HTTPS afin de superviser l'infrastructure de manière sécurisée.
REQ-007 — En tant qu'utilisateur, je veux pouvoir me connecter à Zabbix via mon compte Keycloak afin d'accéder aux tableaux de bord de supervision sans gestion de mot de passe supplémentaire.
REQ-008 — En tant qu'administrateur système, je veux que Zabbix découvre automatiquement les équipements réseau afin de réduire les interventions manuelles de configuration.

Chacune de ces exigences est directement associée à un ou plusieurs cas de test dans TestLink, ce qui garantit que la fonctionnalité décrite sera effectivement validée avant la mise en production de la plateforme.

3.2 Les exigences de sécurité d'ACRA

La sécurité est une dimension essentielle d'une plateforme de supervision. Les données collectées sur l'infrastructure sont sensibles et leur accès doit être strictement contrôlé. Dans ACRA, plusieurs exigences de sécurité ont été définies afin de couvrir les principaux risques identifiés :

REQ-011 — En tant qu'administrateur sécurité, je veux que les droits d'accès soient contrôlés par rôle afin d'empêcher tout accès non autorisé aux fonctionnalités d'administration.
REQ-006 — En tant qu'administrateur sécurité, je veux que tout utilisateur désactivé dans Keycloak soit immédiatement bloqué afin de garantir qu'aucun compte compromis ne puisse accéder à la plateforme.

Ces exigences permettent de s'assurer que les politiques de sécurité définies lors de la conception sont effectivement appliquées par l'ensemble des composants de la plateforme.

3.3 Les exigences d'exploitation d'ACRA

Une plateforme de supervision n'est utile que si elle peut être exploitée efficacement au quotidien. Les exigences d'exploitation d'ACRA décrivent les opérations que les administrateurs doivent pouvoir réaliser sans difficulté une fois la plateforme déployée en production :

REQ-012 — En tant qu'administrateur système, je veux pouvoir créer, modifier et supprimer des tableaux de bord dans Zabbix afin de visualiser les métriques pertinentes pour mon équipe.
REQ-013 — En tant qu'administrateur réseau, je veux pouvoir ajouter de nouveaux nœuds à superviser afin d'étendre la couverture de monitoring au fur et à mesure de la croissance de l'infrastructure.
REQ-010 — En tant qu'administrateur système, je veux que Zabbix génère automatiquement des alertes lorsqu'un seuil est dépassé afin d'intervenir avant que l'incident n'impacte les utilisateurs.

Ces exigences garantissent que la plateforme restera exploitable tout au long de son cycle de vie, même lorsque l'infrastructure évolue ou que de nouveaux besoins apparaissent.

4. Conclusion

Les exigences logicielles constituent le fondement de tout projet informatique bien conduit. Elles permettent de définir précisément ce qu'un système doit accomplir avant même de commencer son développement, d'aligner les équipes techniques et les utilisateurs sur un objectif commun et de fournir la base nécessaire à la rédaction des cas de test lors de la qualification.

Le projet ACRA illustre parfaitement cette démarche. Chaque composant de la plateforme — Zabbix pour la supervision réseau, Prometheus pour la collecte des métriques, Grafana pour la visualisation ou encore Keycloak pour la gestion des identités — est couvert par un ensemble d'exigences fonctionnelles, de sécurité et d'exploitation. Ces exigences, rédigées au format User Story et documentées dans TestLink, garantissent que chaque besoin identifié lors de la conception fera l'objet d'une validation rigoureuse avant la mise en production.

Définir des exigences claires et vérifiables n'est donc pas une contrainte bureaucratique. C'est une étape essentielle qui conditionne la qualité, la fiabilité et la sécurité de toute plateforme logicielle.


No comments yet

No comments yet. Start a new discussion.

Add Comment