Ingeniería de Requerimientos de Software: Fundamentos, Modelo FURPS y Casos de Uso

Gestión de Requerimientos de Software

Definición y Objetivos de los Requerimientos

Requerimientos: Una condición o capacidad con la cual un sistema debe estar en conformidad o debe adaptarse.

Los objetivos principales de establecer requerimientos son:

• Establecer y mantener la conformidad de las necesidades de los clientes y usuarios acerca de lo que el sistema debe hacer.
• Definir las fronteras del sistema.

Administración de Requerimientos

La Administración de Requerimientos es una aproximación sistemática para encontrar, documentar, organizar y localizar los requerimientos cambiantes de un sistema. También permite establecer y mantener acuerdos entre los clientes y el equipo de trabajo.

Desafíos Comunes en la Gestión de Requerimientos

La gestión de requerimientos presenta varios problemas inherentes al proceso:

• Los requerimientos no son siempre obvios y provienen de diferentes fuentes.
• No siempre se expresan con facilidad.
• Son cambiantes.
• Existen muchos tipos diferentes de requerimientos y distintos niveles de detalle.

Flujo de Trabajo (Workflow) de Requerimientos

El flujo de trabajo detallado para la gestión de requerimientos incluye las siguientes etapas:

1. Analizar el problema.
2. Comprender las necesidades del usuario.
3. Definir el sistema.
4. Administrar los cambios.

Clasificación de Requerimientos: Modelo FURPS

El MODELO FURPS es un acrónimo utilizado para clasificar los diferentes tipos de requerimientos de un sistema:

• Functionality (Funcionalidad)
• Usability (Capacidad de Uso)
• Reliability (Fiabilidad)
• Performance (Desempeño)
• Supportability (Capacidad de Soporte)

Requerimientos Funcionales

Los Requerimientos Funcionales especifican algo que el sistema debe hacer asociado a la información. Pueden incluir la lista de acciones que el usuario realiza en el sistema. Su forma de redacción típica es: "El sistema debe hacer..."

Requerimientos No Funcionales

Los Requerimientos No Funcionales son una limitación a cómo el sistema debe actuar o cómo debe construirse. Describen atributos del sistema o del entorno donde se desarrolla.

Subcategorías de Requerimientos No Funcionales

• De Usability (Capacidad de Uso): Incluyen subcategorías como factores humanos, estética, ayudas en línea, agentes y wizards.
• De Reliability (Fiabilidad): Abarcan aspectos como frecuencia de fallos, capacidad predictiva, precisión y capacidad de recuperación.
• De Performance (Desempeño): Afectan a los requerimientos funcionales en la medida de parámetros como velocidad, eficiencia, disponibilidad y exactitud.
• De Supportability (Capacidad de Soporte): Incluyen la capacidad de prueba, crecimiento, portabilidad, mantenimiento, compatibilidad y configuración.

Ejemplos de Requerimientos No Funcionales

• Usability: El texto de la interfaz gráfica está en idioma español.
• Reliability: El sistema debe estar disponible al 98% en el horario de 7:00 a.m. a 10:00 p.m.
• Performance: El sistema debe permitir la concurrencia de hasta 500 usuarios.
• Supportability: El sistema es compatible con el sistema operativo Android desde la versión 6 y iOS desde la versión 10.

Atributos Clave de los Requerimientos

Los requerimientos deben poseer atributos que faciliten su gestión y seguimiento:

• Prioridad: Establece la programación de requerimientos en un plan de iteraciones. Toma valores de Alta, Media y Baja.
• Categoría: Establece la clasificación de los requerimientos de acuerdo con la necesidad. Toma valores Primario, Secundario, Opcional.
• Visibilidad: Establece el nivel de contacto con el usuario que tiene un requerimiento. Toma valores Visible y Oculto.
• Precedencia: Establece qué requerimientos son necesarios para que otros se inicien o sucedan.

Características de un Buen Requerimiento

Para redactar un requerimiento de alta calidad, este debe ser:

• No ambiguo
• Verificable
• Claro
• Correcto
• Entendible
• Factible
• Independiente
• Atómico
• No redundante
• Completo
• Consistente

Modelado de Comportamiento: Casos de Uso

El Modelo de Casos de Uso es fundamental en los workflows de requerimientos, análisis, diseño y pruebas. Su objetivo es comunicar la funcionalidad y el comportamiento del sistema al cliente y al usuario, sirviendo como un instrumento clave de comunicación.

Actores y Casos de Uso

• Actores: Representan cualquier persona o cosa que interactúa con el sistema. No son parte del sistema, sino roles de un usuario. Pueden intercambiar información con el sistema o ser un recipiente pasivo de información.
• Casos de Uso: Son una secuencia de acciones que obtienen resultados de valor para un actor, permitiendo especificar el comportamiento del sistema.

Métodos para Identificar Casos de Uso

Método Basado en Actores

Se relacionan los actores vinculados con un sistema o empresa. Para cada actor, se identifican los procesos que ellos inician.

Preguntas clave:

• ¿Cuáles son las tareas de este actor?
• ¿Qué objetivos concretos necesita alcanzar un actor?

Método Basado en Eventos

Se identifican los eventos externos a los que un sistema debe responder. Se relacionan los eventos con los actores y con los casos de uso.

Diagramas de Casos de Uso

El Diagrama de Casos de Uso representa un conjunto de casos de uso para un sistema, los actores y la relación entre casos de uso y actores.