====== Especificación de requisitos ====== Los documentos de requisitos son diferentes en función a si son para clientes técnicos o clientes no conocedores. El documento de requisitos tiene los siguientes requisitos: * Comunicación entre clientes, usuario y desarrolladores * Permitir iniciar la actividad de diseño * Soportar las actividades de pruebas del sistema * Controlar la evolución del sistema ===== Contenido ===== * Propiedades y comportamientos de nuestro sistema * Restricciones de diseño y de producto * Propiedades emergentes del sistema que No debe incluir * Información referente al proyecto * Diseño * Planes de garantía del producto * Costes ===== Como se deben escribir los requisitos ===== Se usan frases como Mi sistema tiene que, "El sistema debe", "El sistema Hará", "el sistema Habilitará" Debe utilizarse lenguaje natural, este se puede complementar de diagramas y notaciones formales. El cliente debe participar en el documento Los requisitos se deben poner en positivo, salvo excepciones, como sistemas críticos en donde indicaremos que NO hará el sistema ===== Formato de las especificaciones ===== * Solo texto * Texto y técnicas * Lo más usado * Solo técnicas * No recomendables El documento de requisitos es la forma que tenemos de formar y guardar los requisitos. ===== Documentación Requisitos Usuario (DRU) ===== Plasmamos el problema que tiene el usuario. Definimos el problema en un proceso iterativo donde el usuario es el máximo responsable * **Objetivo**: Obtener definiciones de lo que el usuario espera del sistema * **Entradas**: Resultados de entrevistas, encuestas, estudios, ejercicios de prototipado * **Salidas**: Documento de requerimientos de usuario DRU, donde se describen todos los requerimientos con claridad y consistencia Actividades * Especificar los requisitos del usuario * Describir los requisitos en términos de sus atributos * Organizar los requisitos en base a la categoría que pertenezcan * Revisar y comprobar las salidas de la fase Atributros de los requisitos de usuario * Identificador: número necesidad: Como de necesario es * prioridad:Que prioridad tiene, alta, media o baja * estabilidad: Si es muy probable que cambien o no (Alta o baja), por ejemplo una función que depende de una ley tiene estabilidad baja al haber riesgo de que cambien las leyes * fuente: Quien ha dicho el requisito * claridad: Como de claro está * verificabilidad: Todos los requisitos deben poder realizarse ===== Documento de requisitos del software (ERS) ===== Fase de análisis del problema donde se adopta un método Actividades * Especificar los requisitos del software * Describir los requisitos eb tñernminos de sus atributos, asegurando la completitud y consistencia * Organizar los requisitos en base a la categoría a la qu pertenezcan * Revisar y comprobar salidas de la fase Atributos del documento de requisitos del software (ERS): * Identificador: número necesidad: Como de necesario es * prioridad:Que prioridad tiene, alta, media o baja * estabilidad: Si es muy probable que cambien o no (Alta o baja), por ejemplo una función que depende de una ley tiene estabilidad baja al haber riesgo de que cambien las leyes * fuente: Quien ha dicho el requisito * claridad: Como de claro está * verificabilidad: Todos los requisitos deben poder realizarse Lectores/usuarios de la ERS * Clientes: para comprobar que satisface sus necesidades y para hacer cambios en los requisitos * gestores: Para preparar una oferta por el sistema y planificar el proceso de desarrollo * ingenieros de desarrollo: Para comprender el sistema a desarrollar * ingenieros de pruebas: Para elaborar pruebas de validación * ingenieros de mantenimiento: Para facilitar la comprensión del sistema y las relaciones entre sus partes ===== Diferencia entre ERS y DRU ===== El DRU esta en lenguaje más natural e incluye tal cual el problema a resolver, el ERS contiene los requisitos y como se va a solucionar el problema. La diferencia entre ERS y DRU es que uno está más detallado de otro La diferencia entre ambos es el nivel de detalle (EXAMEN), uno está más detallado que otro. ===== Características de una buena ERS (IEE-830) ===== * No puede haber ambigüedad * Un requisito ambigüo se presta a distintas interpretaciones * Completa * No puede haber secciones To Be Determined (TBD) * Se describen todas las posibles respuestas a todas las posibles entradas * Páginas numeradas, figuras y tablas con referencias. El documento debe tener formato estandarizado * Correcto * Todos los requisitos deben satisfacer lo que el cliente quiere * Verificable * Se tiene que comprobar que el requisito se pueda hacer * Consistencia * Los requisitos no pueden entrar en conflicto con otros. * Realizables * Que se puedan implementar * Concisos * Deben ser breves * Independiente del diseño * Trazable * Se deben poder referenciar por numeración * Modificable * Electrónicamente almacenado * Ejecutable/interpretable/Prototipable * Anotada por importancia relativa * Anotada por estabilidad relativa * Anotada por versión * No redundante * A un nivel de detalle adecuado * Precisa * Reutilizable * Trazada * Organizada * Con referencias Cruzadas ===== Estructura del Documento de Requisitos ===== - Introducción - Proposición - Ámbito - Definiciones, Acrónimos, Abreviaturas - Referencias - Visión general del resto del documento - Descripción General - Perspectiva del producto - Funciones del producto - Características del usuario - Restricciones generales - Asunciones y Dependencias - Requisitos específicos: Todos los requisitos que tenemos clasificados con identificador único, referencia, entrada y salida. - Interfaces externas - Descripción detallada de entradas y salidas - Complementa descripciones de interfaz - Funciones - Requisitos de rendimiento/ejecución - Restricciones de diseño - Atributos de calidad del software - Otros Requisitos ===== Problemas que podemos tener en el documento de requisitos ===== * Puede haber demasiados requisitos, de forma que los cambios se vuelven demasiado difíciles * Hay herramientas llamadas CARE que nos permiten gestionar una gran cantidad de requisitos * No consideración de requisitos obvios * Nivel de detalle: Tiene que haber un nivel de detalle adecuado para el cliente * Ubicación de los requisitos: Poner los requisitos donde corresponden ===== Etapas de la revisión ===== - preparamos plan de revisión - Distribuimos los documentos a revisar - Preparación de la reunión - Realizar la reunión de revisión - Identificar defectos y acciones a realizar - Realizar correcciones que sean precisas ===== Herramientas para Revisiones ===== * Checklist de validación: cada organización tiene uno diferente. * Pre-Revisiones: antes de la revisión se realizan reuniones pequeñas para ver que errores hay. * Prototipado * Usado en diversas disciplinas * Se usa para ver y comprobar que los requisitos que tenemos son correctos * Tipos de prototipos: * Mock-Ups: Pantallas dibujadas a mano que representa un aspecto en concreto del sistema. Suele ser dibujado en papel * StoryBoard: Evolución del MockUp, suelen estar hechos a ordenador, muestra la secuencia de acciones o escenarios que se deben realizar con el programa. * Maquetas: versiones simplificadas de nuestra aplicación. Simula realizar las acciones del programa. * Prototipos comunes en Ingeniería de Requisitos: * Seleccionamos quien evaluara el prototipo * Desarrollar escenarios de validacón * Ejecutar Escenarios * Documentar problemas ===== técnicas de validación ===== * Generación de casos de prueba: Un caso de prueba describe una acción que el cliente quiere que realice el software. * Manuales de usuario * Animación y validación de modelos o especificaciones formales