Artículo Relacionado: Escribiendo un buen SRS para tu proyecto
Las siguientes son las características de un buen documento SRS:
- Corrección:
la revisión del usuario se utiliza para garantizar la corrección de los requisitos establecidos en el SRS. Se dice que SRS es correcto si cubre todos los requisitos que realmente se esperan del sistema. - Completitud:
la completitud de SRS indica todos los sentidos de finalización, incluida la numeración de todas las páginas, la resolución de las partes determinadas en la mayor medida posible y la cobertura adecuada de todos los requisitos funcionales y no funcionales. - Consistencia:
Se dice que los requisitos en SRS son consistentes si no hay conflictos entre ningún conjunto de requisitos. Los ejemplos de conflicto incluyen diferencias en las terminologías utilizadas en lugares separados, conflictos lógicos como el período de tiempo de generación del informe, etc. - Falta de ambigüedad :
se dice que un SRS no es ambiguo si todos los requisitos establecidos tienen solo 1 interpretación. Algunas de las formas de evitar la falta de ambigüedad incluyen el uso de técnicas de modelado como diagramas ER, revisiones adecuadas y verificaciones de amigos, etc. - Clasificación por importancia y estabilidad:
Debe existir un criterio para clasificar los requisitos como menos o más importantes o más específicamente como deseables o esenciales. Se puede utilizar una marca de identificación con cada requisito para indicar su rango o estabilidad. - Modificabilidad:
SRS debe ser lo más modificable posible y debe ser capaz de aceptar fácilmente cambios en el sistema hasta cierto punto. Las modificaciones deben estar correctamente indexadas y con referencias cruzadas. - Verificabilidad:
un SRS es verificable si existe una técnica específica para medir cuantificablemente el grado en que el sistema cumple con cada requisito. Por ejemplo, un requisito que comienza con que el sistema debe ser fácil de usar no es verificable y debe evitarse enumerar tales requisitos. - Trazabilidad:
uno debe poder rastrear un requisito para diseñar un componente y luego codificar un segmento en el programa. De manera similar, uno debería poder rastrear un requisito a los casos de prueba correspondientes. - Independencia del diseño:
debe haber una opción para elegir entre múltiples alternativas de diseño para el sistema final. Más específicamente, el SRS no debe incluir ningún detalle de implementación. - Capacidad de prueba:
un SRS debe escribirse de tal manera que sea fácil generar casos de prueba y planes de prueba a partir del documento. - Comprensible para el cliente:
un usuario final puede ser un experto en su dominio específico, pero puede no ser un experto en informática. Por lo tanto, se debe evitar en la medida de lo posible el uso de notaciones y símbolos formales. El lenguaje debe ser fácil y claro. - Nivel correcto de abstracción:
si el SRS está escrito para la fase de requisitos, los detalles deben explicarse explícitamente. Mientras que, para un estudio de factibilidad, se pueden usar menos detalles. Por lo tanto, el nivel de abstracción varía según el propósito del SRS.