Ilustración 10: Requisitos funcionales

Ilustración 11: RF-01 Alta de usuarios

RF-01	Alta de usuarios
Objetivos asociados	OBJ-02 Gestionar usuarios
Requisitos asociados	RI-02 Información sobre socios
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando alguien solicite su ingreso como usuario
Precondición	La persona solicitante no debe estar dado de alta en el sistema
Secuencia normal	Paso
1	El solicitante pide al sistema comenzar el proceso de alta de un nuevo usuario
2	El sistema solicita vincular la Wallet del nuevo usuario
3	El sistema comprueba que los datos del usuario coinciden con los de la Wallet vinculada
4	El solicitante proporciona los datos requeridos y solicita al sistema que los almacene
5	El sistema almacena los datos proporcionados, y envía un correo electrónico que el proceso ha terminado con éxito
6	El sistema asigna un nuevo perfil al solicitante recientemente dado de alta
Postcondición	El solicitante es usuario del sistema y el saldo de su cuenta es 0
Excepciones	Paso
1	Si los datos aportados en el registro no son correctos, el administrador del sistema cancela la operación, a continuación, este caso de uso termina
2	Si el sistema detecta que el nuevo usuario ya existe, el sistema informa de la situación al administrador del sistema permitiéndole mandar una alerta al usuario para modificar los datos proporcionados, al concluir este caso de uso continúa
3	Si el usuario solicita cancelar el proceso, el sistema cancela la operación, a continuación este caso de uso termina
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 10 Requisito Funcional-01

Ilustración 12: RF-02 Baja de usuarios

RF-02	Baja de usuarios
Objetivos asociados	OBJ-02 Gestionar usuarios
Requisitos asociados	RI-02 Información sobre socios
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando alguien solicite su baja.
Precondición	La persona solicitante debe estar dado de alta en el sistema
Secuencia normal	Paso
1	El solicitante pide al sistema comenzar el proceso de baja de un usuario.
	2
	3
Postcondición	El solicitante es usuario del sistema.
Excepciones	Paso
1	Si el usuario tiene pagos pendientes, el sistema comunica la situación al cliente y cancela la operación, a continuación, este caso de uso termina.
1	Si el usuario solicita cancelar la operación, el sistema cancela la operación, a continuación, este caso de uso termina.
Rendimiento	Paso
4	1 segundo
Frecuencia esperada	1 veces/ mes
Estabilidad	alta
Comentarios	Si el usuario desea darse de baja tiene un pago pendiente, puede hacer un ingreso por su importe y repetir el proceso de darse de baja.

Tabla 11 Requisito Funcional-02

Ilustración 13: RF-03 Actualizar datos del Usuario

RF-03	Actualizar datos del Usuario
Objetivos asociados	OBJ-02 Gestionar usuarios
Requisitos asociados	RI-02 Información de los usuarios clientes que solicitan productos o servicios
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando alguien solicite la modificación de sus datos personales
Precondición	La persona solicitante tiene una cuenta de cliente o proveedor en el sistema
Secuencia normal	Paso
1	El solicitante pide al sistema modificar sus datos de usuario
2	El sistema solicita los datos que el usuario necesite modificar o actualizar
3	El usuario comprueba que los datos que desea modificar son los correctos
4	El sistema manda un mensaje de alerta para corroborar que el usuario está seguro de modificar los datos correspondientes y que sus datos coinciden con los datos de su wallet
5	El sistema almacena los datos proporcionados, y envía un código de confirmación a su número de teléfono
6	El sistema actualiza el perfil con los datos nuevos del usuario una vez que el código de confirmación haya sido ingresado correctamente
Postcondición	El solicitante tiene el mismo perfil con los datos nuevos actualizados
Excepciones	Paso
1	Si los datos aportados no coinciden en nada con los datos de la wallet del usuario la operación de actualización no procede
2	Si el sistema detecta que el usuario no da el código de verificación correcto después de 5 veces, la actualización no procede y se envía un mensaje de alerta al número de teléfono proporcionado al crear la cuenta en un inicio
3	Si el usuario solicita cancelar el proceso, el sistema cancela la operación, a continuación este caso de uso termina
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	2 veces/mes
Comentarios	Ninguno

Tabla 12 Requisito Funcional-03

Ilustración 14: RF-04 Buscar Usuario

RF-04	Buscar Usuario
Objetivos asociados	OBJ-02 Gestionar usuarios
Requisitos asociados	RI-02 Información sobre socios
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando alguien solicite la búsqueda de un usuario.
Precondición	La persona solicitante debe de estar dado de alta en el sistema para poder realizar dicha búsqueda de otro usuario, o bien, este deberá ser el administrador mismo de la plataforma.
Secuencia normal	Paso
1	El solicitante solicita al sistema comenzar el proceso de búsqueda de algún otro usuario del sistema.
2	El sistema solicita que el solicitante se identifique a través de la vinculación de su Wallet, esto para poder comenzar el proceso de dicha búsqueda que se ha solicitado.
3	El sistema corrobora que los datos del solicitante de dicha búsqueda coincidan con los de la Wallet vinculada.
4	El sistema muestra los resultados de la búsqueda que el solicitante ha realizado de otro usuario.
5	Si el usuario solicita la descarga de los datos consultados, el sistema los almacena y los envía a su correo para la descarga de la misma.
Postcondición	Ninguna.
Excepciones	Paso
1	Si el solicitante de la búsqueda le pide al sistema la cancelación de dicha operación, el sistema la cancela y este caso de uso termina.
2	Si en el momento de solicitar la identificación del usuario para la realización de búsqueda de otro usuario, la wallet proporcionada no es válida, el sistema notifica al solicitante la situación y este caso de uso termina.
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 13 Requisito Funcional-04

Ilustración 15: RF-05 Verificar de cuenta de usuario

RF-05	Verificar de cuenta de usuario
Objetivos asociados	OBJ-02 Gestionar usuarios
Requisitos asociados	RI-03 Información de los usuarios clientes que solicitan productos o servicios
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso para que el usuario verifique su cuenta
Precondición	La cuenta del usuario debe estar dada de alta
Secuencia normal	Paso
1	El usuario entra al sistema
2	El sistema redirecciona al usuario para que verifique su cuenta mediante el código que se le proporcionó al crear su wallet
3	El usuario autoriza que es él
4	El sistema deja acceder al usuario
Postcondición	El solicitante es usuario del sistema y el saldo de su cuenta es 0
Excepciones	Paso
1	Si los datos aportados en la wallet no son correctos, el sistema cancela la operación, a continuación, este caso de uso termina
2	Si el sistema detecta que el nuevo usuario no existe, el sistema informa de la situación al usuario para modificar la wallet proporcionada, al concluir este caso de uso continúa
3	Si el usuario solicita cancelar el proceso, el sistema cancela la operación, a continuación este caso de uso termina
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 14 Requisito Funcional-05

Ilustración 16: RF-06 Identificación de usuario

RF-06	Identificación de usuario
Objetivos asociados	OBJ-02 Gestionar usuarios
Requisitos asociados	RI-02 Información de los usuarios clientes
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso durante la realización de los casos de uso: RF-02 Baja de usuario RF-03 Modificación de datos de un usuario RF-16 Pago del evento
Precondición	El usuario tiene información disponible.
Secuencia normal	Paso
1	El sistema solicita que se identifique la Wallet del cliente
2	El cliente solicita un código
3	El sistema comprueba el código que le proporcionó el usuario cuando se dio de alta
4	El sistema confirma la identidad del cliente
Postcondición	Ninguna
Excepciones	Paso
1	El sistema detecta que el supuesto cliente no es cliente de la plataforma, el sistema comunica al cliente la situación, a continuación, este caso de uso aborta.
2	Si el cliente no conoce el código, puede reintentar el renvío de este mismo como cuando se dio de alta, a continuación, este caso de uso continua.
Rendimiento	Paso
Frecuencia esperada	50 veces/ día
Comentarios	ninguno

Tabla 15 Requisito Funcional-06

Casos de uso para el subsistema Festividad 3.0 (Proveedor):

Ilustración 17: RF-07 Registro de datos del evento

RF-07	Registro de datos del evento
Objetivos asociados	OBJ-02 Gestionar eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario solicite registrar el registro de datos de un evento.
Precondición	El proveedor que desee de alta un evento en el sistema debe tener una wallet vinculada al sistema.
Secuencia normal	Paso
1	El proveedor solicita al sistema comenzar el proceso de alta (registro de datos de eventos).
2	El sistema le solicita al proveedor la vinculación de una wallet válida para identificar al usuario y así poder comenzar el proceso de alta de eventos.
3	El sistema identifica la wallet del proveedor como válida y comienza el proceso de registro de eventos.
4	El sistema le solicita al proveedor el número de eventos a registrar.
5	El proveedor almacena los datos que se le piden para poder dar de alta sus eventos y los datos de cada evento, posteriormente le solicita al sistema almacenar la información proporcionada y que este se vincule a su usuario.
6	El sistema almacena los datos que el proveedor ha proporcionado para el evento y las registra a nombre del usuario proveedor para mostrarlas en la plataforma.
Postcondición	Los eventos están registrados en el sistema.
Excepciones	Paso
1	Si el proveedor que ha solicitado el registro de sus eventos solicita la cancelación de la operación al sistema, este lo ejecuta y este caso de uso para este evento finaliza.
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 16 Requisito Funcional-07

Ilustración 18: RF-08 Eliminar datos del evento

RF-08	Eliminar datos del evento
Objetivos asociados	OBJ-02 Gestionar eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario-proveedor solicite la eliminación de datos de un evento.
Precondición	La persona solicitante de dar de alta un evento debe ser usuario-proveedor del sistema.
Secuencia normal	Paso
1	El usuario-proveedor hace una búsqueda del evento del que desea eliminar los datos.
2	El usuario-proveedor elimina los datos necesarios del evento.
3	El usuario-proveedor confirma la acción.
4	El sistema solicita que el usuario-proveedor se identifique a través de la verificación de su Wallet, esto para poder comenzar el proceso de dicha acción que se ha solicitado.
Postcondición	Ninguna.
Excepciones	Paso
1	Si el solicitante de la búsqueda le pide al sistema la cancelación de dicha operación, el sistema la cancela y este caso de uso termina.
2	Si en el momento de solicitar la identificación del usuario para la realización de búsqueda de otro usuario, la wallet proporcionada no es válida, el sistema notifica al solicitante la situación y este caso de uso termina.
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 17 Requisito Funcional-08

Ilustración 19: RF-09 Actualizar datos del evento

RF-09	Actualizar datos del evento
Objetivos asociados	OBJ-02 Gestionar eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El proveedor actualiza los datos del evento en el sistema
Precondición	La persona solicitante de solicitar la modificación de los datos de un evento debe ser usuario-cliente del sistema.
Secuencia normal	Paso
1	El usuario-cliente solicita la modificación de datos del evento adquirido para que puedan ser actualizados
2	El usuario-proveedor a través del sistema solicita los datos que serán modificados para la actualización del evento
3	El sistema manda un mensaje de confirmación al usuario-cliente para corroborar que los nuevos datos sean correctos
4	El usuario-cliente verifica que los datos ingresados al sistema sean los correctos.
5	El usuario-proveedor autoriza la actualización de los datos del evento
Postcondición	El evento contiene nuevos datos modificados
Excepciones	Paso
1	Si el usuario-proveedor no autoriza la actualización de datos la operación no procede y se notifica al usuario cliente
2	Si el usuario cliente no verifica sus datos la operación queda incompleta por lo tanto no se realiza.
Rendimiento	Paso
3	5 segundos
Frecuencia esperada	3 veces/mes
Estabilidad	alta
Comentarios	Ninguno

Tabla 18 Requisito Funcional-09

Ilustración 20: RF-10 Buscar Evento

RF-10	Buscar Evento
Objetivos asociados	OBJ-02 Gestionar eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el cliente lo considere oportuno
Precondición	Ninguna
Secuencia normal	Paso
1	El cliente solicita al sistema comenzar el proceso de consulta de datos de un evento.
2	El cliente solicita que se identifique el evento a consultar
3	El sistema identifica el servicio a consultar
4	El sistema muestra los siguientes datos correspondientes: Nombre del servicio, Precio del servicio, disponibilidad del servicio, fechas y horarios.
Postcondición	La información correspondiente al servicio no ha cambiado.
Excepciones	Paso
1	Si el cliente solicita cancelar la operación, el sistema cancela la operación, a continuación, este caso de uso termina.
Rendimiento	Paso
4	1 segundo
Frecuencia esperada	1 veces/ día
Comentarios	Ninguno

Tabla 19 Requisito Funcional-10

Ilustración 21: RF-11 Autorizar evento

RF-11	Autorizar evento
Objetivos asociados	OBJ-02 Gestionar eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un proveedor solicite la autorización de uno de sus eventos para que este pueda estar a la disponibilidad del público.
Precondición	La persona solicitante de dicha autorización de evento debe ser usuario del sistema, en este caso en el apartado de proveedor para que pueda realizar dicha solicitud de autorización.
Secuencia normal	Paso
1
2	El usuario-proveedor a través del sistema solicita los datos que serán modificados para la actualización del evento
3	El sistema manda un mensaje de confirmación al usuario-cliente para corroborar que los nuevos datos sean correctos
4	El usuario-cliente verifica que los datos ingresados al sistema sean los correctos.
5	El usuario-proveedor autoriza la actualización de los datos del evento
Postcondición	El evento contiene nuevos datos modificados
Excepciones	Paso
1	Si el usuario-proveedor no autoriza la actualización de datos la operación no procede y se notifica al usuario cliente
2	Si en el momento de solicitar la identificación del usuario para la realización de búsqueda de otro usuario, la wallet proporcionada no es válida, el sistema notifica al solicitante la situación y este caso de uso termina.
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	Alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 20 Requisito Funcional-11

Ilustración 22: RF-12 Dar de baja el evento

RF-12	Dar de baja el evento
Objetivos asociados	OBJ-02 Gestionar eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El proveedor da de baja el evento del sistema
Precondición	La persona solicitante de solicitar la modificación de los datos de un evento debe ser usuario-proveedor del sistema.
Secuencia normal	Paso
1	El usuario-proveedor solicita la eliminación del evento del sistema.
2	El sistema manda un mensaje de confirmación al usuario-cliente para corroborar que los nuevos datos sean correctos
3	El sistema redirecciona al usuario-proveedor a otra página donde autorizará la acción
4	El usuario-proveedor verifica que los datos mostrados en la wallet sean los correctos.
5	El usuario-proveedor autoriza la eliminación del evento.
Postcondición	El evento contiene nuevos datos modificados
Excepciones	Paso
1	Si el usuario-proveedor no autoriza la actualización de datos la operación no procede y se notifica al usuario cliente
2	Si en el momento de solicitar la identificación del usuario para la realización de búsqueda de otro usuario, la wallet proporcionada no es válida, el sistema notifica al solicitante la situación y este caso de uso termina.
Rendimiento	Paso
4	5 segundos
Frecuencia esperada	10 veces/ día
Estabilidad	Alta
Comentarios	La frecuencia será mucho mayor durante los dos primeros meses, probablemente 100 veces/día.

Tabla 21 Requisito Funcional-12

Casos de uso del subsistema Festividad 3.0 (Clientes).

Ilustración 23: RF-13 Buscar eventos (clientes)

RF-13	Buscar eventos (clientes)
Objetivos asociados	OBJ-02 Gestionar los eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá sugerir mostrar y sugerir eventos realizados o relacionados a la búsqueda del usuario-cliente
Precondición	El usuario-cliente debe tener claro el tipo de evento que requiere para su búsqueda
Secuencia normal	Paso
1	El cliente solicita al sistema comenzar la búsqueda de eventos que requiera o eventos con las características que el cliente le dé al sistema para la búsqueda
2	El sistema muestra los resultados de la búsqueda mostrándolos de acuerdo al número de opiniones buenas que tengan
3	El usuario-cliente selecciona la opción que más se adecué a sus necesidades y el sistema le muestra una lista de proveedores que maneje el tipo de evento que el cliente haya buscado
Postcondición	El usuario-cliente encuentra la mejor opción de evento que se adecué a sus necesidades y gustos
Excepciones	Paso
1	Si el cliente solicita cancelar la búsqueda, el sistema cancela la operación, a continuación, este caso de uso termina.
Rendimiento	Paso
3	1 segundo
Frecuencia esperada	20 veces/ día
Comentarios	La frecuencia de esta operación se supone alta debido a la demanda de servicios relacionados a eventos

Tabla 22 Requisito Funcional-13

Ilustración 24: RF-14 Identificación de eventos (proveedor)

RF-14	Identificación de eventos (proveedor)
Objetivos asociados	OBJ-02 Gestionar los eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el cliente lo considere oportuno
Precondición	Ninguna
Secuencia normal	Paso
1	El cliente solicita al sistema comenzar el proceso de consulta de datos de un evento.
2	El cliente solicita que se identifique el evento a consultar
3	El sistema identifica el servicio a consultar
4	El sistema muestra los siguientes datos correspondientes: Nombre del servicio, Precio del servicio, disponibilidad del servicio, fechas y horarios.
Postcondición	La información correspondiente al servicio no ha cambiado.
Excepciones	Paso
1	Si el cliente solicita cancelar la operación, el sistema cancela la operación, a continuación, este caso de uso termina.
Rendimiento	Paso
4	1 segundo
Frecuencia esperada	1 veces/ día
Comentarios	ninguno

Tabla 23 Requisito Funcional-14

Ilustración 25: RF-15 Calendarización del evento (cliente)

RF-15	Calendarización del evento (cliente)
Objetivos asociados	OBJ-02 Gestionar los eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un cliente realice la solicitud de un evento, mismo que se tendrá que calendarizar.
Precondición	El usuario cliente debe de haber elegido previamente un evento para que este haya sido autorizado por el proveedor y así mismo este pueda ser calendarizado.
Secuencia normal	Paso
1	El cliente solicita al sistema un evento.
2	El cliente solicita que autorización del evento elegido para con el proveedor.
3	El sistema le notifica al cliente sobre su evento y este mismo procede al proceso de calendarización.
4	El sistema muestra los siguientes datos, es decir, primeramente, procede a la creación del evento, marca los objetivos, el lugar y fecha del evento y así mismo le notifica al cliente el presupuesto del evento a cubrir.
5	El sistema le notifica al cliente todos los detalles sobre su evento y le solicita al cliente que corrobore que la información es correcta, así como que de su consentimiento sobre el presupuesto calculado y mismo que se le ha notificado.
	6
Postcondición	La información correspondiente al servicio no ha cambiado.
Excepciones	Paso
1	Si el cliente solicita cancelar el evento, por tanto, sistema cancela la calendarización del evento, a continuación, este caso de uso termina.
Rendimiento	Paso
4	1 segundo
Frecuencia esperada	1 veces/ día
Comentarios	ninguno

Tabla 24 Requisito Funcional-15

Ilustración 26: RF-16 Pago del evento(cliente)

RF-16	Pago del evento(cliente)
Objetivos asociados	OBJ-02 Gestionar los eventos
Requisitos asociados	RI-02 Información sobre eventos
Descripción	El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando un usuario-cliente realice los pagos del evento al usuario-proveedor.
Precondición	El usuario cliente debe de haberse acordado previamente un SmartContract con el proveedor al inicio del evento.
Secuencia normal	Paso
1	Se hace el pago del 50% de costo del evento al usuario proveedor.
2	El sistema corrobora que el cliente hizo el 50% del pago al proveedor.
3	El evento se realiza de acuerdo a lo establecido por ambos usuarios.
4	Al terminar el evento el cliente hace el pago del otro 50% al proveedor.
5	El sistema corrobora que el cliente hizo el resto del pago al proveedor.
Postcondición	La información correspondiente al servicio no ha cambiado.
Excepciones	Paso
1	En caso de que el usuario-proveedor se retrase con el evento, el usuario-cliente recibirá el 50% del pago en su cuenta automáticamente.
2	En caso de que el usuario-cliente se retrase con alguno de los pagos del evento, el evento se retendrá hasta que el usuario-cliente haga el respectivo pago.
3	Si una parte incumple las condiciones, la otra tendrá que reclamar el resarcimiento de los daños ante un juez.
4	En caso de cancelarse el evento antes de tiempo el 50% del pago se le otorgará al cliente en su cuenta y el otro 50% al proveedor de forma automática.
Rendimiento	Paso
4	1 segundo
Frecuencia esperada	1 veces/ día
Comentarios	ninguno

Tabla 25 Requisito Funcional-16