Question

Donc, fondamentalement, je recherche de bons modèles pour rédiger des spécifications techniques et fonctionnelles sur un projet ou une demande de travail.

Qu'est ce que tu utilises?Jusqu’où allez-vous en écrivant les spécifications ?Tous les conseils généraux supplémentaires que vous pourriez fournir seraient appréciés.

Mon entreprise en a cruellement besoin.Je travaille pour un entrepreneur et pour le moment, nous n'utilisons pas du tout ces documents.

MODIFIER: J'ai lu le point de vue de Joel sur Spécification indolore, j'ai vraiment aimé, mais y a-t-il d'autres avis :)

Était-ce utile?

La solution

Sur les conseils généraux ;

Nous mettons en œuvre un processus de

1) Déclaration des exigences commerciales (BRS)

2) Spécification fonctionnelle

3) Spécification technique

Le BRS couvre les problèmes commerciaux et les exigences en matière de solutions, de tests, de sécurité, de fiabilité et de livraison.Cela définit ce qui constituerait une solution réussie.

Les spécifications fonctionnelles détaillent ce qui est nécessaire, à quoi cela devrait ressembler, quelle doit être la longueur des champs, etc.

Les spécifications techniques détaillent l'origine des données et tout code délicat qui pourrait devoir être pris en compte.

Le client est propriétaire des exigences.Les développeurs sont propriétaires des spécifications techniques et les spécifications fonctionnelles constituent un juste milieu.Les tests sont effectués par rapport aux spécifications techniques (généralement des tests unitaires), puis par rapport aux spécifications fonctionnelles (généralement des tests système) et enfin par rapport aux exigences (UAT).

La partie importante de cela (et avec laquelle nous avons du mal) est que les développeurs doivent toujours respecter les spécifications fonctionnelles et les exigences commerciales d'origine.En réalité, les spécifications fonctionnelles et techniques ne sont là que pour plus de clarté.

Bref, mon conseil principal est de définir d’abord le processus que vous souhaitez mettre en œuvre.Recherchez ensuite l’accord de toutes les parties impliquées dans le processus proposé, puis travaillez sur les modèles adaptés.Les modèles eux-mêmes ne représentent qu’une petite partie du changement que vous souhaitez apporter.

Autres conseils

Ce n'est pas un modèle, mais Joel a écrit un quelques articles sur la rédaction d'une spécification fonctionnelle.Il a aussi échantillon ici.

Vous pouvez acheter des modèles chez ieee et ailleurs, mais j'ai toujours fini par créer les miens.

Pour une spécification technique, "Code terminé" de Steve McDonnell a une bonne liste de contrôle, vous pouvez en tirer quelques informations.Lors de mon dernier travail, j'ai simplement créé un modèle à partir de ses en-têtes de section et je l'ai modifié à partir de là.

En ce qui concerne une spécification fonctionnelle, l'important est de définir toutes les interfaces :

  1. UI (maquettes d'écran)
  2. Interfaces logicielles (plugins, etc.)
  3. Interfaces matérielles (le cas échéant)
  4. Interfaces de communication (Services, email, messagerie, etc.)

Il devrait également y avoir une section pour les règles métier, les éléments fonctionnels importants qui ne sont couverts dans aucune définition d'interface.

Si vous souhaitez acheter un livre, Configuration logicielle requise par Karl Wiegers contient des modèles pour quelques documents en annexe.Malheureusement, je suis au travail et ce livre en particulier est à la maison.Si quelqu'un l'a sous la main, il pourra peut-être le confirmer.

Il se trouve que j'aime celui-ci, entre autres : Prêt à l'emploi.

Il vend également une version pro.

C'est le meilleur que j'ai trouvé : http://www.jiludwig.com/templates/FRDTemplate.doc

Commencez simplement et progressez à partir de là.Puisqu'il s'agit de votre première expérience de travail avec cela, utilisez un document Word avec des puces.Écrivez-le, relisez-le et fournissez suffisamment de détails pour que cela ait du sens.Pour les spécifications techniques, vous souhaiterez peut-être guider le développeur vers une solution, mais pour les spécifications fonctionnelles, le « comment » devrait être complètement absent.

Je suggère de jeter un oeil au modèle Volere de Roberston ici.Ils font partie de l'Atlantic Systems Guild, aux côtés de personnes comme Tom DeMarco et Timothy Lister de la renommée "Peopleware".

Le modèle étant protégé par le droit d'auteur, je ne le reproduirai pas ici, mais je vous donnerai quelques-uns des principaux en-têtes :

  1. Le but du projet
  2. Les parties prenantes
  3. Contraintes obligatoires
  4. Conventions de dénomination et terminologie
  5. Faits et hypothèses pertinents
  6. La portée des travaux
  7. Modèle de données métier et dictionnaire de données
  8. La portée du produit
  9. Exigences fonctionnelles
  10. Regardez et ressent des exigences ...

Il y en a bien d'autres, mais cela devrait vous donner une idée.La partie la plus intéressante du modèle est le shell d'exigences qui répertorie les exigences fonctionnelles sur une sorte de fiche signalétique.Encore une fois protégé par le droit d'auteur, mais vraiment précieux.

Regarder ici au chapitre 9.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top