Diferencias

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

--- ingenieria_de_requisitos:especificacion_de_requisitos [2023/11/08 08:03] – thejuanvisu
+++ ingenieria_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
   * **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

Knoppia

Herramientas de usuario

Herramientas del sitio

Diferencias

Herramientas de la página