02-09-2008, 09:56 AM
Coucou,
Contrairement à une rédaction dont le plan est attendu (thèse, anti-thèse, foutaise), un cahier des charges n'est pas conditionné. En effet, le cahier des charges pour un grand projet ne sera pas le même que pour un petit. Un cahier des charges n'est pas un document propre à l'informatique. Il s'agit souvent d'une demande fonctionnelle de la part d'un Maitrise d'oeuvre ou une demande technique de la part d'une maitrise d'ouvrage.
Cependant, comme notre sujet est centré sur les jeux et sur le php (enfin, peut-être est-ce le cas ?) peut-être que quelques similitudes peuvent en sortir.
Il me semble important de parler de :
- une présentation de ton projet
- Le fonctionnement de l'équipe
- les délais fixés et peut-être un détail des différentes versions
- les idées sur le jeu
- Les IHMs et l'enchainement de toutes les IHMs entre elle (au crayon à papier)
- Les technologies employées
- les schémas de BDD (fractionnées si besoin)
Dis toi que :
- un cahier des charges fonctionnelles doit être lisible par tout le monde (fais le lire à tes parents si tu veux ^^) Avec ce cahier des charges en main, la personne doit être capable d'utiliser toutes les fonctionnalités de ton jeu après que tu l'ai codée.
- un cahier des charges techniques qui servira de guide line à tes éventuels développeurs. Théoriquement ils ne devraient se poser aucune question fonctionnel qu'ils ne puissent pas être répondues avec ce document.
Pour éviter les lourdeurs documentaire, on fait souvent appelle à des cahiers de spécifications.
Dans tous les cas, ces documents doivent être le plus clair et le plus détaillé possible.
Kéké
Contrairement à une rédaction dont le plan est attendu (thèse, anti-thèse, foutaise), un cahier des charges n'est pas conditionné. En effet, le cahier des charges pour un grand projet ne sera pas le même que pour un petit. Un cahier des charges n'est pas un document propre à l'informatique. Il s'agit souvent d'une demande fonctionnelle de la part d'un Maitrise d'oeuvre ou une demande technique de la part d'une maitrise d'ouvrage.
Cependant, comme notre sujet est centré sur les jeux et sur le php (enfin, peut-être est-ce le cas ?) peut-être que quelques similitudes peuvent en sortir.
Il me semble important de parler de :
- une présentation de ton projet
- Le fonctionnement de l'équipe
- les délais fixés et peut-être un détail des différentes versions
- les idées sur le jeu
- Les IHMs et l'enchainement de toutes les IHMs entre elle (au crayon à papier)
- Les technologies employées
- les schémas de BDD (fractionnées si besoin)
Dis toi que :
- un cahier des charges fonctionnelles doit être lisible par tout le monde (fais le lire à tes parents si tu veux ^^) Avec ce cahier des charges en main, la personne doit être capable d'utiliser toutes les fonctionnalités de ton jeu après que tu l'ai codée.
- un cahier des charges techniques qui servira de guide line à tes éventuels développeurs. Théoriquement ils ne devraient se poser aucune question fonctionnel qu'ils ne puissent pas être répondues avec ce document.
Pour éviter les lourdeurs documentaire, on fait souvent appelle à des cahiers de spécifications.
Dans tous les cas, ces documents doivent être le plus clair et le plus détaillé possible.
Kéké