SRS(software requirements specification) o ERS (Especificación de requerimientos de software) es un conjunto de recomendaciones para la especificación de los requerimiento o requisitos de software el cuál tiene como producto final la documentación de los acuerdos entre el cliente y el grupo de desarrollo para así cumplir con la totalidad de exigencias estipuladas.

Los requerimientos funcionales...

• Deben estar redactados de tal forma que sean comprensibles para usuarios sin conocimientos técnicos avanzados.

• Deben especificar el comportamiento externo del sistema y evitar, en la medida de lo posible, establecer características de su diseño.

• Deben priorizarse (al menos, se ha de distinguir entre requisitos obligatorios y requisitos deseables).

Los requerimientos no funcionales…

• Han de especificarse cuantitativamente, siempre que sea posible (para que se pueda verificar su cumplimiento).

Los requisitos funcionales definen qué debe hacer un sistema.

Los requisitos no funcionales definen cómo debe ser el sistema.

La distinción entre requerimientos funcionales y no funcionales no siempre resulta evidente.

Ejemplo: La seguridad puede interpretarse inicialmente como un requerimiento no funcional al principio. No obstante, su elaboración puede conducir a nuevos requerimientos funcionales, como la necesidad de autentificar a los usuarios del sistema.

Más allá de si decidimos incluir este tipo de requisitos en una sección u otra, lo importante es identificarlos correctamente.

Los requerimientos han de ser…

• Claros y concretos                                 (evitando imprecisiones y ambigüedades) p.ej. Uso de puntos suspensivos, etcétera…
• Concisos                                                            (sin rodeos ni figuras retóricas)
• Completos y consistentes

Los requerimientos han de indicar…

• Lo que se espera que haga el sistema (¿qué?)
• Su justificación                                              (¿por qué ha de ser así? ¿quién lo propuso?)
• Y en su caso, los criterios de aceptación que sean aplicables (¿cómo se verifica su cumplimiento?).

• El sistema será lo más fácil de utilizar posible.

• El sistema proporcionará una respuesta rápida al usuario.

• El sistema se recuperará automáticamente tras producirse un fallo.

MAL

¿Por qué? Objetivos generales, vagos y abiertos a distintas interpretaciones.

• Un usuario experimentado debe ser capaz de utilizar todas las funciones del sistema tras un entrenamiento de 2 horas, tras el cual no cometerá más de 3 errores diarios en media.

• Cuando haya hasta 100 usuarios accediendo simultáneamente al sistema, su tiempo de respuesta no será en ningún momento superior a 2 segundos.

• Ante un fallo en el software del sistema, no se tardará más de 5 minutos en restaurar los datos del sistema (en un estado válido) y volver a poner en marcha el sistema.

BIEN

¿Por qué? 

Requisitos verificables.