Niveau de détail le plus bas pour les spécifications fonctionnelles afin d'être utile

Question

Là où je travaille, les gens n'aiment pas écrire des spécifications. (Quelqu'un le fait-il?) Alors ils ne le font pas, à moins d'être forcés par leurs patrons. S'ils sont forcés de les écrire, ils les rendent aussi courts que possible. (Au fait, ils incluent également moi .)

Cela se traduit par des spécifications telles que

• Ce logiciel enregistre le temps entre les événements A et B dans le journal des événements
• Le nom et le chemin du paramètre X sont définis dans un fichier de configuration au format ini.
• Le logiciel est actif sans qu'un utilisateur ait besoin de se connecter à l'ordinateur (implémentation en tant que service Windows)

Cet exemple est tiré d'un très petit projet et il a très bien fonctionné. Mais je ne pense pas que cela suffira pour quelque chose de plus complexe. Je n'ai pas spécifié d'exigences relatives au système d'exploitation / au matériel, car il s'agit d'un développement interne et nous avons des normes d'entreprise ou de département qui les concernent

Donc ma question est la suivante: Que considérez-vous comme le niveau de détail minimum absolu dans une spécification fonctionnelle d’un logiciel non trivial?

Answer 1

À mon humble avis, l’important des spécifications fonctionnelles (et de toutes les autres méthodes / outils formels pour le développement de logiciels et la planification de projets (Yourdon, SSADM, PRINCE2, UML, etc.) est qu’elles encouragent les bonnes pratiques en vous faisant penser de manière commune. ne garantissent pas le succès mais encouragent le succès en formalisant les bonnes pratiques

Donc, le fait que les FS soient créés est une bonne chose, même s’ils pourraient peut-être être meilleurs. Une planification et une préparation valent mieux que rien du tout - ce que font beaucoup de développeurs.

Que devrait idéalement aller dans un FS? Autant que nécessaire et le moins possible. Juste parce que certaines spécifications fonctionnelles couvrent X, Y & amp; Z ne veut pas dire que le vôtre le devrait. Si vous devenez trop normatif, vous ajouterez une bureaucratie inutile à des projets plus simples. de même, dans le cas de projets complexes, une approche normative pourrait encourager le développeur à se limiter au niveau de détail auquel il devrait réellement aller.

Answer 2

Joel on Software a écrit un article déchirant sur les spécifications.

Vous pouvez le trouver ici Discussion sur les spécifications