En 1995 se realizó el informe CHAOS sobre los resultados obtenidos en diversos proyectos software
Factores de fracaso incluyen: falta de información por parte de los usuarios, especificación de requisitos incompleta, continuos cambios de los requisitos, pobres habilidades técnicas en la especificación de requisitos...
La ingeniería de requisitos cubre las tareas y proporciona los mecanismos necesarios para:
- Entender y analizar las necesidades del cliente
- Evaluar la viabilidad y negociar una solución razonable
- Especificar la solución sin ambigüedades
- Como resultado se tendrá un documento que describa la solución acordada
- Validar y analizar la especificación reflejada en el documento de especificación de requisitos
- Como resultado se obtendrá el modelo del análisis
- Administrar y controlar los requisitos a lo largo del proceso de desarrollo
El proceso de construcción de una “especificación de Requisitos” es un proceso iterativo, en el que partimos de especificaciones iniciales incompletas, poco claras o ambiguas y llegamos a especificaciones finales completas, claras, documentadas y validadas.
- Condición o capacidad que debe tener un producto para resolver una necesidad expresada por un usuario
- Representación en forma de documento de una capacidad o condición que debe tener un producto software
- Característica de un producto software que es condición para su aceptación por parte del cliente
- Propiedad o restricción determinada con precisión que un producto software debe satisfacer
- Funcional: describen la interacción entre el sistema y su entorno, proporcionando servicios que proveerá el sistema o indicando la manera en que éste reaccionará ante ciertos estímulos
- No funcional o atributo de calidad: describen cualidades o restricciones del sistema que no se relacionan de forma directa con el comportamiento funcional del mismo
- De información: describen necesidades de almacenamiento de información en el sistema
Limitaciones sobre servicios y funciones que ofrece el sistema, suelen aplicarse al sistema como un todo. Restringen los tipos de soluciones que podemos tomar: no describen funciones, sino propiedades. Son los que garantizan la calidad del software
Pueden ser requisitos del producto, de la organización u externos. Tienen algunas dificultades para determinarlos:
- Las metodologías no provienen de herramientas ni formas de abordar de forma directa su obtención
- Suele aparecer al estudiar posibles diseños
- Aumentan la complejidad del diseño
- Uso de lenguaje natural para su especificación
- Funcionality: funcionalidad. Requisito funcional
- **Usability: **facilidad de uso. Factores humanos, ayuda, documentación
- Reliability: fiabilidad. Frecuencia de fallos, disponibilidad, capacidad de recuperación, previsión
- Performance: rendimiento. Tiempos de respuesta, productividad, precisión, velocidad, uso de recursos
- Supportability: soporte. Adaptabilidad, facilidad de mantenimiento, internacionalización, configurabilidad
- Implementación: limitación de recursos, lenguajes y herramientas, hardware...
- Interfaz: restricciones impuestas para la interacción con sistemas externos
- Operación: gestión del sistema en su puesta en marcha y a nivel operacional
- Empaquetamiento: formas y distribución, restricciones de instalación...
- Legales: licencias, derechos de autor...
- Completos: Todos los aspectos del sistema están representados en el modelo de requisitos.
- Consistentes: Los requisitos no se contradicen entre sí.
- No ambiguos: No es posible interpretar los requisitos de dos o más formas diferentes.
- Correctos: Representan exactamente el sistema que el cliente necesita y que el desarrollador construirá.
- Realistas: Los requisitos se pueden implementar con la tecnología y presupuesto disponible.
- Verificables: Se pueden diseñar pruebas para demostrar que el sistema satisface los requisitos.
- Trazables: Cada requisito puede rastrearse a través del desarrollo del software hasta su correspondiente funcionalidad del sistema.