Respuesta corta : 830-1998 no es un estándar, es una mejor práctica recomendada sobre cómo escribir SRS al estilo de 1998.
No puedo encontrar cómo se superó (incluso con la búsqueda avanzada de IEEE :()
Pero supongo que es porque todo el método sobre cómo especificamos los requisitos ha cambiado drásticamente en los últimos años.
Entonces, a partir de ahora, trato de responder un poco de pregunta modificada:
¿Cuál es la mejor práctica industrial / ¿Cuáles son las mejores prácticas recomendadas para escribir SRS al estilo de 2012?
En métodos clásicos:
Por lo general, uso las recomendaciones IEEE 1471 para la documentación del software, aunque eso también fue reemplazado recientemente por ISO / IEC 42010. Este es un tipo de documentación muy complejo, se usa principalmente para traspasos, aunque contiene principalmente los requisitos (es el capítulo 7 en el nuevo documento de estilo ISO)
Un libro moderadamente bueno sobre documentación formal es Documenting Software Architectures , un libro sorprendentemente bueno es el viejo libro iconix , y un viejo clásico es Escritura de casos de uso efectivo de Cockburn .
Sobre cómo se hace actualmente en la industria hoy:
A decir verdad, la documentación formal del proyecto, especialmente la documentación de requisitos, se eliminó principalmente en la era de Agile , ya que el Manifiesto Ágil desalienta la documentación formal. No existe una especificación formal única, grande, pero en su lugar, existen las llamadas historias de usuarios , los atrasos de productos y demás . Esto se debe al desarrollo iterativo, solo un puñado de características se especifican informalmente para cada ciclo de 2-4 semanas. Un libro de renombre es User Stories Applied .
Existen las denominadas especificaciones "ejecutables", que son formales , ya que son esencialmente lenguajes específicos de dominio (DSL) para pruebas. No son mejores ni peores que el OCL de UML , pero quizás son más fáciles de entender pero también menos científicos. La mayoría de ellos se denominan marcos BDD, y los ejemplos incluyen FitNesse , Cucumber , Jasmine ; encontrarás una gran cantidad de estos. También hay libros de renombre sobre BDD y TDD en general.
Además, la especificación de los ingenieros de software fue superada por el diseño de UX , incluida la arquitectura de la información y el diseño de interacción, por lo que no lo hacen personas que realmente pueden codificar en la actualidad, lo que a veces puede generar conflictos. Este es un ejemplo no tan malo de cómo se ve (¡no es un estándar!), Pero encontrará mucho más dentro de la comunidad UX / interacción, pero incluso hay un sitio de intercambio de pila completamente separado para ellos. Tienen sus propios estándares, mejores prácticas recomendadas, etc.
Pero, ¿qué pasa si quieres seguir con los viejos métodos, por ejemplo para el trabajo universitario?
En general, intente adherirse al IEEE 830 (no puedo encontrar en su página web con qué fue reemplazado, aunque IEEE nunca fue bueno con esto, supongo que es porque desafortunadamente ya no importa), y asegúrese de intentarlo para registrar información útil (por ejemplo, no creo que una sola figura de actor -> una sola burbuja con un tema verbal se considere útil) a partir de la cual los objetivos generales de los usuarios, el rango general de usuarios y los métodos generales de El uso puede ser reconstruido en cualquier momento.
¿Por qué me recomiendan libros? ¿Por qué no me muestras estándares?
Una vez más, supongo que este documento fue "superado" porque hoy en día, tenemos un poco de caos en torno a la especificación de requisitos: hay muchos puntos de vista sobre cómo debería hacerse.
No existe una autoridad única que pueda decirle: "así es como deben hacerse las especificaciones" . Hay mejores prácticas , y traté de proporcionarle una lista representativa de documentos e instrucciones , aunque de ninguna manera completa, y quizás sesgada personalmente.
Al final del día, lo que importa es si el documento que crea es capaz de cumplir con todos los objetivos que todas las personas que lo leyeron tienen : lo que la gente quiere ver, lo que la gente necesita saber para comprender los requisitos. están bastante bien descritos en estos libros, y estas son las mejores prácticas por derecho propio, aunque en comunidades mucho más pequeñas que una comunidad de TI única e indivisa, lo que quizás tuvimos en 1998.