Se encuentra en:
Taxonomía de requisitos
RECU-0408 (Recurso Referencia)
Tabla de contenidos
- Á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
El sistema deberá registrar los accesos al edificio mediante el uso de lectores de tarjetas magnéticas.
Ejemplos de Requisitos Funcionales
Ejemplo de Requisito de información del sistema
El sistema deberá almacenar información sobre los perros de caza que componen una reala. En concreto, el código del chip de identificación, el nombre al que responde, la raza, la fecha de nacimiento y la ubicación actual (finca o similar)
Ejemplo de Requisito de regla de negocio del sistema
El sistema deberá respetar la siguiente regla de negocio: un socio del club deportivo podrá reservar un máximo de 5 pistas a la semana y una única pista el mismo día a la misma hora.
Ejemplo de Requisito de conducta del sistema
El sistema deberá generar, a petición del usuario, un informe mensual de préstamos y devoluciones de fondos de la biblioteca.
Ejemplos de Requisitos no funcionales
Ejemplo de Requisito de fiabilidad
El sistema deberá tardar un máximo de 10 minutos para la recuperación de un fallo de caída total, en el 95% de las ocasiones.
Ejemplo de Requisito de usabilidad
El sistema deberá permitir en el 80% de las veces que con un máximo de 5 clicks sea suficiente para llegar a la información deseada.
Ejemplo de Requisito de rendimiento
El sistema deberá tener un tiempo máximo de respuesta de 5 segundos para cualquier operación de consulta.
Ejemplo de Requisito de mantenibilidad
El código fuente que se implemente en JAVA deberá cumplir las recomendaciones de Code Conventions for the Java Programming Language
Ejemplos de Requisito de portabilidad
El sistema deberá evitar el uso de extensiones propietarias al estándar SQL-92 en el sistema de gestión de bases de datos que utilice.
Ejemplo de Requisito de seguridad
El sistema deberá ser capaz de evitar ataques de inyección de SQL sistemáticos.
Ejemplos de Restricción Técnica
Ejemplo de Requisitos de restricción técnica
El sistema deberá ser compatible con los navegadores Internet Explorer 6 y Mozilla Firefox 3.
El sistema deberá utilizar como sistema de gestión de bases de datos Oracle 11g.
Ejemplos de Requisito de Integración
Ejemplo de Requisito de integración del sistema
El sistema deberá utilizar el servicio @firma para todos los aspectos relacionados con validación y firma electrónica.
