Caso de estudio 01 · Análisis funcional

Del requisito a UAT

Convertir una necesidad de negocio poco definida en un proceso claro, requisitos verificables, reglas de negocio, criterios de aceptación y escenarios de UAT.

Análisis funcionalAnálisis de requisitosReglas de negocioAnálisis de procesosHistorias de usuarioCriterios de aceptaciónAnálisis de riesgosTrazabilidadUAT
01

Necesidad de negocio

Empezar por el problema, no por la solución.

Queremos que los clientes puedan cancelar su reserva desde la aplicación y recibir un reembolso automático.

Suena claro hasta que intentamos definir exactamente cuándo se permite cancelar, cuánto se reembolsa, cómo deben evolucionar los estados y qué ocurre cuando falla una operación de pago.

02

Descubrimiento

Preguntas antes que requisitos

Elegibilidad

  • ¿Puede cancelarse cualquier reserva?
  • ¿Hay un plazo límite?
  • ¿Hay productos no reembolsables?

Importes

  • ¿El reembolso es siempre del 100%?
  • ¿Los gastos de servicio son reembolsables?
  • ¿Cómo afectan los descuentos al importe reembolsable?

Tiempo

  • ¿Qué zona horaria controla el corte?
  • ¿Qué ocurre exactamente a las 24 horas?

Pago

  • ¿Todos los métodos de pago admiten reembolso automático?
  • ¿Qué ocurre si el proveedor rechaza la operación o no responde a tiempo?

Proceso

  • ¿Cuándo pasa la reserva a CANCELLED?
  • ¿Pueden diverger el estado del reembolso y el de la reserva?

Seguridad

  • ¿Quién puede cancelar?
  • ¿Puede Soporte actuar en nombre de un usuario?
03

Análisis de procesos

AS-IS → puntos de dolor → TO-BE

AS-IS

01El cliente contacta con Soporte
02El agente consulta la reserva
03El agente cancela manualmente
04Se solicita el reembolso
05El proveedor procesa el reembolso
06Soporte avisa al cliente
Proceso manualRespuesta lentaDependencia operativaPolítica aplicada de forma inconsistenteVisibilidad limitadaRiesgo de error humano

TO-BE

01Mis reservas
02Solicitar cancelación
03Comprobar elegibilidad
04Calcular reembolso
05Mostrar condiciones
06Confirmar
07Registrar la cancelación
08Solicitar el reembolso
09Mostrar estados
04

Requisitos

Definir qué debe hacer el sistema.

FR-01

Permitir que un cliente autenticado solicite la cancelación de una reserva elegible.

FR-02

Evaluar la elegibilidad de cancelación según la política de cancelación aplicable.

FR-03

Calcular el importe reembolsable antes de la confirmación.

FR-04

Mostrar el importe del reembolso y las condiciones de cancelación antes de confirmar.

FR-05

Requerir la confirmación explícita del cliente antes de ejecutar la cancelación.

FR-06

Solicitar el reembolso por el método de pago original cuando esté soportado.

FR-07

Cambiar el estado de la reserva a CANCELLED solo después de registrar correctamente la cancelación.

FR-08

Gestionar el estado del reembolso de forma independiente al estado de la reserva.

FR-09

Mostrar al cliente el estado actual de la cancelación y del reembolso.

FR-10

Notificar al cliente cuando se registre la solicitud de cancelación.

05

Reglas de negocio

Definir las condiciones que gobiernan el comportamiento.

BR-01

La cancelación desde la aplicación está disponible hasta 24 horas antes del inicio del servicio.

BR-02

La elegibilidad utiliza la zona horaria local del servicio reservado.

BR-03

Las reservas NON_REFUNDABLE no se pueden cancelar desde la aplicación.

BR-04

Con más de 72 horas antes del servicio: 100% de la base reembolsable.

BR-05

Entre 24 y 72 horas: 50% de la base reembolsable.

BR-06

Con menos de 24 horas: la cancelación desde la aplicación no está disponible.

BR-07

Los descuentos promocionales ya están reflejados en el importe realmente pagado.

BR-08

Los gastos de servicio no son reembolsables.

BR-09

Una solicitud de cancelación no puede procesarse dos veces.

BR-10

Un fallo del reembolso no debe generar una segunda solicitud de cancelación.

06

Modelo de reglas ejecutable

Convertir las reglas de negocio en comportamiento determinista.

R-01

96 h · reembolsable

Pagado 120,00 € · Gastos 10,00 €

Elegible110,00 €
FULL_REFUND
R-02

48 h · reembolsable

Pagado 120,00 € · Gastos 10,00 €

Elegible55,00 €
PARTIAL_REFUND
R-03

12 h · reembolsable

Pagado 120,00 € · Gastos 10,00 €

No elegible0,00 €
LESS_THAN_24H
07

Historia de usuario

Traducir el análisis en una pieza construible.

Como cliente, quiero cancelar una reserva elegible desde la aplicación, para poder gestionar mi reserva sin tener que contactar con atención al cliente.
08

Criterios de aceptación

Convertir el comportamiento esperado en algo testable.

AC-01

Dada una reserva reembolsable a más de 72 h del servicio, cuando se solicita la cancelación, se muestra un reembolso del 100% de la base reembolsable, excluyendo los gastos de servicio.

AC-02

Dada una reserva entre 24 y 72 h del servicio, cuando se solicita la cancelación, se muestra un reembolso del 50% de la base reembolsable.

AC-03

Dada una reserva a menos de 24 h del servicio, cuando se intenta cancelar, la cancelación desde la aplicación no está disponible y se explica la política.

AC-04

Dada una reserva NON_REFUNDABLE, cuando se muestran las opciones de cancelación, la acción de cancelar está deshabilitada.

AC-05

Dada una reserva elegible, cuando falla la solicitud de reembolso, no se genera un estado inconsistente de la reserva y el usuario recibe un mensaje explicativo.

AC-06

Dada una solicitud de cancelación ya enviada, cuando el usuario intenta enviarla de nuevo, se impide el procesamiento duplicado.

09

Estados del sistema

El estado de la reserva y el estado del reembolso son conceptos de negocio distintos.

Reserva
01CONFIRMED
02CANCELLATION_PENDING
03CANCELLED
04COMPLETED
Reembolso
01NOT_REQUIRED
02PENDING
03PROCESSING
04COMPLETED / FAILED
10

Análisis de impacto

Una funcionalidad puede afectar a varios sistemas.

Customer AppUX de cancelación
Booking ServiceElegibilidad y estado
Policy ServicePolítica de cancelación
Payment ServiceSolicitud de reembolso
Notification ServiceComunicaciones al cliente
Base de datosEstados e historial de auditoría
SoporteVisibilidad operativa
AnalyticsEventos de cancelación
11

Trazabilidad

Mantener la regla conectada desde el requisito hasta la validación.

RequisitoRegla de negocioCriterios de aceptaciónUAT
FR-02BR-01, BR-02, BR-03, BR-06AC-01, AC-02, AC-03, AC-04UAT-01, UAT-02, UAT-03
FR-03BR-04, BR-05, BR-08AC-01, AC-02UAT-01, UAT-02, UAT-04
FR-06BR-10AC-05UAT-05
FR-05BR-09AC-06UAT-06
12

UAT

Validar el comportamiento esperado del negocio, no solo la implementación.

UAT-01

Cancelación con reembolso completo

Reserva cancelada · importe reembolsable correcto · reembolso iniciado · confirmación visible

UAT-02

Cancelación con reembolso parcial

Reembolso del 50% calculado correctamente

UAT-03

Fuera del periodo permitido

Cancelación no disponible · política explicada

UAT-04

Exclusión de gastos de servicio

Gasto no reembolsable excluido correctamente

UAT-05

Fallo del proveedor de pago

Sin estado inconsistente de la reserva

UAT-06

Cancelación duplicada

Solo se procesa una cancelación

UAT-07

Reembolso en proceso

Reserva CANCELLED · Reembolso PROCESSING · estado mostrado correctamente al usuario

Evidencia Gherkin
Scenario: Full refund more than 72 hours before service
  Given a refundable reservation starts in 96 hours
  And the customer paid 120 EUR including a 10 EUR non-refundable service fee
  When the customer requests cancellation
  Then self-service cancellation is available
  And the refundable amount is 110 EUR
13

Validación basada en riesgo

Priorizar por impacto en negocio.

Impacto alto · probabilidad mayor
  • Cálculo de reembolso incorrecto
  • Cancelación duplicada
  • Reserva cancelada sin solicitud de reembolso
Impacto alto · probabilidad menor
  • Respuesta inconsistente del proveedor de pago
  • Concurrencia desde dos dispositivos
14

Resultado del análisis

De la ambigüedad a un comportamiento testable

Reglas de negocio definidas

Las ventanas de cancelación, el cálculo del reembolso y las condiciones de elegibilidad se convirtieron en reglas explícitas y testables.

Casos límite definidos

El comportamiento exacto en los umbrales de 24 h y 72 h se identificó como un punto crítico que debía definirse sin ambigüedades.

Comportamiento del sistema modelado

Los estados de reserva y reembolso se separaron para evitar combinaciones inconsistentes y transiciones poco claras.

Dependencias identificadas

El análisis conectó el comportamiento de cancelación con pagos, reembolsos, notificaciones y estado de la reserva.

Trazabilidad establecida

Necesidad de negocio → requisitos → reglas → criterios de aceptación → escenarios de prueba → UAT.

Cobertura basada en riesgo definida

La cobertura de pruebas se priorizó según el impacto financiero, los casos límite, las acciones duplicadas y la consistencia de estados.

15

Conclusión

La calidad puede empezar antes de que exista un caso de prueba.

Probar permite comprobar si el sistema funciona como esperamos. El análisis funcional ayuda a definir, antes de llegar a ese punto, cuál debe ser ese comportamiento.