27. Requisitos no funcionales relacionados con casos de uso

27.1 Introducción

Los casos de uso describen principalmente comportamiento funcional: qué hace el sistema cuando un actor intenta lograr un objetivo. Sin embargo, muchas veces no alcanza con saber qué debe hacer el sistema; también importa cómo debe hacerlo.

Los requisitos no funcionales expresan cualidades, restricciones y condiciones de calidad que debe cumplir el sistema. Pueden referirse a rendimiento, seguridad, usabilidad, disponibilidad, accesibilidad, confiabilidad, auditoría, privacidad o compatibilidad.

Estos requisitos pueden estar relacionados con todo el sistema o con casos de uso específicos. Por ejemplo, Solicitar turno puede requerir una respuesta rápida, protección de datos personales y confirmación clara para el paciente.

27.2 Qué es un requisito no funcional

Un requisito no funcional define una cualidad o restricción del sistema. No suele describir una funcionalidad nueva, sino una condición que afecta la forma en que se ejecutan las funcionalidades.

Ejemplos:

• El sistema debe responder la búsqueda de turnos en menos de 3 segundos.
• Solo usuarios autorizados pueden consultar datos personales.
• La interfaz debe ser usable desde teléfonos móviles.
• El sistema debe registrar auditoría de cambios en turnos.
• La aplicación debe estar disponible de lunes a viernes durante el horario de atención.

27.3 Relación con casos de uso

Un requisito no funcional puede aplicar a un caso de uso concreto. Por ejemplo, en Solicitar turno, el sistema no solo debe permitir reservar; también debe responder en tiempos aceptables, proteger datos del paciente y evitar reservas duplicadas.

Si el caso de uso tiene importancia crítica, conviene documentar los atributos de calidad que afectan directamente su ejecución.

27.4 Atributos de calidad que condicionan un caso de uso

Los requisitos no funcionales actúan como condiciones de calidad sobre el caso de uso. Una misma funcionalidad puede estar afectada por rendimiento, seguridad, usabilidad, disponibilidad, privacidad y auditoría. Estos atributos no cambian el objetivo del actor, pero sí condicionan la forma aceptable de cumplirlo.

27.5 Rendimiento

El rendimiento indica tiempos de respuesta, capacidad de procesamiento o cantidad de usuarios que el sistema debe soportar. En casos de uso interactivos, es importante porque afecta directamente la experiencia del actor.

Ejemplos relacionados con Solicitar turno:

• La búsqueda de horarios disponibles debe responder en menos de 3 segundos en condiciones normales.
• El sistema debe permitir al menos 100 solicitudes simultáneas de turnos sin degradación crítica.
• La confirmación de reserva debe completarse en menos de 5 segundos.

27.6 Seguridad

La seguridad define cómo se protegen operaciones, datos y accesos. En un caso de uso puede indicar autenticación, autorización, protección contra modificaciones indebidas o manejo seguro de información sensible.

Ejemplos:

• Solo el paciente autenticado puede consultar sus propios turnos.
• Solo usuarios con rol Administrador pueden configurar horarios de atención.
• Las operaciones de cancelación deben registrar usuario, fecha y hora.

27.7 Privacidad

La privacidad se relaciona con el tratamiento de datos personales o sensibles. En sistemas médicos, educativos, financieros o laborales, estos requisitos son especialmente importantes.

Ejemplos:

• Los datos de contacto del paciente solo deben ser visibles para personal autorizado.
• Las confirmaciones no deben exponer información médica sensible.
• El sistema debe permitir auditar quién consultó datos personales.

27.8 Usabilidad

La usabilidad indica qué tan fácil, clara y eficiente debe ser la interacción. Puede afectar el diseño de pantallas, mensajes, cantidad de pasos, prevención de errores y comprensión del proceso.

Ejemplos:

• El paciente debe poder completar la solicitud de turno en un máximo de cinco pasos principales.
• Los mensajes de error deben indicar cómo corregir el problema.
• La confirmación del turno debe mostrar fecha, hora, profesional y sede de manera clara.

27.9 Accesibilidad

La accesibilidad busca que el sistema pueda ser usado por personas con distintas capacidades, dispositivos o condiciones de uso. Puede incluir compatibilidad con lectores de pantalla, contraste suficiente, navegación con teclado y textos comprensibles.

Ejemplos:

• El flujo de solicitud de turno debe poder completarse usando teclado.
• Los mensajes de error deben estar asociados al campo correspondiente.
• Los elementos visuales críticos deben tener descripción textual.

27.10 Disponibilidad

La disponibilidad indica cuándo el sistema debe estar operativo. Puede aplicar al sistema completo o a casos de uso críticos.

Ejemplos:

• La consulta de turnos debe estar disponible todos los días de 7:00 a 22:00.
• La administración de agendas debe estar disponible durante el horario laboral.
• Si el servicio de notificaciones no está disponible, la reserva no debe perderse.

27.11 Confiabilidad y consistencia

La confiabilidad indica que el sistema debe comportarse de manera estable y evitar resultados incorrectos. En casos de uso con datos compartidos, también importa la consistencia.

Ejemplos:

• El sistema no debe permitir dos reservas para el mismo profesional en el mismo horario.
• Si falla el envío de confirmación, el turno confirmado debe conservarse registrado.
• Si la operación se interrumpe antes de confirmar, no debe quedar una reserva incompleta.

27.12 Auditoría

La auditoría permite reconstruir qué ocurrió, quién realizó una operación y cuándo. Es importante cuando hay datos sensibles, responsabilidades legales o cambios críticos.

Ejemplos:

• El sistema debe registrar quién canceló un turno y en qué momento.
• Los cambios de agenda deben quedar auditados.
• Las consultas de datos sensibles deben registrar usuario, fecha y motivo si corresponde.

27.13 Requisitos medibles

Un requisito no funcional debe ser lo más medible posible. Frases como "el sistema debe ser rápido" o "la interfaz debe ser amigable" son demasiado vagas.

Mejores ejemplos:

27.14 Dónde documentarlos

Los requisitos no funcionales pueden documentarse en varios lugares:

• En una sección específica dentro del caso de uso.
• En un documento general de atributos de calidad.
• En criterios de aceptación.
• En reglas de seguridad o privacidad.
• En una matriz de trazabilidad.

Lo importante es que puedan encontrarse, validarse y probarse.

27.15 Ejemplo aplicado a Solicitar turno

Para el caso de uso Solicitar turno, se podrían documentar estos requisitos no funcionales:

27.16 Relación con pruebas

Los requisitos no funcionales deben poder verificarse. Algunos se prueban con pruebas funcionales, otros con pruebas de rendimiento, seguridad, accesibilidad o disponibilidad.

Por ejemplo, si se exige que la búsqueda responda en menos de 3 segundos, debe existir una forma de medirlo. Si se exige que solo usuarios autorizados accedan a datos, debe haber pruebas de permisos.

27.17 Errores frecuentes

Al documentar requisitos no funcionales, suelen aparecer estos errores:

• Escribir frases vagas como rápido, fácil o seguro sin criterio verificable.
• Olvidar requisitos de seguridad y privacidad.
• No relacionar atributos de calidad con casos de uso críticos.
• Confundir reglas de negocio con requisitos no funcionales.
• No definir cómo se comprobará el requisito.
• Documentarlos en un lugar donde nadie los revisa.
• Esperar al final del proyecto para considerarlos.

27.18 Lista de revisión

Antes de cerrar los requisitos no funcionales asociados a un caso de uso, conviene revisar:

• ¿El caso de uso maneja datos sensibles?
• ¿Necesita tiempos de respuesta específicos?
• ¿Debe cumplir permisos o auditoría?
• ¿Debe estar disponible en determinados horarios?
• ¿Requiere accesibilidad o soporte móvil?
• ¿Las condiciones están redactadas de forma medible?
• ¿Existen pruebas para verificarlas?

27.19 Qué debes recordar de este tema

• Los requisitos no funcionales describen cualidades y restricciones del sistema.
• Pueden aplicar al sistema completo o a casos de uso específicos.
• Rendimiento, seguridad, privacidad, usabilidad y disponibilidad pueden condicionar un caso de uso.
• Deben redactarse de forma verificable.
• No deben quedar como frases vagas o deseos generales.
• Influyen en diseño, implementación y pruebas.
• Conviene considerarlos desde el análisis, no al final del proyecto.

27.20 Conclusión

Los casos de uso explican qué comportamiento funcional debe ofrecer el sistema, pero los requisitos no funcionales indican con qué nivel de calidad, seguridad, rendimiento y confiabilidad debe hacerlo.

Documentar estos requisitos junto a los casos de uso críticos permite construir software más adecuado al contexto real. En el próximo tema estudiaremos plantillas para documentar casos de uso.