Software">
Nothing Special   »   [go: up one dir, main page]

Requerimientos Athena

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 3

REQUERIMIENTOS FUNCIONALES

1. El sistema deberá permitir el ingreso usando como usuario el correo


institucional y contraseña mínimo de 8 caracteres entre letras y números, no
debe aceptar caracteres especiales.
2. El sistema deberá permitir la recuperación de la contraseña por medio de un
correo electrónico de verificación de identidad.
3. El sistema debe contar con 5 roles administrador, coordinador, docente interno,
docente externo, estudiante.
4. Cuando el rol sea administrador el sistema debe permitir la creación de nuevos
usuarios, para esta creación se deben ingresar los siguientes campos:
 Numero identificación.
 Nombre completo.
 Usuario (correo institucional).
 Contraseña.
 Confirmar contraseña.
 Rol.

5. El administrador del sistema podrá actualizar el estado de los usuarios, los


cuales pueden ser activo o inactivo, si el estado es inactivo no podrá realizar el
acceso.
6. El sistema debe permitir registrar solicitud de prácticas de los estudiantes
diligenciando los siguientes campos:
 Código estudiante
 Nombres
 Apellido Paterno
 Apellido materno
 Tipo documento
 Numero documento
 Fecha nacimiento
 País nacimiento
 Ciudad nacimiento
 Programa
 Semestre
 Eps
 Correo Institucional
 Correo personal
 Ciudad residencia
 Dirección
 Teléfono fijo
 Teléfono celular
 Opción propuesta para practica

7. El sistema debe permitir realizar el cargue y descargue de los documentos


necesarios para realizar la solicitud de practicas (Hoja de vida, copia eps, copia
documento de identidad.
8. Debe permitir listar los estudiantes registrados en el sistema.
9. El sistema debe permitir consultar los convenios activos de la universidad con
diferentes entidades a nivel nacional.
10. Debe permitir crear nuevos convenios, con los siguientes campos:
 Nombre entidad
 Tiempo convenio
 Tipo de entidad
 Nit entidad
11. Debe permitir actualizar el estado de los convenios, podrá ser activo o inactivo.
12. Para el rol Coordinador el sistema deberá permitir asociar un lugar de practica
para el estudiante.
13. Usuarios con rol coordinador podrán asociar el docente interno y externo para
el seguimiento de prácticas del estudiante.

14. Para el tipo de usuario estudiante el sistema deberá permitir el registro de


bitácora con los siguientes campos:

 Fecha
 Hora entrada
 Hora salida
 Descripción actividades
 Prioridad (Revisar, Retroalimentar).

15. El estudiante debe poder validar la nota dada por los docentes asignados.
16. Los usuarios con rol docente interno podrán visualizar las bitácoras de los
estudiantes asignados.
17. El sistema debe permitir que los docentes internos evalúen la bitácora según la
rubrica dada por la facultad de Psicología.
18. El sistema debe permitir que los docentes internos ingresen la bitácora de
asesoría y generen una nota según las competencias evaluativas cargadas en
el sistema.
19. El sistema debe permitir que los docentes externos evalúen la bitácora según
las actividades diligenciadas en la bitácora.
20. El sistema debe permitir cerrar sesión.

REQUERIMIENTOS NO FUNCIONALES
1. Toda funcionalidad del sistema y transacción debe responder al usuario en
menos de 5 segundos.
2. El sistema debe ser capaz de operar adecuadamente con hasta 600 usuarios
con sesiones concurrentes.
3. Los datos modificados en la base de datos deben ser actualizados para todos
los usuarios que acceden en menos de 2 segundos.
4. El sistema debe contar con manuales de usuario estructurados
adecuadamente.
5. El sistema debe proporcionar mensajes de error que sean informativos y
orientados a usuario final.
6. La aplicación web debe poseer un diseño “Responsive” a fin de garantizar la
adecuada visualización en múltiples computadores personales, dispositivos
tableta y teléfonos inteligentes.
7. El sistema debe poseer interfaces gráficas bien formadas.
8. El sistema debe tener una disponibilidad del 99,99% de las veces en que un
usuario intente accederlo.
9. El tiempo de inactividad no prevista del sistema, no debe superar las 10 horas
al trimestre.
10. Cuando se produzca un fallo del software o del hardware, debe resultar posible
devolver el sistema a un estado conocido (más reciente que la copia de
seguridad del día anterior) en menos de 02 horas de trabajo con el hardware
disponible.

También podría gustarte