Réponse courte : 830-1998 n'est pas une norme, c'est une meilleure pratique recommandée sur la façon d'écrire SRS dans le style de 1998.
Je ne trouve pas comment il a été super-semé (même avec la recherche avancée de l'IEEE :()
Mais je suppose que c'est parce que toute la méthode sur la façon dont nous spécifions les exigences a radicalement changé ces dernières années.
Donc, à partir de maintenant, j'essaie de répondre à une question modifiée:
Quelles sont les meilleures pratiques industrielles / Quelles sont les meilleures pratiques recommandées pour la rédaction de SRS dans le style de 2012?
Sur les méthodes classiques:
Habituellement, j'utilise les recommandations IEEE 1471 pour la documentation du logiciel, bien que cela ait également été récemment remplacé par ISO / IEC 42010. Il s'agit d'un type de documentation très complexe, il est principalement utilisé pour les transferts, bien qu'il contienne principalement les exigences (c'est le chapitre 7 dans le nouveau document de style ISO)
Un livre moyennement bon sur la documentation formelle est Documenting Software Architectures , un livre étonnamment bon est l' ancien livre iconix , et un vieux classique est les cas d'utilisation efficace de l'écriture de Cockburn .
Comment cela se fait actuellement dans l'industrie:
À vrai dire, la documentation formelle du projet, en particulier la documentation des exigences, a été détruite principalement à l'ère de l'Agile , car le Manifeste Agile décourage la documentation formelle. Il n'y a pas de spécification formelle unique, large, mais à la place, il y a ce qu'on appelle des user stories , des backlogs de produits et autres. Cela est dû au développement itératif, seules quelques fonctionnalités sont spécifiées de manière informelle pour chaque cycle de 2 à 4 semaines. Un livre de renom est User Stories Applied .
Il existe des spécifications dites «exécutables», qui sont formelles , car ce sont essentiellement des langages spécifiques au domaine (DSL) pour les tests. Ils ne sont ni meilleurs ni pires que OCL d'UML , mais ils sont peut-être plus faciles à saisir mais aussi moins scientifiques. La plupart d'entre eux sont appelés frameworks BDD, et des exemples incluent FitNesse , Cucumber , Jasmine - vous en trouverez un grand nombre. Il existe également des livres renommés sur le BDD et le TDD en général.
De plus, les spécifications des ingénieurs logiciels ont été remplacées par la conception UX , y compris l'architecture de l'information et la conception d'interaction, de sorte que cela n'est pas fait par des personnes qui peuvent réellement coder de nos jours, ce qui peut parfois entraîner des conflits. Ceci n'est pas un si mauvais exemple sur la façon dont on ressemble (ce n'est pas un standard!), Mais vous en trouverez beaucoup plus au sein de la communauté UX / interaction, mais il y a même un site d' échange de piles distinct pour eux. Ils ont leurs propres normes, meilleures pratiques recommandées, etc.
Mais que faire si vous voulez vous en tenir aux anciennes méthodes, par exemple. pour un travail universitaire?
En général, essayez d'adhérer à l'IEEE 830 (vous ne pouvez pas trouver sur leur page Web de quoi il a été remplacé, bien que l'IEEE n'ait jamais été bon avec cela, je suppose que c'est parce que cela n'a plus d'importance malheureusement), et assurez-vous d'essayer pour enregistrer des informations utiles (par exemple, je ne pense pas qu'une seule figure de bâton d'acteur -> seule bulle avec un verbe-sujet soit considérée comme utile) à partir de laquelle les objectifs globaux des utilisateurs, la gamme globale des utilisateurs et les méthodes globales de l'utilisation peut être reconstruite à tout moment.
Pourquoi recommandez-vous des livres? Pourquoi ne me montrez-vous pas des normes à la place?
Encore une fois, je suppose que ce document a été "dépassé" parce qu'aujourd'hui, nous avons un peu de chaos autour de la spécification des exigences: il existe de nombreux points de vue sur la façon de le faire.
Aucune autorité n'est en mesure de vous dire: "c'est ainsi que les spécifications doivent être établies" . Il existe des pratiques exemplaires et j'ai essayé de vous fournir une liste représentative de documents et de directives , bien que nullement complète, et peut-être personnelle.
À la fin de la journée, ce qui importe, c'est de savoir si le document que vous créez est capable d'atteindre tous les objectifs que toutes les personnes qui l'ont lu ont avec lui : ce que les gens veulent voir, ce que les gens doivent savoir pour comprendre les exigences. sont assez bien décrits dans ces livres, et ce sont les meilleures pratiques à part entière, bien que dans des communautés beaucoup plus petites qu'une communauté informatique unique, ce que nous avions peut-être en 1998.