Ingeniería de requerimientos
Un requerimiento (o requisito) es una característica del sistema o una descripción de algo que el sistema es capaz de hacer para satisfacer su propósito.
Cada requisito debe ser documentado y validado por el solicitante (SH/Actor)
- ! No confundir un pedido/deseo con un requerimiento
- No todos los deseos se convierten en requisitos, aunque estos últimos originan de los pedidos
- Para que un pedido se convierta en requisito debe ser documentado y validado
- Formato sugerido para los requerimientos: "Acción/es + objetos/s + (para qué) + (para quién) + comentarios imprescindibles"
Comprensión de requerimientos
- Primera ley del club de la pelea: El usuario final nunca tiene bien definido qué es lo que quiere de su sistema
- Segunda ley del club de la pelea: El usuario final siempre cambiará constantemente los objetivos/requerimientos
- Es importante no caer en la tentación de saltarse el reconocimiento de los requerimientos para entrar directamente en el desarrollo del software
- La ingeniería de requerimientos proporciona el mecanismo para entender los deseos del cliente, analizar las necesidades, evaluar la factibilidad, negociar la solución razonable, especificar la solución sin ambigüedades, etc.
- Consiste de siete tareas:
- Concepción: Establece el entendimiento del problema, la naturaleza de la solución, y la eficacia de la comunicación y colaboración entre los participantes
- Indagación: Preguntar al cliente, usuarios, y otros interesados cuáles son los objetivos del sistema/producto y cómo va a usarse
- Elaboración: La información obtenida se expande y refina. Se desarrolla un modelo refinado de los requerimientos
- Negociación
- Especificación
- Validación
- Administración
- Algunas de ellas van en paralelo
Proceso de ingeniería de requerimientos
- Consiste en cuatro sub-procesos:
- Estudio de viabilidad
- Obtención [de requerimientos] y análisis
- Especificación (formalización en formularios estándar)
- Validación (de que los requerimientos realmente definen el sistema que quiere el cliente)
Tipos de requerimientos
Funcionales
- Describen una interacción entre el sistema y el ambiente. Es decir, describen cómo debe comportarse el sistema ante un estímulo
- Algunas palabras clave:
- Actualizar, Validar, Registrar, Calcular
Ejemplos
- Informar listado de materias electivas para un año determinado
- Emitir certificado analítico de materias rendidas para un alumno
- Informar cupos disponibles para una fecha determinada
- Registrar cupo para una fecha
- Validar que ele cupo sea válido (fecha + grano)
- Registrar una nueva operación
- Actualizar la operación como finalizada
No funcionales
- Son restricciones o condiciones sobre el sistema o su desarrollo
Ejemplos
- Los cupos se otorgan a los titulares mediante un portal web
- La báscula se comunica con el sistema para informar el peso en cada pesaje
- Cuando se genere el turno, se enviará al titular un QR que deberá usarlo para ingresar a la planta y disparar la operación
- El sistema enviará el QR mediante correo electrónico
- Debe ejecutarse en Linux
- Debe ser desarrollado íntegramente en software libre
- Debe estar corriendo 24/7 del año corriente
- Debe implementarse en Java
- Debe poder procesar 100.000 transacciones por hora
Modelo FURPS+
Es un modelo para comprobar que se cumplen los requerimientos, y reducir el riesgo de dejar de lado alguna faceta importante para el nuevo sistema
- FURPS es una sigla para:
- Functionality: capacidades
- Usability: Factores humanos, ayuda, documentación
- Reliability: Recuperación de fallos, previsión
- Performance: Tiempo de respuesta, uso de recursos
- Supportability: Adaptabilidad, facilidad de mantenimiento
- + se refiere a requerimientos no funcionales como:
- Implementación: Lenguajes, hardware, herramientas
- Interfaz: Restricciones para la interacción con sistemas externos, no se refiere a la GUI
- Operaciones: Gestión del sistema, puesta en marcha
- Empaquetamiento: Forma de distribución
- Legales: Licencia, derechos de autor