3. Casos de uso, requisitos funcionales e historias de usuario
3.1 Introducción
En el análisis de software se utilizan distintas formas de describir lo que un sistema debe hacer. Tres de las más comunes son los casos de uso, los requisitos funcionales y las historias de usuario. Las tres se relacionan con el comportamiento del sistema, pero no expresan la información de la misma manera.
Un caso de uso describe una interacción completa entre un actor y el sistema para lograr un objetivo. Un requisito funcional describe una capacidad o comportamiento que el sistema debe cumplir. Una historia de usuario expresa una necesidad desde la perspectiva de un usuario, normalmente en un formato breve y orientado al valor.
Comprender la diferencia evita confusiones. No se trata de elegir una técnica como si las demás fueran incorrectas; se trata de saber qué aporta cada una y cómo pueden complementarse dentro de un proyecto.
3.2 Requisito funcional
Un requisito funcional indica una función, servicio o comportamiento que el sistema debe ofrecer. Suele redactarse como una obligación del sistema, por ejemplo: "El sistema debe permitir registrar un cliente".
Los requisitos funcionales son útiles porque expresan compromisos concretos. Permiten decir qué debe hacer el sistema y sirven como base para análisis, diseño, construcción y pruebas. Sin embargo, cuando se escriben como una lista aislada, pueden perder contexto: no siempre queda claro quién usa esa funcionalidad, con qué objetivo, en qué orden ocurre y qué alternativas existen.
El sistema debe permitir que un paciente solicite un turno con un profesional médico disponible.
3.3 Historia de usuario
Una historia de usuario describe una necesidad desde el punto de vista de un usuario o rol. Es frecuente en enfoques ágiles porque permite expresar valor de manera breve y priorizable.
Un formato habitual es:
Por ejemplo:
La historia de usuario no pretende describir todos los detalles por sí sola. Normalmente se complementa con conversación, criterios de aceptación, prototipos, reglas de negocio o casos de uso más detallados cuando el comportamiento lo requiere.
3.4 Caso de uso
Un caso de uso describe una interacción completa entre un actor y el sistema. A diferencia de un requisito funcional breve, el caso de uso suele incluir flujo principal, alternativas, excepciones, precondiciones, postcondiciones y reglas de negocio relacionadas.
Por ejemplo, el caso de uso Solicitar turno puede explicar que el paciente inicia la solicitud, el sistema muestra especialidades, el paciente selecciona un profesional, el sistema muestra horarios, el paciente confirma y el sistema registra el turno. También puede describir qué ocurre si no hay horarios, si el paciente no está registrado o si el turno fue tomado por otra persona antes de confirmar.
3.5 Tres formas de describir una misma necesidad
La misma necesidad puede expresarse como requisito funcional, historia de usuario y caso de uso. Cada formato resalta un aspecto distinto: obligación del sistema, valor para el usuario o interacción detallada entre actor y sistema.
3.6 Comparación general
La siguiente tabla resume las diferencias principales entre las tres formas de documentación:
| Técnica | Pregunta que responde | Nivel de detalle | Ejemplo |
|---|---|---|---|
| Requisito funcional | ¿Qué debe hacer el sistema? | Variable, normalmente puntual. | El sistema debe permitir solicitar turnos. |
| Historia de usuario | ¿Qué necesita lograr un usuario y para qué? | Breve, orientado al valor. | Como paciente, quiero solicitar un turno para organizar mi consulta médica. |
| Caso de uso | ¿Cómo interactúan actor y sistema para lograr el objetivo? | Medio o alto, según la especificación. | Solicitar turno, con flujo principal, alternativas y excepciones. |
3.7 Relación entre las tres técnicas
No hay una única manera de organizar la documentación. En algunos proyectos, primero se escriben historias de usuario y luego se detallan con criterios de aceptación o casos de uso. En otros, primero se identifican casos de uso y de ellos se derivan requisitos funcionales. También puede ocurrir que una lista de requisitos inicial se refine mediante casos de uso para aclarar comportamiento.
Lo importante es mantener coherencia. Si una historia dice que el paciente quiere solicitar un turno, los requisitos funcionales y el caso de uso relacionados deben describir el mismo objetivo, sin contradicciones.
3.8 De la historia al caso de uso
Una historia de usuario suele ser un buen punto de partida para conversar. A partir de ella, el analista puede preguntar qué pasos ocurren, qué datos se necesitan, qué reglas deben cumplirse y qué problemas pueden aparecer.
Ejemplo:
Como paciente, quiero solicitar un turno médico en línea, para evitar llamar por teléfono a la clínica.
A partir de esa historia pueden surgir preguntas como:
- ¿El paciente debe estar registrado antes de solicitar el turno?
- ¿Puede buscar por profesional, especialidad o fecha?
- ¿Se permite reservar más de un turno para la misma especialidad?
- ¿Qué ocurre si no hay disponibilidad?
- ¿El sistema envía confirmación por correo electrónico, mensaje o notificación interna?
- ¿El turno queda confirmado inmediatamente o requiere aprobación?
Las respuestas a estas preguntas permiten construir una especificación de caso de uso más precisa.
3.9 Del caso de uso a requisitos funcionales
También es posible partir de un caso de uso y extraer requisitos funcionales. Cada responsabilidad importante del sistema puede convertirse en un requisito verificable.
Por ejemplo, si el caso de uso indica que el sistema muestra horarios disponibles y registra la confirmación del paciente, pueden derivarse estos requisitos:
- El sistema debe listar horarios disponibles según profesional, especialidad y fecha.
- El sistema debe impedir la reserva de horarios ocupados.
- El sistema debe registrar el turno seleccionado por el paciente.
- El sistema debe generar una confirmación de reserva.
- El sistema debe actualizar la disponibilidad después de confirmar el turno.
3.10 Transformación entre formatos
La información puede pasar de un formato a otro si se conserva el mismo objetivo. Una historia ayuda a iniciar la conversación, el caso de uso organiza la interacción y los requisitos funcionales dejan registradas las capacidades que el sistema debe cumplir.
3.11 Criterios de aceptación
Las historias de usuario suelen acompañarse con criterios de aceptación. Estos criterios indican condiciones que deben cumplirse para considerar que la historia fue implementada correctamente.
Ejemplo para la historia "Como paciente, quiero solicitar un turno médico en línea":
- Debe ser posible buscar turnos por especialidad.
- Solo deben mostrarse horarios disponibles.
- El paciente debe poder confirmar un turno seleccionado.
- Después de confirmar, el sistema debe mostrar un comprobante.
- Si no hay turnos disponibles, el sistema debe informar la situación y permitir modificar la búsqueda.
Estos criterios se relacionan directamente con los flujos del caso de uso y con las pruebas de aceptación.
3.12 Evitar duplicaciones y contradicciones
Cuando se usan varias técnicas en el mismo proyecto, hay que evitar que la documentación se contradiga. Si una historia dice que el paciente puede cancelar un turno hasta 24 horas antes, pero el caso de uso indica 48 horas, el equipo tendrá dudas y el sistema puede implementarse de manera incorrecta.
Para reducir este problema conviene:
- Usar identificadores para relacionar historias, casos de uso y requisitos.
- Evitar copiar la misma regla de negocio en muchos lugares sin necesidad.
- Definir una fuente principal para reglas críticas.
- Actualizar la documentación cuando cambia una decisión.
- Revisar los casos de uso con usuarios y con el equipo técnico.
3.13 Cuándo conviene usar casos de uso
Los casos de uso convienen especialmente cuando el comportamiento tiene varios pasos, reglas, alternativas o excepciones. También son útiles cuando participan varios actores o cuando se necesita validar con detalle cómo debe responder el sistema.
Por ejemplo, un botón simple para activar o desactivar una preferencia quizá pueda describirse con una historia breve y criterios de aceptación. En cambio, un proceso de inscripción, compra, reserva, reclamo, autorización o liquidación suele beneficiarse de una especificación de caso de uso.
3.14 Cuándo conviene usar historias de usuario
Las historias de usuario son muy útiles para planificar trabajo incremental, priorizar necesidades y mantener el foco en el valor para el usuario. Funcionan bien en equipos ágiles porque son breves, conversables y fáciles de ordenar en una lista de producto.
Sin embargo, una historia breve no siempre alcanza para comportamientos complejos. Si la historia contiene muchas reglas, excepciones o integraciones, puede necesitar documentación adicional. Esa documentación puede tomar la forma de criterios de aceptación detallados, ejemplos, prototipos o casos de uso.
3.15 Cuándo conviene usar requisitos funcionales
Los requisitos funcionales son útiles cuando se necesita una especificación clara de obligaciones del sistema. Pueden aparecer en contratos, documentos formales, matrices de trazabilidad, pruebas de aceptación y documentación de alcance.
Su principal ventaja es que permiten declarar capacidades verificables. Su principal riesgo es convertirse en una lista larga y descontextualizada. Por eso conviene relacionarlos con actores, objetivos, casos de uso o historias de usuario.
3.16 Comparación aplicada a un sistema de turnos
En un sistema de turnos médicos, las tres técnicas pueden convivir de esta manera:
| Elemento | Contenido | Uso principal |
|---|---|---|
| Historia de usuario | Como paciente, quiero solicitar un turno para organizar mi consulta médica. | Priorizar necesidad y conversar sobre valor. |
| Caso de uso | Solicitar turno: actor, precondiciones, flujo principal, alternativas, excepciones y resultado esperado. | Describir la interacción completa. |
| Requisito funcional | El sistema debe permitir seleccionar un horario disponible y registrar la reserva. | Formalizar una capacidad verificable. |
| Criterio de aceptación | Dado un paciente registrado, cuando selecciona un horario disponible y confirma, entonces el turno queda reservado. | Verificar que la funcionalidad cumple lo esperado. |
3.17 Relación con pruebas
Las tres técnicas pueden aportar a las pruebas, pero de manera distinta. Los requisitos funcionales indican qué se debe verificar. Las historias de usuario y sus criterios de aceptación ayudan a definir cuándo una necesidad está satisfecha. Los casos de uso permiten recorrer flujos completos y probar alternativas o excepciones.
3.18 Errores frecuentes
Al combinar estas técnicas, suelen aparecer errores como los siguientes:
- Creer que una historia de usuario siempre reemplaza a un caso de uso.
- Redactar requisitos funcionales sin contexto de actor ni objetivo.
- Escribir casos de uso demasiado extensos para comportamientos simples.
- Duplicar reglas de negocio en muchos documentos y luego actualizarlas de forma inconsistente.
- Confundir criterios de aceptación con el flujo completo de un caso de uso.
- Usar una técnica por obligación, sin que aporte claridad al proyecto.
3.19 Qué debes recordar de este tema
- Un requisito funcional describe una capacidad o comportamiento obligatorio del sistema.
- Una historia de usuario expresa una necesidad desde la perspectiva de un usuario y su valor esperado.
- Un caso de uso describe la interacción entre actor y sistema para lograr un objetivo.
- Las tres técnicas pueden complementarse dentro del mismo proyecto.
- Los casos de uso son especialmente útiles cuando hay secuencias, alternativas, excepciones y reglas de negocio.
- Las historias de usuario ayudan a priorizar y conversar sobre valor.
- Los requisitos funcionales ayudan a formalizar capacidades verificables.
3.20 Conclusión
Casos de uso, requisitos funcionales e historias de usuario no son enemigos ni reemplazos automáticos entre sí. Son herramientas distintas para expresar necesidades y comportamiento del sistema desde ángulos complementarios.
En un proyecto real, la elección depende del nivel de detalle necesario, la forma de trabajo del equipo, la complejidad del dominio y la necesidad de validación. Lo importante es que la documentación ayude a construir el sistema correcto, con claridad suficiente para usuarios y equipo técnico.
En el próximo tema estudiaremos el alcance del sistema y el límite del sistema, dos conceptos esenciales para saber qué queda dentro y fuera del análisis.