Bonjour,
Je suis débutant en programmation et je voudrai apprendre à effectuer un cahier des charges.  
 
Est ce quelqu'un pourrait m'expliquer les différentes étapes qu'un programmeur doit faire pour rédiger son cahier des charges.
 
Merci d'avance !
 

c'est pas au programmeur de le faire
 
 
Dans la réalité, le terme "cahier des charge" peut faire référence à tellement de trucs différents que tu fais ce que tu veux, ça sera jamais bien. Si tu es dans une boite, tu en demandes 2 anciens pour t'en inspirer. Si tu fais le premier, alors il deviendra la référence.

OK Merci... mais quelques conseils pour en faire un m'auraient été utiles !    
 
Merci d'avance  

je dirais qu'il doit au moins comporter la description du besoin. apres tu peux aussi mettre dedans l'etude de faisabilité, les chartes (graphique ou d'echange), ou bien encore un planning.
globalement c'est un document qui doit comporter tout ce qui est nécéssaire pour qu'une tierce personne puisse executer la tache decrite
mais comme le dit nraynaud, c'est tres attaché à la culture d'entreprise.  

Si je me rappelle bien ce qu'on nous a raconté en cours, il faudrait y mettre au minimum (en vrac) :
 
besoins fonctionnels (ça marche pas sans)
besoins non fonctionnels (ça marche sans, mais c'est vraiment pas top)
extensions envisagées (c'est très utilisable sans, mais ce serait un plus)
étude de faisabilité
planning

une explication de la terminologie employée peut etre pas mal aussi.

Dans certaines boites le CdC va jusqu'à définir très précisémment l'aspect de chaque fenêtre du logiciel (type de controle, emplacement). En gros y'a tout sauf le code. Je pense à la Société Générale (vu ça à une soutenance de stage), où programmeur là bas doit réellement dire pisse code. Le stagiaire avait passé l'essentiel de son stage à faire le CdC. La grosse amélioration qu'elle a proposé c'est de remplacer un formulaire sur 2 pages par une seule page grâce à l'utilisation d'une barre de défilement dans la fenêtre...

Merci à tous de vos réponses !
Je croyais que ma question était idiote mais aparement non    
 
Encore Merci pour les infos cela me servira prochainement    
 

ça, c'est assez courant en IHM: tu fais la liste des fonctionnalités que tu veux puis tu penses l'interface graphique en conséquence (en incluant la charte graphique s'il y en a une ou en la créant à ce moment là)

Vu la taille qu'un CdC peut faire, il convient d'en produire des versions allégées ne contenant que les infos pertinentes pour telle ou telle personne.

Autre boîte, autre culture...
 
Chez nous, le CdC, c'est le client qui le fait, et ça se résume à une expression des besoins.
 
Ensuite, c'est à nous de pondre plusieurs documents:
 
- Spécifications fonctionnelles générales (En gros on reprends le CdC du client, mais avec une structure standard)
 
- Spécification fonctionnelles détaillées. Là on va voir tous les intervenant du projet pour définir dans le détail à quoi doit ressembler la solution. Ca peut aller jusqu'à des indices de performances.
 
- Spécification techniques générales (Architecture, type de bd, language, outils....
 
- Spécification techniques détaillés (ou dossier de conception). Là on est pas loin du code Le programmeur n'as plus qu'à pisser le code presque sans réfléchir.
 
- Plan qualité : Ce truc est énorme, impossible à décrire en résumer
 
Bref, on commence à coder quand le client a validé 20 tonnes de papier
 
EDIT : J'ai surement oublié plein d'autres trucs...

sur les CDC de commande, nous on a aussi les nombres de licences prévisionels, le mode de paiement (90 jours nets, 50% de part variable sur la maintenance), le temps de correction des bugs (3 niveaux de gravité, avec 3 temps de contournement puis correctif définitif différent).
Et *surtout* on marque que les conditions générales de vente du fournisseur ne s'appliquent pas.

Ca arrive souvent qu'un client vous ponde une "vraie" expression des besoins ? en % ?

En fait j'en sais trop rien, je suis trop bas dans l'échelle pour avoir accès à des données aussi sensibles

pain-aux-raisins > de toutes façons, s'il n'a pas d'assistance à la maîtrise d'ouvrage, il est sensé se faire aider de la maîtrise d'oeuvre pour exprimer ses besoins (c'est le rôle de psychanaliste dont je parle de temps en temps, analyse des besoins). D'autre part, si la relation est commerciale, le fournisseur a un DEVOIR de conseil envers son client.

+1
 
C'est pour ca que c'est sensible comme infos.
 
On serait tous trop MDR à lire les trucs que les clients imaginent. Les progueux, n'ont pas le droit de se moquer des clients

jamais dis le contraire
 
j'étais juste intéressé de savoir s'il y avait une évolution de comportement ou si, et en cela je te rejoins complétement, cette phase d'expression des besoins était toujours aussi acrobatique.

bon ben je vais developper un peu ce qui se passe chez nous. nous on a plus une approche produit.
donc le truc, c'est plusieurs clients qui expriment plusieurs besoins à la base différent.
tout ça passe au marketing qui compulse les differentes demandes et essaye d'en extraire un cahier des charges de produit (donc principalement fonctionnalités + etude de marché).  
ça arrive à la tete de la R&D qui elle aussi fait son cahier des charges (fonctionnalités + faisabilité + cout + planning).
une fois que tout le monde est d'accord sur ces 2 documents, ça passe entierement à la R&D et là on rentre dans les documents de specifications diverses et variées.