LOG2420 Analyse et conception d interfaces utilisateur École Polytechnique de Montréal Notes du cours Hiver, 2015

Transcription

1 LOG2420 Analyse et conception d interfaces utilisateur École Polytechnique de Montréal Notes du cours Hiver, 2015 Michel C. Desmarais Version 17 janvier

2 partie Table des matières TABLE DES MATIÈRES I Processus de développement centré utilisateur 3 1 Cycles de conception et de développement ISO Exigences utilisateur Élaboration et validation Utilisabilité

3 Première partie Processus de développement centré utilisateur 1 Cycles de conception et de développement La conception et le développement d applications interactives comportent des caractéristiques différentes du développement de logiciels non interactifs. Nous référons au terme conception centrée utilisateur (ou développement centré utilisateur pour réréfer au cycle complet) pour désigner un processus comportant les caractéristiques et activités propres et adaptées à la conception et au développement d applications interactives. D une part et comme nous l avons vu dans l introduction, le produit final qui intéresse le client d une application interactive provient de l utilisation du logiciel par l utilisateur. Or, ce produit dépend en bonne partie de l utilisateur, de son expertise, de son degré de familiarité avec l application, et bien entendu de la qualité de l interface. Il faut donc que le processus de développement tienne compte de l utilisateur et de sa maîtrise l interface pour accomplir un certain nombre de tâches. L évaluation de la satisfaction des exigences ultimes du système doit se faire au niveau du système utilisateur-ordinateur. Au contraire, dans le cas d un système qui n a pas d interface directe avec l ordinateur et qui est piloté par une autre application ou un mécanisme quelconque, on peut plus facilement se contenter de valider uniquement les spécifications fonctionnelles offertes par le système. Par exemple, dans le cas d une librairie graphique ou de calcul scientifique, on peut souvent se contenter de vérifier le fonctionnement par des tests unitaires l ensemble de l API sur les plates-formes visées. Des tests plus poussés vont aussi valider la performance de l utilisation de la librairie dans un contexte pratique, mais les résultats sont souvent prévisibles ou, du moins, ne réservent pas autant de surprises que pour les applications interactives. Et ces tests sont, quoi qu il en soit, à effectuer pour toute application. Tandis que la validation que les exigences utilisateurs sont les bonnes, ainsi que les tests pour valider que les utilisateurs visés réussissent à effectuer les tâches désirées correctement, sont des activités qui sont en sus et qui ne s appliquent que pour les applications interactives. Une autre différence majeure entre une application interactive et un logiciel non interactif est que la gestion des exigences est très différente. Or, la gestion des exigences est critique, car on sait fort bien que les erreurs au niveau des exigences sont les plus coûteuses : une erreur au niveau des exigences qui est découverte dans la phase de déploiement du logiciel peut coûter de 100 à 1000 fois le coût de correction lors de la phase

4 de spécification des exigences 1. Or, les exigences utilisateurs sont particulièrement changeantes et volatiles en comparaison à des exigences techniques. Par exemple, dans le cas du développement de pilotes logiciel d un nouvel appareil, une carte de communication ou un numériseur vidéo, peu importe, les spécifications sont relativement stables et bien définies. Souvent, les spécifications suivent des normes et il n y a que très peu d inconnus. Au contraire, les exigences utilisateurs sont mal connues au début. Les utilisateurs potentiels que l on a questionnés initialement n ont qu une vague idée de ce que doit faire l application et c est souvent au moment de commencer à l utiliser (dans la phase de déploiement) qu il réalisent que des fonctions critiques manquent ou ne sont pas implantées de la bonne façon et ne correspondent pas à leurs attentes. Un processus adapté au développement d application interactive doit investir bien davantage dans la validation des exigences tôt dans le processus pour éviter ces situations et il doit recourir à des activités spécifiques à ce type de développement comme des analyses de tâches et des maquettes plus ou moins interactives pour valider les concepts initiaux. Le développement de logiciel Il existe des différences fondamentales entre le développement d un logiciel interactif et un logiciel non interactif Ex. logiciel interactif : interface à un téléphone portable Ex. logiciel non interactif : pilote de la carte antenne du téléphone portable La différence principale : les exigences utilisateurs sont volatiles, elles changent au long du projet Pour des applications interactives, c est près de 50% du code qui est dédié à l interface Par conséquent, le processus de développement doit être adapté Le coût de changements d exigences selon la phase 1. Sharif, B., Khan, S. A., Bhatti, M. W. (2012). Measuring the Impact of Changing Requirements on Software Project Cost : An Empirical Investigation. International Journal of Computer Science Issues (IJCSI), 9(3). Young, R. (2001). Effective Requirements Practices. 4

5 Coût Phase 1$ Exigences 2 6$ Conception 10$ Codage 15 60$ Tests (développement) 30 70$ Tests (acceptabilité) $ Opérations Practices. source : Young, R. (2001). Effective Requirements Modèle en cascades avec retours Le modèle en spirale s approche du centré utilisateur sans toutefois en comporter les particularités spécifiques. Modèle en spirale 5

6 Le modèle en spirale est un autre modèle bien connu qui se prête à la conception d interfaces utilisateur, sans toutefois spécifier explicitement les caractéristiques et activités propres au développement centré utilisateur. Néanmoins, l emphase mise sur les itérations et le prototypage progressif de l application finale lui confère un caractère peut-être plus près de ce type de développement que le RUP en lui-même. Modèle itératif est adaptable, mais pas adapté au modèle centré utilisateur. Les cas d utilisation sont les artefacts clés pour le développement d applications interactives. 6

7 Les modèles itératifs, comme le processus unifié (unified process), dont le RUP c est un produit commercial bien connu) est un processus très répandu dans l entreprise et enseigné à l École, tout comme dans plusieurs autres institutions. Il n est pas spécifiquement adapté au développement d applications interactives, mais il comporte une structure générale et un ensemble d artefacts qui peuvent se prêter à un tel type de développement. Dans le cadre du processus unifié, un des plus importants artefacts pour la conception d application interactive est le cas d utilisation. Il s approche de la notion de scénario (Rosson et Carroll, 2002) 2, mais s en distingue par son niveau de généricité qui est plus élevé que le scénario. On peut considérer le scénario comme une mise en contexte d un cas d utilisation. Rosson et Carroll suggèrent qu un scénario devrait être une description plus spécifique d un cas d utilisation où les problèmes d utilisabilité sont spécifiquement relevés (p. 19). Bref, on peut, avec le processus unifié, implanter un processus de développement relativement bien adapté pour les applications interactives, comme on peut passer complètement à côté des activités importantes (voir par exemple Gulliksen et al, 2005) 3. Plusieurs de ces processus existent et nous en survolons quelques-uns très brièvement avant de ce concentrer sur le processus centré utilisateur de conception d interfaces ISO (maintenant ISO :2010). 2. Rosson, M.-B. et Carroll, J. M. (2002) Usability Engineering, Scenario-Based Development of Human- Computer Interaction. Morgan Kaufmann. 3. Gulliksen, J., Göransson, B., Boivie, I., Blomkvist, S., Persson, J., and Cajander, Å., Key principles of user-centred systems design. In Seffah, A., Gulliksen J. and Desmarais, M.C., Human-Centered Software Engineering : Integrating Usability in the Development Process, Wiley,

8 Processus de développement centré utilisateur selon Constantine et Lockwood (1999) Constantine et Lockwood (1999) 4 définissent un cycle de développement propre à l approche centrée utilisateur. On y retrouve certaines activités propres au développement centré utilisateur, notamment l analyse de tâches, la modélisation du contenu de l interface et l inspection de l utilisabilité, ainsi que d autres activités propres à ce cycle mais à saveur centrée utilisateur comme le dialogue collaboratif autour des exigences et la contextualisation opérationnelle. Un autre processus processus bien connu est celui de Mayhew (1999) 5. Il a la particularité d être relativement bien arrimé avec des jalons et artéfacts de processus et pratiques répandus dans l industrie, tel que la production d un guide de style. Processus de développement centré utilisateur selon Mayhew (1999) 4. Constantine L., and Lockwood, L. Software for Use : A Practical Guide to the Essential Models and Methods of Usage-Centered Design. Reading, MA : Addison-Wesley, Mayhew, D. J. (1999). The usability engineering lifecycle. San Francisco, CA. : Morgan Kaufmann Publishers, Inc. 8

9 Processus de développement centré utilisateur selon Mayhew (1999) Processus de développement centré utilisateur selon Mayhew (1999) 9

10 Processus de développement centré utilisateur selon Mayhew (1999) Quelques prémisses fondamentales d un cycle centré utilisateur 1. Les exigences, et en particulier les exigences utilisateur : peuvent difficilement être entièrement, précisément et correctement spécifiées ; il faut un une série de prototypes pour aider à mieux les circonscrire et les comprendre ; elles évoluent au long des itérations. 10

11 2. Il est essentiel de bien connaître les utilisateurs et le contexte d utilisation afin d effectuer une conception éclairée 3. On ne peut anticiper parfaitement le comportement des utilisateurs, il faut tester avec une approche empirique et faire appel à plusieurs experts pour évaluer un prototype. 1.1 Le cycle centré utilisateur ISO ISO (3) Spécifier les exigences utilisateurs et organisationnelles (4) Concevoir des solutions de conception Exigences satisfaites? (2) Comprendre et spécifier le contexte d utilisation (5) Évaluer les solutions par rapport aux exigences (1) Planification du processus centré-utilisateur L organisme de normalisation ISO a aussi défini un cycle de conception centré utilisateur, ISO (maintenant ISO :2010). Ce cycle ne couvre pas l ensemble du processus de développement, mais porte uniquement sur la spécification des exigences utilisateurs. C est probablement la phase la plus critique du cycle de développement d une application interactive puisqu elle aborde le problème de la définition et de la validation des exigences utilisateur qui, si elles sont erronnées, auront un impact majeur sur la qualité du logiciel et le débordement de l échéancier ou du budget du projet (comme c est généralement le cas pour toute exigence mal définie ou invalide). Le cycle de validation des exigences comporte cinq étapes que nous révisons ici. (1) Planification du cycle centré utilisateur Enjeux de l utilisabilité pour le projet 11

12 Impact sur les opérations Complexité (ex. flux d échanges entre utilisateurs dans l organisation) Analyse coût-bénéfice Détermine l effort qu on devrait y consacrer Ex. 1% de 50 utilisateurs 20h 40 sem 3 ans 50 $ = $ 1% de 4h = 2,5 minutes! Qui sont les utilisateurs? Utilisateurs captifs? Expérience et habileté Fréquence d utilisation La loi de la puissance de l apprentissage (T = K 1 K n 2 ) La première étape du cycle défini par ISO est celle de la planification du cycle centré utilisateur. Cette étape consiste en premier lieu à bien circonscrire les objectifs globaux du projet et à établir le lien entre ces objectifs, les exigences utilisateurs et les objectifs d utilisabilité. Une des activités potentielles de cette étape est l analyse coût-bénéfice afin de baliser le retour potentiel de facteurs d utilisabilité. Par exemple, on tentera de chiffrer combien chaque dollar investi en utilisabilité peut représenter en calculant le gain de productivité pour l ensemble des utilisateurs. Parfois, ce gain peut être très important lorsqu il y a plusieurs utilisateurs qui utilisent le logiciel durant de longues périodes. Inversement, on peut aussi découvrir que les enjeux d utilisabilité ne sont pas très grands et l on réduira la portée des efforts investis en proportion. On déterminera aussi, dans les grandes lignes, qui sont les intervenants et les principaux utilisateurs (les détails quant aux utilisateurs seront complétés à l étape suivante) et comment on les impliquera dans le projet. Les grands objectifs d utilisabilité à atteindre et les jalons qui y correspondent dans le plan de projet seront définis. Le choix du nombre d itérations, la composition de l équipe et la façon dont on fera la gestion du volet utilisabilité seront définis. (2) Contexte d utilisation Utilisateurs Expérience et habiletés, connaissances du domaine, âge et sexe, attitudes et motivations Diversité (horizontale et verticale) Tâches Fréquences Importances respectives Durées et niveau de difficulté 12

13 (3) Spécifier les exigences utilisateurs et organisationnelles (2) Comprendre et spécifier le contexte d utilisation (1) Planification du processus centré-utilisateur (4) Concevoir des solutions de conception Exigences satisfaites? (5) Évaluer les solutions par rapport aux exigences Première partie 1 CYCLES DE CONCEPTION ET DE DÉVELOPPEMENT Dépendances Environnement technique (2) Contexte d utilisation (suite) Environnement physique Bruit, chaleur, vibrations, éclairage (ex. guichets dans le rayon du soleil!) Posture, risques à la santé (normes internationales) Environnement organisationnel Pratiques, politiques d utilisation et d achats matériels, relations de pouvoir L exemple de Chernobyl révèle l importance de bien prendre en compte les pratiques Avant de définir les exigences utilisateurs, il importe de spécifier le contexte d utilisation. Quel est le profil des utilisateurs visés? Quelles tâches vont-ils effectuer avec l application et avec quelle fréquence? Quelles sont les dépendances entre les tâches et les informations qui sont nécessaires pour les effectuer? Quel est le flux d information qui s échange entre utilisateurs? Quelles sont les conditions physiques d utilisation? Etc. Le contexte d utilisation permet de cerner des informations critiques pour la définition des exigences utilisateur. (2) Méthodologies d analyse du contexte d utilisation Questionnaires, documentation Interviews Observations ethnographiques Journal de bord Analyse de tâche Il existe un bon nombre de méthodes pour aider la spécification du contexte d utilisation. Certaines sont bien connues comme les questionnaires et les interviews, d autres le sont moins et proviennes de domaines comme l ergonomie, l ethnographie et la communication. Une des techniques fondamentales est l analyse des tâches qui est très utilisée en ergonomie. Les techniques d observation, très utilisées en ethnographie, sont aussi utiles pour tirer une information sur le contexte et les tâches des utilisateurs qui ne se retrouve pas dans aucune documentation et dont même les interviews ne reflètent pas le contenu. On pense, par exemple, à des pratiques non documentées ou à des échanges qui, bien qu informels, sont des 13

14 éléments clés d échange d information pour effectuer différentes tâches. En communication et en études psycho-sociales, on utilise souvent un journal de bord pour colliger des informations sur les activités réalisées par des individus et ainsi en établir la fréquence, l horaire ou autre information qui doit être recueilli sur plusieurs jours et ne se prête pas à l observation directe et dont il est parfois difficile de se remémorer fidèlement. Maguire (2001) passe en revue plusieurs activités qui sont utiles à la définition du contexte d utilisation. Exemple d analyse de tâche Tâches pour de gestion d un magasin ( htm) (3) Exigences utilisateurs, d utilisabilité et organnisationnels Exigences utilisateurs surtout des exigences fonctionnelles qui découlent des tâches 14

15 Exigences d utilisabilité Taux de succès Nombre d erreurs Temps d exécution des tâches Rythme d apprentissage Satisfaction Les exigences changent selon les catégories d utilisateurs et le niveau d apprentissage Exigences organisationnels Processus et flux d échanges Ex. taux d appels d un centre de télémarketing ou taux de recouvrement d un service de facturation Distinguons dans un premier entre exigences utilisateurs et exigences d utilisabilité. Les premières sont notamment les exigences fonctionnelles que l on retrouve dans l interface utilisateur. Elles découlent normalement de l analyse des tâches que les utilisateurs doivent effectuer. Les exigences d utilisabilité, elles, portent sur les critères d utilisabilité qui doivent être respectés lors de l exécution de ces tâches avec les fonctions du système. Il s agit, par exemple, du taux de succès, du taux d erreurs, du temps d exécution, pour ne nommer que les principales. À noter que toutes ces exigences peuvent varier selon les catégories d utilisateurs. Cela découle du fait que différentes catégories peuvent avoir différentes tâches et les exigences fonctionnelles doivent donc nécessairement varier. De plus, les profils utilisateurs peuvent aussi varier, ce qui explique pourquoi les exigences d utilisabilité peuvent varier à leur tour. Lorsque le système s adresse à une organisation et implique plusieurs groupes de personnes, des exigences organisationnelles peuvent alors s appliquer. Par exemple, dans le cas où l on désire introduire un système de gestion des appels de clients dans un centre de soutien technique, on pourra établir une exigence quant au nombre maximal de requêtes qui ne sont pas réglées au cours du premier appel. Une telle exigence aura un impact sur la conception de l interface afin de maximiser le nombre de problèmes réglés sur le champ. (4) Solutions de design Remue-méninges Conception parallèle Scénarisation Diagrammes d affinité et tri de cartes Maquettes papier Prototypes Wizard of oz 15

16 Prototypage organisationnel Une fois un ensemble d exigence défini, le cycle ISO prescrit la définition de solutions pour satisfaire les exigences définies à l étape précédente. Lors des premières itérations, ces solutions peuvent être très embryonnaires. On peut premièrement évoquer des concepts très généraux qui serviront de base à l ébauche de maquettes. Ce sera l objectif de séance de remue-méninge. Si plusieurs concepts s avèrent intéressants, on peut même les poursuivre en parallèle jusqu à ébaucher des maquettes qui permettront, dans un second, un choix plus éclairé quant à la solution qui apparaît la plus favorable. Des maquettes papier ou des prototypes connus sous le nom de magicien d Oz permettent de tester initialement des solutions sans investir dans le prototypage fonctionnel. Elles sont très utiles dans la mesure où il est souvent utile de valider très tôt des pistes de solutions et de valider des exigences, plutôt que de le faire après un effort de développement plus lourd. Comme on le mentionnait plus haut, les utilisateurs ont généralement de la difficulté à imaginer une solution logicielle et c est en leur présentant des maquettes concrètes qu ils peuvent alors se faire une idée plus précise de ce dont ils ont réellement besoin et de ce que le concepteur a réellement en tête! Dans des projets de plus grande envergure et qui peuvent impacter un grand nombre d employés dans une entreprise, on ira jusqu à déployer un prototype d application dans une partie de l entreprise afin de valider la solution envisagée. Cette approche est préconisée lorsque l introduction d une application comporte un risque de perturber les opérations critiques de l entreprise. (5) Évaluations Évaluation participative Évaluation heuristique Tests utilisateur contrôlés Questionnaires de satisfaction Inspections cognitives Incidents critiques Feedback suite à un test ou une utilisation prolongée Statistiques d utilisation (ex. Web) Les solutions avancées doivent être validées afin de déterminer si elles satisfont aux exigences spécifiées. Il existe plusieurs techniques dont l utilité varie selon le type d application est le stade d avancement. Nous les mentionnons simplement ici et les reverrons dans la partie dédiée à l évaluation (??). 16

17 Survol des méthodes *source : Le tableau du syte fournit une liste de méthodes et activités recomandés pour le développement centré utilisateur. Ces activités sont organisées en fonction des différentes phases. Exemple Le baladeur Sanyo revu et corrigé Supposons que l on a effectué le processus ISO pour déterminer les exigences utilisateur du baladeur Sanyo. Identification des enjeux d utilisabilité quant aux objectifs et au contexte d affaires ; on le fera entre autres avec les gens du marketing et de la conception matérielle et logicielle Analyse des produits concurrents Sondage auprès de 100 consommateurs (échantillonnage selon des utilisateurs cibles, p. ex. 4 25) Interviews de 20 utilisateurs Définition de principes généraux de design et conception de quelques prototypes d interfaces, par ex. : définir le contexte d utilisation faire une ou plusieurs maquettes et effectuer une évaluation heuristique et une inspection cognitive des maquettes de chacune (concepts qui seront vus dans la partie évaluation) itérer sur la base de ces évaluations Prenons l exemple du baladeur Sanyo vu dans la première partie pour illustrer quelle forme le processus ISO pourrait prendre. Premièrement, il faut établir le rôle que l utilisabilité jouera dans le produit. Curieusement, si l on s en fie à mon comportement de consommateur, on en conclurait que ce rôle est minime par rapport au prix! J ai acheté cet appareil sans préoccupation pour son utilisabilité, simplement sur la base qu il offrait aussi la lecture de fichier MP3 et qu il était bon marché. Mais mon comportement ne s arrête pas là. Je suis maintenant plus craintif par 17

18 rapport à la marque Sanyo et j en ai une image d entreprise qui ne se soucie pas de ce qu on nomme la qualité totale, ce que l on peut associer à la qualité qui apparaît après que l on s est procuré le produit! J y pense maintenant deux fois avant d acheter la marque Sanyo. De cette analyse tout à fait informelle et subjective, il est difficile de dériver, par exemple, quel est le budget et le niveau d utilisabilité qu on devrait viser avec le baladeur, mais disons simplement que ça vaut au moins quelques jours de travail et qu il faut pouvoir effectuer les tâches essentielles sans manuel utilisateur, comme celle de passer à l album suivant pour un utilisateur normal! Une fois le rôle de l utilisabilité circonscrit dans le cadre du projet (nous sautons les étapes ici car la spécification de ce rôle nécessiterait à lui seul quelques pages), on établit une première version des exigences utilisateurs et organisationnelles. Comme l appareil s adresse à un usage individuel et qu il est relativement indépendant d autres produits de l entreprise d une perspective d utilisation (contrairement au ipod, par exemple, dont on vise à lier l utilisation au site de vente en ligne de musique/vidéo de Apple), alors on peut ignorer les exigences organisationnelles pour cet exemple. Un certain nombre d activités peuvent être entreprises pour faciliter la spécification des exigences. La plus simple et probablement la plus efficace est celle d analyser les produits concurrents lorsqu ils existent. Lorsqu ils n existent pas et lorsqu on veut offrir un produit original qui se distingue des autres par son originalité et une interface mieux adaptée aux besoins, d autres activités sont indiquées. Si on possède peu ou pas d information quant aux profils utilisateur, on effectuera un sondage en prenant soin de le distribuer à tous les types d utilisateurs. Le taux de réponse aux sondages peut varier considérablement et le nombre de réponses que l on espère recevoir doit donc être déterminé en conséquence. Le sondage est une activité qui permet surtout d obtenir des données quantitatives quant aux profils socioéconomique, aux attentes et préférences, aux tâches et aux types d utilisation auxquelles on peut s attendre des utilisateurs. Les questions ouvertes, où les gens inscrivent un texte ou des termes selon leur choix, se prêtent mal à une compilation avec un grand nombre de répondants. Ils sont donc peu indiqués pour un sondage auprès de plusieurs personnes. Pour le baladeur Sanyo, on voudra savoir, par exemple, qui en possède déjà un, à quelle fréquence ils l utilisent, qui a un ordinateur avec de la musique MP3, la fourchette de prix qu ils s attendent à débourser, etc. Pour aller plus loin et obtenir des réponses plus ouvertes, on procèdera avec un interview. Les interviews permettent entre autres d obtenir des informations qui sont difficiles à obtenir par un sondage. On pourra poser des questions du style qu elle est la raison pour laquelle vous n avez pas de lecteur MP3?, avez-vous de la difficulté à créer des CD audio et numériques? Quel est le principal problème que vous rencontrez?. Bref, toute information de nature difficilement quantifiable et ouverte se prête à l utilisation de sondage pour les obtenir. L analyse des tâches courantes à effectuer avec un baladeur nécessite, elle aussi, des activités spécifiques. Les interviews peuvent en indiquer plusieurs, mais certaines tâches 18

19 Première partie 2 EXIGENCES UTILISATEUR peuvent être difficile à identifier de cette manière et ont de meilleures chances d être trouvées par une observation de comment les individus gèrent leurs CD musicaux audio et leurs fichiers MP3, et comment ils les écoutent sur différents appareils. Cette analyse aurait certainement dû permettre d identifier les besoins les plus évidents comme celui d avoir des boutons album avant et album arrière (en présumant que l analyse des produits concurrents ne l ait pas déjà relevé). Les exigences doivent être validées. Ce n est pas parce que 98% les répondants d un sondage disent répondent positivement à une question comme aimeriez-vous pouvoir effectuer une recherche dans vos fichiers MP3? que l on doit accorder une grande importance à l exigence d implanter la fonction correspondante! Il faut que les utilisateurs puissent bien comprendre à quoi peut correspondre une exigence en pratique et qu ils puissent faire l expérience de l utilisation du produit afin de se faire une meilleure idée des fonctions qu ils désireraient vraiment avoir. Pour valider les exigences, l analyse du contexte d utilisation fournit souvent des données auxquelles il faut référer. Si, par exemple, seulement 5% des répondants au sondage affirment connaître ce qu est un fichier MP3 (on se rapporte en environ) et qu encore moins d entre eux ont de tels fichiers sur leur ordinateur, les exigences autour des fichiers numériques deviennent moins prioritaires 6. Mais au-delà de ce qu on peut obtenir de l analyse du contexte d utilisation et de la tâche, il importe de valider les exigences en les soumettant à une mise en oeuvre concrête dans une maquette d interface. La maquette peut n être qu une série d écrans simulés et plus ou moins fonctionnels, ou même une série de dessins sur du papier. L important est de fournir à l utilisateur une représentation concrète de ce qu on envisage implanter pour satisfaire les exigences utilisateur. Dans le cas du Sanyo, il est évident qu une simple maquette papier, où l on aura demandé à deux ou trois personnes les tâches courantes, aurait mis en évidence que la fonction de recherche d une chanson par mots-clés était beaucoup trop complexe pour être utilisée dans le contexte normal d utilisation du baladeur. 2 Exigences utilisateur Comme mentionné, les erreurs au niveau des exigences s avèrent les plus coûteuses, surtout lorsqu on les découvre tard dans le cycle de développement. Les exigences utilisateurs n échappent pas à cette règle. On peut même dire qu elles sont peut-être les plus susceptibles d être sujettes à erreur, car, par exemple, les utilisateurs n ont pas une idée claire de ce qu ils veulent, et aussi les plus susceptibles d être découvertes au moment de la dernière phase du 6. C est évidemment bien différent si le produit vise à se différencier de la concurrence et s adresse spécifiquement à ce faible pourcentage de la population qui tient à l utilisation de baladeur pour fichiers MP3. 19

20 Première partie 2 EXIGENCES UTILISATEUR cycle, le déploiement, puisque c est à ce moment que les utilisateurs font l expérience concrète de l application est expriment leurs véritables besoins! Tout développeur expérimenté a vécu une expérience où l utilisateur client reviens sur une fonctionnalité du système qui n est pas tout à fait ce qu il voulait dire et qu en réalité c est d une autre façon qu il faudrait implanter la fonctionnalité en question... sans oublier qu il lui faudrait aussi telles et telles autres fonctionnalités! Nous complétons donc la partie des processus avec quelques remarques supplémentaires quant aux exigences utilisateur. 2.1 Élaboration et validation Exigences utilisateur et exigences d utilisabilité Exigences utilisateur fonctionnalité profil, compétences, préférences toute autre exigence qui touche directement les utilisateurs Exigences d utilisabilité temps d exécution d une tâche, taux d erreurs, temps d apprentissage, etc., selon des profils utilisateur spécifiques, bien entendu! déterminées en fonction du contexte d utilisation, d applications concurrentes, ou d objectifs corporatifs. Nous ouvrons une parenthèse sur la distinction entre exigences utilisateur et exigences d utilisabilité, qui sont très différentes l une de l autre. La définition des exigences utilisateur n est pas universelle. Nous définirons les exigences utilisateurs comme les exigences qui ont un impact direct sur les utilisateurs ou les exigences qui émanent des utilisateurs. Ceci inclut en général toutes les exigences fonctionnelles d une application interactive qui se retrouve dans l interface. On inclut aussi les profils des utilisateurs anticipés, à savoir leur expérience avec l application, les ordinateurs en général et avec le domaine d application, qui sont des facteurs qui influencent grandement la conception de l interface. Les exigences d utilisabilité portent, quant à elles, uniquement sur des facteurs d utilisabilité. On peut par exemple référer au temps moyen d exécution d une tâche avec l interface. Pour opérationnaliser cette exigence, on référera à un temps moyen d exécution pour un échantillon de n utilisateurs avec un profil de compétences donné, tel que mesuré par x tests utilisateur. Dans des cas extrêmes, on pourrait même spécifier des écarts types auxquels on s attend. 20

21 Première partie 2 EXIGENCES UTILISATEUR Toute mesure d utilisabilité est susceptible d être utilisée pour spécifier une exigence d utilisabilité. Ces exigences se définissent en général par rapport à des tâches que l on peut effectuer avec l application. À propos des utilisateurs L utilisateur moyen n existe pas Les utilisateurs ne sont pas des concepteurs Ils ont de la difficulté à se représenter le système à partir de spécifications techniques Ils sont très bons pour réagir à des propositions concrètes : Schémas, papier, maquettes, prototypes Ils ne connaissent pas les possibilités offertes par la technologie Ils ne savent pas nécessairement ce qu ils veulent, ni ce dont ils ont besoin Ils ont une connaissance qui évolue avec l usage du système Ils pensent en termes de logique d utilisation alors que les concepteurs ont une logique de fonctionnement du système Problèmes fréquents avec les exigences utilisateur Selon McConnel (Rapid Development), les utilisateurs : ne comprennent pas ce qu ils veulent refusent de se commettre sur des exigences écrites et fixes insistent pour de nouvelles exigences une fois le budget et l échéancier déterminés ne participent pas à des séances de révision ou sont incapable de contribuer de façon productive et efficace ne sont pas suffisamment outillés techniquement ne comprennent pas le processus de développement et, de plus, la communication avec eux est fastidieuse. Les problèmes avec les exigences utilisateur relevés ci-dessus par McConnel sont relativement universels et tout développeur d expérience pourra en attester. Ces problèmes sont à la source de la volatilité des exigences utilisateurs, volatilité est à son tour la source de dépassement de budget et d échéancier de projet de développement de logiciels intéractifs. L élaboration des exigences 21

22 Première partie 2 EXIGENCES UTILISATEUR Protypage des spécifications floues les utilisateurs comprennent mieux leurs propres besoins lorsqu ils sont confrontés avec une représentation concrète de l interface Utilisation de scénarios pour éliciter les spécifications à l instar des utilisateurs, les concepteurs imaginent mieux les besoins lorsqu ils sont confrontés à un scénario spécifique d utilisation Il existe, heureusement, bon nombre de principes et d approches pour aider à élaborer et valider les exigences utilisateurs. En anglais, on réfère au problème d élaboration des exigences utilisateur par le terme elicitation. Cette notion réfère à l art de soutirer les véritables besoins utilisateur, ces besoins qu il n exprime jamais clairement lorsqu on lui pose simplement la question de quelles fonctionnalités il a besoin! Une des approches les plus efficaces est celle de fournir aux utilisateurs prospectifs un prototype semi-fonctionnel de l application. Pensons par exemple aux premiers tableurs. Il serait très difficile pour un comptable des années 1970 d imaginer les fonctions d un tableur et d exprimer que c est bien ce qu il veut. À moins qu il soit un véritable visionnaire, il est fort peu probable qu il exprime ce besoin spontanément! Puis, une description verbale des fonctions de tableur pourrait lui sembler totalement abstraite. Par contre, il est fort probable qu un prototype semi-fonctionnel évoque immédiatement le besoin d une telle application! Il imaginera alors ce à quoi pourrait ressembler son travail pour telle ou telle autre tâche, ce qui en retour fournira le concepteur logiciel des informations supplémentaires pour élaborer les fonctions à développer. À l inverse, si on se reporte maintenant en 2000 et qu on demande à un utilisateur s il désire accéder au Web à partir de son téléphone, la réponse sera certainement un oui convaincu. Puis, si on lui donne un de ces téléphones de 32 pixels par 24 pixels pour visualiser une page Web et qu on lui demande si c est bien ce qu il voulait, sa réponse peut facilement être anticipée, surtout si on complète l expérience en lui demandant de consulter ses courriels ou les cotes de la bourse sur le site finance.yahoo.com... Il ne réussira pas à compléter efficacement aucune de ces tâches à cause de l écran trop petit. Pourtant, une série de téléphones avec ce type d accès Web ont vu le jour autour de ces années! De là on peut en tirer l importance de prototyper ce qu on envisage comme application et d obtenir un retour d information de la part d utilisateurs quant à l utilité et aux améliorations de la solution prototypée. En outre, le prototype est une excellente forme de spécification logicelle. Bien que assez peu acceptés dans les milieux académiques et dans les processus de génie logiciel répandus (à l exception peut-être des processus dits agiles), les prototypes peuvent néanmoins représenter une forme de spécification précise de l interactivité et de l affichage d une interface utilisateur qui s avère souvent bien plus utile que des descriptions verbales ou schématiques. 22

23 Première partie 2 EXIGENCES UTILISATEUR Outre les prototypes, des scénarios où l on décrit un contexte précis d un utilisateur qui interagit avec l application. Par exemple, Greg Cooper a introduit la notion de personna qui représente un utilisateur et incarne une personnalité et un profil spécifique. L utilisation d un contexte très spécifique permet au concepteur de mieux envisager les besoins et exigences utilisateurs, à l instar de l utilisateur qui envisage mieux les fonctionnalités qu il désire lorsqu il se trouve devant une représentation concrète de l interface de l application. La validation des exigences Coordonner des inspections formelles des spécifications Recours à des équipes interdisciplinaires Définir des listes de validation ( checklist ) Valider la conformité des spécifications aux normes Recours au prototypage pour améliorer les spécifications Écriture d une esquisse du manuel de l utilisateur Élaboration d une batterie de tests utilisateur Paraphrasage des modèles systèmes Une fois le processus d élicitation effectué, différentes activités peuvent être mises en oeuvre pour valider si les exigences utilisateurs obtenues sont adéquates. Les inspections, ou revues, des exigences par les intervenants sont une étape incontournable du processus de validation. Cette étape est, en fait, souvent prescrite par les processus de gestion de projet qui exigent que les utilisateurs, le client, le chef de projet et certains autres intervenants acceptent les spécifications telles que décrites. 2.2 Exigences d utilisabilité Les spécifications propres à l utilisabilité Efficacité et efficience Temps, nb. d actions, ratio de tâches réussies, erreurs Facilité d apprentissage Temps, ratio de tâches réussies, erreurs Flexibilité Méthodes alternatives, adaptation à d autres contextes Attitude 23

24 Première partie 2 EXIGENCES UTILISATEUR Questionnaire qualitatif, commentaires Différences individuelles Variance par rapport à différents critères Les critères d évaluation propres à l utilisabilité Temps pour accomplir une tâche Pourcentage des tâches réussies Taux d erreur Temps de récupération des erreurs Commentaires positifs/négatifs des utilisateurs Évaluation du domaine Les exigences d utilisabilité se définissent selon un ensemble de critères propres à l utilisabilité. Ces critères sont listés ci-dessus. Ils se définissent selon l ensemble des tâches que l on doit effectuer avec l application et peuvent aussi être pondérés tout comme les tâches peuvent l être. On peut déterminer les exigences quant à l utilisabilité en se basant sur différentes approches, par exemple : les applications concurrentes : en particulier lorsque le produit est en vente libre ; les objectifs d affaires : lorsque l entreprise paye pour un développement et vise un gain de productivité ; un calcul coûts-bénéfices permettra de fixer des objectifs de temps d exécution, par exemple ; les contraintes de sécurité : pour les systèmes critiques comparaison avec d autres versions : permet de valider si l utilisabilité s améliore ou non. Exercice Émilie de Bell 24