ORDENADO POR GRADO DE IMPORTANCIA O ESTABILIDAD

Cada requerimiento especificado debe tener alguna identificación (número, letra, secuencia alfanumérica) para indicar su grado de importancia o de estabilidad
Algunos requerimientos son más importantes que otros
Al “rankearlos” se puede dar a cada requerimiento la atención que se merece
El SRS es completo si incluye:
– Todos los requerimientos significativos sobre funcionalidades, desempeño, restricciones de diseño, atributos, o interfaces externas
– Las respuestas que debería dar el software a todas las posibles entradas de datos en todas las situaciones posibles (entradas aceptables o no aceptables: validación)
– Especificación de unidades de medida (si son aplicables)
– En caso de que el SRS tenga diagramas o tablas informativas, hay que darles número o identificación

EVOLUCIÓN DEL SRS

- Un SRS puede necesitar cambios mientras el software está en etapas de diseño o de desarrollo
- Los cambios pueden estar motivados por: deficiencias, errores, omisiones o imprecisiones en el documento original
- Cada requerimiento debe documentarse tan completo como sea posible, aún si pudiera necesitar cambios posteriormente
- Los cambios en los requerimientos tienen que documentarse con el propósito de: identificarlos, controlarlos, rastrearlos, y reportarlos
- Tanto el cliente como el proveedor deben designar a su respectivo responsable de autorizar (o rechazar) cambios en los requerimientos

CREACIÓN DE PROTOTIPOS

• l El prototipo es útil para:
  – Que el cliente/usuario vea y describa más fácilmente las funcionalidades que desea
  – Prever aspectos de la conducta del sistema, haciendo que el SRS sea más completo y preciso
  – Reducir la cantidad de cambios durante las etapas de diseño o desarrollo

CONTENIDO DE UN SRS

Debe incluir una descripción general del SRS, mostrando lo siguiente:
Propósito del documento
Alcance
Definiciones, acrónimos, y abreviaturas
Referencias
Descripción general del documento

DISEÑO “IMPLÍCITO” EN EL SRS

l Aunque el SRS no constituye un documento de diseño, implícitamente está diciéndole a los desarrolladores lo que se espera que ellos diseñen
– Establece restricciones
l El SRS tiene que especificar las funcionalidades que se aplicarán sobre ciertos datos para producir resultados en cierto lugar para determinados usuarios

Contextualizacion

SRS
El SRS es una especificación para un producto de software en particular, ya sea un sólo programaa, o un conjunto de programas, que realicen ciertas funciones en un ambiente específico
NATURALEZA DEL SRS
Frecuentemente, el usuario sólo conoce las necesidades pero no el tipo de solución más conveniente. El SRS puede escribirse por uno o más representantes del proveedor, uno o más del cliente, o por ambos Lo más recomendable es que haya representantes de ambas partes
El usuario/cliente puede redactar un borrador inicial y después revisarlo con el proveedor

-Funcionalidades deseadas
-Interfaces externas
-Desempeño

Atributos (seguridad, portabilidad, mantenibilidad, etc.)

Restricciones de diseño impuestas a la implementación (estándares técnicos propios o internacionales, lenguaje de progr., sistema operativo, límites de recursos, políticas internas).

AMBIENTE DEL SRS
El SRS es la fuente principal para hacer el plan detallado de un proyecto de software

Un SRS puede referirse a los requerimientos deseados de todos los componentes de un sistema grande, o a componentes (módulos) individuales del mismo. Si se hacen SRS por separado para varios módulos, tiene que mantenerse la consistencia en los documentos. Si un software necesita interactuar con otro, tienen que especificarse los requerimientos de esa interacción (interfaces), definiendo sus funcionalidades y el nivel de desempeño deseado.

Antes de empesasr
Para definir los requerimientos de un software, podemos apoyarnos en una norma que nos guía
para hacer las preguntas pertinentes: IEEE 830
Esta norma le sirve tanto al usuario/cliente como al desarrollador

Un cliente describa claramente lo que quiere
Un proveedor entienda claramente lo que el cliente quiere
Se establezcan bases para un contrato de desarrollo (o de compra-venta)
Se reduzca el esfuerzo de análisis, diseño, y programación (evitando re-trabajos)
Se tenga una base o referencia para validar o probar el software solicitado
Se facilite el traspaso del software a otros clientes/usuarios
Se le puedan hacer mejoras (o innovaciones) a ese software