it-swarm-fr.com

Écrire une spécification d'exigence logicielle

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

  1. Lorsque nous écrivons une spécification logicielle, sous la rubrique "Définition des exigences de l'utilisateur", nous devons spécifier les "fonctions" et les "contraintes" uniquement?

  2. Est-ce que "l'interface utilisateur" tombe dans "fonctions" ou "contraintes"?

  3. Quels sont les principaux domaines clés (exigences) qu'un logiciel peut être divisé (par exemple, UI)?

15
Mafahir Fairoze

Tandis que je ne suis pas un gros fan de rassemblement Tous Les exigences en détail à l'avant (comme elles sont soumises à tant de changements au cours d'un projet non trivial ), Si vous écriez des documents d'exigences, le modèle de spécification Exigences de FIXERE est un excellent guide.

Bien que cela puisse être surchargé pour certains projets, il offre une bonne liste de contrôle des choses à réfléchir, même si elle vient de vérifier mentalement la liste que vous n'avez pas besoin de cet article 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 de configuration - qui est effectivement moins coûteux que le modèle et contient le texte de modèle complet) contient beaucoup d'informations, d'exemples et de conseils dans les différentes sections de Que devrait aller dans chaque section.

Voici un résumé des sections de celui-ci (cité du lien ci-dessus):

  1. Le but du projet

  2. Les parties prenantes

  3. Contraintes mandatées

  4. Nommer des conventions 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. Regarder et ressentir des exigences

  11. Exigences de convivialité et d'humanité

  12. Exigences de performance

  13. Exigences opérationnelles et environnementales

  14. Conditions de maintenabilité et de soutien

  15. Exigences de sécurité

  16. Exigences culturelles et politiques

  17. Exigences légales

  18. Questions ouvertes

  19. Solutions hors tension

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

16
Paddyslacker

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 cela 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 sur vous-même tout par vous-même, et que vous écrivez une spécification uniquement pour votre propre avantage, l'acte de rédaction de la spécification - décrivant comment le programme fonctionne dans les détails des minutes - vous vous obligera à réellement conception le programme ...

... Lorsque vous concevez votre produit dans une langue humaine, cela ne prend que quelques minutes pour essayer de penser à plusieurs possibilités, de réviser et d'améliorer votre conception. Personne ne se sent mal quand ils suppriment un paragraphe dans un traitement de texte. Mais lorsque vous concevez votre produit dans un langage de programmation, il faut semaines Pour faire des conceptions itératives. Ce qui est pire, un programmeur qui vient de passer 2 semaines d'écrire du code va être assez attaché à ce code, peu importe la fausse ...

... Lorsque vous écrivez une spécification, il vous suffit de communiquer comment le programme est censé travailler une fois. Tout le monde de l'équipe peut simplement lire les spécifications. Les personnes QA le lisent afin qu'ils sachent comment le programme est censé travailler et ils savent quoi tester. Les personnes marketing l'utilisent pour écrire leurs papiers blancs vaporware vagues pour vomir sur le site Web sur les produits qui n'ont pas encore été créés. Les gens du développement des affaires ont mal interprété de tourner les fantasmes étranges sur la façon dont le produit guérira la calvitie et les verrues, mais cela reçoit des investisseurs, c'est bon. Les développeurs le lisent afin qu'ils sachent quel code écrire. Les clients le lisent pour s'assurer que les développeurs construisent un produit qu'ils voudraient payer. Les écrivains techniques le lisent et écrivent un joli manuel ...

Lorsque vous n'avez pas de spécification, toute cette communication se produit toujours, parce que cela doit, mais cela arrive ad hoc. Le peuple QA rigide avec le programme Willy-Nilly, et quand quelque chose a l'air étrange, ils vont interrompre les programmeurs encore une fois Pour leur demander Un autre question stupide sur comment la chose est censée travailler ...

sans une spécification détaillée, il est impossible de faire un calendrier ... dans trop d'organisations de programmation, chaque fois qu'il y a un débat de conception, personne ne gère jamais de prendre une décision, généralement pour des raisons politiques. Les programmeurs ne fonctionnent donc que sur des trucs non controversés. Au fil du temps, toutes les décisions dures sont poussées à la fin ... Écrire 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. ..

10
Jonathan Swinney

Lorsque nous écrivons une spécification logicielle, sous la rubrique "Définition des exigences de l'utilisateur", nous devons spécifier les "fonctions" et les "contraintes" uniquement?

Une exigence est une combinaison de deux choses ...

  1. Quelle est la chose. Exigence fonctionnelle.
  2. Comment ça fait ça. Exigence non fonctionnelle ou "contrainte"

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

Je dirais que "l'interface utilisateur" serait la catégorie d'exigences que vous avez identifiées dans votre dernière question.

Quels sont les principaux domaines clés (exigences) qu'un logiciel peut être divisé (par exemple, UI)?

Cela dépend du logiciel. Vous pouvez regrouper des exigences en groupe basées sur des parties du système ou vous pouvez les regrouper en fonction du cas d'utilisation ou de l'obligation d'activité que les fonctions sont remplies.

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

6
Henry