Fundamentos de la Ingeniería de Requerimientos y Gestión de Software
Clasificado en Informática
Escrito el en 
español con un tamaño de 4,7 KB
Ingeniería de Requerimientos (IR)
La Ingeniería de Requerimientos (IR) no es solo anotar pedidos. Es el proceso sistemático de recopilar, analizar y verificar qué necesita el cliente para resolver su problema con software.
Dato vs. Información
- Dato: Es la materia prima suelta, sin sentido por sí sola (ej. "15").
- Información: Es el dato procesado en un contexto que reduce la incertidumbre y permite tomar decisiones (ej. "Quedan 15 entradas disponibles").
Las 3 Perspectivas
Para entender bien un problema hay que mirarlo desde tres ángulos:
- Negocio: El "Para qué" (Objetivos, retorno de inversión, beneficios de la empresa).
- Usuario: El trabajo diario (Qué tareas operativas se le facilitan, qué problemas se le resuelven).
- Desarrollador: El "Cómo" técnico (Arquitectura, bases de datos, lenguajes, mantenibilidad).
El Ciclo de la Ingeniería de Requerimientos
La IR es un ciclo continuo, no un paso único:
- Elicitación: Consiste en "sacar" la información. Se investiga mediante entrevistas (preguntas abiertas para explorar, cerradas para confirmar, de sondeo, indirectas y directas, exploratorias), observación del entorno de trabajo y análisis de documentos.
- Análisis: Procesar lo relevado. Aquí se resuelven conflictos, se prioriza (indispensable vs. deseable vs. posible) y se generan los primeros modelos.
- Especificación: Ponerlo por escrito. Redactar los requerimientos de forma formal, clara y sin ambigüedades (se usan los Casos de Uso y las plantillas).
- Validación: Mostrarle al cliente el documento y corroborar: "¿Es esto exactamente lo que necesitas?".
Clasificación de Requerimientos
| REQ Funcionales (EL QUÉ) | REQ No Funcionales (EL CÓMO) |
|---|---|
| Comportamientos del sistema, cálculos, validaciones, secuencias. Ejemplo: El sistema debe validar que el DNI y el Ticket coincidan. | Atributos de calidad, rendimiento, restricciones tecnológicas. Ejemplo: Rendimiento (respuestas < 3 seg), Disponibilidad (24/7), Usabilidad, Seguridad. |
Casos de Uso y Especificación
Historias de Usuario
Sirven para redactar la necesidad desde los ojos de quien lo va a usar, asegurando que aporte valor:
- COMO: [rol / usuario]
- QUIERO: [funcionalidad o acción a realizar]
- PARA QUE: [beneficio o valor para el negocio]
Relaciones entre Casos de Uso
- Include (Inclusión): Es OBLIGATORIO. El caso base llama a otro porque no puede terminar su trabajo sin él (ej. "Retirar dinero" incluye "Validar PIN").
- Extend (Extensión): Es OPCIONAL o CONDICIONAL. Ocurre solo bajo ciertas reglas y el caso base ni se entera de que existe (ej. "Pagar" se extiende a "Emitir factura con descuento" solo si hay promoción).
Metodologías de Desarrollo (SDLC)
- Cascada (Tradicional): Fases estrictas una tras otra. Primero se releva todo, luego se diseña todo, luego se programa todo. Es ideal para proyectos donde todo está clarísimo desde el día 1, pero es muy poco flexible ante cambios.
- Ágiles (Scrum / Kanban): Se adaptan al cambio con entregas cortas (iterativas). El Manifiesto Ágil prioriza a las personas y el software funcionando por encima de los procesos rígidos y la documentación excesiva.
Diagramas de Flujo de Datos (DFD)
Representa gráficamente cómo la información se mueve dentro de la empresa (Norma Yourdon):
- Proceso (Círculo/Burbuja): Transforma datos de entrada en salida. Errores críticos: Si le falta una entrada para calcular ("Error de conservación"), si no emite ninguna salida ("Pérdida de información").
- Almacén (Dos líneas paralelas): Donde se guardan datos temporal o definitivamente (ej. Base de datos).
- Entidad Externa (Cuadrado): Un cliente, persona o sistema externo que nos manda información o la recibe. Define la frontera de nuestro sistema.
- Flujo (Flecha): La "tubería" por donde viaja el dato.