Discussion :

[smarlytomtom]

Bonjour à tous !
Dans le cadre de mon projet de fin d'étude je travaille sur un projet qui demande la réalisation de pas mal de paperasse dont un dossier de spécifications fonctionnel. Hors, gros problème je n'ai jamais vu ce que c'était ! je suis donc allez chercher sur le web pour trouver des exemples et peut être même des exemples et j'en ai trouvé, seulement ils sont tous aussi différents les uns que les autres et j'ai réussi à me "perdre", si je peux dire, dans la forme que doit prendre ce dernier !

C'est pour ça que je viens vous demander si il existe un modèle que l'on pourrai qualifier de générique pour s'adapter à n'importe quel projet !? Je tiens à préciser que le projet consiste au développement d'une application qui communique par voie série (RS232) avec un chariot posté sur un rail, puis avec un appareil photo (par le biais de l'API constructeur) qui est lui même sur le chariot. Tout ça dans le but de réaliser des time lapse.

Je vous remercie d'avance pour les solutions que vous pourrez m'apporter !

[Carhiboux]

Salut,

Bienvenue dans la jungle des formalismes. A ma connaissance, il n'y a pas un modèle applicable partout. Il y a des constantes, mais après, le contenu change pas mal d'une entreprise à une autre, voir même d'un service à un autre.

Libre à toi donc d'adopter le formalisme qui te conviendra le mieux et que tu jugeras le plus à même de bien exprimer ton besoin. Le but est avant tout que le(s) lecteur(s) comprennent ton besoin en lisant ton dossier de specs fonctionnelles. Donc ne pas hésiter à mettre des schémas, à bien préciser les prérequis et les résultats attendus pour chaque fonctionnalité, etc...

[Glutinus]

Question bête : ton école ou université te demande un cahier de specifications fonctionnelles... ils n'ont pas un exemple ou du moins un sommaire à suivre ?

Pour la blague, j'ai déjà eu une mission où les documents faisaient une page :
Spécifications techniques générales : "voir spécifications fonctionnelles détaillées"
Spécifications fonctionnelles détaillées : "voir spécifications fonctionnelles générales"
Spécifications fonctionnelles générales : "voir cahier des charges"

et ainsi de suite.

[smarlytomtom]

Merci pour vos réponses !
alors pour carhiboux, merci des conseils je m'en doutais un peu mais on sait jamais :p ! donc en gros je fais une courte présentation des différents buts et modules du projet, suite à quoi je fais une analyse générale avec des diagrammes des cas d'utilisations et des diagrammes de déploiement et par la suite je détail les cas d'utilisations !?

pour glutinus, l'école c'est plus ce que c'étais :p ! donc déjà pas de modèle qui traîne sur le réseau du bahut et les profs ne vont apparemment pas en fournir... pour achever le tout il nous on prévenu mardi de cette semaine et c'est à rendre pour le 25 Mai.. et c'est pas le seul puisque qu'on doit aussi faire un dossier d'étude préliminaire, une flotte de fiche de test et ça juste pour la partie commune... ce qui donne un dossier d'environ 90 pages pour un groupe de 3 personnes !
Sinon je trouve ton histoire assez marrante ^^, c'est pas ce qu'on veux nous les programmeurs, on veux pas faire plus de paperasse que de code !!!

[yento]

Question bête : ton école ou université te demande un cahier de specifications fonctionnelles... ils n'ont pas un exemple ou du moins un sommaire à suivre ?

Been there, done that...
(Et non on n'avait rien du tout de fourni )

###########################################################
(les tirets marquent les changements de section/page)
-----------------------------
SPECIFICATIONS FONCTIONNELLES
TITRE DU PROJET
LOGO DE l'ENTREPRISE

------
SOMMAIRE

...
...


---------
CONTACT

nom, prénom, mail, tél, role, entreprise...

(pour toutes les personnes impliquées dans le projet)
(c'est important pour pouvoir les retrouver plus tard)

---------------
MODIFICATIONS

(un tableau)
sections (modifiées) | description des modifications | auteur | relecteur | date

(très important de garder un historique des modifications)

-------
CONTEXTE ET OBJECTIF DU PROJET

Explication en quelques paragraphes du contexte et des objectifs du projets.

(Cette partie doit permettre de comprendre quel est le problème auquel l'entreprise est confrontée ? pourquoi elle lance un projet ? qu'est ce qu'elle espère atteindre comme objectif ?)
(L'idée c'est que quelqu'un qui n'a jamais entendu parler de ton projet puisse lire ces paragraphes et tout comprendre).

-------
BETE A CORNES

diagramme bete a cornes
(toujours pratique pour expliquer rapidement le projet et ca rend bien sur powerpoint )

----------------------
DIAGRAMME PIEUVRE

Pour présenter les FP et les FC (fonctions principales, fonctions contraintes).
J'ai des amis qui sont fans. C'est pas forcément évident à faire selon le produit. Ca peut être redondant avec les autres diagrammes.

Personnellement j'ai abandonné ce diagramme et je ne le recommande plus mais tu peux croiser des specs qui s'en servent et/ou le conseil.


-------------------
CAS D'UTILISATION

Diagramme UML de cas d'utilisations

(Contente toi de lister les cas d'utilisations principaux du programme)
(Pour reconnaître un bon diagramme pour cette partie: quand tu le ré ouvres dans 6 mois, le diagramme est toujours correcte, parce que le client cherche toujours a résoudre le même problème et les fonctionnalité principales ne changent pas.)

-----------------
FONCTIONALITES

*ENORME TABLEAU AVEC 5 COLONNES*
Catégorie | Fonctionnalité | -------------PRIORITE--------------
Catégorie | Fonctionnalité | obligatoire | secondaire | optionnel

(Note de mise en page: tu fais ça bien avec un tableau Word et les lignes/colonnes alignées et fusionnées comme il se doit. Je peux pas faire un tableau d'exemple correctement sur un forum internet.)

(C'est dans ce tableau que tu peux détailler plein de choses, plutot que de polluer le diagramme de cas d'utilisation).
(Liste toutes les fonctionnalités, regroupe les en catégories si nécessaire.)
(Il est très important d'assigner une priorité à chaque fonctionnalité.)
(Grosso merdo: Les fonctionnalités principales sont indispensables pour livrer le projet. Les secondaires seront développées en commençant par les plus importantes. Les optionnelles sont laissées de côté sauf changement de situation.)

-------------
CONTRAINTES

Lister les contraintes connues.
Découper en plusieurs parties si nécessaire.

quelques exemples:
- Le produit doit couter moins de 5$ en fabrication
- Le produit doit être conforme à la norme ISO56789
- Volumes de données, nombre d'utilisateurs attendus par jour/mois.
- Le développement utilisera JAVA 7, sous windows 7


---------
LIVRABLES

(encore un tableau)
Nom du livrable | Livré par ... | Date Visée

exemple de livrables:
- Spécifications fonctionnelles
- Fiches de test
- Cahier de recette
- Code Source des logiciels réalisées
- Documentation d'installation
- Manuel utilisateur

Astuce pour les juniors: Bien penser qu'il y a aussi des livrables donnés par le client (notamment matériel et/ou documentation)
- Livraison des tablettes Android (il faudra bien des tablettes Android pour développeur sous Android, n'est ce pas ? Soit le client fourni, soit on achète et on lui refacture, il les récupérera à la fin pour continuer le projet.)
- Livraison des serveurs
- Carte de controle commandes USB-PELT avec documentation (e.g. quand il est demandé de s'interfacer avec des équipements, des webservices, etc...)
- Pelleteuse PT532 (e.g. si tu fais un projet embarqué qui interagit avec des pelleteuses, tu peux demander une pelleteuse au client pour réaliser des tests grandeurs natures)

(Astuce: "Fin mai", "début juillet", "fin du projet", "15 septembre 2016" sont des dates tout à fait acceptables)

---------
ANNEXES

Documents et trucs divers

(par exemple, le projet concerne un logiciel de cartographie, le client fournie une carte d'un secteur, qui servira d'exemple pour les tests/démos du logiciel)
###########################################################

Je n'ai pas accès a mes cahiers des charges depuis là où je suis. J'ai écris ce que je me souviens de tête. Ca devrait donner les éléments principaux.

Grosso modo un document de spécifications fonctionnelles/cahier des charges est très simple dans sa structure. C'est quelques diagrammes + quelques tableaux + quelques listes. J'ai déjà vu un doc de 10 pages pour un projet qui va mobiliser 10 personnes pendant la moitié de l'année.

La grosse difficulté c'est de remplir les diagrammes et les tableaux en questions. Ca peut prendre la journée pour vaguement comprendre chaque type de diagramme si tu les as jamais fais. Et il te faudra l'expérience de plusieurs projets pour arriver à identifier parfaitement les besoins du clients et à les exprimer dans le bon diagramme avec le niveau de détails au poil.

----------
Aujourd'hui, vous avez appris à rédiger les spécifications fonctionnelles.
Pour la prochaine leçon nous verrons comment planifier et gérer le projet grâce à Unified Process, Scrum et eXtreme Programming

[Mat.M]

Salut,

Bienvenue dans la jungle des formalismes. A ma connaissance, il n'y a pas un modèle applicable partout.

remarque pertinente
Pourquoi ne pas passer directement à des outils de conception comme UML plutôt que de générer de la paperasse et de la bureaucratie. ?
C'est juste une remarque que je fais en passant

Sinon je trouve ton histoire assez marrante ^^, c'est pas ce qu'on veux nous les programmeurs, on veux pas faire plus de paperasse que de code !!!

c'est certain;
je croyais que le but de l'informatique et du numérique c'était de produire moins de paperasse et de simplifier les choses , sans vouloir lancer un débat.

[smarlytomtom]

Pour te répondre Mat, si seulement je pouvais me contenter de ça ^^ !!
en tout cas un grand merci yento ! je vais voir comment je me débrouille avec toutes vos réponses ! je devrais arriiver à faire quelque chose qui tiens debout maintenant !