Le recueil des besoins
Les techniques de recueil (entretien, questionnaire, observation, atelier, analyse de l'existant, maquette), le choix de la bonne selon la situation, les types de questions et les parties prenantes à interroger.
- 23 cartes
- 4 thèmes
- Gratuit
Le programme, thème par thème
Le poids de chaque thème suit celui que lui donne l'examen.
- Notions
- Questions
- Ranger et relier
- Mises en situation
Quelques cartes du deck
Recueil des besoins : de quoi s'agit-il ?
Voir la réponse
Activité qui découvre, auprès des personnes concernées et dans les documents existants, ce que le futur système doit apporter.
Les besoins ne se « ramassent » pas : beaucoup ne sont pas exprimés, parce que l'utilisateur les juge évidents ou ne sait pas les dire.
Des préparateurs de commandes trient les colis très vite et n'arrivent pas à expliquer leur méthode. Quelle technique de recueil choisir pour la comprendre ?
- L'observation sur le poste de travail
- Un questionnaire envoyé à tous les préparateurs
- Un atelier avec la direction de l'entrepôt
- L'analyse des procédures écrites de l'entreprise
Voir la réponse
L'observation sur le poste de travail
Un geste devenu automatique se voit mais ne se décrit pas. Les procédures écrites montrent le travail prescrit, pas le travail réel, et la direction ne le fait pas elle-même.
Une question … laisse la personne répondre avec ses mots ; une question … attend « oui », « non » ou un choix dans une liste.
Voir la réponse
Une question ouverte laisse la personne répondre avec ses mots ; une question fermée attend « oui », « non » ou un choix dans une liste.
L'ouverte sert à découvrir (« Comment faites-vous ? »), la fermée à confirmer ou à chiffrer (« Combien de fois par semaine ? »).
Partie prenante : de quoi s'agit-il ?
Voir la réponse
Personne ou groupe concerné par le système ou capable d'influencer le projet : utilisateurs, commanditaire, exploitants, juristes.
Oublier une partie prenante, c'est oublier ses besoins : l'équipe qui exploitera l'application a des exigences que ni le commanditaire ni les utilisateurs ne formulent.
Le client a validé le cahier des charges, puis rejette la livraison : « ce n'est pas ce que nous voulions ». Quelle cause retenir, et que changer sur le projet suivant ?
- Le cahier des charges était trop court : en rédiger un plus long et plus détaillé
- Aucun utilisateur n'a vu de maquette : en montrer une à de vrais utilisateurs tôt
- Le client a validé trop vite : lui faire parapher chaque page avant de coder
- Le client a changé d'avis : interdire toute modification après la validation
Voir la réponse
Aucun utilisateur n'a vu de maquette : en montrer une à de vrais utilisateurs tôt
Valider un texte n'est pas valider un usage : sans maquette ni échange avec ceux qui s'en serviront, l'écart n'apparaît qu'à la livraison. Plus de texte, plus de signatures ou un document figé n'apprennent rien sur l'usage réel ; seul un retour tôt d'utilisateurs devant du concret corrige le tir.