Risposta breve : 830-1998 non è uno standard, è una best practice consigliata su come scrivere SRS nello stile del 1998.
Non riesco a trovare come è stato sostituito (anche con la ricerca avanzata dell'IEEE :()
Ma credo sia perché l'intero metodo su come specifichiamo i requisiti è cambiato drasticamente negli ultimi anni.
Quindi, da ora in poi, provo a rispondere a una domanda modificata:
Quali sono le migliori pratiche industriali / Quali sono le migliori pratiche consigliate per la scrittura di SRS nello stile del 2012?
Sui metodi classici:
Di solito utilizzo i consigli IEEE 1471 per la documentazione del software, anche se recentemente è stato superato da ISO / IEC 42010. Questo è un tipo di documentazione molto complesso, viene utilizzato principalmente per i passaggi di mano, sebbene contenga principalmente i requisiti (è il capitolo 7 della nuovo documento in stile ISO)
Un libro moderatamente buono sulla documentazione formale è Documenting Software Architectures , un libro sorprendentemente buono è il vecchio libro iconix , e un vecchio classico sono i casi di scrittura efficace di Cockburn .
Su come viene effettivamente fatto oggi nel settore:
A dire la verità, la documentazione formale del progetto, in particolare la documentazione sui requisiti, è stata eliminata principalmente nell'età di Agile , poiché il Manifesto Agile scoraggia la documentazione formale. Non esiste una specifica unica, singola e di grandi dimensioni, ma esistono invece cosiddette storie utente , arretrati di prodotti e simili. Ciò è dovuto allo sviluppo iterativo, solo una manciata di funzioni sono specificate in modo informale per ciascun ciclo di 2-4 settimane. Un libro rinomato è User Stories Applied .
Esistono specifiche cosiddette "eseguibili", che sono formali , poiché sono essenzialmente linguaggi specifici di dominio (DSL) per i test. Essi non sono meglio o peggio di quella di UML OCL , ma sono più facili da cogliere, forse, ma anche meno scientifica. Molti di questi sono chiamati framework BDD, e alcuni esempi includono FitNesse , Cucumber , Jasmine : ne troverai molti . Ci sono anche libri famosi su BDD e TDD in generale.
Inoltre, le specifiche degli ingegneri del software sono state sostituite dalla progettazione di UX , compresa l'architettura delle informazioni e la progettazione delle interazioni, quindi non sono fatte da persone che possono effettivamente codificare al giorno d'oggi, il che può portare a conflitti a volte. Questo è un esempio non male di come appare (non è uno standard!), Ma troverai molto di più all'interno della comunità UX / interazione, ma c'è anche un sito stackexchange completamente separato per loro. Hanno i loro standard, le migliori pratiche consigliate, ecc.
Ma cosa succede se si desidera attenersi ai vecchi metodi, ad es. per lavoro universitario?
In generale, prova ad aderire a IEEE 830 (non riesco a trovare sulla loro pagina web con cosa è stato superato, anche se IEEE non è mai stato bravo con questo, suppongo sia perché sfortunatamente non conta più) e assicurati di provare per registrare informazioni utili (ad esempio, non penso che una singola figura stilizzata dell'attore -> una singola bolla con un soggetto verbo sia considerata utile) da cui gli obiettivi generali degli utenti, la gamma complessiva degli utenti e i metodi generali di l'utilizzo può essere ricostruito in qualsiasi momento.
Perché consigli i libri? Perché invece non mi mostri standard?
Ancora una volta, immagino che questo documento sia stato "superato" perché oggi abbiamo un po 'di caos attorno alla specifica dei requisiti: ci sono molti punti di vista su come dovrebbe essere fatto.
Non esiste un'unica autorità in grado di dirti: "ecco come devono essere fatte le specifiche" . Esistono buone pratiche e ho cercato di fornirti un elenco rappresentativo di documenti e indicazioni , anche se non completo, e forse di parte.
Alla fine della giornata, ciò che conta è se il documento che crei è in grado di soddisfare tutti gli obiettivi che tutte le persone che lo leggono hanno con sé : ciò che le persone vogliono vedere, ciò che le persone devono sapere per comprendere i requisiti sono piuttosto ben descritti in questi libri, e queste sono le migliori pratiche a sé stanti, sebbene in comunità molto più piccole di una singola comunità IT indivisa, ciò che forse abbiamo avuto nel 1998.