Comment rédiger des exigences non fonctionnelles en 6 étapes
Les équipes définissent les exigences non fonctionnelles (NFR) en identifiant les caractéristiques du système telles que la sécurité, la fiabilité, les performances, la maintenabilité, l'évolutivité et la convivialité, puis en les formulant en termes clairs et mesurables.
C'est important car les exigences non fonctionnelles (NFR) sont essentielles pour garantir l'efficacité, la facilité d'utilisation, la pérennité et la satisfaction des utilisateurs du système.
Listen to this blog
C'est pourquoi cet article explique, en six étapes, comment rédiger des NFR et qui s'en charge, en vous proposant des exemples et des modèles pour vous guider.
Remarque : si vous souhaitez découvrir ce que sont les exigences non fonctionnelles, comprendre leurs différences par rapport aux exigences fonctionnelles et approfondir les différents types d'exigences non fonctionnelles, lisez Les exigences non fonctionnelles expliquées (avec des exemples concrets).
Table des matières
Durée de lecture : 15 minutes
Auteur : Arunabh Satpathy
1. Qui rédige les exigences non fonctionnelles ?
Les exigences non fonctionnelles (NFR) sont généralement rédigées par les différentes parties prenantes impliquées dans le projet. Elles comprennent généralement :
- Analystes métier: ce sont souvent eux qui prennent l'initiative d'identifier et de documenter les exigences non fonctionnelles, car ils sont généralement en contact avec les clients tout en faisant partie de l'entreprise qui développe les produits. Ils ont ainsi une vision claire des besoins, des préférences et des attentes tant des clients que des parties prenantes internes.
- Architectes/ingénieurs système: grâce à leur connaissance approfondie de l'architecture, des limites et des possibilités du système, leur contribution aux exigences non fonctionnelles est inestimable.
- Responsables produit: ils peuvent contribuer à définir les exigences non fonctionnelles (NFR) en s'appuyant sur les besoins des clients, les besoins de l'entreprise et leur connaissance du marché.
- Équipes d'assurance qualité (AQ): elles peuvent contribuer à définir les exigences non fonctionnelles (NFR) relatives aux normes de qualité, à la conformité réglementaire et aux critères de test.
Apprendre à rédiger et/ou à définir des exigences non fonctionnelles est un travail de collaboration. Une communication efficace entre toutes les parties prenantes est donc essentielle pour les définir et les mettre en œuvre avec précision.
2. Comment rédiger des exigences non fonctionnelles en 6 étapes ?
Étape 1 : Définir le champ d'application et l'objectif
La portée d'un projet détermine les ressources ou les livrables que vous pouvez ajouter ou supprimer au fur et à mesure de son avancement, en fonction des besoins identifiés des parties prenantes. Elle détermine également les exigences non fonctionnelles (NFR) que l'équipe doit définir. Une portée mal définie et des exigences non fonctionnelles (NFR) inadéquates peuvent entraîner des problèmes importants, tels que des dépassements de coûts, des retards, le mécontentement des parties prenantes, voire des problèmes juridiques.
Des études montrent que 85 % des projets de construction soumis à un glissement de périmètre dépassent leur budget, avec un dépassement de coûts moyen de 27 %.
À titre d'exemple, si un système est une application de diffusion vidéo en temps réel, les exigences non fonctionnelles liées aux performances (telles que la qualité vidéo et les temps d'indisponibilité) revêtent alors une importance capitale.
Étape 2 : Recueillir les commentaires des parties prenantes
La meilleure façon de s'assurer qu'un système répond aux besoins de l'entreprise, des clients et du marché est de recueillir l'avis des parties prenantes. Cela permet également d'éviter des problèmes majeurs tels que les dépassements de coûts et les risques juridiques. Pour recueillir l'avis des parties prenantes, il suffit de suivre deux étapes :
- Impliquer les parties prenantes
Il est essentiel d'identifier les parties prenantes dès le début d'un projet. Celles-ci peuvent être classées en trois catégories : les parties prenantes principales, secondaires et tertiaires, en fonction de leur impact direct et de leur influence sur le projet.
Une fois les parties prenantes internes et externes identifiées, les équipes peuvent passer à la collecte des exigences, y compris les exigences non fonctionnelles.
- Recueil des exigences
La collecte des exigences consiste, pour les équipes, à recueillir des informations auprès des parties prenantes afin de définir les exigences du projet, y compris les exigences non fonctionnelles.
Les techniques de recueil des besoinscomprennent diverses méthodes qualitatives et quantitatives, telles que les entretiens, les séances de brainstorming, les groupes de discussion et les enquêtes. Le choix de la technique dépend de la portée du projet, des ressources allouées et de la disponibilité des parties prenantes.
Les meilleurs outils de gestion de projet permettent également aux équipes de recueillir les exigences provenant d'autres sources, telles que les e-mails, les notes, les FAQ et les documents Word téléchargés.
Les équipes ont désormais commencé à utiliser des outils d'IA de pointe pour automatiser la collecte des exigences, ce qui rend ce processus plus efficace et plus complet.
Étape 3 : Classer les exigences non fonctionnelles (NFR)
La classification des exigences non fonctionnelles (ENF) oriente la conception du produit ou du service et influe sur ses performances, sa sécurité et la satisfaction des utilisateurs. Une classification inadéquate des ENF peut conduire à des projets qui ne répondent pas aux besoins des parties prenantes. Voici deux méthodes pour classer les ENF :
- Trier par type Les exigences non fonctionnelles (NFR) peuvent être classées selon trois grandes catégories :
- Aspects opérationnels: ceux-ci portent sur l'efficacité et la sécurité du système dans des conditions normales. Par exemple, le système doit pouvoir prendre en charge 10 000 utilisateurs actifs simultanément sans baisse notable de la qualité du streaming.
- Aspects liés à l'évolutivité: ceux-ci garantissent que le système peut s'adapter aux changements avec un minimum d'efforts. Par exemple, le système doit pouvoir s'adapter pour accueillir jusqu'à 15 000 utilisateurs sans subir de panne majeure.
- Aspects liés à la transition: ils concernent la capacité du système à s'adapter en douceur, par exemple en s'intégrant à d'autres systèmes ou en s'adaptant aux changements. Par exemple, le système devrait fonctionner sur tous les principaux systèmes d'exploitation (Windows, macOS, Linux) et sur tous les types d'appareils (mobile, PC, ordinateur de bureau, tablette) sans nécessiter de modifications importantes.
Ces catégories permettent de mieux comprendre et gérer les NFR au cours du développement d'un produit, d'un système ou d'un processus.
- Classement par ordre de priorité : une fois que vous avez déterminé le type d'exigences que vous rédigez, il est temps de les classer par ordre de priorité. La méthode que vous utiliserez dépendra des besoins de votre projet. Parmi les techniques courantes, on peut citer MoSCoW, RICE, la matrice de priorité, etc.
- Trier par type Les exigences non fonctionnelles (NFR) peuvent être classées selon trois grandes catégories :
Vous pouvez hiérarchiser les NFR en fonction de plusieurs aspects de l'activité et du projet, notamment :
- Valeur commerciale: hiérarchisez les exigences non fonctionnelles (NFR) en fonction de leur impact sur la valeur commerciale du système. Les NFR qui améliorent considérablement la valeur du système doivent se voir attribuer une priorité plus élevée. Par exemple, pour une petite citadine, une NFR portant sur la consommation de carburant présente une plus grande valeur commerciale qu’une autre portant sur le confort des amortisseurs.
- Évaluation des risques: les exigences non fonctionnelles (NFR) associées à des risques plus élevés doivent être traitées en priorité. Par exemple, les NFR liées à la sécurité pourraient se voir attribuer une priorité plus élevée dans un système bancaire. Les NFR décrivant la conformité du véhicule aux critères de sécurité Euro NCAP en matière de chocs latéraux contribuent à protéger les passagers contre les blessures.
- Avis des parties prenantes: Tenez compte de l'avis des parties prenantes. Certaines parties prenantes peuvent accorder plus d'importance à certaines exigences non fonctionnelles.
- Coût et délai: les exigences non fonctionnelles (NFR) dont la mise en œuvre nécessite des ressources ou un temps considérables peuvent se voir attribuer une priorité moindre, à moins qu'elles ne soient essentielles au fonctionnement du système ou à sa valeur commerciale. Par exemple, un système d'infodivertissement de pointe sera considéré comme moins prioritaire si sa mise en œuvre s'avère trop coûteuse.
Conformité légale et réglementaire: les exigences non fonctionnelles (NFR) liées à la conformité légale ou réglementaire revêtent souvent une grande importance en raison des conséquences potentielles d'un manquement à ces obligations. Dans une affaire récente très médiatisée, le constructeur automobile Volkswagen a installé des « dispositifs de mise en échec » dans ses véhicules diesel afin de truquer les tests d'émissions, enfreignant ainsi la réglementation en la matière. Ce scandale a coûté 30 milliards de dollars à l'entreprise.
Étape 4 : Définir les indicateurs et les mesures
Les exigences non fonctionnelles peuvent sembler vagues et difficiles à cerner pour certains, mais elles sont tout aussi essentielles à la réussite d'un projet que les exigences fonctionnelles. La manière dont nous structurons une exigence non fonctionnelle doit mettre en évidence certains éléments importants, tels que :
- Que mesurez-vous ?
- S'agit-il d'une application, d'un système, d'un projet ou d'un processus ?
- Quels indicateurs mesurez-vous ?
- S'agit-il de l'évolutivité, de la facilité de maintenance, de la sécurité ou d'autre chose ?
- Quel est votre objectif ?
- Quels indicateurs utilisez-vous pour évaluer votre réussite ?
Vous pouvez résumer ces réponses en une seule phrase : « Le [insérer la réponse à A] devrait être [insérer la réponse à B] afin que/pour [insérer la réponse à C] »
Pour une exigence non fonctionnelle liée à l'évolutivité, cette phrase pourrait se formuler ainsi :
- « Le système devrait pouvoir prendre en charge jusqu'à 10 000 utilisateurs d'ici deux ans. »
- « L'application doit être évolutive afin de pouvoir gérer 10 000 connexions simultanées par minute. »
Dans la mesure du possible, un NFR devrait comporter à la fois un indicateur et une valeur.
Par exemple, si vous souhaitez définir une exigence non fonctionnelle à partir d'un attribut opérationnel tel que la fiabilité, vous pouvez poser les questions suivantes (et y apporter les réponses suivantes) :
Questions |
|---|
Que mesurez-vous ? |
Quels sont les indicateurs que vous mesurez ? |
Quel est l'objectif ? |
Quels sont les indicateurs et les mesures que vous utilisez pour évaluer la réussite de vos objectifs ? |
Réponses |
|---|
Nous effectuons des mesures sur un système. |
Nous mesurons la fiabilité. |
Nous voulons une disponibilité de 100 % au cours de la première année. |
Notre objectif est une disponibilité de 100 %, notre indicateur est la disponibilité |
On peut résumer ces réponses en une seule phrase :
- « Le système doit être opérationnel de manière à garantir une disponibilité de 100 % pendant la première année d'exploitation, afin de respecter notre garantie de performance d'un an. »
Il est possible d'ajouter des précisions sur les raisons pour lesquelles ce NFR répond aux critères mentionnés ci-dessus.
Comme vous pouvez le constater, vous pouvez créer des exigences non fonctionnelles à l'aide de modèles. Si vous souhaitez savoir comment créer des modèles d'exigences non fonctionnelles, consultez l'article « Création de modèles d'exigences non fonctionnelles ».
Même avec un modèle, il arrive souvent d'oublier d'ajouter des exigences non fonctionnelles. Dans ce cas, il convient de faire preuve de la prudence nécessaire.
Étape 5 : Consignez vos exigences non fonctionnelles
La documentation sert à informer et à garantir la transparence ; elle fait office de liste de contrôle des exigences convenues et d’outil de vérification des travaux réalisés. Elle permet aux équipes de suivre l’évolution et la portée des exigences tout au long du cycle de vie d’un projet, ce qui aide à identifier tout écart par rapport au périmètre initial. Bien qu’il n’existe pas de document standardisé pour les exigences non fonctionnelles, nous aborderons ici les trois principaux types de documents :
- Document des exigences fonctionnelles (FRD): il s'agit d'un énoncé formel des exigences fonctionnelles d'une application, généralement rédigé par un analyste métier sous la supervision du chef de projet. Il fait office de contrat entre le développeur et le client, décrivant les fonctionnalités que l'application doit offrir.
- Document des spécifications du produit (PRD): généralement rédigé par le chef de projet, le PRD présente les fonctionnalités requises pour une version du produit aux équipes de test et de développement. Il définit l'objectif, les fonctionnalités et le comportement du produit, et guide les efforts des équipes produit.
- Spécification des exigences système (SRS): ce document, généralement rédigé par des architectes système ou des chefs de produit, décrit les fonctionnalités et les comportements d'un logiciel ou d'un système. Il sert de base au développement, permet d'estimer les coûts et d'établir le calendrier, et contient des informations essentielles concernant le développement, l'assurance qualité, l'exploitation et la maintenance.
Outils pour la documentation des exigences non fonctionnelles
Les équipes ont besoin d'outils de documentation efficaces, faciles à modifier et à partager, et qui s'intègrent à leur flux de travail, tels que :
- Smart Docs: cette solution permet aux utilisateurs de créer des cahiers des charges, de suivre les modifications grâce à la gestion des versions et de lancer des revues critiques des éléments de travail, y compris les exigences non fonctionnelles.
Elle répond également aux enjeux de normalisation en permettant la création de modèles de documents réutilisables dotés d'une structure personnalisable, favorisant ainsi la cohérence et l'efficacité du processus de documentation.
Système de gestion des documents : il est conçu pour gérer les documents tout au long du projet, en assurant le téléchargement, l'organisation et la gestion des versions des documents et des dossiers.
Ces outils, ainsi que bien d'autres permettant d'étendre la gestion des exigences au sein d'Azure DevOps, sont disponibles avec Modern Requirements4DevOps.
Étape 6 : Relire et corriger
Au fil du temps, les équipes, les entreprises et les parties prenantes constateront que leur liste d'exigences non fonctionnelles s'allonge et évolue. Cela est tout à fait normal, car les besoins d'une organisation s'adaptent et changent. Il s'agit là d'une étape cruciale dans la gestion des exigences non fonctionnelles (NFR).
Par exemple, une application de santé peut générer des fichiers journaux qui enregistrent l'activité des patients ou les transactions du système. Il est essentiel de procéder régulièrement à la rotation de ces fichiers journaux afin de libérer de l'espace disque et de maintenir les performances de l'application.
Au fil du temps, les équipes, les entreprises et les parties prenantes constateront que leur liste d'exigences non fonctionnelles s'allonge et évolue. Cela est tout à fait normal, car les besoins d'une organisation s'adaptent et changent. Il s'agit là d'une étape cruciale dans la gestion des exigences non fonctionnelles (NFR).
Par exemple, une application de santé peut générer des fichiers journaux qui enregistrent l'activité des patients ou les transactions du système. Il est essentiel de procéder régulièrement à la rotation de ces fichiers journaux afin de libérer de l'espace disque et de maintenir les performances de l'application.
3. En quoi les exigences non fonctionnelles contribuent-elles à la normalisation ?
Les exigences non fonctionnelles (NFR) jouent un rôle crucial dans la normalisation, en particulier dans les secteurs où les questions de réglementation et de conformité sont primordiales. Par exemple, dans le secteur des dispositifs médicaux, qui est fortement réglementé, des caractéristiques opérationnelles telles que la confidentialité revêtent une importance capitale.
L'Organisation internationale de normalisation (ISO) a défini des exigences non fonctionnelles (NFR) spécifiques qui doivent être strictement respectées tout au long du développement d'un dispositif médical. Ces exigences sont regroupées dans diverses normes ISO, telles que :
ASPICE – Exigences en matière de développement logiciel pour les constructeurs automobiles
- Garantir une efficacité en temps réel en période de pointe.
- Respecter les normes de sécurité automobile.
- Protégez-vous contre les accès non autorisés et les fuites de données.
- Une interface conviviale pour les conducteurs et les techniciens.
- Des performances constantes dans des conditions variées et en situation de stress.
ISO 13485 – Systèmes de gestion de la qualité pour les dispositifs médicaux
- Contrôles de gestion
- Planification des produits
- Évaluation des processus qualité
- Gestion des ressources
- Régulation par rétroaction
ISO 14971:2007 – Application de la gestion des risques aux dispositifs médicaux
- Responsabilités de la direction
- Processus d'analyse des risques
- Maîtrise des risques
- Processus de gestion des risques
- Rapport sur la gestion des risques
4. Maîtriser les exigences non fonctionnelles
Savoir rédiger, définir et documenter les exigences non fonctionnelles (ENF) est essentiel à la réussite d'un projet. Des ENF bien définies ont une incidence sur la gestion du temps, la satisfaction des utilisateurs et la conformité. Les équipes doivent se concentrer sur des caractéristiques du système claires et mesurables, telles que la sécurité, la fiabilité, les performances et l'évolutivité. La compréhension et la gestion des ENF améliorent l'efficacité, la convivialité et la pérennité du système, contribuant ainsi à la réussite du projet.
Mais les exigences non fonctionnelles ne constituent qu'une partie du succès d'un produit ou d'un projet. En général, vous aurez besoin d'une solution de gestion des exigences dotée de plusieurs fonctionnalités telles que :
- Smart Docs: Création, mise en forme et liaison de documents dans Azure DevOps.
- Copilot4DevOps Plus: un outil de gestion des exigences basé sur l'IA qui change la donne.
- Rapports intelligents: Création et partage en un clic de rapports récapitulatifs de projet dans Azure DevOps.
- Traçabilité: Traçabilité des tâches dans Azure DevOps avec des matrices de traçabilité horizontales et croisées disponibles.
Modern Requirements4DevOps est un outil primé qui transforme Azure DevOps en une source unique de vérité.
5. Autres questions qui nous sont posées au sujet des exigences non fonctionnelles
Voici les réponses à certaines questions fréquentes qui nous sont posées au sujet des exigences non fonctionnelles :
-
- Quelles sont les stratégies organisationnelles permettant de garantir l'efficacité de la NFR ?
Voici d'autres stratégies organisationnelles qui peuvent vous aider à optimiser leur impact. - Priorité : planifier et définir les exigences non fonctionnelles avec le même soin que les autres types d'exigences
- Références : utilisez les références du secteur pour évaluer l'efficacité d'une exigence non fonctionnelle. Par exemple, la norme du secteur en matière de temps de chargement d'un site web est de 2 secondes. Les équipes doivent utiliser des outils tels que GTMetrix et Google Page Speed Insights pour comparer leur site web.
- Une vision à long terme : dans un contexte DevOps, une équipe doit adopter une vision à long terme. Il convient de sélectionner judicieusement les exigences non fonctionnelles.
- Collaboration : Encourager la collaboration et la communication entre les membres de l'équipe afin de s'assurer que chacun comprenne les NFR et s'efforce de les respecter.
- Formation : Organiser des formations à l'intention des développeurs sur l'importance des exigences non fonctionnelles et sur la manière de les mettre en œuvre efficacement dans leur travail. Cela permettra de s'assurer que les exigences non fonctionnelles ne sont pas négligées au cours du processus de développement.
- Quelles sont les stratégies organisationnelles permettant de garantir l'efficacité de la NFR ?
- Qui rédige les exigences non fonctionnelles dans le cadre d'une méthode Agile ? Les architectes système et solution, ainsi que les équipes de gestion des produits et des solutions, élaborent les exigences non fonctionnelles de manière collaborative dans le cadre d'une méthode Agile.
- Les exigences non fonctionnelles sont-elles rédigées sous forme d'histoires utilisateur ? Oui, il est parfois possible de rédiger des exigences non fonctionnelles sous forme d'histoires utilisateur. Par exemple, vous pouvez formuler une exigence non fonctionnelle relative à la sécurité ainsi : « En tant qu'utilisateur, je souhaite que mes données personnelles soient cryptées, afin que mes informations soient protégées contre tout accès non autorisé. »
