Quelle est l’importance d’écrire des spécifications fonctionnelles?

Question

Je n'ai jamais écrit de spécifications fonctionnelles, je préfère me lancer dans le code et concevoir les choses au fur et à mesure. Jusqu’à présent, cela a bien fonctionné, mais pour un projet personnel récent, j’écris quelques spécifications décrivant toutes les fonctionnalités du produit et indiquant comment il devrait «fonctionner» sans entrer dans les détails de la manière dont il sera mis en œuvre. le trouvant très précieux.

Quelles sont vos pensées, écrivez-vous des spécifications ou commencez-vous simplement à coder et à planifier au fur et à mesure, et quelle pratique est la meilleure?

Answer 1

Si vous conduisez de votre domicile à l'épicerie la plus proche, vous n'avez probablement pas besoin de carte. Mais ...

Si vous vous rendez dans un État où vous n'êtes jamais allé auparavant, c'est probablement le cas.

Si vous conduisez au hasard pour le plaisir de conduire, vous n’avez probablement pas besoin d’une carte. Mais ...

Si vous essayez de trouver le moyen le plus efficace (minimisez la distance, le temps, faites trois arrêts spécifiques en cours de route, etc.), vous y arriverez probablement.

Si vous conduisez seul et que vous pouvez prendre tout le temps voulu, vous arrêter à tout moment si vous voyez quelque chose d'intéressant ou pour reconsidérer votre destination ou votre itinéraire, vous n'aurez peut-être pas besoin de carte. Mais ...

Si vous conduisez dans le cadre d'un convoi et que vous devez tous vous rendre la nuit pour la nuit, la nourriture s'arrête ensemble et que vous devez arriver ensemble, c'est probablement votre cas.

Si vous pensez que je ne parle pas de programmation, vous n’avez probablement pas besoin de spécifications fonctionnelles, de cartes récit, de récit, de CRC, etc. Mais ...

Si vous pensez que je le suis, vous pouvez envisager au moins l'une des solutions ci-dessus.

; -)

Answer 2

Pour quelqu'un qui "saute dans le code" et "concevoir comme ils vont", je dirais que tout ce qui inclut une spécification fonctionnelle est meilleur que vos méthodes actuelles. Vous pouvez économiser beaucoup de temps et d’efforts si vous prenez le temps de réfléchir et de le concevoir avant même de commencer.

• Les exigences vous aident à définir ce que vous devez créer.
• Design vous aide à définir vos objectifs.
• La documentation utilisateur définit ce que vous avez fait.

Vous constaterez que la plupart des endroits auront une variation de ces trois documents. Les spécifications fonctionnelles peuvent être regroupées dans le document de conception.

Je vous conseillerais de lire Développement rapide si vous n'êtes pas convaincu. Vous pouvez vraiment travailler plus rapidement si vous prenez plus de temps pour planifier et concevoir.

Answer 3

Sauter " directement au code " dans le cas de grands projets informatiques, cela entraînerait presque certainement un échec (comme le ferait immédiatement le fait de poser des briques pour construire un pont).

Selon 37 Signals , il est préférable d'écrire un court document sur papier plutôt que d'écrire un document. spec complexe. Je dirais que cela pourrait être vrai pour créer rapidement de nouveaux sites Web (où la conception et l’idée pourrait mieux conduire qu’un schéma rigide), mais pas toujours acceptable dans d’autres situations de la vie réelle.

Pensez simplement à l’importance (juridique, voire) d’un document de spécification signé par votre client.

Le moral est probablement le suivant: soyez flexible et planifiez avec des spécifications fonctionnelles ou techniques autant que vous le souhaitez , selon le scénario de votre projet.

Answer 4

Pour les hacks ponctuels et les petits utilitaires, ne vous inquiétez pas.

Mais si vous écrivez une application sérieuse et volumineuse, si vous avez des clients exigeants et que vous devez l'exécuter longtemps, c'est un MUST. Lisez les articles de Joel sur le sujet - c'est un bon début.

Answer 5

Je le fais dans les deux sens, mais j'ai appris quelque chose du développement piloté par les tests ...

Si vous commencez à coder avec une feuille de route, vous arriverez à la fin du voyage beaucoup plus vite que si vous commencez à marcher sur la route sans avoir la moindre idée de la façon dont il se divisera au milieu.

Vous n'avez pas besoin d'écrire chaque détail de ce que chaque fonction va faire, mais de définir vos bases afin que vous sachiez ce que vous devriez faire pour que tout fonctionne bien ensemble.

Cela étant dit, j’avais besoin d’écrire une série de gestionnaires d’exception hier et je me suis contenté de plonger sans essayer de le concevoir du tout. Je devrais peut-être relire mon propre conseil;)

Answer 6

Ce que beaucoup de gens ne veulent pas admettre ou réaliser, c'est que le développement logiciel est une discipline d'ingénierie. On peut en apprendre beaucoup sur la manière dont ils abordent les choses. Cartographier ce que vous allez faire dans une application n'est pas nécessairement vital pour les petits projets car il est généralement plus facile de revenir rapidement en arrière et de corriger vos erreurs. Vous ne voyez pas combien de temps est perdu par rapport à l'écriture de ce que le système va faire en premier.

En réalité, dans les grands projets, il est presque nécessaire d’avoir une feuille de route du fonctionnement et des activités du système. Appelez cela une spécification fonctionnelle si vous voulez, mais vous devez normalement avoir quelque chose qui peut vous montrer pourquoi l'étape b suit l'étape a. Nous pensons tous que nous pouvons le penser à la volée (je suis certainement coupable de cela aussi), mais en réalité, cela nous pose des problèmes. Repensez-vous et demandez-vous combien de fois vous avez rencontré quelque chose et vous vous êtes dit: "J'aurais aimé pouvoir y penser plus tôt?" Ou quelqu'un d'autre voit ce que vous avez fait et vous a montré que vous pouviez suivre 3 étapes pour accomplir une tâche où vous en avez effectué 10.

Le mettre sur papier vous oblige vraiment à réfléchir à ce que vous allez faire. Une fois sur papier, ce n'est plus une pensée nébuleuse et vous pouvez ensuite l'examiner et évaluer si ce que vous pensiez est vraiment logique. Changer un document d'une page est plus facile que de changer 5000 lignes de code.

Answer 7

Si vous travaillez dans un environnement XP (ou similaire), vous utiliserez stories pour guider le développement, ainsi que de nombreux tests d'utilisabilité des unités et des couloirs (j'ai bu le Kool-Aid , je suppose).

Cependant, il existe un domaine dans lequel une spécification est absolument requise: lors de la coordination avec une équipe externe. J'avais un projet avec une grande compagnie d'assurance où nous devions avoir un accord sur certains comportements du programme, certains aspects de la conception de la base de données et un certain nombre de dispositions de fichiers. Sans la spécification, j'étais large ouvert à une interprétation créative de ce que nous avions promis. C'étaient de bonnes personnes - je leur faisais confiance et j'aimais travailler avec elles. Mais encore, sans cette spécification, cela aurait été une marche à mort. Avec les spécifications, je pouvais toujours indiquer où ils s'étaient écartés de la mise en page convenue ou où ils demandaient un travail personnalisé supplémentaire ($$!). Si vous travaillez avec une relation semi-antagoniste, la spécification peut vous sauver encore plus mal: un procès.

Oh oui, et je suis d’accord avec Kieveli: "Sauter directement dans le code" n’est presque jamais une bonne idée.

Answer 8

Je dirais que c'est totalement "ça dépend". sur le type de problème. J'ai tendance à me demander si je l'écris pour le plaisir de le faire ou pour les couches superposées. J'avais également débattu de cela et mon expérience personnelle me dit que cela devrait rester dans la mesure où le projet reste en phase avec les attentes (au lieu de dévier du cap).

Answer 9

J'aime décomposer n'importe quel problème non trivial sur papier plutôt que de passer au code, pour un certain nombre de raisons;

• Les éléments que j'écris sur du papier n'ont pas à compiler ni donner de sens à un ordinateur
• Je peux travailler à des niveaux d'abstraction arbitraires sur papier
• Je peux ajouter des images et des diagrammes très facilement
• Je peux réfléchir et déboguer un concept très rapidement

Si le problème que je traite est susceptible de prendre beaucoup de temps ou d’autres personnes, je l’écrirai sous forme de spécification fonctionnelle. Si quelqu'un d'autre me paie pour développer le logiciel et qu'il y a un risque d'ambiguïté, je vais ajouter suffisamment de détails pour supprimer cette ambiguïté. J'aime également utiliser cette documentation comme point de départ pour développer des scénarios de test automatisés, une fois le logiciel écrit.

En d’autres termes, j’écris suffisamment de spécifications fonctionnelles pour bien comprendre le logiciel que j’écris moi-même et pour résoudre les éventuelles ambiguïtés qui pourraient en résulter pour quiconque.

Answer 10

Je ressens rarement le besoin d’une spécification fonctionnelle. OTOH L’utilisateur étant toujours responsable de la fonction à un appel téléphonique, je peux toujours lui demander ses exigences fonctionnelles au fur et à mesure de ses déplacements.

Pour moi, une spécification fonctionnelle est plus un outil politique que technique. Je suppose qu'une fois que vous avez une spécification, vous pouvez toujours blâmer la spécification si vous découvrez par la suite des problèmes d'implémentation. Mais qui blâmer ne m’intéresse vraiment pas, le problème sera toujours là, même si vous trouvez un bouc émissaire, mieux vaut alors revenir sur la mise en œuvre et essayer de le faire correctement.

Il est pratiquement impossible de rédiger une bonne spécification, car vous ne connaissez pas suffisamment le problème, ni les outils, ni les modifications futures de l'environnement pour le résoudre correctement.

Par conséquent, j'estime qu'il est beaucoup plus important d'adapter une approche agile au développement et de consacrer suffisamment de temps et de ressources pour la révision et la refactorisation au fur et à mesure.

Answer 11

Il est important de ne pas les écrire: Il n'y a rien de fonctionnel à propos d'une spécification fonctionnelle