Especificación de Requisitos Clase 08

Especificación de requisitos Es una descripción completa del comportamiento del sistema a desarrollar

Especificación de requisitos Son las necesidades del producto que se debe desarrollar. En la fase de análisis de requisitos se deben identificar claramente estas necesidades y documentarlas. Como resultado de esta fase se debe producir un documento de especificación de requisitos en el que se describa lo que el futuro sistema debe hacer

Objetivos de la ERS. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un determinado software. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente. Servir de base para desarrollos de estándares de ERS particulares para cada organización.

Importancia de la Ingeniería de Requerimientos Importancia ERS. Permite gestionar las necesidades del proyecto en forma estructurada. Mejora la capacidad de predecir cronogramas de proyectos. Disminuye los costos y retrasos del proyecto. Mejora la calidad del software. Mejora la comunicación entre equipos. Evita rechazos de usuarios finales Los principales beneficios que se obtienen de la Ingeniería de Requerimientos son: Permite gestionar las necesidades del proyecto en forma estructurada: Cada actividad de la IR consiste de una serie de pasos organizados y bien definidos. Mejora la capacidad de predecir cronogramas de proyectos, así como sus resultados: La IR proporciona un punto de partida para controles subsecuentes y actividades de mantenimiento, tales como estimación de costos, tiempo y recursos necesarios. Disminuye los costos y retrasos del proyecto: Muchos estudios han demostrado que reparar errores por un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente aquellas decisiones tomadas durante la RE. Mejora la calidad del software: La calidad en el software tiene que ver con cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso, confiabilidad, desempeño, etc.). Mejora la comunicación entre equipos: La especificación de requerimientos representa una forma de consenso entre clientes y desarrolladores. Si este consenso no ocurre, el proyecto no será exitoso. Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del marco del problema, por lo que se le involucra durante todo el desarrollo del proyecto.

Especificación de requisitos se relevan por medio de Entrevistas Talleres Observación Encuestas Revisión documental Uso de especificaciones formales para requerimientos (formatos estándar de documentos, UML, etc.)

Condición o capacidad que debe estar presente en un sistema. Requerimiento Condición o capacidad que debe estar presente en un sistema.

Características de una buena ERS. Correcta. No ambigua. Completa. Verificable. Consistente Clasificada. Modificable. Explorable. Utilizable durante las tareas de mantenimiento y uso. Características de una buena SRS [IEEE Std 830-1998] 1.      Correcta 2.      No ambigua 3.      Completa 4.      Consistente 5.      Calificada de acuerdo a la importancia y/o estabilidad 6.      Verificable 7.      Modificable 8.      Rastreable   Una SRS es correcta, sí y solo sí, cada requisito especificado es un requisito que el software debe cumplir. No ambigua Una SRS no es ambigua sí y solo sí cada requisito especificado tiene sólo una interpretación. Completa Una SRS es completa, sí y solo sí, incluye los siguientes elementos: a) Todos los requisitos significativos, ya sea que se relacionen a funcionalidad, desempeño, restricciones de diseño, atributos o interfaces externas. En particular cualquier requisito externo impuesto por una especificación del sistema debe ser reconocido y tratado. b) Definición de las respuestas del software a todos los tipos posibles de clases de datos de entrada en todos los tipos posibles de clases de situaciones. Notar que es importante especificar las respuestas tanto para valores de entrada válidos como inválidos. c) Etiquetas y referencias completas a todas las figuras, tablas y diagramas en la SRS así como la definición de todos los términos y unidades de medida. Consistente Una SRS es consistente, sí y solo sí, no se contradice a sí misma, es decir, si ningún subconjunto de requisitos ahí descritos se contradicen o entran en conflicto. Jerarquizada de acuerdo a la importancia y/o estabilidad Una SRS está calificada de acuerdo a la importancia y/o estabilidad si cada requisito tienen un identificador que indique la importancia o estabilidad del requisito. Verificable Una SRS es verificable, sí y solo sí, cada requisito especificado es verificable. Un requisito es verificable sí y solo sí existe un proceso finito de costo-efectivo con el cual una persona o una máquina puede verificar que el producto de software cumple el requisito. En general cualquier requisito ambiguo no es verificable. Modificable Una SRS es modificable, sí y solo sí, su estructura y estilo son tales que, cualquier cambio a los requisitos pueden ser hechos fácil, completa y consistentemente sin perder la estructura y el estilo. La modificabilidad generalmente requiere que una SRS: a)                           Tenga una organización coherente y fácil de usar con una tabla de contenido, un índice y referencias cruzadas explícitas. b)                           No sea redundante (esto es, el mismo requisito no debe aparecer en más de una parte en la SRS). c)                           Expresa cada requisito de manera separada, en vez de hacerlo mezclado con otros requisitos. Rastreable Una SRS es rastreable si el origen de cada uno de sus requisitos es clara y si facilita la referencia de cada requisito en el desarrollo futuro o mejora de la documentación. Se recomiendan los siguientes dos tipos de rastreabilidad: a)                             Rastreabilidad hacia atrás (esto es, a estados previos del desarrollo). El requisito tiene referencias explícitas a sus fuentes en documentos anteriores. b)                            Rastreabilidad hacia enfrente (esto es, a todos los documentos derivados del SRS). Depende de que cada requisito en la SRS tenga un nombre único o número de referencia. Es particularmente importante cuando el software entra en operación y mantenimiento. Cuando el código y los documentos de diseño son modificados, es escencial contar con la capacidad para conocer el conjunto completo de requisitos que pueden ser afectados por esas modificaciones.

Ejemplo de Verificabilidad. No verificables: El producto debería funcionar bien. El producto debería tener una buena interfaz de usuario. Verificable: La salida se suministra dentro de los 20 segundos siguientes al evento E el 60% de las veces, y en los 30 segundos siguientes en el 100%

Clasificación de los requisitos Requisitos Funcionales (RF): Son los requisitos que tienen relación con funcionalidad que envuelven aspectos de ejecución de negocio del producto de software y que tengan relación con operaciones de pantallas o informes del producto de software.

Clasificación de los requisitos Requisitos No-Funcionales (RN): En este tipo de requisitos son considerados las premisas o restricciones del sistema. Tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc.

Esquema de la ERS definida en el IEEE 830-1998. 1 Introducción 1.1 Propósito 1.2 Ámbito del Sistema 1.3 Definiciones, Acrónimos y Abreviaturas 1.4 Referencias 1.5 Visión general del documento 2 Descripción General 2.1 Perspectiva del Producto 2.2 Funciones del Producto 2.3 Características de los usuarios 2.4 Restricciones 2.5 Suposiciones y Dependencias 2.6 Requisitos Futuros 3 Requisitos Específicos 3.1 Interfaces Externas 3.2 Funciones 3.3 Requisitos de Rendimiento 3.4 Restricciones de Diseño 3.5 Atributos del Sistema 3.6 Otros Requisitos 4 Apéndices 5 Índice