"Non-Functional Requirements" Are Stupid • Dave Farley • GOTO 2025

Summary

Dans cette vidéo, Dave Farley critique l'utilisation du terme « exigences non fonctionnelles » (ENF), qu'il considère comme réducteur et trompeur. Il souligne que ces exigences, comme la sécurité et la performance, sont cruciales pour le succès d'un système et ne doivent pas être reléguées au second plan. Farley propose une approche en trois étapes pour les gérer efficacement : modéliser, compartimenter et affirmer. Il insiste sur l'importance de concevoir les systèmes de manière à ce que ces aspects soient pris en compte dès le début, pour éviter des problèmes complexes à long terme.

Takeaways

• 😀 Le terme 'exigences non fonctionnelles' (NFR) est trompeur et minimise l'importance des attributs clés des systèmes logiciels.
• 😀 Les exigences non fonctionnelles comme la réactivité, la sécurité et la résilience sont tout aussi importantes que les exigences fonctionnelles dans un système logiciel.
• 😀 Les exigences non fonctionnelles sont souvent des caractéristiques transversales qui affectent plusieurs parties du système, ce qui les rend difficiles à gérer.
• 😀 La distinction entre exigences fonctionnelles et non fonctionnelles est floue, car de nombreuses exigences non fonctionnelles sont en réalité des comportements fondamentaux du système.
• 😀 Penser aux exigences non fonctionnelles comme 'non fonctionnelles' sous-estime leur impact et peut mener à des erreurs de planification dans le développement logiciel.
• 😀 Les grandes entreprises comme Amazon et Twitter ont passé des années à résoudre des problèmes non fonctionnels complexes, bien au-delà de l'ajout de nouvelles fonctionnalités.
• 😀 Une approche simplifiée pour la planification d'un système pourrait conduire à ignorer les exigences non fonctionnelles cruciales, compromettant la qualité du produit final.
• 😀 Il est important de modéliser, compartimenter et affirmer les exigences non fonctionnelles dès le début du développement pour gérer la complexité de manière plus efficace.
• 😀 La compartimentation des systèmes permet de traiter chaque problème de manière indépendante, facilitant ainsi les modifications et évolutions futures.
• 😀 En établissant des tests d'affirmation sur des exigences non fonctionnelles, on peut garantir que le système évolue correctement tout en répondant aux besoins futurs de performance et de scalabilité.

Q & A

Pourquoi le terme « exigences non fonctionnelles » (ENF) est-il considéré comme inapproprié ?

Le terme « exigences non fonctionnelles » est considéré comme inapproprié car il minimise l'importance de ces caractéristiques qui sont en réalité essentielles au bon fonctionnement du système. Des aspects comme la sécurité, la performance et la scalabilité sont cruciaux pour le succès d'un logiciel et devraient être considérés comme des exigences fonctionnelles, et non non fonctionnelles.

Quels sont les problèmes liés à l'usage du terme « exigences non fonctionnelles » dans le développement logiciel ?

Le problème principal est que ce terme donne l'impression que ces exigences sont moins importantes que les exigences fonctionnelles. Cela peut entraîner une sous-estimation de leur importance dans la conception du système, et parfois un manque d'attention aux aspects cruciaux comme la sécurité et la réactivité.

Pourquoi certaines exigences non fonctionnelles, comme la latence ou la sécurité, sont en réalité des exigences fonctionnelles ?

Des exigences comme la latence maximale ou la sécurité sont des aspects fondamentaux du comportement du système. Par exemple, un système de trading doit répondre en moins d'une milliseconde, et la sécurité d'un système traitant des paiements est essentielle. Ces exigences sont directement liées à la réussite ou à l'échec du système, ce qui les rend aussi fonctionnelles que n'importe quelle autre exigence.

Quelle est la différence entre les exigences fonctionnelles et non fonctionnelles selon l'auteur ?

La différence n'est pas que l'une est fonctionnelle et l'autre non, mais plutôt que les exigences fonctionnelles sont souvent atomiques et faciles à identifier, tandis que les exigences non fonctionnelles sont transversales et affectent de nombreux aspects du système. Par exemple, la résilience et la sécurité concernent l'ensemble du système et ne peuvent pas être traitées dans un seul module.

Pourquoi est-il difficile de planifier et d'estimer les exigences non fonctionnelles ?

Les exigences non fonctionnelles sont difficiles à planifier et à estimer car elles sont transversales et touchent plusieurs composants du système. De plus, elles évoluent au fur et à mesure que le système se développe et que la charge augmente. Contrairement aux exigences fonctionnelles, il est beaucoup plus difficile de prédire précisément le temps et les efforts nécessaires pour résoudre ces problèmes.

Comment l'auteur suggère-t-il de traiter les exigences non fonctionnelles dans la conception d'un système ?

L'auteur propose de modéliser la compréhension actuelle des exigences non fonctionnelles, de compartimenter le système pour différer certaines décisions complexes et de tester de manière continue pour valider les hypothèses. Cela permet de maintenir la flexibilité et de modifier le système au fur et à mesure que de nouvelles informations sont disponibles.

Qu'est-ce que la compartimentalisation dans la conception de systèmes, et pourquoi est-elle importante ?

La compartimentalisation consiste à diviser le système en différentes parties ou modules, de manière à ce que les problèmes complexes liés aux exigences non fonctionnelles ne nécessitent pas une reconfiguration complète du système à chaque changement. Cela rend le système plus flexible et permet d'appliquer des modifications sans perturber l'ensemble du système.

Comment la culture de l'équipe affecte-t-elle la gestion des exigences non fonctionnelles ?

La culture de l'équipe est cruciale car elle permet à chaque développeur de comprendre l'importance des exigences non fonctionnelles, même s'ils ne travaillent pas directement dessus. Cette conscience permet à l'équipe de repérer des problèmes potentiels et de mieux aborder les défis liés à ces exigences dès qu'ils se présentent.

Quel est l'impact de la mauvaise gestion des exigences non fonctionnelles sur un projet logiciel ?

Une mauvaise gestion des exigences non fonctionnelles peut entraîner des systèmes peu fiables, non sécurisés et difficilement scalables, ce qui peut compromettre le succès du projet. Si ces aspects ne sont pas correctement pris en compte, le système peut échouer à répondre aux besoins réels des utilisateurs, et les erreurs peuvent être coûteuses à corriger plus tard.

Pourquoi l'auteur pense-t-il qu'un modèle de système vivant et en constante évolution est nécessaire ?

Un modèle vivant et évolutif permet d'ajuster et d'améliorer en continu la conception du système à mesure que l'on apprend davantage sur son comportement. Ce modèle doit être alimenté par des discussions continues sur la conception et l'architecture, et il doit inclure des tests pour valider les hypothèses sur la scalabilité, la performance et d'autres exigences non fonctionnelles.