Qu’est ce que c’est ?

Il est important de faire le distinguo entre spec technique et spec fonctionelle

1. Une spécification fonctionnelle décrit comment un produit fonctionnera, entièrement du point de vue de l’utilisateur. Elle ne s’attache pas à la façon d’implémenter la chose. Elle parle de fonctionnalités. Elle spécifie les écrans, les menus, les dialogues et ainsi de suite. Elle indique le QUOI

2. Une spécification technique décrit l’implémentation interne du programme. Elle parle des structures de données, des modèles de bases de données relationnelles, du choix des langages et des outils de programmation, des algorithmes, etc. Elle exprime le COMMENT.

A quoi ça sert ?

Quand on conçoit un produit, il est important de fixer précisément l’expérience que va vivre l’utilisateur.

Pourquoi ?

Pour tout projet informatique nécessitant plus d’une semaine de code ou plus pour un programmeur, il faut des "specs". Si vous n’avez pas de specs, vous passerez toujours plus de temps que prévu pour un code de moins bonne qualité. Voici pourquoi.

La fonction la plus importante d’une spec est de concevoir l’architecture du programme. Même si vous travaillez seul sur du code et que vous écrivez une spec dans votre seul intérêt, le fait d’écrire cette spec — détaillant la marche du programme par le menu — vous forcera à effectivement concevoir le programme.

Joël Spolsky dit "[quand] vous planifiez votre produit en language humain, cela prend quelques minutes pour balayer plusieurs possibilités, réviser ou améliorer votre architecture. Cela ne pose de problème à personne d’effacer un paragraphe dans un traitement de texte. Mais lorsque vous concevez votre produit avec un langage de programmation, la conception itérative prend des semaines. Pire encore, un programmeur qui a travaillé 2 semaines sur du code va être relativement attaché à ce code, aussi mauvais soit-il."

Donc raison 1 : Ecrire en langage humant est plus rapide et plus simple.

Raison numéro 2 est déconomiser du temps en communiquant. Quand vous écrivez une spec, vous ne devez communiquer qu’une seule fois la manière dont le programme est supposé fonctionner et chacun est capable de lire et comprendre.

Raison numéro 3 : sans specifications détaillées pas de planning.

Comment ?

Mettre une décharge

 : l’état : non terminé ou terminé mais si j’ai oublié qqch merci de me le dire

Un seul auteur. Si projet important, on découpe le projet et un auteur par partie pour les speechs

Des scénarios. Il faut lister les différents publics, imaginer un utilisateur fictif mais stéréotypé. PLus le scénario sera vivant meilleur sera la conception.

Des non-buts. Cad les choses que l’on ne fera pas quoiqu’il arrive. Par ex. nous ne tiendrons pas compte de la lenteur d’exécution dans cette version.

Un aperçu. Sorte de table des matières sous forme de diagramme ou de grande discussion.

Des détails, des détails… Donner un nom à chaque écran, puis un chapitre loe décrivant dans les moindres détails.

Il ne faut pas oublier non plus tout les cas d’erreur. La spécification doit documenter la décision. Les messages adressés à l’utilisateur doivent donc être écrits il seront ainsi relu par les équipe du marketing ou de la com’.

Des questions en suspens. Il n’y a pas de problème à laisser des questions en suspens dans la première version des specs.

Des annotations. "notes aux testeurs", "notes au marketing", "notes de documentation",…

Mettre à jour même pendant le développement. Les notes de révision permettent aux différents lecteurs de ne pas tout relire.

Pour réaliser des specs qui soient lues

1. être drôle

"Miss Peggy, tapant sur son clavier avec un crayon à cils parce que ses petits doigts boudinés sont trop gros pour presser les touches individuellement, tape Ctrl+N pour créer une nouvelle table "Petits Copains" et saisit le seul enregistrement "Kermit."

c’est mieux que d’écrire

"L’utilisateur entre Ctrl+N pour créer un nouvelle table Employés et commence à entrer le nom des employés."

2. Ecrire du code exécutable pour le cerveau.

3 Ecrire aussi simplement que possible

4. Repasser sur ses specs et les relire plusieurs fois.

5. Ne pas utiliser pas de modèles