Skip to content

Tema 5: Comprensión de los Requisitos y Casos de Uso

📝 Resumen Ejecutivo

Esta sesión establece la base de todo proyecto de software: entender qué necesita el cliente antes de construirlo. Se detalla el proceso formal de Ingeniería de Requisitos (desde la obtención hasta la validación) y se profundiza en el Modelado de Casos de Uso, la herramienta principal de UML para capturar la funcionalidad del sistema. El mensaje central es que un error aquí es el más costoso de corregir, ya que implica que hemos resuelto el problema equivocado.

🗝️ Conceptos Clave

  • Ingeniería de Requisitos: Proceso sistemático de descubrimiento, comunicación y gestión de las necesidades del cliente.
  • Elicitación: El acto de "sacar" o levantar los requisitos del cliente.
  • Verificación vs. Validación: Verificación es comprobar la calidad formal (¿está bien escrito?); Validación es comprobar si es lo que el usuario quería (¿es el producto correcto?).
  • Requisito No Funcional: Restricciones del sistema (rendimiento, legalidad) que no son servicios directos pero son críticos.
  • Caso de Uso (CU): Unidad funcional atómica que produce un resultado observable para un actor.
  • Actor: Entidad externa (humana o sistema) que interactúa con el sistema.

📚 Desarrollo del Temario

1. La Problemática de los Requisitos

El profesor inicia ilustrando la dificultad de comunicación entre el dominio del problema (cliente) y el dominio de la solución (nosotros/informáticos).

  • El "Teléfono Escacharrado": Lo que el usuario pide a menudo no es lo que realmente necesita, y lo que nosotros entendemos suele distorsionarse en cada paso (analista -> diseñador -> programador) .
    • Contexto Profesional: La toma de requisitos es un trabajo complejo y fundamental. El profesor enfatiza (con la anécdota de Tectris Ingeniería) que este proceso se debe cobrar. Es una consultoría profesional diagnóstica, similar a la de un médico.

2. El Proceso de Ingeniería de Requisitos

No es un caos, es un ciclo ordenado definido por actividades específicas:

  1. Obtención (Elicitación): Buscar, investigar y documentar necesidades usando el vocabulario del cliente (lenguaje natural). Técnicas: entrevistas, reuniones .
  2. Análisis: Descomponer el todo en partes para detectar conflictos o inconsistencias .
  3. Aseguramiento de Calidad (QA):
    • Verificación: ¿El requisito está bien construido? ¿Cumple el estándar formal? Detecta defectos técnicos .
    • Validación: Enfrentar el requisito al cliente. ¿Es esto lo que querías? Detecta errores de concepto .

      ¡OJO AL DATO!: Entender la diferencia es pregunta de examen. Verificación = Correcto formalmente. Validación = Correcto para el usuario.

  4. Negociación: Resolver conflictos. Ejemplo del profesor: Si un requisito dice "Login obligatorio" y otro "Compra como invitado", hay un conflicto que se debe negociar y resolver antes de seguir.
  5. Gestión: Controlar los cambios y el versionado de los requisitos a lo largo del tiempo .

3. Tipos de Requisitos (Modelo RSM de K. Pohl)

Un requisito es una condición necesaria para resolver un problema. Se clasifican en tres tipos:

  • 1. Requisitos Funcionales: Describen servicios o funcionalidades (lo que el sistema hace).
    • Ejemplo: "Dar de alta un pedido", "Calcular nota media".
  • 2. Requisitos de Datos: Estructura de la información (lo que el sistema almacena).
    • Ejemplo: "Guardar nombre, apellidos y DNI del profesor".
  • 3. Requisitos No Funcionales: Restricciones o condiciones de calidad.
    • Ejemplo del profesor: "El sistema debe cumplir el RGPD" (Legislativo) o "La respuesta debe tardar menos de 200ms" (Rendimiento).

      Nota: A veces un requisito no funcional es más crítico que uno funcional. Si no cumples la ley o el rendimiento es pésimo, el software no sirve.

4. Especificación de Requisitos Software (ERS)

Para documentar todo esto formalmente, se utiliza el estándar IEEE 830-1998. Este documento actúa como contrato técnico. * Estructura típica: Introducción, Descripción general, Requisitos específicos (Funcionales, Datos, No funcionales) .

5. Casos de Uso (UML)

Es la técnica propuesta por Ivar Jacobson para especificar requisitos funcionales. Describe el sistema basado en interacciones.

Elementos Básicos

  1. Actor:
    • Rol que juega una entidad externa.
    • Puede ser Humano (Usuario, Administrador) o Sistema Externo (PayPal, Pasarela de Pago).
    • ¡Importante! Un actor también puede ser el Tiempo o el propio sistema actuando automáticamente (ej. un script a las 4:00 AM que limpia cestas vacías). El profesor destaca que la clave es que inicia una acción.
  2. Caso de Uso (El Óvalo):
    • Unidad atómica y funcional.
    • Debe producir un resultado observable.
    • Ejemplo: "Introducir nombre" NO es un caso de uso (es un paso). "Registrar Usuario" SÍ es un caso de uso (es completo).

Relaciones (La parte técnica compleja)

Hay 4 tipos de relaciones fundamentales en estos diagramas:

  • A. Asociación: Línea sólida. Conecta Actor con Caso de Uso. Indica quién inicia o participa en la funcionalidad.

  • B. Generalización (Herencia): Triángulo blanco.

    • Entre Actores: Un actor "hijo" hereda todos los permisos del "padre".
      • Ejemplo: Si Administrador hereda de Estudiante, el admin puede hacer todo lo que hace el estudiante (entregar prácticas) más lo suyo propio.
    • Entre Casos de Uso: Un caso de uso hijo es una versión especializada del padre.
      • Principio de Sustitución: El hijo puede sustituir al padre.

  • C. Inclusión (<<Include>>):

    • Obligatorio. El caso de uso base siempre ejecuta el incluido.
    • Se usa para reutilizar código común o subdividir lógica compleja.
    • Dirección de la flecha: Del Base al Incluido.
    • Ejemplo: Calificar Actividad incluye Escribir Feedback (siempre hay que dar feedback al calificar).

  • D. Extensión (<<Extend>>):

    • Opcional. El caso de uso extensor solo se ejecuta si se cumple una condición (Punto de extensión).
    • Dirección de la flecha: Del Extensor al Extendido (¡Cuidado! Se dibuja al revés de como se lee lógicamente).
    • Ejemplo: Al Matricular Estudiante, si el estudiante no existe (condición), se ejecuta Registrar Estudiante (<<Extend>>).

6. Metodología y Documentación

El diagrama por sí solo no basta ("son solo monigotes"). Se requiere una ficha textual por cada caso de uso que detalle: * Precondiciones. * Secuencia normal (paso a paso). * Excepciones (caminos alternativos). * Poscondiciones.

El Proceso Unificado (UP) es "Dirigido por Casos de Uso". Esto significa que los casos de uso definidos aquí se usarán para diseñar la arquitectura, escribir el código y crear las pruebas.

🧪 Preguntas de Autoevaluación

  1. Diferencia clave entre Verificación y Validación en el contexto de requisitos.

    • Respuesta: La verificación comprueba la corrección técnica y formal del requisito (¿lo hemos hecho bien?), mientras que la validación asegura que el requisito corresponde a la necesidad real del usuario (¿hemos hecho lo que el usuario quería?).

  2. Si tengo un proceso de "Pagar Compra" que siempre requiere "Validar Tarjeta", ¿qué relación UML debo usar?

    • Respuesta: <<Include>>. Porque es una ejecución obligatoria y necesaria para completar el caso base. La flecha iría de "Pagar Compra" a "Validar Tarjeta".

  3. ¿Puede un sistema informático ser un Actor en un diagrama de casos de uso?

    • Respuesta: Sí. Un actor es cualquier entidad externa que interactúa con el sistema. Puede ser una pasarela de pago (PayPal) o un cron job que lanza un proceso automático.

  4. Según el modelo de K. Pohl, ¿dónde clasificarías la restricción "El sistema debe cumplir la ley de protección de datos"?

    • Respuesta: Es un Requisito No Funcional (específicamente legal/legislativo).

  5. En una relación de generalización de actores, si el "Administrador" hereda del "Profesor", ¿puede el Profesor realizar las acciones exclusivas del Administrador?

    • Respuesta: No. La herencia va hacia abajo. El hijo (Admin) puede hacer lo del padre (Profesor), pero el padre no puede hacer lo exclusivo del hijo.