Historias de usuario

Historia de Usuario

Número: HU1 Usuario: Programador

Nombre historia:
1.1.1 Página de inicio (interfaz inicio)

Prioridad en negocio: Alta Riesgo en desarrollo: Bajo

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Fernando Lopez

Descripción: Como programador se debe presentar al usuario una primera interfaz

amigable para el cliente que sea de fácil manejo.

Requerimientos no funcionales:
● La pantalla de inicio debe contener un menú que permita al administrador del
sistema acceder a las diferentes interfaces, como son: Login, registro de nuevos
usuarios, aplicación de encuesta, y búsqueda e informes.
● La interfaz debe mostrar una breve descripción del sistema.
● Si el usuario intenta acceder a cualquiera de las opciones del menú el sistema le
solicitará primero el login.

Historia de Usuario

Número: HU2 Usuario: Operador del sistema

Nombre historia:
1.1.2 Acceso al sistema (Login)

Prioridad en negocio: Media Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: por seguridad de la información el sistema debe solicitar al administrador

un nombre de usuario y una contraseña.

Requerimientos no funcionales:
● La pantalla de login y registro debe contener los siguientes campos: Nombre de
usuario y Password.
● Debe indicarse que campos son obligatorios mediante un carácter (*).
● Si el administrador no se registra no puede acceder a otras partes del sistema..
● El administrador podrá registrar un nuevo operador siempre y cuando haya
iniciado sesión en el sistema.

Historia de Usuario

Número: HU3 Usuario: Administrador del sistema

Nombre historia:
1.1.3 Registro de nuevo operador

Prioridad en negocio: Media Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: Como administrador del sistema debe poder registrar a un nuevo operador
del sistema.

Requerimientos no funcionales:
● El administrador podrá registrar un nuevo operador siempre y cuando haya
iniciado sesión en el sistema.
● La interfaz de registro del operador debe contener los siguientes campos: Nombre,
Apellido, Nombre de usuario, Email, Password, Confirm password.
● Debe indicarse que campos son obligatorios mediante un carácter (*) al lado del
input.
● Si el usuario intenta enviar el formulario sin tener los campos obligatorios
diligenciados, se debe mostrar una alerta indicando el problema.
● Llevar el enfoque al campo que contiene errores.
Historia de Usuario

Número: HU4 Usuario: Operador del sistema

Nombre historia:
1.1.4 Búsqueda de datos de usuario

Prioridad en negocio: Media Riesgo en desarrollo: Bajo

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: El operador del sistema debe tener acceso a la información de usuarios que
se maneje en la base de datos.

Requerimientos no funcionales:
● El sistema debe permitir al operador realizar una búsqueda para verificar si el
usuario o visitante ya ha sido registrado con anterioridad en la base de datos.
● La búsqueda se debe realizar al ingresar la identificación del usuario y luego dar
en botón de búsqueda.
● La interfaz de búsqueda debe contener los siguientes campos: Identificación,
Nombre, Apellido, Dirección, Teléfono, Email.

Historia de Usuario

Número: HU5 Usuario: Operador del sistema

Nombre historia:
1.1.5 Modificación de datos de usuario

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: El operador del sistema debe tener permisos de modificar la información en

caso de ser necesario.

Requerimientos no funcionales:
 ● El sistema debe permitir al operador realizar una búsqueda para verificar si el
usuario o visitante ya ha sido registrado con anterioridad en la base de datos.
● La búsqueda se debe realizar al ingresar la identificación del usuario y luego dar
en botón de búsqueda.
● La interfaz de búsqueda debe contener los siguientes campos: Identificación,
Nombre, Apellido, Dirección, Teléfono, Email.
● Debe haber un botón específico de modificación de datos y también un botón de
guardar.
● Solo se debe permitir la modificación de campos como Teléfono, Dirección,
Email

Historia de Usuario

Número: HU6 Usuario: Operador del sistema

Nombre historia:
1.1.6 Ingresar nuevo visitante Estudiante

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: Si un visitante estudiante, no está registrado en la base de datos el operador

debe hacer el debido registro en la base de datos.

Requerimientos no funcionales:
● La pantalla de registro de estudiante debe contener los siguientes campos:
Nombre, Apellido, Email, Teléfono, Dirección, Programa Académico, Facultad,
Semestre
● Debe indicarse que campos son obligatorios mediante un carácter (*).
● Si el operador intenta enviar el formulario sin tener los campos obligatorios
diligenciados, se debe mostrar una alerta indicando el problema.
● La interfaz debe tener un botón de aplicación de encuesta que se pueda ejecutar
una vez se guarden los datos del estudiante.
Historia de Usuario

Número: HU7 Usuario: Operador del sistema

Nombre historia:
1.1.7 Ingresar nuevo visitante Funcionario

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: Si un visitante funcionario, no está registrado en la base de datos el

operador debe hacer el debido registro en la base de datos.

Requerimientos no funcionales:
● La pantalla de registro de funcionario debe contener los siguientes campos:
Nombre, Apellido, Email, Teléfono, Dirección, Cargo, Dependencia o Facultad.
● Debe indicarse que campos son obligatorios mediante un carácter (*).
● Si el operador intenta enviar el formulario sin tener los campos obligatorios
diligenciados, se debe mostrar una alerta indicando el problema.
● La interfaz debe tener un botón de aplicación de encuesta que se pueda ejecutar
una vez se guarden los datos del estudiante.

Historia de Usuario

Número: HU8 Usuario: Operador del sistema

Nombre historia:
1.1.8 Ingresar nuevo Visitante Externo

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: Si un visitante externo, no está registrado en la base de datos el operador

debe hacer el debido registro en la base de datos.

Requerimientos no funcionales:
 ● La pantalla de registro de visitante externo debe contener los siguientes campos:
Nombre, Apellido, Email, Teléfono, Dirección.
● Debe indicarse que campos son obligatorios mediante un carácter (*).
● Si el operador intenta enviar el formulario sin tener los campos obligatorios
diligenciados, se debe mostrar una alerta indicando el problema.
● La interfaz debe tener un botón de aplicación de encuesta que se pueda ejecutar
una vez se guarden los datos del estudiante.

Historia de Usuario

Número: HU9 Usuario: Operador del sistema

Nombre historia:
1.1.9 Aplicación de encuesta

Prioridad en negocio: Alta Riesgo en desarrollo: Alto

Puntos estimados: 3 Iteración asignada: 1

Programador responsable: Milton Mora, Fernando Lopez

Descripción: Una vez se verifique que el visitante está registrado en la base de datos se
procede a aplicar la encuesta.

Requerimientos no funcionales:

● La interfaz de encuesta debe contener los datos del usuario con los campos:
Nombre, Apellido, Email, Teléfono, Dirección.
● La interfaz debe contener mínimo cuatro preguntas de única respuesta (si, no).
● En la encuesta se debe registrar quién realizó la encuesta, una hora y fecha
específica, un campo para el registro de temperatura y uno para registrar la
dependencia de la entidad a la que se va a acceder.
● Si el usuario intenta enviar el formulario sin tener los campos obligatorios
diligenciados, se debe mostrar una alerta indicando el problema.

Historia de Usuario
Número: HU10 Usuario: Programador

Nombre historia:
1.1.10 Validación de datos de encuesta

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 4 Iteración asignada: 1

Programador responsable: Milton Mora – Mildred Ortega

Descripción: El sistema debe validar si los datos diligenciados en la encuesta suponen un

posible caso de COVID y mostrar los datos al operador y administrador del sistema.

Requerimientos no funcionales:
● El sistema debe generar una alerta cuando se ingresen datos como temperatura
superior a 37 grados.
● La alerta se debe mostrar como un mensaje de ventana emergente.
● El sistema debe alertar inmediatamente al administrador del sistema, vía correo
electrónico.

Historia de Usuario

Número: HU11 Usuario: Administrador

Nombre historia:
1.1.11 Verificación de informes

Prioridad en negocio: Media Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Arley Cuaran

Descripción: El administrador del sistema debe tener acceso a la información de visitas

registradas según sea la necesidad.

Requerimientos no funcionales:
● El administrador debe ingresar al sistema (Login)
● En el menú inicio debe ingresar a verificar informes.
● La interfaz de informe debe permitir búsqueda por fechas, por usuario y por
 dependencia visitada.
● El sistema debe permitir imprimir y exportar informes en formato excel.

Historia de Usuario

Número: HU12 Usuario: Operador del sistema

Nombre historia:
1.1.12 Menú ayuda

Prioridad en negocio: Baja Riesgo en desarrollo: Bajo

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Arley Cuaran

Descripción: El operador del sistema debe tener acceso al menú de ayuda que debe llevar
al manual de usuario en caso de requerir.

Requerimientos no funcionales:
● Todas las interfaces deben tener un botón de ayuda
● El botón debe llevar directo al manual de usuario
● Se debe hacer una base de preguntas frecuentes.

Historia de Usuario

Número: HU13 Usuario: Operador del sistema

Nombre historia:
1.1.13 Cambio de interfaz

Prioridad en negocio: Bajo Riesgo en desarrollo: Bajo

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Arley Cuaran

Descripción: El operador debe poder cambiar de interfaz cada vez que lo requiera, ej: de
aplicar encuesta a menú inicial.

Requerimientos no funcionales:
 ● Todas las interfaces deben contar con un botón para regresar al inicio.
● El sistema no debe permitir cambio de interfaz si se está diligenciando una
encuesta o no se han guardado datos.

Historia de Usuario

Número: HU14 Usuario: Administrador

Nombre historia:
1.1.14 Cambio de contraseña de los operadores.

Prioridad en negocio: Media Riesgo en desarrollo: Bajo

Puntos estimados: 1 Iteración asignada: 1

Programador responsable: Fernando López

Descripción: El sistema cada mes pedirá al operador que cambie su contraseña este
proceso será automatizado y sin realizarse el operador no puede proseguir en el sistema.

Requerimientos no funcionales:
● Cada mes el sistema le pedirá al operador que actualice su contraseña. este aviso
saldrá cuando el intente ingresar al sistema.
● La notificación que solicita el cambio de contraseña se mostrará en una ventana
emergente.
● El operador no podrá proseguir en el sistema si no actualiza su contraseña.
● El sistema evaluará que la contraseña como mínimo sea alfanumérica de lo
contrario la rechazará.

Historia de Usuario

Número: HU15 Usuario: Operador del sistema

Nombre historia:
1.1.15 Restablecimiento de contraseña

Prioridad en negocio: Media Riesgo en desarrollo: Medio

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Mildred Ortega

Descripción: Como operador se debe tener opción de recuperar contraseña en caso de ser
necesario.

Requerimientos no funcionales:
● El login debe tener un número limitado de intentos permitidos de acceso al
sistema.
● La interfaz de registro y login debe tener opción de recuperar contraseña mediante
un código enviado al correo que se haya registrado del operador.

Historia de Usuario

Número: HU16 Usuario: Administrador

Nombre historia:
1.1.16 Verificación de estadísticas.

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 3 Iteración asignada: 1

Programador responsable: Fernando López

Descripción: El administrador debe tener acceso a las gráficas de estadísticas que genera
el sistema.

Requerimientos no funcionales:
● El sistema genera estadísticas en gráficas que puedan ser consultadas desde una
interfaz alojada en la zona de informes.
● Las estadísticas se deben programar con inteligencia artificial.

Historia de Usuario

Número: HU17 Usuario: Programador

Nombre historia:
1.1.17 Permisos de usuario

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Milton Mora

Descripción: el programador se encargará de establecer privilegios y permisos al

administrador y al operador, los privilegios se establecerán por seguridad para no afectar
ciertos registros

Requerimientos no funcionales:
● Se establecerá por código derechos de escritura y de lectura según corresponda en
los campos de la base datos y formularios del sistema
● se establecerán interfaces distintas para cada usuario (operador, administrador)
● Los privilegios pueden ser editables por el programador.

Historia de Usuario

Número: HU18 Usuario: Operador del sistema

Nombre historia:
1.1.18 Cierre diario de encuestas realizadas

Prioridad en negocio: Alta Riesgo en desarrollo: Bajo

Puntos estimados: 3 Iteración asignada: 1

Programador responsable: Fernando Lopez

Descripción: El operador debe realizar un cierre diario del sistema de encuestas y

registro de acceso de usuarios.

Requerimientos no funcionales:
● El sistema debe tener un botón de terminar sesión o cerrar jornada.
● Se debe abrir una interfaz en la que se pida hora de cierre y observaciones no
superiores a cincuenta caracteres.

Historia de Usuario

Número: HU19 Usuario: Administrador

Nombre historia:
 1.1.19 Inicio y cierre de encuestas diarias realizadas por el operador

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 2 Iteración asignada: 1

Programador responsable: Mildred Ortega

Descripción: el administrador tendrá en su correo el informe acerca del total de personas

encuestadas con sus respectivos usuarios

Requerimientos no funcionales:
● El contador inicia cuando se registre la primera persona en el sistema y terminará
cuando el operador termine la jornada y cierre el sistema manualmente
● Al registrar el administrador debe especificar el correo al cual se le será enviado
el informe diario
● El correo irá con copia al agente de salud y seguridad en el trabajo.

Historia de Usuario

Número: HU20 Usuario: Administrador

Nombre historia:
1.1.20 Informe semanal generado por inteligencia artificial.

Prioridad en negocio: Alto Riesgo en desarrollo: Bajo

Puntos estimados: 4 Iteración asignada: 1

Programador responsable: Milton Mora - Arley Cuaran

Descripción: El usuario va a tener la opción de generar informes semanales de las

encuestas realizadas, informes que serán evaluados con inteligencia artificial.

Requerimientos no funcionales:
● Botón para generar informe de las encuestas realizadas.
● Este informe se puede descargar semanalmente.
● En el informe se debe especificar qué personas posiblemente están contagiadas
con COVID 19 y a quien pudieron infectar.
● El informe se mostrará en pantalla mediante un cuadro que muestra el sistema al
 dar clic en el botón informe.
● El informe se actualizará semanalmente.