Définition des besoins pour le logiciel (Collection études et logiciels informatiques)

Définir les besoins pour un logiciel est un processus difficile qui fait appel à des compétences humaines, techniques et méthodologiques très variées, alliant rigueur et créativité. Une étude efficace des besoins réduit très sensiblement le coût du développement et de la maintenance d'une application et accroît sa qualité. Définition des besoins pour le logiciel est un outil d'aide à la maîtrise d'ouvrage et à la conception de projets. Il permet de recueillir et d'analyser les besoins et d'élaborer un cahier des charges pour un logiciel. L'ouvrage décrit : les étapes pour définir les besoins en partant des objectifs, les différentes techniques de recueil et d'analyse, une méthode efficace pour élaborer un cahier des charges, des plans types de cahiers des charges et un guide de rédaction, des conseils techniques et des recommandations aux managers, des études de cas.
Chapitre 1. Le besoin et l'exigence. La relation client-fournisseur. Besoin, demande, exigence, spécification. Le cycle de vie du logiciel. À qui s'adresse ce livre ? Guide de lecture. Chapitre 2. Qu'est-ce qu'un "bon" logiciel ? Les attributs fondamentaux du logiciel. Trois niveaux de vision de la qualité. Les caractéristiques de la qualité. La fiabilité. La maintenabilité. La portabilité et la facilité d'installation. La transparence. L'esthétique. La variabilité. Chapitre 3. La maîtrise de l'ouvrage. Projet, oeuvre et ouvrage. Les trois activités sous la responsabilité de la maîtrise d'ouvrage. Le cahier des charges. La validation. Le suivi du projet. Chapitre 4. La définition des objectifs. Au préalable : une décision de changement. Le contenu de la phase d'objectifs. Les activités de la phase d'objectifs. L'analyse de l'existant. L'analyse des parties prenantes (les acteurs). L'étude comparative. La déclaration d'objectifs. Chapitre 5. Recueil et analyse des besoins. Activités de l'ingénierie des besoins. Les grandes étapes. De la difficulté d'exprimer les besoins. L'intervention de recueil des besoins. Typologie des exigences. Les diverses techniques de recueil et d'analyse. Chapitre 6. Sept critères d'ergonomie. Qu'est-ce que l'ergonomie ? Ergonomie : la qualité vue de l'utilisateur. Les sept règles d'ergonomie. L'application des principes d'ergonomie à la construction du logiciel. Chapitre 7. Le cahier des charges : élaboration. L'utilité du cahier des charges. Producteurs et consommateurs des exigences. Centrer le projet autour du cahier des charges. Présentation de la démarche. Lancer le projet d'élaboration du cahier des charges. Spécifier l'objectif. Analyser l'existant. Proposer des améliorations. Réviser l'organisation. Les défauts fréquents sur un cahier des charges. Conseils pratiques et précautions à prendre. Chapitre 8. Le cahier des charges : guide de rédaction. Présentation de ce chapitre. La norme X50-151. Autres modes de présentation du cahier des charges. Guide de rédaction du cahier des charges. Chapitre 9. Validation et diagnostics. Validation des exigences. Les différentes méthodes de validation. Audits et diagnostics de logiciel. Mesure de l'utilisabilité : le questionnaire SUMI. Chapitre 10. La gestion et le suivi des exigences. Pourquoi les exigences doivent être gérées ? Comment les exigences doivent être gérées. Les activités de gestion des exigences. De la rentabilité des opérations de gestion. Chapitre 11. Quelques conseils techniques. Considérer la définition des exigences comme un vrai projet. Gérer par les objectifs. Choisir le bon modèle de cahier des charges. Utiliser les outils avec discernement. Utiliser de multiples techniques et formalismes. Maquetter et prototyper juste ce qu'il faut. Chapitre 12. Aspects managériaux et facteurs humains. Savoir quels sont les acteurs. Ne pas croire que le client a toujours raison. Gérer les priorités dynamiquement et chercher le consensus. Connaître le coût et la valeur de chaque exigence. Gérer la qualité, par la qualité et avec la qualité du produit. Alterner rigueur et imagination. Choisir un représentant des utilisateurs dynamique et volontaire. Garder en permanence le contact avec les utilisateurs. Informer et faire participer toutes les parties prenantes. Perdre du temps pour en gagner. Chapitre 13. Trois études de cas. Une histoire de communication. Cas numéro 1 : le RAD perverti. Cas numéro 2 : la lourdeur qui tue. Cas numéro 3 : la simplicité gagnante. Chapitre 14. Un nouveau métier : le designer de logiciel. Rigueur et innovation. La construction de la qualité. Le besoin d'un designer. Un homme de terrain, une vision stratégique. Quel avenir pour le designer ? Conclusion. Glossaire. Bibliographie. Sites web utiles.