1. Es
1.1. conjunto de características necesarias para la obtención de una buena especificación de requisitos.
2. Sirve para
2.1. Se tenga una base o referencia para validar o probar el software solicitado
2.2. Se facilite el traspaso del software a otros clientes/usuarios
2.3. Se le puedan hacer mejoras (o innovaciones) a ese software
3. Características de una buena ERS
3.1. Correcta
3.1.1. La ERS es correcta si y sólo si todo requisito que figura en ella refleja alguna necesidad real.
3.2. No ambigua
3.2.1. Un documento es no ambiguo si y solo si cada requisito descrito tiene una única interpretación.
3.3. Completa
3.3.1. Existe una definición de respuestas a todas las posibles entradas, tanto válidas como inválidas, en todas las posibles situaciones.
3.3.2. Aparecen etiquetadas todas las figuras, tablas, diagramas, etc, así como definidos todos los términos y unidades de medida empleados.
3.3.3. Cumple con el estándar utilizado. Si hay alguna parte del estándar que no se utiliza, se debe razonar suficientemente el porqué no se ha utilizado dicho apartado.
3.3.4. Incluye todos los requisitos significativos del software (relacionados con la funcionalidad, ejecución, diseño, atributos de calidad o interfaces externas).
3.4. Verificable
3.4.1. Un requisito se dice que es verificable si existe algún proceso no excesivamente costoso por el cual una persona o una máquina pueda chequear que el software satisface dicho requerimiento.
3.5. Consistente
3.5.1. Una ERS es consistente si y sólo si ningún conjunto de requisitos descritos en ella son contradictorios o entran en conflicto.
3.6. Clasificada
3.6.1. No todos los requisitos son igual de importantes. Los requisitos pueden clasificarse por diversos criterios
3.6.1.1. Importancia: Pueden ser esenciales, condicionales u opcionales.
3.6.1.2. Estabilidad: Cambios que pueden afectar al requisito.
3.7. Modificable
3.7.1. Una ERS es modificable si cualquier cambio puede realizarse de manera fácil, completa y consistente. Es deseable tener una organización coherente y fácil de usar en la que aparezca el índice o una tabla de contenidos fácilmente accesible.
3.7.2. También es deseable evitar la redundancia, es decir que no aparezca un mismo requisito en más de un lugar de la ERS.
3.8. Explorabilidad (traceability)
3.8.1. Una ERS es explorable si el origen de cada requerimiento es claro tanto hacia atrás (origen que puede ser un documento, una persona etc.) como hacia delante (componentes del sistema que realizan dicho requisito).
3.9. Utilizable durante las tareas de mantenimiento y uso
3.9.1. El personal que no ha intervenido directamente en el desarrollo debe ser capaz de encargarse de su mantenimiento.