Recueil des exigences : 10 bonnes pratiques pour la réussite d’un projet de simulation
Dans le cadre du développement de produits, une exigence est un besoin physique ou fonctionnel qu’une conception particulière doit satisfaire. Elle définit l’écart qu’une capacité, une fonctionnalité ou une caractéristique nécessaire ou souhaitée doit combler pour apporter de la valeur et de l’utilité aux parties prenantes, qu’il s’agisse d’utilisateurs, de clients, d’organisations, etc. Les exigences sont utilisées à la fois au début d’un projet (« voici ce que cela doit faire ») et à la fin, dans le cadre du processus de vérification (« est-ce que cela fait vraiment ce que nous voulons qu’il fasse ? »). C’est pourquoi la qualité de la phase de collecte des exigences est essentielle à la réussite d’un projet – une maison solide a besoin de fondations solides. Pour qu’un projet de simulation soit couronné de succès, il faut tout d’abord en définir pleinement les objectifs et les besoins, afin de ne pas perdre de temps sur des points non essentiels. Cela peut sembler évident, mais des discussions vagues peuvent conduire à des exigences qui s’avèrent incomplètes ou, pire, trompeuses.
Pour commencer
La meilleure façon de recueillir les exigences est de s’engager dans un processus formel, avec une documentation qui implique l’examen et l’approbation de toutes les parties prenantes au projet. Définissez clairement la portée du projet – et veillez à ce que tout le monde soit d’accord ! Il sera ainsi beaucoup plus facile de refuser les demandes coûteuses du type « ne serait-ce pas bien si… » qui apparaissent inévitablement à mi-parcours de la conception et de la mise en œuvre.
Description sommaire: Construisez-vous un simulateur de conduite ou étudiez-vous la géométrie des suspensions proposées avec un conducteur dans la boucle ? Il est important de définir correctement le projet, car cela indiquera le domaine dans lequel l’essentiel des efforts sera investi. Dans l’exemple du simulateur de conduite ci-dessus, une simulation de base de la suspension est probablement suffisante ; il est préférable de consacrer du temps et des efforts à l’élaboration de scénarios de formation.
Une liste d’objectifs clés: Il s’agit des objectifs de haut niveau qui doivent être atteints pour que le projet soit considéré comme une réussite. Par exemple, « le simulateur comprendra une plate-forme de mouvement 6DOF » ou « la zone simulée couvrira au moins 1 km2 ». Soyez honnête et ne mentionnez que les véritables objectifs clés.
Une description complète du matériel prévu pour le simulateur: l’énumération des ordinateurs, écrans, commandes, etc. disponibles permettra d’éviter les problèmes d’optimisation par la suite. Notez que pour certains projets, le choix du matériel ne sera décidé qu’une fois les exigences définies, spécifiquement pour y répondre – cela ne pose pas de problème non plus.
Contraintes: S’il existe des contraintes connues, elles doivent également être mentionnées ici. La première itération doit-elle être réalisée à temps pour un salon professionnel ou une réunion de haut niveau avec des parties prenantes essentielles ? Le projet fait-il appel à une nouvelle technologie ? Le simulateur doit-il être facilement déplaçable ?
Cela dit, une fois que vous avez posé les fondations, la réussite du projet dépend de l’application d’un certain nombre de bonnes pratiques.
10 bonnes pratiques à suivre pour la réussite d’un projet
Une définition claire et stable des besoins augmentera les chances de succès de tout projet.
- Impliquez toutes les parties prenantes dès le départ. C’est avec eux que le projet doit commencer et se terminer. Consultez si possible les utilisateurs finaux et les experts en la matière, et pas seulement les personnes qui signeront le chèque.
- Le document d’exigences doit être relativement stable. Les exigences sont rédigées par des humains et sont donc sujettes à l’ambiguïté, à l’incomplétude et à l’incohérence. Les clarifier tôt coûte généralement beaucoup moins cher que lorsque ces mêmes problèmes sont découverts plus tard dans le développement du produit. Notez que dans les méthodes agiles, l’élaboration des détails peut se faire juste à temps, mais les exigences de base de haut niveau doivent toujours être fixées dès le départ !
- Soyez clair, concis et évitez le jargon si possible. Les exigences sont un moyen de communication entre les parties prenantes. Elles doivent être faciles à comprendre pour les utilisateurs normaux comme pour les développeurs, et il convient donc d’éviter le jargon technique, les acronymes et autres références obscures. Une façon courante de documenter une exigence est d’énoncer, en texte clair, ce que le système doit faire. Par exemple : « La simulation doit inclure trois charges différentes : « La simulation doit inclure trois charges différentes à lever par la grue ». D’autres méthodes font appel aux cas d’utilisation et aux récits d’utilisateurs.
- Assurez-vous que les exigences sont mesurables. Elles doivent être fondées sur des faits objectifs, et non sur des opinions, et n’avoir qu’une seule interprétation possible. Les définitions vagues, les adjectifs (« le véhicule simulé doit avoir l’air cool ») et autres formulations subjectives doivent être évités, de même que les déclarations négatives. Cela permet également de s’assurer qu’aucune exigence ne contredit une autre.
- Les exigences ne sont pas des solutions ! Les parties prenantes doivent expliquer les résultats finaux qu’elles recherchent et les besoins qu’elles ont, et non la manière d’y parvenir. Pour toute exigence qui demande une fonctionnalité ou une mise en œuvre technique spécifique, vous devez comprendre pourquoi la demande est formulée – sinon elle est suspecte. Il existe peut-être un moyen plus simple de répondre au besoin, mais les parties prenantes ne le connaissent pas. Identifiez les problèmes et les besoins avant de tenter de les résoudre.
- Toutes les exigences doivent être vérifiables. Ils doivent être rédigés de manière à pouvoir être testés, inspectés, examinés, vérifiés, etc. Évitez les termes tels que « toujours » ou « jamais » (car le prouver impliquerait un cycle de test infini !). Les exigences doivent comporter des critères de réussite clairs et être réalistes, à la fois en termes de temps et de portée. N’hésitez pas à les présenter aux parties prenantes pour confirmer votre compréhension. Cela doit être fait avant le début du projet, car les changements deviennent beaucoup plus difficiles une fois que le travail a commencé.
- Ne présumez jamais de ce que veut le client. Inclure un volant à retour de force est évident pour un simulateur de conduite ? Peut-être que le client a des restrictions budgétaires et d’espace, et qu’il a besoin de commandes par joystick à la place. Cela vaut la peine de demander ! N’hésitez jamais à revenir en arrière et à poser des questions supplémentaires en cas de doute.
- Chaque exigence doit répondre à un besoin. Si votre exigence contient une conjonction (« faire ceci et cela »), elle peut probablement être décomposée en deux exigences distinctes. Le fait d’avoir des exigences à but unique permet de créer des maquettes ou des prototypes fonctionnels en cours de route. Vous n’avez pas besoin de l’environnement et des scénarios complets et définitifs pour tester un modèle de véhicule, par exemple. Cela permet d’éviter les mauvaises surprises lors de l’utilisation de technologies complexes ou de pointe, surtout si l’on tient compte des problèmes de démarrage potentiels.
- Toutes les exigences doivent être classées par ordre de priorité. Aucun plan ne survit au contact avec la réalité. Vous n’aurez peut-être pas le temps de tout faire, alors qu’est-ce qui est essentiel à la réussite du projet ? Qu’est-ce qui pourrait être fait plus tard, ou pas du tout ? Par exemple, disposer d’une réponse appropriée sur les systèmes hydrauliques serait un « must » dans une simulation de machinerie lourde, mais pouvoir modifier facilement le logo sur la portière du véhicule ? Pas vraiment.
- Document, document, document. Tout doit être écrit dans un endroit accessible à toutes les parties prenantes. Toutes les exigences doivent être énoncées de manière exhaustive en un seul endroit, sans aucune information manquante. Vous éviterez ainsi toute confusion et récriminations ultérieures.
Quels sont vos conseils pour réussir un projet ? Avez-vous des leçons à partager ? N’hésitez pas à nous en faire part et nous vous en ferons part dans un prochain article de blog.
10 bonnes pratiques pour la réussite d’un projet de simulation
1. Impliquer toutes les parties prenantes dès le départ
Consultez si possible les utilisateurs finaux et les experts en la matière, et pas seulement les personnes qui signeront le chèque.
2. Le document d’exigences doit être relativement stable.
Les exigences sont rédigées par des humains et sont donc sujettes à l’ambiguïté, à l’incomplétude et à l’incohérence.
3. Soyez clair, concis et évitez le jargon si possible.
Les exigences sont un moyen de communication entre les parties prenantes.
4. Assurez-vous que les exigences sont mesurables
Elles doivent être basées sur des faits objectifs, et non sur des opinions, et n’avoir qu’une seule interprétation possible.
5. Les exigences ne sont pas des solutions !
Les parties prenantes doivent expliquer les résultats finaux qu’elles recherchent et les besoins qu’elles ont, et non la manière d’y parvenir.
6. Toutes les exigences doivent être vérifiables
Ils doivent être rédigés de manière à pouvoir être testés, inspectés, examinés, vérifiés, etc.
7. Ne présumez jamais de ce que veut le client
N’hésitez jamais à revenir en arrière et à poser des questions supplémentaires en cas de doute.
8. Chaque exigence doit répondre à un besoin
Cela permet d’éviter les mauvaises surprises lors de l’utilisation de technologies complexes ou de pointe, surtout si l’on tient compte des problèmes de démarrage qu’elles peuvent entraîner.
9. Toutes les exigences doivent être classées par ordre de priorité
Aucun plan ne survit au contact avec la réalité.
10. Document, document, document
Toutes les exigences doivent être énoncées de manière exhaustive en un seul endroit, sans aucune information manquante.