Resposta curta : 830-1998 não é um padrão, é uma prática recomendada para escrever SRS no estilo de 1998.
Não consigo encontrar como foi substituído (mesmo com a pesquisa avançada do IEEE :()
Mas acho que é porque todo o método de especificar requisitos mudou drasticamente nos últimos anos.
Então, a partir de agora, tento responder a uma pergunta modificada:
Quais são as melhores práticas industriais / Quais são as melhores práticas recomendadas para escrever SRSs no estilo de 2012?
Nos métodos clássicos:
Normalmente, eu uso as recomendações da IEEE 1471 para documentação de software, embora essa também tenha sido substituída recentemente pela ISO / IEC 42010. Esse é um tipo de documentação muito complexo, é usado principalmente para transferências, embora contenha principalmente os requisitos (é o capítulo 7 no novo documento de estilo ISO)
Um livro moderadamente bom sobre documentação formal é o Documenting Software Architectures , um livro surpreendentemente bom é o livro iconix antigo e um clássico antigo é o caso de uso eficaz de escrita de Cockburn .
Sobre como é realmente feito no setor hoje:
Para dizer a verdade, a documentação formal do projeto, especialmente a documentação de requisitos, foi eliminada principalmente na era do Agile , pois o Manifesto do Agile desencoraja a documentação formal. Não há ninguém,, grande especificação formal único, mas em vez disso, não são chamados histórias de usuários , atrasos de produtos e tal. Isso ocorre devido ao desenvolvimento iterativo, apenas alguns recursos são especificados informalmente para cada ciclo de 2 a 4 semanas. Um livro de renome é User Stories Applied .
Existem especificações ditas "executáveis", que são formais , pois são essencialmente DSLs (linguagens específicas do domínio) para teste. Eles não são melhores nem piores que o OCL da UML , mas são mais fáceis de entender, talvez, mas também menos científicos. A maioria deles é chamada de estruturas BDD, e exemplos incluem FitNesse , Cucumber , Jasmine - você encontrará muitos deles. Também existem livros de renome sobre BDD e TDD em geral.
Além disso, as especificações dos engenheiros de software foram substituídas pelo design de UX , incluindo arquitetura de informações e design de interação, por isso não é feito por pessoas que realmente podem codificar atualmente, o que pode levar a conflitos às vezes. Este é um exemplo não tão ruim de como se parece (não é um padrão!), Mas você encontrará muito mais dentro da comunidade de interação / UX, mas há até um site de troca de pilhas separado para eles. Eles têm seus próprios padrões, práticas recomendadas, etc.
Mas e se você quiser ficar com os métodos antigos, por exemplo. para o trabalho da universidade?
Em geral, tente aderir ao IEEE 830 (não é possível encontrar em sua página da Web o que foi substituído, embora o IEEE nunca tenha sido bom com isso, acho que é porque isso não importa mais, infelizmente) e certifique-se de tentar registrar informações úteis (por exemplo, não acho que uma única figura do ator -> um único balão com um assunto verbal seja considerado útil) a partir da qual os objetivos gerais dos usuários, a faixa geral de usuários e os métodos gerais de o uso pode ser reconstruído a qualquer momento.
Por que você recomenda livros? Por que você não me mostra os padrões?
Mais uma vez, acho que esse documento foi "superado" porque hoje temos um pouco de caos em torno da especificação de requisitos: existem muitos pontos de vista sobre como deve ser feito.
Não existe uma autoridade única capaz de lhe dizer: "é assim que as especificações devem ser feitas" . Existem práticas recomendadas , e tentei fornecer uma lista representativa de documentos e instruções , embora de maneira alguma completa, e talvez pessoalmente tendenciosa.
No final das contas, o que importa é se o documento que você cria é capaz de cumprir todos os objetivos de todas as pessoas que já o leram : o que as pessoas querem ver, o que as pessoas precisam saber para entender os requisitos são bastante bem descritos nesses livros, e essas são as práticas recomendadas por si só, embora em comunidades muito menores do que em uma única comunidade de TI indivisa do que tínhamos talvez em 1998.