SRS
¿Que es?
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.
Requerimientos funcionales
Expresan la naturaleza del funcionamiento del sistema (cómo interacciona el sistema con su entorno y cuáles van a ser su estado y funcionamiento).
NOTA: A veces, también es conveniente indicar lo que no hará el sistema.
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).
Requerimientos no funcionales
Restricciones sobre el espacio de posibles soluciones.
- Rendimiento del sistema: Fiabilidad, tiempo de respuesta, disponibilidad…
- Interfaces: Dispositivos de E/S, usabilidad, interoperabilidad
- Proceso de desarrollo: Estándares, herramientas, plazo de entrega…
Los requerimientos no funcionales…
- Han de especificarse cuantitativamente, siempre que sea posible (para que se pueda verificar su cumplimiento).
RESUMEN
Los requisitos funcionales definen qué debe hacer un sistema.
Los requisitos no funcionales definen cómo debe ser el sistema.
A los requisitos no funcionales se les suele llamar coloquialmente “cualidades” del sistema [“-ilities” en inglés”] y pueden dividirse en dos categorías:
Cualidades de ejecución, como la seguridad o la usabilidad, observables en tiempo de ejecución.
Cualidades de evolución, como la “testabilidad”, mantenibilidad, extensibilidad o escalabilidad, determinadas por la estructura estática del software.
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...
- Se suelen especificar en lenguaje natural
- Se expresan de forma individual (p.ej. esquemáticamente)
- Se organizan de forma jerárquica (a distintos niveles de detalle)
- A menudo, se numeran (para facilitar su gestión)
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?).
Miremos un ejemplo
-
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.
Eso es todo amigos, me voy...
Hecho por Alejandro Gonzalez
@m4g5
