Taxonomía de requisitos
- Área: Ingeniería de requisitos
- Carácter del recurso: Recomendado
Descripción
Contar con una buena clasificación de requisitos permite determinar las necesidades de un proyecto software cubriendo sus aspectos más relevantes.
Características
Los requisitos del sistema software a desarrollar (requisitos de producto en terminología CMMI-DEV 1.2) pueden clasificarse según distintos criterios. En Madeja se ha optado por la clasificación que puede en la siguiente tabla y que atiende a la distinta naturaleza de los mismos. En las siguientes secciones se detalla dicha clasificación.
Tipo de requisito de producto | Subtipos |
---|---|
Requisitos generales | Ninguno |
Requisitos funcionales | Casos de uso Requisitos de información Requisitos de reglas de negocio Requisitos de conducta |
Requisitos no funcionales | Fiabilidad Usabilidad Eficiencia Mantenibilidad Portabilidad Seguridad |
Restricciones técnicas | Ninguno |
Requisitos de integración | Ninguno |
Requisitos generales
Los requisitos generales, también denominados características del sistema (system features) u objetivos del sistema, describen a alto nivel las características básicas del sistema que luego se detallarán mediante los otros tipos de requisitos.
Requisitos funcionales
Definen las funcionalidades o capacidades que debe ofrecer el sistema a los usuarios para alcanzar sus objetivos de su negocio. Se clasifican en los siguientes subtipos:
- Casos de uso: describen interacciones entre el sistema y los usuarios en los que éstos últimos realizan sus tareas de negocio utilizando los servicios ofrecidos por el sistema a desarrollar.
- Reglas de negocio: describen restricciones, reglas o políticas del negocio que deben ser respetadas por el sistema a desarrollar.
- Requisitos de conducta: describen los servicios que debe ofrecer el sistema para que los usuarios u otros sistemas puedan realizar sus tareas de negocio, por ejemplo: El sistema deberá imprimir, a petición de los usuarios, un listado de contribuyentes cuyo resultado "a devolver" del IRPF supere los 3.000 euros. Si son servicios con una gran interactividad, se suelen describir como casos de uo.
- Requisitos de información: describen qué información debe almacenar el sistema para poder ofrecer los servicios necesarios. Deben identificar el concepto relevante sobre el que se debe guardar información así como qué datos específicos relativos al concepto son importantes para cumplir los objetivos del sistema.
Requisitos no funcionales
Son condiciones que se le imponen al sistema a desarrollar relacionadas con aspectos principalmente de calidad, algunos de los cuales influyen en la arquitectura del sistema.
El modelo de calidad del software de la norma IS0-9126 organiza los requisitos no funcionales en las siguientes características y subcaracterísticas.
- Fiabilidad: esta categoría define aspectos relacionados con la capacidad del software desarrollado para mantener su nivel de prestación bajo condiciones establecidas y durante un período de tiempo establecido. Las subcaracterísticas son: madurez, recuperabilidad, tolerancia a fallos.
- Usabilidad: esta categoría define aspectos relacionados con las dificultades que pueden encontrar los usuarios al enfrentarse al uso del nuevo software. Las subcaracterísticas son: aprendizaje, comprensión, operatividad, atractividad.
- Eficiencia: esta categoría define aspectos que indican la proporción entre el nivel de cumplimiento del software y la cantidad de recursos necesitados bajo condiciones establecidas. Las subcaracterísticas son: comportamiento en el tiempo, comportamiento según otros recursos.
- Mantenibilidad: esta categoría define aspectos relacionados con la facilidad de ampliar la funcionalidad, modificar o corregir errores en un sistema software. Las subcaracterísticas son: estabilidad, facilidad de análisis, facilidad de cambio, facilidad de pruebas.
- Portabilidad: eesta categoría define aspectos relacionados con la capacidad de un sistema software para ser transferido desde una plataforma a otra. Las subcaracterísticas son: capacidad de instalación, capacidad de sustitución, adaptabilidad, coexistencia, compatibilidad con hardware o software, etc.
- Seguridad: esta categoría define aspectos relativos a la políticas de privacidad del sistema a desarrollar. Las subcaracterísticas son: accesos al sistema, identificación y autenticación, protección de datos y privacidad.
Este conjunto de requisitos no funcionales puede ser ampliado si el proyecto de desarrollo así lo requiriera.
Restricciones técnicas
Definen condiciones o limitaciones de diversa índole (industriales, tecnológicas, metodológicas) que se imponen al proyecto y que impactan tanto en el desarrollo como en el producto final. Algunas de ellas vienen limitadas por el entorno tecnológico de la organización donde se va a implantar el software y otras vienen impuestas directamente por el cliente.
Requisitos de integración
Identifican aquellos servicios que van a ser utilizados siguiendo el paradigma de reutilización y arquitecturas SOA.
Buenas prácticas y recomendaciones de uso
A la hora de definir la taxonomía de requisitos se recomiendan seguir las siguientes buenas prácticas:
- Establecer de forma clara y eficiente, los objetivos del sistema de manera que se interpreten como la primera abstracción de la necesidad de negocio.
- Establecer los tiempo de vida estimados para los requisitos de información
- Reflejar mediante reglas de negocio, todas las causisticas posibles dentro de las diversas funcionalidades que compondrán el sistema
Ejemplos
Ejemplos de Requisitos Generales
Ejemplo de Requisito general del sistema
Ejemplos de Requisitos Funcionales
Ejemplo de Requisito de información del sistema
Ejemplo de Requisito de regla de negocio del sistema
Ejemplo de Requisito de conducta del sistema
Ejemplos de Requisitos no funcionales
Ejemplo de Requisito de fiabilidad
Ejemplo de Requisito de usabilidad
Ejemplo de Requisito de rendimiento
Ejemplo de Requisito de mantenibilidad
Ejemplos de Requisito de portabilidad
Ejemplo de Requisito de seguridad
Ejemplos de Restricción Técnica
Ejemplo de Requisitos de restricción técnica
Ejemplos de Requisito de Integración
Ejemplo de Requisito de integración del sistema