La etapa de producción de requisitos del proceso de desarrollo de software es Especificaciones de requisitos de software (SRS) (también llamado un documento de requisitos ). Este informe sienta las bases para las actividades de ingeniería de software y se construye cuando se obtienen y analizan todos los requisitos. SRS Es un informe formal, que actúa como una representación del software que permite a los clientes revisar si (SRS) cumple con sus requisitos. Además, comprende los requisitos del usuario para un sistema, así como especificaciones detalladas de los requisitos del sistema.
El SRS es una especificación para un producto de software, programa o conjunto de aplicaciones específico que realiza funciones particulares en un entorno específico. Tiene varios objetivos dependiendo de quién lo escriba. En primer lugar, el cliente de un sistema podría escribir el SRS. En segundo lugar, el SRS podría escribirlo un desarrollador del sistema. Los dos métodos crean situaciones completamente diferentes y establecen propósitos completamente diferentes para el documento. El primer caso, SRS, se utiliza para definir las necesidades y expectativas de los usuarios. El segundo caso, SRS, está escrito para diversos fines y sirve como documento de contrato entre el cliente y el desarrollador.
Características de un buen SRS
Las siguientes son las características de un buen documento SRS:
1. Corrección: La revisión del usuario se utiliza para proporcionar la exactitud de los requisitos establecidos en el SRS. Se dice que SRS es perfecto si cubre todas las necesidades que realmente se esperan del sistema.
2. Integridad: El SRS está completo si, y sólo si, incluye los siguientes elementos:
(1). Todos los requisitos esenciales, ya sean relacionados con funcionalidad, rendimiento, diseño, restricciones, atributos o interfaces externas.
entero a doble java
(2). Definición de sus respuestas del software a todas las clases realizables de datos de entrada en todas las categorías de situaciones disponibles.
Nota: Es esencial especificar las respuestas tanto para valores válidos como no válidos.
(3). Etiquetas completas y referencias a todas las figuras, tablas y diagramas del SRS y definiciones de todos los términos y unidades de medida.
3. Consistencia: El SRS es consistente si, y sólo si, ningún subconjunto de requisitos individuales se describe en su conflicto. Hay tres tipos de posibles conflictos en el SRS:
(1). Las características especificadas de los objetos del mundo real pueden entrar en conflicto. Por ejemplo,
(a) El formato de un informe de resultados puede describirse en un requisito como tabular y en otro como textual.
(b) Una condición puede establecer que todas las luces serán verdes mientras que otra establece que todas las luces serán azules.
(2). Puede haber un conflicto razonable o temporal entre las dos acciones especificadas. Por ejemplo,
(a) Un requisito puede determinar que el programa agregará dos insumos y otro puede determinar que el programa los multiplicará.
(b) Una condición puede establecer que 'A' siempre debe seguir a 'B', mientras que otra requiere que 'A y B' coexistan.
miflixer
(3). Dos o más requisitos pueden definir el mismo objeto del mundo real pero utilizar términos diferentes para ese objeto. Por ejemplo, la solicitud de entrada del usuario por parte de un programa puede denominarse 'mensaje' en un requisito y 'señal' en otro. El uso de terminología y descripciones estándar promueve la coherencia.
4. Inequívoco: SRS es inequívoco cuando cada requisito fijo tiene una sola interpretación. Esto sugiere que cada elemento se interpreta de forma única. En caso de que se utilice un método con múltiples definiciones, el informe de requisitos debe determinar las implicaciones en el SRS para que sea claro y sencillo de entender.
5. Clasificación por importancia y estabilidad: El SRS se clasifica según su importancia y estabilidad si cada requisito tiene un identificador que indica la importancia o la estabilidad de ese requisito en particular.
Normalmente, no todos los requisitos son igualmente importantes. Algunos requisitos previos pueden ser esenciales, especialmente para aplicaciones críticas para la vida, mientras que otros pueden ser deseables. Cada elemento debe identificarse para que estas diferencias sean claras y explícitas. Otra forma de clasificar los requisitos es distinguir clases de elementos como esenciales, condicionales y opcionales.
6. Modificabilidad: El SRS debe ser lo más modificable posible y debe ser capaz de obtener rápidamente cambios en el sistema hasta cierto punto. Las modificaciones deben estar perfectamente indexadas y cruzadas.
7. Verificabilidad: SRS es correcto cuando los requisitos especificados se pueden verificar con un sistema rentable para verificar si el software final cumple con esos requisitos. Los requisitos se verifican con la ayuda de revisiones.
8. Trazabilidad: El SRS es rastreable si el origen de cada uno de los requisitos es claro y si facilita la referencia de cada condición en futuros desarrollos o documentación de mejora.
Existen dos tipos de Trazabilidad:
1. Trazabilidad hacia atrás: Esto depende de que cada requisito haga referencia explícita a su fuente en documentos anteriores.
2. Trazabilidad directa: Esto depende de que cada elemento del SRS tenga un nombre o número de referencia exclusivo.
La trazabilidad directa del SRS es especialmente crucial cuando el producto de software entra en la fase de operación y mantenimiento. A medida que se modifica el código y el documento de diseño, es necesario poder determinar el conjunto completo de requisitos que pueden estar relacionados con esas modificaciones.
saltar lista
9. Independencia del diseño: Debería haber una opción para seleccionar entre múltiples alternativas de diseño para el sistema final. Más específicamente, el SRS no debe contener ningún detalle de implementación.
10. Comprobabilidad: Un SRS debe escribirse con un método tal que sea sencillo generar casos de prueba y planes de prueba a partir del informe.
11. Comprensible por el cliente: Un usuario final puede ser un experto en su dominio explícito, pero puede no tener formación en informática. Por lo tanto, se debe evitar en la medida de lo posible el propósito de notaciones y símbolos formales. El lenguaje debe mantenerse simple y claro.
12. El nivel correcto de abstracción: Si el SRS está escrito para la etapa de requisitos, los detalles deben explicarse explícitamente. Mientras que, para un estudio de viabilidad, se pueden utilizar menos análisis. Por tanto, el nivel de abstracción se modifica según el objetivo del SRS.
Propiedades de un buen documento SRS
Las propiedades esenciales de un buen documento SRS son las siguientes:
Conciso: El informe SRS debe ser conciso y, al mismo tiempo, inequívoco, coherente y completo. Las descripciones detalladas e irrelevantes disminuyen la legibilidad y también aumentan las posibilidades de error.
Estructurado: Debe estar bien estructurado. Un documento bien estructurado es fácil de entender y modificar. En la práctica, el documento SRS sufre varias revisiones para adaptarse a los requisitos de los usuarios. A menudo, los requisitos de los usuarios evolucionan con el tiempo. Por lo tanto, para facilitar las modificaciones al documento SRS, es vital que el informe esté bien estructurado.
Vista de caja negra: Sólo debe definir qué debe hacer el sistema y abstenerse de indicar cómo hacerlo. Esto significa que el documento SRS debe definir el comportamiento externo del sistema y no discutir los problemas de implementación. El informe SRS debe ver el sistema a desarrollar como una caja negra y debe definir el comportamiento visible externamente del sistema. Por esta razón, el informe SRS también se conoce como la especificación de caja negra de un sistema.
Integridad conceptual: Debe mostrar integridad conceptual para que el lector pueda simplemente entenderlo. Respuesta a eventos no deseados: Debe caracterizar respuestas aceptables a eventos no deseados. A esto se le llama respuesta del sistema a condiciones excepcionales.
Verifiable: Todos los requisitos del sistema, tal como se documentan en el documento SRS, deben ser correctos. Esto significa que debería ser posible decidir si se han cumplido o no los requisitos en una implementación.