Ingeniería de Requerimientos

Ingeniería de Requerimientos

Introducción:

Los requerimientos describen las necesidades de los clientes y son usados como base para determinar la apariencia y comportamiento de los productos.

La ingeniería de requerimientos tiende el puente entre los deseos del cliente y el producto.

Que Busca ?

• La CALIDAD de los productos

• captar las necesidades/demandas de los clientes

• la facilidad del proceso

• reducción de costos

• descubrir incompletitudes e inconsistencias en las primeras etapas del ciclo

• administrar los cambios y evolución de los requerimientos integrando los factores contextuales humanos y sociales.

Por que ? (problemas)

• Los requerimientos difusos son el principal riesgo de los proyectos.
• La evolución y el rehuso de componentes de IT marcan la línea entre el éxito y el fracaso de los proyectos, estos se obtienen sólo a través de un conocimiento cabal de los requerimientos.
• Los errores en esta fase se propagan al resto.
• Se cometen muchos errores en la definición de los requisitos.
• Muchos errores no se detectan tempranamente.
• Muchos errores se podrían detectar tempranamente.
• La no detección de estos errores contribuye a distorsionar los costos del software.
• El software resultante puede no satisfacer las necesidades reales de los usuarios.
• Muchas veces se invierte tiempo y dinero en el software equivocado.

Fases del proceso de especificación de requerimientos

• Adquisición de la visión global de las necesidades de los clientes, incluyendo: necesidades de ingeniería, seguridad, legislación, estrategia y los aspectos blandos como cultura del equipo, memoria corporativa y "lecciones aprendidas".

• La especificación de los requerimientos describe de una manera más formal las funciones deseadas y la apariencia que alcanzará el sistema en el dominio de la aplicación debe estar lo mas libre posible de implicancias de diseño, completa, consistente, precisa, clara y validadas la base para el diseño.

• La administración de los requerimientos maneja los cambios y evolución, rehuso, integración, documentación, aseguramiento de calidad y familia de productos.

• En la validación y verificación
• Validación: se confirma con el cliente si el dominio del problema fue correctamente entendido y documentado o sea especifiqué lo correcto ?
• Verificación: mostrar que las especificaciones son comprensibles, precisas, completas y consistentes o sea especifiqué correctamente ?

Actividades del proceso de definición de requerimientos

• Establecer los alcances del sistema
• Construir el modelo escencial hasta la primera métrica elegida.
• Construir el diagrama de contexto.
• Redactar documento que describa el diagrama de contexto especificando volúmenes.

• Determinar los beneficios esperados
• Es válido atribuir el proyecto de software el beneficio esperado para el área global.

• Definir usuarios
• Listar entidades externas del diagrama de contexto
• Describir las funciones derivadas de los intercambios de flujos con el sistema.
• Aquí no se consideran los usuarios que puedan seguir luego en el diseño.

• Definir objetivos
• Funcionales
• Describir propósito perseguido con las funciones.
• Especificar los  beneficios esperados en unidades medibles ($, tiempo, calidad de servicios de información) por el usuario.

• De eficiencia
• Describir con precisión las necesidades de eficiencia: tiempo medio y máximo de respuesta, volumen de datos crítico.

• De seguridad
• Separar los paquetes de cada flujo según necesidades de seguridad
• Describir las restricciones de acceso por  paquete en cada flujo
• Asignar los paquetes en diferentes categorías de seguridad.

• Mantenibilidad
• Para cada evento especificar los tiempos medios entre caídas y hasta la recuperación

• Análisis de Prefactibilidad
• Factibilidad económica
• Estimar costo de desarrollo mediante un predictor.
• Comparar contra beneficio esperado.
• Analizar costos fijos ( no dependen del volumen) y variables (dependen del volumen)
• Analizar vida útil, período de repago y retorno de inversión.
• Analizar riesgos y alternativas.

• Factibilidad Técnica
• Tecnología nueva o desconocida

• Factibilidad Operativa
• Dimensión de riesgo

• Evaluación de Alternativas

Características de una buena especificación de requerimientos.

• No ambigua: cada característica debe describirse usando un único término en los casos en que un término tenga múltiples significados, debe incluirse en un glosario el lenguaje natural es especialmente ambiguo.

• Completa: Debe incluir todos los requerimientos significativos relacionados con funcionalidad, performance, contraints (restricciones) de diseño, atributos, interfases externas, debe considerar la respuesta deseada para todas las clases posibles de datos de entrada en todas las clases posibles de situaciones.

• Verificable: el documento de especificación es verificable si y sólo si todos sus requerimientos son verificables. Un requerimiento es verificable si y solo si existe un número finitos de procesos que una persona o maquina pueda realizar a un costo efectivo

• Consistente: no debe haber conflicto entre ninguna combinación de requisitos.

• Modificable: su estructura y estilo debe permitir que los cambios en los requerimientos se hagan fácil, completa y consistentemente.

• Trazable: el origen de cada requerimiento es claro y habilita su referencia en futuros desarrollos.

...