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


15

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)?


Réponses:


16

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


10

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. ..


@gnat Je ne pense pas que la citation de l'article soit nécessaire. Si vous souhaitez mettre en évidence votre choix d'extraits, je vous suggère de poster votre propre réponse à la question.
Jonathan Swinney

pensez à lire votre réponse est dans un autre château: quand une réponse n'est-elle pas une réponse? "laissez-moi être clair: ce genre de réponse n'est pas une réponse . Si vous voyez cela, signalez-le. Modérateurs, si vous le voyez marqué, supprimez-le "
moucher

1
Si vous n'êtes pas d'accord avec les extraits cités, n'hésitez pas à les modifier. Cependant, le fait d'avoir une réponse qui n'est qu'un lien n'est pas considéré comme une bonne réponse et peut être supprimé en vertu de nos politiques de qualité. Un article qui fait référence à une ressource ou une référence hors site doit fournir suffisamment d'informations pour continuer à ajouter de la valeur si le lien n'est pas accessible pour une raison quelconque.
Thomas Owens

6

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.


4

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 "

Vos exemples ne sont pas des exigences, ils sont de conception. Les détails sur la façon dont l'exigence doit être satisfaite sont une décision de conception, pas une exigence. Ainsi, "deux boutons" est une décision de conception. Cela devient évident lorsque vous réalisez qu'il existe de nombreuses autres façons valables d'atteindre le même objectif (démarrer ou arrêter quelque chose). Ainsi, pour en faire davantage une exigence, vous diriez "L'interface utilisateur doit fournir un moyen de démarrer et d'arrêter quelque chose". Mais j'irais plus loin, car l'utilisation d'une interface utilisateur est également une décision de conception. Donc, pour l'exigence du système, ce serait "Le système doit fournir un moyen de démarrer et d'arrêter quelque chose"
Dunk
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.