Knoppia

Wiki de Informática y otras historias

Herramientas de usuario

Herramientas del sitio


ingenieria_de_requisitos:especificacion_de_requisitos

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

Próxima revisión
Revisión previa
ingenieria_de_requisitos:especificacion_de_requisitos [2023/11/08 08:01] – creado thejuanvisuingenieria_de_requisitos:especificacion_de_requisitos [2023/11/20 10:41] (actual) thejuanvisu
Línea 40: Línea 40:
 ===== Documentación Requisitos Usuario (DRU) ===== ===== Documentación Requisitos Usuario (DRU) =====
  
-Plasmamos el problema que tiene el usuario+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 
 + 
 + 
 + 
 + 
 + 
 + 
 + 
 + 
  
ingenieria_de_requisitos/especificacion_de_requisitos.1699430516.txt.gz · Última modificación: 2023/11/08 08:01 por thejuanvisu