J’ai eu l’occasion de remarquer dans les projets informatiques que j’ai managé ou bien été amené à auditer que les besoins non fonctionnels sont souvent très pauvrement documentés, voire sous entendus plutôt que clairement exprimés. Cet article propose une liste à parcourir pour ne pas oublier de documenter les vôtres dans vos prochains projets informatiques.

I had the opportunity to notice in the computing projects that I led or audited that the non functional needs are often poorly documented, even presumed taken into account rather than clearly expressed. This article suggests a list to browse in order not to forget to document yours in your next IT projects.

Besoins Non-fonctionnels dans les projets informatiques – Liste de contrôle minimale par Mike Griffiths

Http://www.pmhut.com/non-functional-requirements-in-it-projects-minimal-checklist

Tous les systèmes d’information à un certain point dans leur cycle de vie doivent considérer des besoins non-fonctionnels et leurs tests. Pour certains projets ces besoins demanderont un travail très important et pour d’autres un contrôle rapide sera suffisant. Au minimum, la liste suivante peut être un rappel utile pour s’assurer que vous avez couvert l’essentiel. Selon vos propres spécificités de projet, je recommanderais que les sujets soient convertis en besoins « SMART » (Spécifique, Mesurable, Atteignable, Réalisable, limité dans le Temps / Traçable) avec le détail et la rigueur appropriés pour votre projet.

Sécurité
• Besoins d’établissement de la connexion – niveaux d’accès « CRUD levels » (Create, Read, Update and Delete)
• Besoins de mot de passe – longueur, caractères spéciaux, expiration, politique de réutilisation
• Déconnexion après temps morts d’inactivité – durées, actions

Audit
• Éléments Vérifiés – quels éléments métiers seront vérifiés ?
• Champs Vérifiés – quels champs de données seront vérifiés ?
• Caractéristiques de fichier d’audit – image avant, image après, signature utilisateur et horaire, etc.

Performance
• Temps de réponse – le chargement de l’application, ouverture d’écran et des délais de rafraîchissement, etc.
• En temps de traitement – fonctions, calculs, importations/exportations de données
• L’interrogation de données et Rapports – temps de chargement initial et des chargements suivantes

Capacité
• Bande passante – combien de transactions par heure le système doit-il être capable de traiter ?
• Mémoire(Stockage) – combien de données le système doit-il être capable de stocker?
• Besoins de croissance d’année-en-année (croissance organique)

Disponibilité
• Les heures d’opération – quelles heures de disponibilité ? Considérez les week-ends, les vacances, des périodes de maintenance, etc.
• Les emplacements d’opération – d’où devrait-il être disponible, quels sont les besoins de connexion ?

Fiabilité
• Moyenne des temps de bon fonctionnement – Quel est le seuil acceptable de temps d’indisponibilité ? Par exemple : une fois par an, 4,000 heures par an.
• Le temps Moyen de Rétablissement – si cassé, combien de temps est disponible pour restaurer le système à nouveau ?

Intégrité
• La capture des erreurs d’entrée-sortie – comment traiter les échecs d’interface électroniques, etc.
• Le traitement des mauvaises données – import de données, marquer-et-continuer ou arrêt la politique d’importation, etc.
• Intégrité des données – intégrité référentielle dans tables de base de données et interfaces
• Compression d’image et normes de décompression

Rétablissement
• Processus de rétablissement – comment ce travail est-il réalisé, quel est le processus ?
• Durées des temps de récupération – combien de temps le rétablissement devrait-il prendre pour s’exécuter ?
• Fréquences des sauvegardes – à quelle fréquences les données de transaction, d’installation(de paramétrage) et le système (le code) doivent-ils être sauvegardés ?
• Générations de secours – quels sont les besoins pour la restauration à l’état précédent le problème ?

Compatibilité
• La compatibilité avec des applications partagées – À quels autres systèmes doit-il parler ?
• La compatibilité avec des applications tierces – Avec quels autres systèmes doit-il cohabiter ?
• La compatibilité sur des systèmes d’exploitation différents – sur lesquels doit-il être capable de fonctionner ?
• La compatibilité sur des plateformes différentes – Sur quelles sont les plateformes matérielles doit-il marcher ?

Aptitude à la maintenance
• La conformité aux standards d’architecture – à quels standards a-t-il besoin de se conformer ou en être exempté ?
• La conformité aux standards de design – Quels standards de conception doivent être suivis ou des exemptions obtenues ?
• La conformité au standards de développement – Quels standards de développement doivent être suivis ou des exemptions obtenues ?

Ergonomie
• Les standards d’ergonomie – la densité d’éléments sur les écrans, la disposition et le flux, les couleurs, l’Interface Utilisateur, les raccourcis clavier
• Internationalisation / besoins de localisation – langages, orthographe, claviers, formats de papier, etc.

Documentation
• Eléments de documentation requis et utilisateur de chaque élément