IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Gestion de projet Discussion :

Spécifications fonctionnelles vs manuel utilisateur


Sujet :

Gestion de projet

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 12
    Points : 7
    Points
    7
    Par défaut Spécifications fonctionnelles vs manuel utilisateur
    Un manuel utilisateur peut-il être considéré comme un document de spécifications fonctionnelles ?

    Indépendamment de la réponse, est-il possible ou souhaitable de baser les efforts de développement sur le manuel utilisateur du futur logiciel ?

  2. #2
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Kaeru No Uta Voir le message
    Un manuel utilisateur peut-il être considéré comme un document de spécifications fonctionnelles ?
    Pourquoi pas ?

    C'est une bonne base..

    En tous cas en ce qui concerne la fonctionalité DEMANDEE.. ainsi que son arborescence..



    Citation Envoyé par Kaeru No Uta Voir le message
    Indépendamment de la réponse, est-il possible ou souhaitable de baser les efforts de développement sur le manuel utilisateur du futur logiciel ?
    Absolument...

    Cependant, un travail nécessaire et préparatoire à l'utilisation en terme de développement est un examen approfondi avec l'équipe technique afin d'y identifier et rajouter les détails / fonctionalités logicielles nécessaires et SOUS-JACENTES (c'est à dire non visibles par l'utilisateur).

    Par exemple, tu as une fenêtre avec un bouton "recherche". Il faut explorer ce que sous-tend cette fonctionalité, et en déduire la spécification éventuelle (multi-bases, multi-sites, etc etc).

    Mais effectivement le Manuel Utilisateur devrait fournir le squelette de l'arborescence fonctionelle, ainsi que (si il est bien fait et que chaque fenêtre et action y est détaillée) l'ensemble des paramètres et possibilités pour chaque fonctionalité, et donc est une bonne Spécification Fonctionnelle (aux suppléments cités ci-dessus près)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    mars 2007
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 288
    Points : 412
    Points
    412
    Par défaut
    Citation Envoyé par Kaeru No Uta Voir le message
    Un manuel utilisateur peut-il être considéré comme un document de spécifications fonctionnelles ?

    Indépendamment de la réponse, est-il possible ou souhaitable de baser les efforts de développement sur le manuel utilisateur du futur logiciel ?
    Bof, en tout cas pas en agile...
    cf http://agilemanifesto.org/
    "Working software over comprehensive documentation"

  4. #4
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    quel est le rapport ?


    Justement il ne parle pas de "documentation exhaustive", ce que serait une Spec Fonctionnelle du style cycle en V..


    Je crois que manifestement tu n'as pas saisi ni ce qu'il demandait ni ce à quoi se réfère le Manifeste...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  5. #5
    Membre averti
    Profil pro
    Inscrit en
    mars 2007
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 288
    Points : 412
    Points
    412
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    quel est le rapport ?


    Justement il ne parle pas de "documentation exhaustive", ce que serait une Spec Fonctionnelle du style cycle en V..


    Je crois que manifestement tu n'as pas saisi ni ce qu'il demandait ni ce à quoi se réfère le Manifeste...
    Pour moi le manuel utilisateur est une documentation détaillée du fonctionnement de l'application du point de vue utilisateur, non?

  6. #6
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    lol

    As-tu déjà vu des docs de gros softs en cycle en V, celles qui sont décrites dans :

    "Working software over comprehensive documentation"

    Il y a au moins 10 000 pages, de la Spécification Système à la Spécification Fonctionelle, puis le Document de Conception Préliminaire, le Document de Conception Détaillée, le Document de Test Unitaires, le Document de Tests Système, le Dictionnaire des Mots, etc etc...

    C'est cela que veut recouvrir le terme "comprehensive documentation".

    Lis juste http://fr.wikipedia.org/wiki/Cycle_en_V et tu commnceras juste à avoir une (toute) petite idée de ce qu'on appelle "documentation exhaustive".



    D'une part le Manuel Utilsateur est nécessaire (c'est cela que l'utilisateur aura, et il FAUT le produire), mais de plus il doit contenir tout ce qui est nécessaire pour faire tourner le soft.

    Cela peut donc être une excellente base , et c'est la documentation MINIMUM...
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  7. #7
    Membre averti
    Profil pro
    Inscrit en
    mars 2007
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 288
    Points : 412
    Points
    412
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Cela peut donc être une excellente base , et c'est la documentation MINIMUM...
    Je ne remet pas en cause ni l'intérêt, ni la nécessité du manuel utilisateur.

    Cependant, écrire le manuel utilisateur avant le développement c'est ni plus ni moins tirer un trait sur tous les changements qui peuvent intervenir durant les développements ou alors perdre son temps à revenir dessus au fur et à mesure des "aléas". Où est l'agilité?

  8. #8
    Futur Membre du Club
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 12
    Points : 7
    Points
    7
    Par défaut
    Merci pour ces réponses. Je pense comprendre l'explication de souviron34.

    Citation Envoyé par montesq Voir le message
    Je ne remet pas en cause ni l'intérêt, ni la nécessité du manuel utilisateur.

    Cependant, écrire le manuel utilisateur avant le développement c'est ni plus ni moins tirer un trait sur tous les changements qui peuvent intervenir durant les développements ou alors perdre son temps à revenir dessus au fur et à mesure des "aléas". Où est l'agilité?
    Si on attend qu'il n'y ait plus de changements dans les besoins avant de rédiger le manuel, il me semble que c'est sur le manuel qu'il faut tirer un trait.

    Lorsqu'un changement intervient, le manuel est mis à jour (puisqu'il faut le faire tôt ou tard, pourquoi pas tôt ?) puis l'équipe technique effectue le travail nécessaire. Où n'est pas l'agilité ?

  9. #9
    Membre confirmé
    Avatar de Mindiell
    Profil pro
    Inscrit en
    juin 2006
    Messages
    735
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 735
    Points : 544
    Points
    544
    Par défaut
    D'accord avec souviron34 et Kaeru, mais comme montesq j'avoue que c'est un peu bizarre d'avoir un manuel utilisateur avant un logiciel (je vois le manuel avec des parties bien séparées et tout et des screen-shots moi).

    Cependant, si un tel manuel existe (modification de soft par exemple, ou même portage (langage, plateforme)) je trouve alors qu'il faut en effet l'utiliser comme base de développement.
    Mindiell
    "Souvent, femme barrit" - Elephant man

  10. #10
    Membre averti
    Profil pro
    Inscrit en
    mars 2007
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 288
    Points : 412
    Points
    412
    Par défaut
    Citation Envoyé par Kaeru No Uta Voir le message
    Si on attend qu'il n'y ait plus de changements dans les besoins avant de rédiger le manuel, il me semble que c'est sur le manuel qu'il faut tirer un trait.

    Lorsqu'un changement intervient, le manuel est mis à jour (puisqu'il faut le faire tôt ou tard, pourquoi pas tôt ?) puis l'équipe technique effectue le travail nécessaire. Où n'est pas l'agilité ?
    Pour moi le manuel utilisateur est un document formel qui doit être livré à la fin de la release une fois que le produit est (quasi) stable (pour la release).
    Si tu fais ton manuel avant les dévs et que tu le modifies au fur et à mesure, c'est juste une perte de temps et d'énergie.

    De plus, il ne faut pas oublier à quelle population chacun des documents doit s'adresser!
    Le manuel utilisateur -> aux utilisateurs (pour expliquer comment utiliser l'application dans le cadre de son utilisation)
    Les "spécifications" -> à l'équipe de développement (pour expliquer les fonctionnalités attendues du produit).
    Quand bien même la lecture du manuel utilisateur donnera une meilleure visibilité sur le produit aux développeurs, il n'empêche que les 2 populations n'attendent pas le même niveau d'information/langage, ni la même organisation dans sa rédaction.

    Imaginons : comment vas-tu procéder si tu veux enrichir la description d'une fonctionnalité suite à une discussion avec le métier et/ou l'équipe de dév :
    - tu vas ajouter un commentaire dans le manuel? -> non car l'utilisateur n'a probablement pas besoin de ces détails
    - tu vas créer une autre doc en demandant de te référer à la section x.x.x du manuel utilisateur pour connaître le contexte? -> pas très pratique :/

    Par ailleurs, il peut y avoir plusieurs types d'utilisateurs et donc plusieurs manuels adaptés aux activités de chacun avec des choses redondantes, etc. Faudra-t'il demandé aux développeurs de faire la glu entre tout ça?

    Pourquoi ne pas vouloir utiliser des artefacts tels que les "user stories" qui sont reconnus par un certain nombre d'acteurs agiles?

  11. #11
    Futur Membre du Club
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 12
    Points : 7
    Points
    7
    Par défaut
    Citation Envoyé par Mindiell
    D'accord avec souviron34 et Kaeru, mais comme montesq j'avoue que c'est un peu bizarre d'avoir un manuel utilisateur avant un logiciel (je vois le manuel avec des parties bien séparées et tout et des screen-shots moi).
    Les screenshots sont faits sur des prototypes d'interface dont le seul rôle est de fournir des screenshots avant que le logiciel soit suffisamment avancé pour le permettre.

    Parmi les informations présentes dans un manuel utilisateur, je m'attends à trouver :
    1. une description fonctionnelle de l'interface (eg : que fait ce bouton ? à quoi sert cette zone de texte ?)
    2. des remarques sur le comportement du logiciel (eg : que se passe-t-il si l'utilisateur clique sur la croix sans avoir sauvé son travail ?)
    3. des sections "How To" / tutoriels (eg : comment effectuer telle tâche ?)


    Les "user stories" sont utilisables pour les points b et c, soit directement, soit sous forme de questions auxquelles le manuel fournit une réponse.

    Comme tu le fais remarquer (et souviron34 l'a signalé aussi) le manuel utilisateur seul n'est pas suffisant, c'est un squelette.

    Je voudrais voir les spécifications fonctionnelles comme un sur-ensemble du manuel utilisateur (ce qui est possible si le manuel est un document de spécifications fonctionnelles, cf ma première question).

    J'ai pensé à faire un 2eme document, mais c'est vrai que c'est peu pratique.

    Une alternative est d'avoir un manuel utilisateur "annoté", sachant que les annotations n'apparaîtront pas dans les releases.

    Citation Envoyé par montesq
    Par ailleurs, il peut y avoir plusieurs types d'utilisateurs et donc plusieurs manuels adaptés aux activités de chacun avec des choses redondantes, etc.
    J'ai pensé à la traduction, mais pas à la possibilité de plusieurs manuels différents. Aurais-tu un exemple ?

    Citation Envoyé par montesq
    Si tu fais ton manuel avant les dévs et que tu le modifies au fur et à mesure, c'est juste une perte de temps et d'énergie.
    J'ai peut-être juste été malchanceux, mais j'ai eu des expériences inconfortables avec le manuel fait après-coup (pas tout à fait complet, pas tout à fait à jour...).

    Le manuel utilisé comme je le propose est une partie des spécifications. Il n'y a pas de redondance, pas de parties manquantes, et le risque de désynchronisation avec le produit est (idéalement) nul. À quel niveau se situe la perte de temps ?

  12. #12
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par montesq Voir le message
    Je ne remet pas en cause ni l'intérêt, ni la nécessité du manuel utilisateur.

    Cependant, écrire le manuel utilisateur avant le développement c'est ni plus ni moins tirer un trait sur tous les changements qui peuvent intervenir durant les développements ou alors perdre son temps à revenir dessus au fur et à mesure des "aléas". Où est l'agilité?[/

    Citation Envoyé par Mindiell Voir le message
    mais comme montesq j'avoue que c'est un peu bizarre d'avoir un manuel utilisateur avant un logiciel (je vois le manuel avec des parties bien séparées et tout et des screen-shots moi).
    Citation Envoyé par montesq Voir le message
    Pour moi le manuel utilisateur est un document formel qui doit être livré à la fin de la release une fois que le produit est (quasi) stable (pour la release).
    Si tu fais ton manuel avant les dévs et que tu le modifies au fur et à mesure, c'est juste une perte de temps et d'énergie.

    De plus, il ne faut pas oublier à quelle population chacun des documents doit s'adresser!
    Le manuel utilisateur -> aux utilisateurs (pour expliquer comment utiliser l'application dans le cadre de son utilisation)
    Les "spécifications" -> à l'équipe de développement (pour expliquer les fonctionnalités attendues du produit).
    Quand bien même la lecture du manuel utilisateur donnera une meilleure visibilité sur le produit aux développeurs, il n'empêche que les 2 populations n'attendent pas le même niveau d'information/langage, ni la même organisation dans sa rédaction.

    Imaginons : comment vas-tu procéder si tu veux enrichir la description d'une fonctionnalité suite à une discussion avec le métier et/ou l'équipe de dév :
    - tu vas ajouter un commentaire dans le manuel? -> non car l'utilisateur n'a probablement pas besoin de ces détails
    - tu vas créer une autre doc en demandant de te référer à la section x.x.x du manuel utilisateur pour connaître le contexte? -> pas très pratique :/

    Par ailleurs, il peut y avoir plusieurs types d'utilisateurs et donc plusieurs manuels adaptés aux activités de chacun avec des choses redondantes, etc. Faudra-t'il demandé aux développeurs de faire la glu entre tout ça?

    Pourquoi ne pas vouloir utiliser des artefacts tels que les "user stories" qui sont reconnus par un certain nombre d'acteurs agiles?
    Je crois que vous n'avez pas compris du tout (mais ce n'est pas facilité par la plupart des "présentations" des "démarches" agiles), ce en quoi repose cette fameuse "démarche".


    Comme il est dit ici :

    Citation Envoyé par Kaeru No Uta Voir le message
    Lorsqu'un changement intervient, le manuel est mis à jour (puisqu'il faut le faire tôt ou tard, pourquoi pas tôt ?) puis l'équipe technique effectue le travail nécessaire. Où n'est pas l'agilité ?

    Le principe de base de l'agilité est (malgré le non-usage de ce terme dans les "méthodologies" en vogue), une approche ergonomique et qui en anglais se dénomme "USER-CENTERED".

    Les notions de story-board, de "user-stories", de prototypes, et de cycles rapides, sont toutes liées à cette notion centrale.

    Or la meilleure manière de passer d'un story-board ou d'un prototype à un document papier utilisable par une équipe technique est justement de fournir la succession des écrans et des actions, ce qui se passe lorsqu'on écrit un story-boad ou que l'on utilise un outil de fabrication de "mockups".


    Et ceci est la base de ce qui sera dans le manuel utilisateur.


    Par conséquent (mais comme dans toute l'approche, rien n'est coulé dans le béton une fois pour toutes, et par conséquent il y aura des révisions), un document de travail correct pour l'équipe informatique est le Manuel Utilsateur, qui, contrairement à ce que tu penses, montesq, est, sous une forme ou une autre, le départ de la démarche agile. Comme je l'ai dit plus haut, une approche centrée sur l'utilisateur utilise soit un prototype, soit un mockup. Une fois que ceci est validé et mis au point conjointement aec les utilisateurs, l'équipe informatique a besoin d'une base pour travailler.

    Une copie des écrans et des actions successives, avec des flèches renvoyant d'un bouton à une fenêtre etc etc, nécessite un peu plus d'explications. C'est ce qu'il y aura dans le Manuel Utilisateur. C'est ce qui donnera l'architecture fonctionnelle du logiciel.

    Maintenant, ce n'est pas suffisant pour l'équipe informatique, comme dit plus haut. Mias c'est une base plus que correcte, car elle détermine l'aborescence fontionnelle.




    Ce que tu exposes ("Imaginons : comment vas-tu procéder si tu veux enrichir la description d'une fonctionnalité suite à une discussion avec le métier et/ou l'équipe de dév") est justement l'approche traditionnelle, où les documents nécessaires à l'informatique sont découplés de ceux des utilisateurs, et c'est justement tout le contraire de l'approche user-centered.

    L'évolution d'une fonctionalité est déterminée par l'utilisation du prototype ou du mockup, et, comme mentionné ci-dessus, la production de la description de cette modification est beaucoup plus directe en passant par les copies d'écran et un Manuel Utilsateur enrichi que dans l'autre sens.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  13. #13
    Membre confirmé
    Avatar de Mindiell
    Profil pro
    Inscrit en
    juin 2006
    Messages
    735
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 735
    Points : 544
    Points
    544
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    Et ceci est la base de ce qui sera dans le manuel utilisateur.
    On est d'accord, la seule différence que je voyais c'est que je n'aurais pas appeler le premier document "manuel utilisateur", mais je suis d'accord sur le fait que cette base évoluera et finira en tant que manuel utilisateur, constamment mis à jour pendant les évolutions.
    Mindiell
    "Souvent, femme barrit" - Elephant man

  14. #14
    Futur Membre du Club
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 12
    Points : 7
    Points
    7
    Par défaut
    Citation Envoyé par Mindiell Voir le message
    On est d'accord, la seule différence que je voyais c'est que je n'aurais pas appeler le premier document "manuel utilisateur"
    Quel autre nom donnes-tu à un document qui décrit un logiciel et son opération du point de vue de l'utilisateur ?

  15. #15
    Membre confirmé
    Avatar de Mindiell
    Profil pro
    Inscrit en
    juin 2006
    Messages
    735
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 735
    Points : 544
    Points
    544
    Par défaut
    Euh...

    Je ne sais pas quel nom je lui donnerais, j'avoue que j'aurais tendance à appeler ca un "brouillon", un "cahier des charges", une "liste des spécifications", etc..., voire "manuel utilisateur".

    Mindiell
    "Souvent, femme barrit" - Elephant man

  16. #16
    Futur Membre du Club
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    12
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : janvier 2010
    Messages : 12
    Points : 7
    Points
    7
    Par défaut
    Merci pour tous ces avis.

    J'en conclus :
    • un manuel utilisateur est un document de spécifications fonctionnelles ;
    • il est possible et même souhaitable de baser les efforts de développement sur le manuel ; dans ce cas, il doit être mis à jour immédiatement lors de chaque changement, et annoté (les annotations ne figurant pas dans le document délivré à l'utilisateur) pour que l'équipe technique puisse faire son travail.

  17. #17
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par Kaeru No Uta Voir le message
    • un manuel utilisateur est un document de spécifications fonctionnelles ;
    NON...


    Le Manuel Utilisateur est une bonne base



    Le français est une langue précise...

    Les termes ont une signification.

    Comme je l'ai dit dans mon premier post, il demande à être approfondi, fouillé, pour être assimilé à une spec.

    Il devrait cependant être le document de référence dans une approche User-Centered..



    Citation Envoyé par Kaeru No Uta Voir le message
    • il est possible et même souhaitable de baser les efforts de développement sur le manuel ; dans ce cas, il doit être mis à jour immédiatement lors de chaque changement, et annoté (les annotations ne figurant pas dans le document délivré à l'utilisateur) pour que l'équipe technique puisse faire son travail.
    C'est exact, encore une fois dans une approche centrée sur l'utilisateur.

    Dans tous les cas, il est possible de baser les efforts de développement dessus.


    Dans une approche centrée sur l'utilisateur, et donc dans l'approche à l'origine de la démarche agile, c'est souhaitable.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  18. #18
    Membre averti
    Profil pro
    Inscrit en
    mars 2007
    Messages
    288
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : mars 2007
    Messages : 288
    Points : 412
    Points
    412
    Par défaut
    Citation Envoyé par souviron34 Voir le message
    NON...


    Le Manuel Utilisateur est une bonne base
    Tu vois souviron34 tu n'es pas clair...

    Donc pour toi il faut maintenir les 2 documents à jours en parallèle (le manuel utilisateur et les spécifications)
    (Personnellement, j'ai déjà du mal à maintenir 1 doc à jour alors 2...)

    Pour moi (que l'on soit user centered ou pas) il ne doit y avoir qu'UN document de spécification (qui inclut les maquettes, les scénarios, les uses cases ou autres stories). Ce document doit être mis à jour en fonction de l'évolution des besoins et de la précision que l'on souhaite y apporter (on part d'un besoin macro et on affine de + en + au fur et à mesure).
    Une fois la release livrée, on doit fournir un manuel utilisateur en copiant/collant les parties de la spécification qui sont adaptées et en les organisant pour permettre une présentation adaptée à chaque type d'utilisateur de l'application (administrateurs, clients, back-office...)

    Encore une fois, ton incompréhension de nos interventions vient principalement d'un problème de vocabulaire justement. Ce que tu appelles "manuel utilisateur" (avant rédaction des spécs) est simplement pour moi la première forme de spécifications fonctionnelles...

  19. #19
    Membre confirmé
    Avatar de Mindiell
    Profil pro
    Inscrit en
    juin 2006
    Messages
    735
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 735
    Points : 544
    Points
    544
    Par défaut
    De ce que j'ai compris moi de l'intervention de souviron, c'est que le manuel utilisateur peut jouer les 2 rôles :
    - avec annotation c'est une bonne base pour les spécifications fonctionnelles
    - sans annotation c'est le manuel utilisateur final a donné

    Il s'agit donc d'un seul document à maintenir mais dont certaines parties ne seront pas conservées pour les utilisateurs.

    De plus, souviron souligne bien que c'est dans une optique user-centered
    Mindiell
    "Souvent, femme barrit" - Elephant man

  20. #20
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 591
    Détails du profil
    Informations personnelles :
    Âge : 64
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 591
    Points : 17 295
    Points
    17 295
    Billets dans le blog
    2
    Par défaut
    Citation Envoyé par montesq Voir le message
    Tu vois souviron34 tu n'es pas clair...


    Regarde mon premier post :

    Citation Envoyé par souviron34 Voir le message
    C'est une bonne base..
    ..
    Mais effectivement le Manuel Utilisateur devrait fournir le squelette de l'arborescence fonctionelle, ainsi que (si il est bien fait et que chaque fenêtre et action y est détaillée) l'ensemble des paramètres et possibilités pour chaque fonctionalité, et donc est une bonne Spécification Fonctionnelle (aux suppléments cités ci-dessus près)

    En quoi n'est-ce pas clair ????





    Citation Envoyé par montesq Voir le message
    Donc pour toi il faut maintenir les 2 documents à jours en parallèle (le manuel utilisateur et les spécifications)
    (Personnellement, j'ai déjà du mal à maintenir 1 doc à jour alors 2...)
    Franchement, relis un peu le débat...


    Je dis :

    "NON CE N'EST PAS UN DOCUMENT DE SPEC"

    je dis :

    "OUI CA PEUT SERVIR DE DOCUMENT DE SPEC"



    Citation Envoyé par montesq Voir le message
    Pour moi (que l'on soit user centered ou pas) il ne doit y avoir qu'UN document de spécification (qui inclut les maquettes, les scénarios, les uses cases ou autres stories). Ce document doit être mis à jour en fonction de l'évolution des besoins et de la précision que l'on souhaite y apporter (on part d'un besoin macro et on affine de + en + au fur et à mesure).
    Une fois la release livrée, on doit fournir un manuel utilisateur en copiant/collant les parties de la spécification qui sont adaptées et en les organisant pour permettre une présentation adaptée à chaque type d'utilisateur de l'application (administrateurs, clients, back-office...)

    Encore une fois, ton incompréhension de nos interventions vient principalement d'un problème de vocabulaire justement. Ce que tu appelles "manuel utilisateur" (avant rédaction des spécs) est simplement pour moi la première forme de spécifications fonctionnelles...
    LOL..

    Ce sont TES incompréhensions qui viennent d'un problème de vocabulaire..

    Un Document de Spécification a une signification dans le domaine de l'informatique depuis plus de 40 ans...

    Cette signification n'inclue pas "qui inclut les maquettes, les scénarios, les uses cases ou autres stories".

    Elle ne l'inclue QUE dans l'approche USER-CENTERED.

    Dans toute autre approche, ces maquettes ou uses cases sont du domaine du prototypage, du Manuel Utilisateur, ou des tests.



    Je ne dis pas de faire 2 documents. Comme le fais très justement remarquer Kaeru No Uta, il existe tout un tas d'outils permettant de faire des annotations, des couches, dans un document.

    Je souligne simplement que, à part des fonctionalités nécessaires à l'informatique et non-visibles à l'utilisateur, le Manuel Utilisateur est un excellent document de description fonctionnelle et de l'arborescence de la fonctionalité, ainsi que des paramètres, et que, à ce titre, il PEUT être effectivement pris comme une Spec, à laquelle il faut ajouter simplement comme dit plus haut les quelques (éventuelles) fonctionalités cachées.

    Maintenant, une Spec est de toutes façons de haut niveau.

    Ce qui doit servir de base à l'informatique est, dans le cycle traditionnel, un Document de Conception.
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. Cas d'utilisation et spécification fonctionnelle
    Par Marco Polo dans le forum Cas d'utilisation
    Réponses: 3
    Dernier message: 29/05/2009, 20h06
  2. Rédiger un manuel utilisateurs pour site intranet Help-desk
    Par hélios44 dans le forum Autres Logiciels
    Réponses: 3
    Dernier message: 24/02/2008, 19h41
  3. Dossier de spécifications fonctionnelles
    Par Marty000 dans le forum Gestion de projet
    Réponses: 3
    Dernier message: 23/04/2007, 19h34
  4. Réponses: 2
    Dernier message: 04/07/2006, 09h07
  5. Projet : Manuel utilisateur en Flash
    Par chmike dans le forum Flash
    Réponses: 1
    Dernier message: 02/06/2006, 21h21

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo