• Obtención, especificación, análisis y validación.
• Interno de la organización: El sistema lo construye la propia organización.
• A medida: Programa hecho expresamente par auna organización.
• Adaptación: Un programa estándar adaptado a una organización.
• Cooperativo: Queremos un software común para varias organizaciones, como la app de la universidad.
• Orientado al producto: Se desarrolla un programa para el mercado.

El proceso de ingeniería de requisitos tiene una serie de entradas y salida.

• Necesidades del usuario
• Estándares de la Organización
• Regulación y normativas
• Sistemas de información Existentes

• Requisitos acordados
• Especificación para el sistema
• Modelos del sistema

• Entendimiento del problema: Captura, definición, Identificación…
• Descripción del problema
• Alcanzar un acuerdo sobre la naturaleza del problema: Validación

La ventaja de este modelo es que no tiene orden.

• No tiene orden
• Proceso iterativo
• Secuencia habitual:
  • Se obtienen los requisitos
  • Se negocia con los participantes
  • Se integran con el resto de la documentación
  • Se verifican y validan

• Es un Modelo Iterativo:
  • Educción
  • Análisis
  • Especificación
  • Validación
• El problema es que no sabemos cuando termina
• Actividad de gestión
• Durante todo el proceso
• Gestiona la obtención incremental de requisitos y cambios

• Son procesos iterativos
• El modelo en espirar obliga a un orden, los otros menos
• Los productos de profeso y fase no están claramente definidos

Modelo perteneciente a la IEEE. Nos centramos en la parte de Requerimientos. Tiene 4 Fases:

• Educción
• Análisis
• Especificación
• Validación

Estudio de viabilidad: No es obligatorio en requisitos, pero si aconsejable.

Tendremos problemas si se dan estos casos:

• Falta tiempo y otros requisitos
• Si los documentos no se entienden
• El proceso es excesivamente largo y costoso
• Trabajo perdido por culpa de errores
• No utiliza muchas de las capacidades del sistema
• Inmensa cantidad de solicitudes de cambio tras la entrega
• Demasiado tiempo para alcanzar un acuerdo cuando se proponen cambios

• Estudio de viabilidad (Opcional)
• Captura y análisis
• Especificación de requisitos
• Validación

Los Stakeholder son los usuarios e interesados en la plataforma, gente importante, dueños del proceso que queremos hacer, personas que entrevistaremos para hacer el software:

• Usuarios: Los que utilizaran el sistema
• Clientes: Propietarios del software o representantes del mercado objetivo
• Analistas de mercado: Identifican lo que el mercado demanda
• Reguladores: Asegura el cumplimiento de leyes y normativas
• Ingenieros del Software

Cada StakeHolder tiene su punto de vista. Se debe negociar el equilibrio requisitos-presupuesto planificación. El cliente confía en que el ingeniero de requisitos pueda aclarar sus necesidades

Productos del proceso de la Ingeniería de Requisitos Informe de viabilidad Requisitos acordados Especificación del sistema

• A0: Estudio de viabilidad
  • Al comienzo del proceso de desarrollo
  • Es opcional
  • Es un proceso para conocer los objetivos de la organización
  • Evaluar si se dispone de la tecnología necesaria
  • Analizar si se puede integrar con otros sistemas
  • Entrada
    • Conjunto de requisitos de negocio preliminares
    • Descrpción resupida del sistema
    • Contribución del sistema al proceso de negocio
  • Salida: Informe de viabilidad, que ayuda a decidir si continuar o no
  • El proceso debe durar máximo 2 o 3 semanas
• A1: Captura de requisitos (Educción)
  • Es la primera actividad a realizar
  • Para llevar a cabo se debe saber de donde vienen los requisitos y como recopilarlos
  • Buscamos detectar y resolver ciertos conflictos
  • También buscamos descubrir los límites del software y como este debe interactuar con su entorno.
  • Diversas tareas:
    • Clasificación
    • Modelado Conceptual
    • Localización
    • Negociación
• A2: Especificación de requisitos
  • Se refiere a la producción de un ducomuento basado en la IEEE-830
• A3: Validación de requisitos
  • Se validan para comprobar que el ingeniero de requisitos los ha entendido
  • Se trata de asegurar que el documento ERS define el software adecuado
  • Tecnicas de validación
    • Revisiones
    • Prototipado
    • Validación de Modelos
    • Pruebas de aceptación

Los requisitos cambian:

• Cambio en la estrategia o prioridades de negocio
• Cambios tecnológicos
• Cambios en leyes o regulaciones

La Gestión de requisitos consiste en gestionar

• Los cambios en los requisitos acordados
• Las relaciones entre requisitos
• Las dependencias entre el documento ERS y otros documentos.

• Es un proceso Iterativo
• Suele tener un estudio de viabilidad
• Hay diferentes stakeholder con diferentes requisitos
• Los cambios en los negocios, que van a pasar, producen cambios en nuestros requisitos.