Discussion :

[n3ptvn7]

Bonjour futur étudiant en développement Web, je viens poser une question dont je n'arrive pas à avoir le degré d'information qui me convient. J'ai accès à des cours qui sont assez théoriques.
De ce que j'ai pu comprendre, je vais apprendre des choses qui ne sont plus appliquées dans la réalité. Par exemple la manière dont on doit rédiger des spécifications techniques.Cependant je vais avoir des projets à rendre sur la maniéré dont on choisis une solution technique et on liste les fonctionnalites demandés par un client.
J'aimerai savoir lorsque je rédige le backlog, est ce que c'est cela lister les fonctionnalités ou je devrais faire autre chose*?

Pour m'entrainer, j'ai imaginé qu'une entreprise venait me donner un cahier des charges pour réaliser un site internet.
J'ai donc réaliser un backlog et j'aimerai savoir si créer ce backlog, c'est uniquement cela lister les fonctionnalités*?
Je sais que chaque fonctionnalité je devrais rédiger un manuel utilisateur, de la documentation technique, je voudrais savoir si c'est de cela dont on parle ou si je dois rédiger un autre document ou je vais lister toutes les fonctionnalités*? Si c'est le cas, j'aimerai savoir quelles sont les normes que je devrais respecter pour les rédiger*? Est ce que comme un backlog, je dois commencer par les plus importantes*?
Si par exemple une des fonctionnalité serait une barre de recherches, je dois ajouter quoi comme autre information ou je liste uniquement barre de recherche.
Là pour l'exercice que j'ai imaginé, j'ai créer un document qui a pour titre:Ensemble des fonctionnalités
Ensuite j'ai fais des tirets ou je met le nom de la fonction puis à cotés à quoi elle va servir
Exemple*:
-Barre de recherche*: Fonction qui permettra à l'utilisateur de rechercher des informations sur le site et/ou dans la base de données.
Si je suis hors sujet, n'hésitez pas à me le dire
Si vous avez un document d'exemple, je suis preneur.

Merci d'avance pour vos réponses.*

[CinePhil]

Le backlog me semble effectivement une manière moderne de lister les fonctionnalités.
Et comme c'est un outil de discussion avec le "client" (le product owner dans la méthode Scrum), Ça permet de lui faire valider l'exhaustivité de ce qu'il attend et la priorisation.

Un cahier des charges à l'ancienne est généralement faux quand il sort de l'imprimante !

L'avantage du backlog est qu'il est évolutif plus facilement qu'un cahier des charges de 100 pages ou plus. Surtout avec un logiciel de gestion de projet Agile, comme par exemple IceScrum.

[n3ptvn7]

Merci Cinephil pour ta réponse.
Mais avec la méthode Agile, je devrais quand même réaliser un manuel utilisateur et de la documentation technique pour chaque fonctionnalité?

[n3ptvn7]

là j'ai crée un manuel utilisateur pour une seule fonctionnalité.
Il fait environs 11 pages

Il se presente de la manière suivante:

Le manuel utilisateur devra se presenter ainsi

Page 1
Logo + nom de l'entreprise + Manuel utilisateur + Adresse de l'entreprise

Page 2
Suivi du document
Indique toutes les versions du documents qu'il y a eu
Qui sont intervenu sur le documents à quel dates et ce qu'ils ont apportés

Page3
Tables des matières

Page 4
Présentation Generale
->Objet
Public Cible
Acces
Prerequis techniques
Prerequis Organisationnels

Page 5 Guide Utilisateur
La fonction et comment on l'utilise

Page 6 Glossaire

Page 7 Note pour le responsable technique
Page 8 Note Generale
Page 9 Assistance

Je suis hors sujet?

[CinePhil]

Le manuel utilisateur, ça vient - éventuellement - à la fin.
Éventuellement parce qu'on ne fait plus trop ce genre de document (obsolète à la sortie de l'imprimante, lui aussi parce qu'une correction de bug ou une dernière modif a changé des trucs) mais plutôt une aide en ligne sur certains points délicats et d'éventuels tutoriels sur l'utilisation générale de l'application à destination des professionnels du métier. Et comme tu seras semble t-il dans le développement web, tu ne seras peut-être même pas confronté à ce genre de souci. On vise maintenant plutôt une ergonomie explicite. L'utilisateur du métier doit trouver son chemin "naturellement" pour faire ce qu'il a à faire. Dans certains cas un peu spéciaux : aide en ligne ou tutoriel séparé avec des captures d'écran, des logigrammes d'enchaînement des opếrations... bref, un truc simple à lire avec un minimum d'informations annexes telles que celles que tu as listées. Il faut aller à l'essentiel, surtout que la rédaction de ce genre de truc prend du temps.

Pour ça aussi, d'ailleurs, une user story "Documentation" à discuter avec le product owner, notamment quant au poids à lui donner et le degré de complexité à atteindre. Ne pas se lancer à l'aveugle dans la rédaction d'un tel document.

La rédaction des tests pour valider la fonctionnalité est à mon avis plus importante. Au CNAM, on m'avait enseigné une méthode que j'ai parfois appliquée dans certains cas un peu délicats : un tableau du genre
N° et nom de la fonctionnalité en titre.
Une première partie avec les "pré-conditions" : comment arrive t-on à cette fonctionnalité, quelles variables ou paramètres a t-on en entrée et quelle est leur plage normale de valeurs.
Une deuxième avec les "post-conditions" : ce qui sort comme résultats de la fonctionnalité avec là aussi les plages de valeurs possibles.
3ème partie : le cas normal de déroulement de la fonctionnalité.
4ème partie : les cas alternatifs qui déclenchent des erreurs ou des résultats différents du cas normal.

Voilà ce qui me revient en mémoire ; ça fait des années que je n'ai plus utilisé ça.

Cependant je vais avoir des projets à rendre sur la maniéré dont on choisis une solution technique et on liste les fonctionnalites demandés par un client.

Il faut commencer par du très synthétique. Si on fait une sorte de backlog, juste les titres des features puis des users storys.

Quant au choix de la solution technique, elle dépend de multiples facteurs tels que la prise en compte de l'existant, de branchement ou pas sur des logiciels existants, d'imposition du monde Windows ou Linux ou Mac ou autre, d'une notion au moins à la louche du budget et des délais, de la politique de la maison entre le développement personnalisé ou l'utilisation d'outils du marché...

Tout ceci n'est QUE MON AVIS !

[n3ptvn7]

Merci pour ta réponse