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

Ambos lados, revisión anteriorRevisión previa
Próxima revisión
Revisión previa
ingenieria_de_requisitos:especificacion_de_requisitos [2023/11/08 08:03] thejuanvisuingenieria_de_requisitos:especificacion_de_requisitos [2023/11/20 10:41] (actual) thejuanvisu
Línea 44: Línea 44:
   * **Entradas**: Resultados de entrevistas, encuestas, estudios, ejercicios de prototipado   * **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   * **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.1699430638.txt.gz · Última modificación: 2023/11/08 08:03 por thejuanvisu