Rédaction d'une spécification d'exigence logicielle

J'ai quelques questions sur la rédaction d'une spécification et elles sont:

1. Lorsque nous écrivons une spécification logicielle, sous la rubrique "Définition des besoins des utilisateurs", nous devons spécifier uniquement les "Fonctions" et les "Contraintes"?

2. Est-ce que l '"interface utilisateur" relève des "fonctions" ou des "contraintes"?

3. Quels sont les principaux domaines clés (exigences) dans lesquels un logiciel peut être divisé (par exemple, l'interface utilisateur)?

Bien que je ne suis pas un grand fan de rassembler toutes les exigences en détail à l'avance (car elles sont sujettes à tant de changements au cours d'un projet non trivial), si vous écrivez des documents d'exigences, le modèle de spécification des exigences Volere est un excellent guide .

Bien que cela puisse être exagéré pour certains projets, il fournit une excellente liste de choses à penser, même si c'est juste pour cocher mentalement la liste que vous n'avez pas besoin de cet élément pour cette exigence.

Voici un lien vers plus d'informations sur le modèle:

http://www.volere.co.uk/template.htm

Le modèle lui-même (et le livre Maîtriser le processus des exigences - qui est en fait légèrement moins cher que le modèle et contient le texte complet du modèle) contient beaucoup d'informations, d'exemples et de conseils dans les différentes sections quant à ce qui devrait aller dans chaque section.

Voici un résumé des sections qu'il contient (citées à partir du lien ci-dessus):

1. Le but du projet

2. Les intervenants

3. Contraintes obligatoires

4. Conventions de dénomination et définitions

5. Faits et hypothèses pertinents

6. La portée du travail

7. Modèle de données d'entreprise et dictionnaire de données

8. La portée du produit

9. Exigences fonctionnelles et de données

10. Exigences relatives à l'apparence

11. Conditions d'utilisation et d'humanité

12. Exigences de performance

13. Exigences opérationnelles et environnementales

14. Maintenabilité et exigences de support

15. Exigences de sécurité

16. Exigences culturelles et politiques

17. Exigences légales

18. Questions ouvertes

19. Solutions prêtes à l'emploi

20. De nouveaux problèmes

21. Tâches

22. Migration vers le nouveau produit

23. Des risques

24. Frais

25. Documentation utilisateur et formation

26. Salle d'attente

27. Idées de solutions

Je recommande de lire Joel sur le logiciel. Je ne sais pas si cela répond à vos questions spécifiques, mais il a un excellent aperçu de ce que signifie écrire des spécifications fonctionnelles :

La fonction la plus importante d'une spécification est de concevoir le programme . Même si vous travaillez vous-même sur du code et que vous écrivez une spécification uniquement pour votre propre bénéfice, le fait d'écrire la spécification - décrivant comment le programme fonctionne dans les moindres détails - vous obligera à réellement concevoir le programme ...

... lorsque vous concevez votre produit dans un langage humain, il ne faut que quelques minutes pour réfléchir à plusieurs possibilités, réviser et améliorer votre conception. Personne ne se sent mal quand il supprime un paragraphe dans un traitement de texte. Mais lorsque vous concevez votre produit dans un langage de programmation, il faut des semaines pour réaliser des conceptions itératives. Pire encore, un programmeur qui vient de passer 2 semaines à écrire du code va être très attaché à ce code, peu importe à quel point c'est faux ...

... Lorsque vous écrivez une spécification, il suffit de communiquer la façon dont le programme est censé fonctionner une fois . Tout le monde dans l'équipe peut simplement lire la spécification. Les personnes chargées de l'assurance qualité l'ont lu pour savoir comment le programme est censé fonctionner et pour quoi tester. Les responsables marketing l'utilisent pour rédiger leurs vagues livres blancs vaporware à publier sur le site Web sur des produits qui n'ont pas encore été créés. Les gens du développement commercial l'ont mal lu pour faire tourner des fantasmes étranges sur la façon dont le produit guérira la calvitie et les verrues et autres, mais cela attire les investisseurs, donc ça va. Les développeurs l'ont lu pour savoir quel code écrire. Les clients l'ont lu pour s'assurer que les développeurs construisent un produit qu'ils voudraient payer. Les rédacteurs techniques l'ont lu et écrit un beau manuel ...

Lorsque vous n'avez pas de spécification, toute cette communication se produit toujours, car elle doit l'être , mais elle se produit de manière ponctuelle . Les gens de l'AQ s'amusent avec le programme bon gré mal gré, et quand quelque chose semble étrange, ils vont encore une fois interrompre les programmeurs pour leur poser une autre question stupide sur la façon dont la chose est censée fonctionner ...

sans un cahier des charges détaillé, il est impossible de faire un planning ... Dans trop d'organismes de programmation, à chaque fois qu'il y a un débat sur le design, personne ne parvient jamais à prendre une décision, généralement pour des raisons politiques. Les programmeurs ne travaillent donc que sur des choses non controversées. Au fil du temps, toutes les décisions difficiles sont poussées jusqu'au bout ... La rédaction d'une spécification est un excellent moyen de clouer toutes ces décisions de conception irritantes, grandes et petites, qui sont couvertes si vous n'avez pas de spécification. ..

Lorsque nous écrivons une spécification logicielle, sous la rubrique "Définition des besoins des utilisateurs", nous devons spécifier uniquement les "Fonctions" et les "Contraintes"?

Une exigence est une combinaison de deux choses ...

1. Ce que fait la chose. Exigence fonctionnelle.
2. Comme il le fait bien. Exigence non fonctionnelle ou «contrainte»

Est-ce que l '"interface utilisateur" entre dans les "fonctions" ou les "contraintes"?

Je dirais que "Interface utilisateur" serait une catégorie d'exigences comme vous l'avez identifié dans votre dernière question.

Quels sont les principaux domaines clés (exigences) dans lesquels un logiciel peut être divisé (par exemple, l'interface utilisateur)?

Cela dépend du logiciel. Vous pouvez regrouper les exigences en fonction de parties du système ou vous pouvez les regrouper en fonction du cas d'utilisation ou de l'exigence métier que les fonctions remplissent.

Bien sûr, tout cela est secondaire par rapport à votre objectif réel qui est de déterminer une description claire, non ambiguë et testable du système logiciel.

La principale exigence d'une exigence est qu'elle peut être testée. Si vous ne savez pas comment tester une exigence, il y a de fortes chances qu'elle ne soit pas implémentée comme le rédacteur le souhaitait.

Je n'ai jamais vu un document d'exigences limité aux fonctions et contraintes uniquement, mais je peux voir une certaine valeur à avoir une structure comme celle-ci - cela oblige le rédacteur à classer les exigences en «choses que le logiciel doit faire» et «règle les logiciel doit suivre. "

Je pense qu'une interface utilisateur a des exigences dans les deux catégories

Contraintes:

• "l'écran de démarrage doit afficher deux boutons:" Démarrer "et" Arrêter "
• "La police d'affichage ne doit pas être inférieure à 10 points."

Les fonctions:

• "Lorsque la Starttouche est enfoncée, le logiciel établit une connexion TCP / IP avec WOPR "