Comment les spécifications des exigences logicielles et les maquettes permettent aux entreprises de gagner du temps et de l'argent

Saviez-vous que 701 projets informatiques dépassent le budget prévu ou échouent complètement à cause d'erreurs de planification ? Selon le Standish Group (2023), la principale raison est l'absence d'exigences métier claires et de représentation visuelle du produit. C'est là que les spécifications des exigences logicielles (SRS) et les maquettes entrent en jeu : deux outils indispensables. conseil en logiciels L'entreprise utilise cette méthode pour transformer le chaos du développement et des tests de produits en un processus gérable.

Une bonne spécification des exigences logicielles n'est pas une simple formalité, mais la clé de la réussite de tout projet de développement. Une spécification des exigences logicielles SRS bien préparée détaille les fonctions du système logiciel, ses interactions avec les utilisateurs et les systèmes, et les normes de qualité qu'il respectera.

Par exemple, une startup californienne a perdu 100 000 USD à cause d'une erreur mineure : l'équipe a commencé à écrire du code sans SRS approuvé. Résultat : le client a reçu un produit qui ne répondait pas à ses attentes, et il a fallu trois mois pour le refaire.

Les maquettes, quant à elles, permettent de visualiser les idées avant même le début de la programmation. Elles permettent de coordonner la conception, l'interface logique et les scénarios utilisateur, ce qui est particulièrement important en développement informatique. Sans elles, le rôle des logiciels dans les processus métier peut être faussé, et la correction des erreurs à des étapes ultérieures peut coûter 10 à 100 fois plus cher (IBM, 2021). Le développement des exigences logicielles est essentiel.

Voyons comment le SRS et les maquettes permettent de gagner du temps, de réduire les coûts et de soulager tous les participants au processus de développement. Vous apprendrez :

• Comment rédiger un plan SRS pour éviter les conflits avec les entrepreneurs.
• Pourquoi les exigences fonctionnelles et non fonctionnelles sont cruciales et tout aussi importantes.
• Les outils utilisés par les meilleures entreprises pour créer un document SRS efficace.
  

Prêt à faire de votre prochain projet informatique une réussite ? Commençons par les bases.

Conseil en logiciels

Le conseil en logiciels joue un rôle crucial en aidant les entreprises à rationaliser leurs processus de développement et à atteindre efficacement leurs objectifs. société de conseil en logiciels Offre des conseils d'experts pour créer des architectures logicielles robustes, mettre en œuvre les meilleures pratiques et éviter les erreurs coûteuses. L'un des principaux domaines d'intervention du conseil en logiciels est le développement de spécifications logicielles (SRS) et de maquettes. Ces outils garantissent la structuration et l'efficacité du processus de développement logiciel, permettant ainsi aux entreprises de gagner du temps et de réduire le risque d'erreurs coûteuses.

Par exemple, selon le Standish Group (2023), 701 projets informatiques échouent ou dépassent leur budget en raison d'exigences floues. Un SRS n'est pas un simple document administratif ; il constitue un plan détaillé pour le développement logiciel, couvrant les exigences fonctionnelles et non fonctionnelles. En collaborant avec un cabinet de conseil en logiciels ou un cabinet de conseil SRS, les entreprises peuvent éviter les pièges courants tels qu'une planification inadéquate ou des objectifs mal définis, ce qui contribue in fine à préserver le budget et le calendrier du projet.

Les maquettes, qui représentent visuellement les idées avant la phase de programmation, sont un autre outil précieux. Elles contribuent à garantir l'adéquation entre la conception, l'expérience utilisateur et les exigences fonctionnelles. Ces visuels permettent aux parties prenantes de vérifier que le produit répond aux attentes, réduisant ainsi le risque de refontes coûteuses ultérieures.

En définitive, le conseil en logiciels permet aux entreprises de mieux comprendre leurs besoins logiciels, les aidant ainsi à gérer des projets informatiques complexes et à assurer leur réussite. Le conseil SRS optimise ce processus en garantissant des exigences logicielles précises et bien documentées, en minimisant les risques et en alignant les efforts de développement sur les objectifs commerciaux.

Développement SaaS

Le développement SaaS (Software as a Service) consiste à créer des applications logicielles cloud accessibles en ligne, plutôt que d'être installées localement. Les plateformes SaaS offrent aux entreprises des solutions évolutives par abonnement, accessibles depuis n'importe quel appareil connecté à Internet. Les principaux avantages du développement SaaS sont des coûts initiaux réduits, des mises à jour automatiques et une intégration aisée avec d'autres systèmes. Développement SaaS se concentre sur les interfaces conviviales, la sécurité et la garantie d'une haute disponibilité et d'une évolutivité pour s'adapter aux bases d'utilisateurs croissantes.

Document SRS : Rôle dans l'ingénierie des produits logiciels

Document de spécification des exigences logicielles : fondement d'un projet réussi

Le document SRS (Software Requirements Specification) est un accord formalisé entre le client et l'équipe de développement. Il décrit en détail les caractéristiques du projet logiciel, son fonctionnement et ses conditions. Il ne s'agit pas d'une simple liste de souhaits, mais d'une véritable bible du projet qui élimine les malentendus et réduit les risques. Selon la norme IEEE 830, une bonne spécification des exigences logicielles SRS comprend des objectifs clairs, des exigences fonctionnelles, des critères de performance et des contraintes système, constituant ainsi la base d'un développement logiciel réussi.

1. Objectifs et portée : pourquoi le produit est créé.
2. Exigences fonctionnelles : ce que le système doit faire (par exemple, « l’utilisateur peut télécharger des fichiers »).
3. Exigences non fonctionnelles : comment le système le fait (performances, sécurité, compatibilité).
4. Interfaces — interaction avec des systèmes externes et des utilisateurs.
5. Contraintes — règles techniques ou commerciales.

Exemple : une spécification d’exigences logicielles prototype pour une banque mobile comprend une section « Exigences de sécurité » qui spécifie l’authentification à deux facteurs et le cryptage des données.

Exigences fonctionnelles et exigences non fonctionnelles : analyse comparative

En génie logiciel, les exigences sont divisées en deux types :

Les exigences fonctionnelles définissent la logique fondamentale d'un produit. Par exemple, dans une application de commerce électronique, une exigence fonctionnelle pourrait être : « Le panier doit conserver les articles pendant 24 heures. »

Les exigences non fonctionnelles, cependant, servent souvent de « bouée de sauvetage ». 

Étude de cas : Une startup fintech incluse dans son Document SRS L'exigence « le système doit gérer 5 000 transactions par seconde ». Lorsque la charge augmentait, cette exigence permettait d'éviter les pannes système et les pertes de clients.

Le coût de l'ignorance des exigences non fonctionnelles

Les négliger est une erreur courante. En 2022, HealthCareSoft a lancé une application logicielle pour les cliniques sans sauvegarde.

Résultat : une panne de serveur a supprimé 10 000 dossiers de patients. La récupération a pris 1 million de livres sterling (9 0 ...

Conclusion : Un document SRS n’est pas une bureaucratie ; c’est un investissement dans la prévisibilité. Il transforme des idées abstraites en instructions claires pour l’équipe de développement, tout en préservant le budget des surprises.

Rédaction d'un document SRS : étapes et outils

Guide étape par étape pour créer un SRS

Rédiger un SRS peut paraître complexe au premier abord. Voyons ce que doit contenir un document SRS et les quatre étapes suivantes pour transformer des idées chaotiques en documentation structurée :

1. Collecte des exigences
   • Mener des entretiens avec les clients, des études de marché et des analyses de scénarios d’utilisateurs.
   • Capturez à la fois les exigences fonctionnelles (« ce que fait le système ») et non fonctionnelles (« comment il le fait »).
   • Exemple : pour un produit bancaire en ligne, les exigences incluent la sécurité, la vitesse de traitement des demandes et l’intégration du système de paiement.
2. Analyse et priorisation
   • Assurez-vous que les exigences ne sont pas en contradiction entre elles ou avec les objectifs commerciaux.
   • Utilisez la méthode MoSCoW : Doit avoir, Devrait avoir, Pourrait avoir, N'aura pas.
3. Documentation
   • Exigences de formatage à l'aide d'un modèle SRS (par exemple, norme IEEE 830).
   • Inclure les sections : Introduction, Exigences fonctionnelles et non fonctionnelles, Interfaces, Contraintes.
4. Approbation
   • Alignez le document avec le client et l’équipe de développement.
   • Exemple : le document SRS doit être approuvé par les parties prenantes avant le début du codage.

Outils d'automatisation pour le développement SRS

Pour simplifier le processus SRS, utilisez :

• Jira – pour le suivi des exigences et des tâches.
• Confluence – pour stocker et éditer de manière collaborative la documentation SRS.
• Helix ALM – pour le contrôle de version et les tests.

Ces outils réduisent les risques de perte de données et accélèrent la gestion des exigences.

Exemple d'échec d'une mise en œuvre SRS

Une start-up berlinoise a développé un logiciel de gestion d'entrepôt. Faute de temps, l'équipe n'a pas défini les exigences détaillées relatives à l'interface externe. Résultat :

• Les développeurs ont construit le système sur la base d’hypothèses.
• Le client a rejeté le produit car l’interface utilisateur ne répondait pas aux besoins des employés.
• $30 000 et deux mois ont été consacrés à la refonte.

Conclusion : Les raccourcis pris dans le SRS ont conduit à l’échec du projet.

Pourquoi les erreurs SRS sont coûteuses

Selon une étude d’IBM, le coût de la correction des bugs augmente considérablement au fil du temps :

• Correction d'un bug lors de la phase de conception : $1.
• Pendant la phase de test : $15.
• Après la sortie : $100+.

Source : IBM Systems Sciences Institute, 2023.

Conclusion : Un SRS et un document d'exigences système ne sont pas une charge administrative, mais une assurance contre les pertes financières. Investir du temps dans la création d'un SRS protège votre projet des mauvaises surprises et accélère le processus de développement logiciel.

Développement informatique : fonctionnalités de la documentation SRS

Le développement informatique ne se limite pas à l'écriture de code ; il s'agit de créer un produit capable de fonctionner dans un environnement numérique en constante évolution. Contrairement aux applications bureautiques, les projets web (SaaS, e-commerce, portails d'entreprise) font face à des défis spécifiques :

• Évolutivité – le système doit gérer la croissance du trafic.
• Compatibilité entre navigateurs – affichage cohérent sur Chrome, Safari et Firefox.
• Intégrations – systèmes de paiement, CRM, outils d’analyse.

Par exemple, un document SRS pour une plateforme de gestion de projet SaaS peut inclure une section d’exigences indiquant : « Le système doit prendre en charge 1 000 utilisateurs simultanés sans délai. »

Fonctionnalités SRS pour SaaS et e-commerce

1. Solutions SaaS :
   • Concentrez-vous sur les types d'exigences non fonctionnelles : sécurité des données (cryptage, accès basé sur les rôles), disponibilité de 99,9%.
   • Exemple : un SRS pour un éditeur de texte basé sur le cloud peut spécifier :

« Sauvegarde automatique toutes les 2 minutes. »

1. Sites de commerce électronique :
   • En-tête : logo, barre de recherche, icône de panier.
   • Section produit : filtres par prix, catégorie et note.
   • Pied de page : coordonnées, liens vers les réseaux sociaux.
     
   • Accent mis sur les exigences UI/UX : un panier d'achat convivial, intégration PayPal/Stripe.
   • Étude de cas : La mise en page principale d'un site de commerce électronique comprend :

Cette structure permet d’aligner les attentes entre les développeurs et les clients avant le début du développement.

Externalisation du développement logiciel : une réussite

Une start-up néerlandaise développait une plateforme SaaS pour l'enseignement en ligne. Manquant de ressources internes, elle a opté pour un développement externalisé, mais au préalable :

• Création d'un SRS détaillé spécifiant les fonctionnalités (webinaires vidéo, quiz) et la conformité en matière de sécurité (RGPD).
• Inclusion des exigences d’analyse comparative de projets similaires.
• Attentes de performances définies : prise en charge de 5 000 utilisateurs simultanés.

Résultat:

• L'entrepreneur a estimé avec précision le calendrier et le budget ($150K au lieu du $200K initial).
• Le produit final a réussi un audit de sécurité dès la première tentative.
• La startup a obtenu un investissement de $2M grâce à un alignement MVP et SRS bien défini.

Pourquoi SRS est votre arme secrète dans le développement informatique ?

• Pour les clients : transforme les idées abstraites en spécifications techniques claires, protégeant ainsi contre les entrepreneurs peu fiables.
• Pour les développeurs : réduit les révisions et les problèmes de communication.

À retenir : le développement externalisé ne fonctionne que si vous disposez d'un SRS détaillé. Sans cela, vous risquez d'obtenir un produit qui ne répond pas aux besoins de votre entreprise.

Exigences non fonctionnelles : élément clé du SRS

Imaginez que votre application fonctionne parfaitement sur un serveur local, mais plante avec 100 utilisateurs en ligne. Ou qu'elle soit piratée une semaine après son lancement. Il ne s'agit pas d'histoires d'horreur hypothétiques, mais des conséquences réelles du non-respect des exigences non fonctionnelles (NFR). Même si les fonctionnalités sont irréprochables, sans « cadre caché », votre produit est voué à l'échec.

Que sont les exigences non fonctionnelles (NFR) ?

Les NFR définissent le fonctionnement du système, plutôt que sa fonction. Les principales catégories sont :

• Performances – temps de réponse, capacité de charge du serveur.
• Sécurité – protection des données, authentification.
• Évolutivité – capacité à évoluer sans réécrire le code.
• Facilité d’utilisation – conception d’interface conviviale.

Exemple : dans un système bancaire en ligne, les exigences fonctionnelles couvrent les transferts d’argent et les paiements, tandis que les exigences non fonctionnelles garantissent le cryptage des données et la résistance aux attaques DDoS.

Étude de cas : comment le fait d'ignorer les NFR a gaspillé $2M

En 2021, une startup EdTech a lancé une plateforme de cours en ligne. Son SRS couvrait des exigences fonctionnelles détaillées (cours vidéo, quiz), mais ignorait les exigences de performance.

Résultat:

• Avec 500 utilisateurs simultanés, les serveurs sont surchargés.
• Les vidéos étaient mises en mémoire tampon pendant 10 à 15 secondes, ce qui provoquait un désabonnement massif des utilisateurs.
• L'optimisation des infrastructures d'urgence a coûté $2M et a duré 4 mois.

Conclusion : les NFR ne sont pas facultatifs, ils sont le fondement de la stabilité

Comment définir les exigences non fonctionnelles dans un SRS ?

1. Soyez précis, pas abstrait
   • ❌ Mauvais : « Le système doit être rapide. »
   • ✅ Bon : « Le temps de chargement de la page doit être ≤ 2 secondes avec 1 000 utilisateurs simultanés. »
2. Utiliser les normes
   • Pour la sécurité : RGPD, ISO 27001.
   • Pour les performances : SLA (exemple, disponibilité 99,9%).

Pourquoi est-ce important pour l’externalisation ?

Lors de l'externalisation du développement de logiciels, définition des NFR dans le SRS :

• Aide le fournisseur à choisir les bonnes technologies (par exemple, des solutions cloud pour l'évolutivité).
• Empêche les litiges lors des tests d'acceptation (« Vous n'avez pas spécifié les exigences de charge ! »).
• Permet d’économiser du budget : corriger ultérieurement les erreurs architecturales coûte 10 à 20 fois plus cher. 

En résumé : les exigences fonctionnelles répondent à la question « Quoi ? », les exigences non fonctionnelles répondent à la question « Comment ? » et « Comment ? ». Ignorer les exigences non fonctionnelles revient à construire une maison sans fondations. Assurez-vous que votre SRS couvre les deux pour éviter les défaillances de produit au moment le plus crucial.

Externalisation du développement de logiciels : le rôle du SRS

Imaginez que vous déléguiez votre projet à une équipe externe, pour vous rendre compte un mois plus tard qu'elle construit quelque chose de complètement différent de ce que vous attendiez. Cela vous rappelle quelque chose ? Ce phénomène se produit lorsqu'on externalise un projet sans SRS détaillé.

Pourquoi SRS est-il votre « bouclier » dans les contrats d’externalisation ?

Un SRS n’est pas seulement une liste de souhaits : c’est un document juridiquement important qui :

1. Verrouillage des exigences – garantissant que les deux parties ont les mêmes objectifs.
2. Réduit le risque de manipulation : l’entrepreneur ne pourra pas imposer de fonctionnalités inutiles « par défaut ».
3. Sert de base aux tests : l’acceptation est effectuée selon des critères clairs.

Par exemple, si le SRS stipule : « le logiciel doit traiter 100 commandes par minute », mais que l’entrepreneur livre un système qui ne gère que 50 commandes, il s’agit d’une violation directe du contrat.

Étude de cas : Comment SRS a économisé $50k et a préservé la réputation de l'entreprise

Une start-up barcelonaise a externalisé le développement logiciel d'une application mobile de suivi d'activité. Au lieu d'une spécification technique abstraite, elle a fourni :

• Une spécification détaillée des exigences logicielles (SRS) avec des exemples d'interface.
• Exigences de performance : synchronisation des données avec Apple Health en ≤ 3 secondes.
• Exigences non fonctionnelles : fonctionnement autonome 24 heures sur 24.

Résultat:

• L’entrepreneur ne pouvait pas gonfler le budget avec des révisions cachées.
• Le coût final du projet était de $50K inférieur à la moyenne du marché.
• L'application a reçu 4,8 étoiles sur l'App Store grâce à une UX bien pensée.

5 risques liés à l'externalisation sans SRS

Si vous décidez de ne pas rédiger un SRS pour gagner du temps, voici ce qui vous attend :

1. Délais changeants – Sans exigences claires, les estimations de temps et de budget deviennent des conjectures.
2. Conflits lors de l'acceptation – « Nous avons fait ce que vous avez demandé ! » vs. « Ce n'est pas ce que nous voulions ! »
3. Dette technique – Les entrepreneurs peuvent utiliser des solutions bon marché qui nécessiteront des retouches coûteuses.
4. Perte de connaissances – Si l’équipe part, une nouvelle équipe ne comprendra pas comment développer le produit.
5. Risques juridiques – Les litiges ne peuvent être résolus sans faire appel à un SRS.

Comment se protéger ?

Si vous externalisez le développement de logiciels, suivez trois étapes :

1. Investissez dans la création d’un SRS – Cela prend 2 à 3 semaines mais permet d’économiser des mois de travail.
2. Assurez-vous que votre entrepreneur comprend et accepte toutes les exigences.
3. Utilisez le SRS comme liste de contrôle à chaque étape du projet.

N'oubliez pas : le SRS n'est pas une bureaucratie ; c'est votre principal outil de contrôle. Ne laissez pas votre projet se transformer en gouffre budgétaire !

SRS et Wireframes – Votre police d'assurance pour vos projets informatiques

Imaginez que chaque projet soit lancé dans les délais, dans le respect du budget et des attentes. Ce n'est pas une utopie, c'est une réalité pour ceux qui investissent dans des spécifications logicielles (SRS) et des wireframes. Ces outils agissent comme une assurance : ils n'éliminent pas tous les risques, mais minimisent leur impact financier.

Selon IBM, chaque $1 investi dans la planification permet d'économiser $15 en corrections de bugs post-version. Un SRS transforme des idées abstraites en instructions claires, tandis que les wireframes visualisent les concepts avant même l'écriture d'une seule ligne de code. Ensemble, ils :

• Réduire le besoin de révisions de 60–70%.
• Accélérez les approbations des entrepreneurs.
• Permet des prévisions de retour sur investissement plus précises.

Que se passe-t-il si vous sautez le SRS ? Des exigences vagues, des révisions sans fin, des délais non respectés et, au final, un dépassement budgétaire de 40–200%.

Conclusion

Un programme bien structuré Spécification des exigences logicielles Le document SRS (Structured Standards) garantit que le logiciel répond aux besoins métier en décrivant ses fonctionnalités et en détaillant les exigences nécessaires à son développement. Le SRS fournit un ensemble complet de cas d'utilisation qui décrivent précisément les exigences fonctionnelles et techniques, y compris les contraintes de fonctionnement du logiciel. La rédaction d'un document SRS aide les chefs de projet à gérer efficacement les exigences lors du développement logiciel, réduisant ainsi les écarts entre le document et la mise en œuvre finale du logiciel. 

Un SRS existant peut servir de référence pour les nouveaux projets, tandis qu'un exemple de plan SRS peut contribuer à standardiser le processus de gestion des exigences. Les entreprises souhaitant externaliser le développement logiciel ont intérêt à compléter le SRS avant de faire appel à des équipes externes, ce qui garantit la clarté et réduit les révisions coûteuses. Qu'il s'agisse de développer un système de gestion documentaire cloud ou une autre solution complexe, la formulation d'un document SRS solide rationalise les processus de développement système et logiciel, permettant ainsi de gagner du temps et de l'argent.

Ne faites pas du développement une loterie. Confiez la création de votre SRS aux professionnels de Camel Expert : nous vous aiderons à formaliser vos idées, à préparer les wireframes et à sélectionner le prestataire idéal. Résultat ? Vous économiserez jusqu'à 40% sur votre budget et lancerez votre produit plus rapidement que vos concurrents.

Pourquoi payer pour des erreurs quand on peut les éviter ? Commencez par planifier : c'est la seule étape où votre investissement sera forcément rentable.

Annexe : Liste de contrôle pour l'auto-vérification du SRS

Liste de contrôle 1 : Exhaustivité des exigences

✅ Toutes les exigences fonctionnelles sont clairement décrites (par exemple, « Les utilisateurs peuvent s'inscrire via Google »).
✅ Les exigences non fonctionnelles sont spécifiées : sécurité, performance, évolutivité.
✅ La section « Exigences d’interface externe » est incluse (UI/UX, compatibilité entre navigateurs).
✅ Les contraintes sont documentées (par exemple, compatibilité avec Windows 10+).
✅ Des scénarios utilisateur (cas d’utilisation) pour les fonctionnalités clés sont fournis.
✅ Tous les objectifs commerciaux du client sont pris en compte.

Liste de contrôle 2 : Bonne structure du document SRS

✅ Un modèle SRS est utilisé (par exemple, IEEE 830 ou ISO/IEC/IEEE 29148).
✅ Le document comprend :

• Introduction (objectif, ensemble de cas d'utilisation du logiciel et rôle).
• Exigences fonctionnelles et non fonctionnelles.
• Interfaces (API, intégrations matérielles/logicielles).
• Contraintes et dépendances.
  Des exemples de spécifications SRS pour des projets similaires sont inclus.
  Les exigences sont numérotées avec des identifiants uniques (par exemple, FTR-001, NFR-005).

Liste de contrôle 3 : Vérification de la cohérence

✅ Aucune exigence contradictoire (par exemple, « Le système doit fonctionner hors ligne » ou « Nécessite une connexion Internet constante »).
✅ Les exigences de performance correspondent aux limitations techniques (par exemple, « 10 000 requêtes/s » sur un hébergement partagé n’est pas réaliste).
✅ Les spécifications des exigences du système sont synchronisées avec le SRS (par exemple, la capacité du serveur correspond à la charge de travail).

Liste de contrôle 4 : Préparation à l'externalisation

✅ Le SRS comprend des critères d'acceptation (par exemple, « Prend en charge 5 000 utilisateurs simultanés »).
✅ Des normes de sécurité sont spécifiées (RGPD, ISO 27001 pour les logiciels).
✅ Les exigences en matière de documentation sont décrites (par exemple, manuel d’utilisation en anglais).
✅ Tous les termes du glossaire sont clairement définis (par exemple, « fonctionnement autonome » = 24 heures sans charge).

Liste de contrôle 5 : Validation des exigences

✅ Des entretiens avec les chefs de projet et les parties prenantes ont été menés.
✅ Les exigences sont testées via des scénarios de cas d'utilisation (par exemple, « Inscription → Paiement → Livraison »).
✅ Les spécifications de développement Web sont prises en compte : SEO, adaptation mobile, mise en cache.
✅ Des outils de gestion des exigences sont utilisés (Jira, Helix ALM).

Liste de contrôle 6 : Évaluation de la qualité du SRS

✅ Un SRS fort répond à ces critères :

• Exhaustivité : Aucune fonction manquante.
• Clarté : Aucune interprétation ambiguë.
• Testabilité : Chaque exigence peut être vérifiée.
  Des références à la documentation de support (spécifications techniques, documents API) sont incluses.
  Le document est approuvé par toutes les parties (développeurs, client, testeurs).
  

Liste de contrôle 7 : Préparation au développement

✅ Des exigences logicielles claires s’alignent sur le processus de développement.
✅ Des méthodologies adaptées sont choisies pour l'ingénierie logicielle (Agile, Waterfall).
✅ Un document en direct est maintenu avec la possibilité d'apporter des modifications (par exemple, Confluence + Jira).

Comment utiliser les listes de contrôle :

1. Examinez chaque point par rapport à la formulation de votre document SRS.
2. Si la réponse est « Non », révisez le SRS avant de continuer.
3. Pour le développement de logiciels, fournissez la liste de contrôle à l’entrepreneur dans le cadre du contrat.
   

Exemple:

Pour un projet de développement web e-commerce, consultez :

• L'intégration de PayPal est-elle mentionnée dans le SRS (exigence fonctionnelle) ?
• Un temps de chargement de page ≤ 2 secondes est-il spécifié (exigence non fonctionnelle) ?