Comment écrire des exigences non fonctionnelles en 6 étapes
Les équipes construisent des exigences non fonctionnelles (NFR) en identifiant des attributs du système comme la sécurité, la fiabilité, la performance, la maintenabilité, l’évolutivité et l’utilisabilité, puis en les spécifiant en termes clairs et mesurables.
C’est important puisque les exigences non fonctionnelles (NFR) sont cruciales pour assurer l’efficacité du système, l’ergonomie, la longévité et la satisfaction des utilisateurs.
Pour cette raison, cet article explique comment rédiger des NFR en 6 étapes et qui les rédige, avec des exemples et des modèles pour vous guider.
Note : Si vous souhaitez comprendre ce que sont les exigences non fonctionnelles, les différences avec les exigences fonctionnelles, et approfondir les types d’exigences non fonctionnelles, lisez Non-Functional Requirements Explained (With Real Examples).
Table des matières
Temps de lecture : 15 minutes
Auteur : Arunabh Satpathy
1. Qui écrit les exigences non fonctionnelles?
Les exigences non fonctionnelles (NFR) sont généralement rédigées par diverses parties prenantes impliquées dans le projet. Cela inclut généralement :
- Analystes d’affaires : Ils prennent souvent la tête de l’identification et de la documentation des NFR, car ils traitent généralement avec les clients tout en faisant partie de l’entreprise qui crée les produits. En conséquence, ils ont une vision claire des besoins, préférences et attentes tant des clients que des parties prenantes internes.
- Architectes/Ingénieurs systèmes : Grâce à leur compréhension approfondie de l’architecture système, des limites et des possibilités, leur contribution sur les NFR est inestimable.
- Propriétaires/gestionnaires de produit : Ils peuvent aider à définir les NFR en fonction des besoins des clients, des besoins d’affaires et des connaissances du marché.
- Équipes d’assurance qualité (QA) : Elles peuvent contribuer à la définition des NFR pertinentes aux normes de qualité, à la conformité légale et aux critères de test.
Apprendre à écrire et/ou créer des exigences non fonctionnelles est un effort collaboratif. Ainsi, une communication efficace entre toutes les parties est essentielle pour les définir et les mettre en œuvre avec précision.
2. Comment écrire des exigences non fonctionnelles en 6 étapes?
Étape 1 : Identifier la portée et l’objectif
La portée d’un projet guide les ressources ou livrables que vous pouvez ajouter ou retirer au fur et à mesure que le projet progresse, selon les besoins identifiés des parties prenantes. Il détermine aussi quels NFR l’équipe crée. Des projets mal conçus et des exigences non fonctionnelles (NFR) peuvent entraîner des problèmes importants comme des dépassements de coûts, des retards, l’insatisfaction des parties prenantes, voire des problèmes juridiques.
Des études montrent que 85% des projets de construction avec un dépassement de portée dépassent leur budget, avec un dépassement de coût moyen de 27%.
Par exemple, si un système est une application de diffusion vidéo en temps réel, alors les NFR liés à la performance (comme la fidélité vidéo et les temps d’arrêt) seraient très pertinents.
Étape 2 : Rassembler les avis 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 d’obtenir l’avis des parties prenantes. Cela évite aussi des problèmes importants comme les dépassements de coûts et l’exposition juridique. Obtenir l’avis des parties prenantes est faisable en deux étapes :
- Engagement des parties prenantes
Identifier les parties prenantes au début d’un projet est crucial. Les parties prenantes peuvent être classées en groupes primaires, secondaires et tertiaires, selon leur impact direct et leur influence sur le projet.
Après avoir identifié à la fois les parties prenantes internes et externes, les équipes peuvent passer à la collecte des exigences, y compris celles non fonctionnelles.
- Exigences de collecte
La collecte des exigences est la façon dont les équipes recueillent des informations auprès des parties prenantes pour définir les exigences du projet, y compris les exigences non fonctionnelles.
Les techniques de collecte des besoins incluent une variété de méthodes qualitatives et quantitatives comme les entrevues, le remue-méninges, les groupes de discussion et les sondages. 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 aussi aux équipes de recueillir les exigences d’autres sources comme les courriels, notes, FAQ et documents Word téléversés.
Les équipes ont maintenant commencé à utiliser des outils d’IA de pointe pour automatiser l’obtention des exigences, rendant cela plus efficace et complet.
Étape 3 : Catégoriser les exigences non fonctionnelles (NFR)
La catégorisation des exigences non fonctionnelles (NFR) guide la conception du produit/service et influence sa performance, sa sécurité et sa satisfaction des utilisateurs. Des NFR mal catégorisés peuvent mener à des projets qui ne répondent pas aux besoins des parties prenantes. Voici deux façons de catégoriser les NFR :
- Tri par type Les exigences non fonctionnelles (NFR) peuvent être catégorisées de trois façons principales :
- Aspects opérationnels : Celles-ci se concentrent sur l’efficacité et la sécurité du système dans des conditions normales. Par exemple, le système devrait desservir 10 000 utilisateurs actifs simultanément sans baisse significative de la qualité du streaming.
- Aspects révisionnels : Cela permet au système de s’adapter aux changements avec un minimum d’effort. Par exemple, le système devrait s’étendre pour accueillir jusqu’à 15 000 utilisateurs sans panne majeure du système.
- Aspects transitionnels : Ils concernent la capacité du système à effectuer une transition fluide, comme l’intégration avec d’autres systèmes ou l’adaptation aux changements. Par exemple, le système devrait fonctionner sur tous les principaux systèmes d’exploitation (Windows, macOS, Linux) et sur tous les formats (mobile, PC, bureau, tablette) sans nécessiter de changements significatifs.
Ces catégories aident à comprendre et à gérer les NFR lors du développement d’un produit, d’un système ou d’un processus.
- Tri par priorité : Une fois que vous comprenez quels types d’exigences vous rédigez, il est temps de les prioriser. La méthode que vous utilisez dépend des besoins de votre projet. Parmi les techniques courantes, on retrouve MoSCoW, RICE, la matrice de priorités, et plus encore.
- Tri par type Les exigences non fonctionnelles (NFR) peuvent être catégorisées de trois façons principales :
Vous pouvez prioriser les NFR selon plusieurs aspects de l’entreprise et du projet, notamment :
- Valeur commerciale : Priorisez les NFR selon leur impact sur la valeur commerciale du système. Les NFR qui augmentent significativement la valeur du système devraient recevoir une priorité accrue. Par exemple, pour une petite voiture urbaine, un NFR précisant l’efficacité énergétique a plus de valeur commerciale qu’un seul déterminant le confort des amortisseurs.
- Évaluation des risques : Les NFR associés à des risques plus élevés devraient être priorisés. Par exemple, les NFR liés à la sécurité pourraient avoir une priorité plus élevée dans un système bancaire. Les NFR décrivant la conformité de la voiture aux classifications de sécurité Euro NCAP pour les impacts secondaires aident à protéger les passagers contre les dangers.
- Avis des parties prenantes : Considérez les contributions des parties prenantes. Certains intervenants peuvent accorder plus d’importance à certains NFR.
- Coût et temps : Les NFR qui nécessitent des ressources ou du temps importants pour leur mise en œuvre peuvent recevoir une priorité moindre, sauf s’ils sont essentiels au fonctionnement ou à la valeur commerciale du système. Par exemple, un système d’infodivertissement à la fine pointe de la technologie est une priorité moindre s’il est trop coûteux à mettre en place.
Conformité légale et réglementaire : Les NFR liés à la conformité légale ou réglementaire ont souvent une priorité élevée en raison des conséquences potentielles d’une non-conformité. Dans un cas récent célèbre, le constructeur automobile Volkswagen a installé des « dispositifs de défaillance » dans ses véhicules diesel pour tromper les tests d’émissions, ce qui violait la réglementation sur les émissions. Le scandale a coûté à l’entreprise 30 milliards de dollars.
Étape 4 : Définir les mesures et les indicateurs
Les NFR peuvent être larges et difficiles à comprendre pour certains, mais ils sont tout aussi essentiels au succès d’un projet que les exigences fonctionnelles. La façon dont nous structurons une exigence non fonctionnelle devrait indiquer quelques éléments importants comme :
- Qu’est-ce que tu mesures?
- Est-ce une application, un système, un projet ou un processus?
- Quels attributs mesurez-vous?
- Est-ce que c’est de la scalabilité, de la maintenabilité, de la sécurité ou autre chose?
- Quel est votre objectif?
- Quels indicateurs utilisez-vous pour déterminer le succès?
Vous pouvez condenser ces réponses en une seule affirmation : « La [insérer la réponse à A] devrait être [insérer la réponse à B] afin que/à [insérer la réponse à C] »
Pour un NFR lié à l’évolutivité, cette déclaration pourrait être la suivante :
- « Le système devrait être évolutif jusqu’à 10 000 utilisateurs dans les deux prochaines années. »
- « L’application devrait être évolutive pour gérer 10 000 connexions simultanées par minute »
Dans la mesure du possible, un NFR devrait avoir à la fois une métrique et une mesure.
Par exemple, si vous souhaitez construire une exigence non fonctionnelle en utilisant un attribut opérationnel comme la fiabilité, vous pouvez poser les questions (et réponses suivantes) :
Questions |
|---|
Qu’est-ce que tu mesures? |
Quelle(s) attribut(s) mesurez-vous? |
Quel est l’objectif? |
Quelles sont les mesures et métriques que vous utilisez pour déterminer le succès des objectifs? |
Réponses |
|---|
Nous mesurons un système. |
Nous mesurons la fiabilité. |
Nous voulons 100% de disponibilité dès la première année. |
Notre mesure est 100% du temps de fonctionnement, notre métrique est la disponibilité |
Vous pouvez condenser ces réponses en une seule affirmation :
- « Le système devrait être opérationnel afin que nous ayons un temps de disponibilité de 100% pour la première année d’exploitation afin de respecter notre garantie de performance d’un an. »
Ajouter un peu plus d’informations sur les raisons pour lesquelles ce NFR applique ces critères comme ci-dessus est une option.
Comme vous pouvez le voir, vous pouvez créer des exigences non fonctionnelles en utilisant des modèles. Si vous souhaitez apprendre à construire des NFR à l’aide de modèles, lisez Building Non-Functional Requirements Templates.
Malgré le modèle, il est toujours possible d’oublier d’ajouter des exigences non fonctionnelles. Vous devriez faire preuve de prudence appropriée dans ce cas.
Étape 5 : Documentez vos exigences non fonctionnelles
La documentation sert à informer et à assurer la responsabilité, servant de liste de vérification des exigences convenues et d’outil pour vérifier le travail terminé. Il permet aux équipes de surveiller l’évolution et la portée des exigences tout au long de la durée de vie d’un projet, aidant à identifier toute écartation par rapport à la portée initiale. 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’une déclaration formelle des exigences fonctionnelles d’une application, généralement compilée par un analyste d’affaires et supervisée par le gestionnaire de projet. Elle sert de contrat entre le développeur et le client, définissant ce que l’application doit faire.
- Document d’exigences produit (PRD) : Généralement rédigé par le gestionnaire de projet, le PRD communique les fonctionnalités requises pour une version produit aux équipes de test et de développement. Il établit la finalité, 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 propriétaires de produits, décrit les caractéristiques et comportements d’un logiciel ou d’un système. Il sert de base au développement, fournit une base pour estimer les coûts et la planification, et contient des informations cruciales liées au développement, à l’assurance qualité, aux opérations et à la maintenance.
Outils pour la documentation des exigences non fonctionnelles
Les équipes ont besoin de bons outils de documentation, facilement modifiables, partageables et intégrés à leur flux de travail, comme :
- Smart Docs : Cela permet aux utilisateurs de créer des documents d’exigences, de suivre les changements avec la gestion des versions et d’initier des examens critiques des éléments de travail, y compris les exigences non fonctionnelles.
Il répond également aux enjeux de normalisation en permettant la création de modèles de documents réutilisables avec une structure personnalisable, favorisant la cohérence et l’efficacité du processus de documentation.
Système de gestion documentaire : Il est conçu pour gérer des documents pendant toute la durée du projet, en effectuant des tâches de téléchargement, de structuration et de versionnement des documents et dossiers.
Ces outils et bien d’autres pour étendre la gestion des exigences dans Azure DevOps sont disponibles avec Modern Requirements4DevOps.
Étape 6 : Réviser et réviser
Avec le temps, les équipes, les entreprises et les parties prenantes remarqueront que leur liste d’exigences non fonctionnelles va s’allonger et changer. C’est attendu à mesure que les besoins d’une organisation s’adaptent et changent. C’est une étape cruciale dans la gestion des exigences non fonctionnelles (NFR).
Par exemple, une application de soins de santé pourrait générer des fichiers journaux qui enregistrent l’activité des patients ou les transactions système. Un cycle régulier de ces fichiers journaux est essentiel pour récupérer l’espace disque et maintenir la performance de l’application.
Avec le temps, les équipes, les entreprises et les parties prenantes remarqueront que leur liste d’exigences non fonctionnelles va s’allonger et changer. C’est attendu à mesure que les besoins d’une organisation s’adaptent et changent. C’est une étape cruciale dans la gestion des exigences non fonctionnelles (NFR).
Par exemple, une application de soins de santé pourrait générer des fichiers journaux qui enregistrent l’activité des patients ou les transactions système. Un cycle régulier de ces fichiers journaux est essentiel pour récupérer l’espace disque et maintenir la performance de l’application.
3. Comment les exigences non fonctionnelles aident-elles à la normalisation?
Les exigences non fonctionnelles (NFR) jouent un rôle crucial dans la normalisation, particulièrement dans les secteurs où les enjeux réglementaires et de conformité sont primordiaux. Par exemple, dans l’industrie des dispositifs médicaux, qui est fortement réglementée, les attributs opérationnels comme la confidentialité sont d’une importance capitale.
L’Organisation internationale de normalisation (ISO) a défini des NFR spécifiques qui doivent être strictement suivis lors du développement de tout dispositif médical. Ces exigences sont classées selon diverses normes ISO telles que :
ASPICE – Exigences de développement logiciel pour les constructeurs automobiles
- Assurez-vous d’une efficacité en temps réel sous les charges de pointe.
- Respectez les normes de sécurité automobile.
- Sécurisez contre les accès non autorisés et les violations de données.
- Interface conviviale pour les pilotes et les techniciens.
- Performance constante dans des conditions et des contraintes variées.
ISO 13485 – Systèmes de gestion de la qualité pour les dispositifs médicaux
- Contrôles de gestion
- Planification de produit
- Évaluation des procédés de qualité
- Contrôle des ressources
- Contrôle par rétroaction
ISO 14971:2007 – Application de la gestion des risques aux dispositifs médicaux
- Responsabilités de gestion
- Processus d’analyse des risques
- Contrôle des risques
- Processus de gestion des risques
- Rapport sur la gestion des risques
4. Maîtrise des exigences non fonctionnelles
Savoir comment écrire, définir et documenter les exigences non fonctionnelles (NFR) est crucial pour la réussite du projet. Les NFR bien définis influencent la gestion du temps, la satisfaction des utilisateurs et la conformité. Les équipes devraient se concentrer sur des attributs clairs et mesurables du système comme la sécurité, la fiabilité, la performance et l’évolutivité. Comprendre et gérer les NFR améliore l’efficacité du système, l’ergonomie et la longévité, ce qui favorise ultimement la réussite des projets.
Mais les exigences non fonctionnelles ne sont qu’une partie du succès du produit ou du projet. En général, vous aurez besoin d’une solution de gestion des exigences qui offre plusieurs fonctionnalités telles que :
- Smart Docs : Création, mise en forme et lien de documents dans Azure DevOps.
- Copilot4DevOps Plus : Outil révolutionnaire de gestion des exigences en IA.
- Smart Reports : Génération et partage en un clic de rapports instantanés de projet dans Azure DevOps.
- Traçabilité : Traçabilité des items de travail dans Azure DevOps avec des matrices de traçabilité horizontale et intersectionnelle disponibles.
Modern Requirements4DevOps est un outil primé qui étend Azure DevOps en une seule source de vérité.
5. Autres questions qu’on nous pose concernant les exigences non fonctionnelles
Voici les réponses à quelques questions courantes qu’on nous pose sur les exigences non fonctionnelles :
-
- Quelles sont certaines stratégies organisationnelles pour assurer une NFR efficace?
Voici d’autres stratégies organisationnelles qui peuvent vous aider à maximiser leur impact. - Prioriser : planifier et créer des exigences non fonctionnelles avec les mêmes soins que les autres types d’exigences
- Références : Utilisez les références de l’industrie pour déterminer l’efficacité d’une exigence non fonctionnelle. Par exemple, une norme de l’industrie pour le temps de chargement d’un site web est de 2 secondes. Les équipes devraient utiliser des outils comme GTMetrix et Google Page Speed Insights pour comparer leur site web.
- Mentalité à long terme : Dans un contexte DevOps, une équipe doit penser à long terme. Vous devriez choisir correctement les exigences non fonctionnelles.
- Collaboration : Encourager la collaboration et la communication entre les membres de l’équipe afin que tout le monde comprenne et travaille à respecter les NFR.
- Formation : Offrir une formation aux développeurs sur l’importance des NFR et sur la manière de les mettre en œuvre efficacement dans leur travail. Cela peut aider à s’assurer que les NFR ne soient pas négligés lors du processus de développement.
- Quelles sont certaines stratégies organisationnelles pour assurer une NFR efficace?
- Qui écrit des exigences non fonctionnelles en Agile? Les architectes systèmes et solutions ainsi que la gestion des produits et solutions créent des exigences non fonctionnelles en Agile de manière collaborative.
- Les exigences non fonctionnelles sont-elles rédigées sous forme d’histoires utilisateur? Oui, parfois on peut écrire des exigences non fonctionnelles sous forme d’histoires utilisateur. Par exemple, vous pouvez écrire un NFR de sécurité comme : « En tant qu’utilisateur, je veux que mes données personnelles soient chiffrées, afin que mes informations soient protégées contre tout accès non autorisé. »