Alcancé - sjperalta/nexthome GitHub Wiki
NexHome
Es una innovadora plataforma diseñada para simplificar y optimizar la gestión de solicitudes de financiamiento para terrenos. Con una interfaz intuitiva y herramientas avanzadas, NexHome facilita a los usuarios el proceso de aplicar, seguir y gestionar sus solicitudes de financiamiento, asegurando una experiencia eficiente y transparente.
Requisitos Funcionales
Etapa 1:
1. Registro de Usuarios
Descripción: El sistema debe permitir el registro de nuevos usuarios.
- RF1.1: El sistema debe permitir que un usuario con el rol de vendedor, poder registre usuarios proporcionando nombre completo, correo electrónico.
- RF1.2: El sistema debe validar que el correo electrónico no esté ya en uso.
- RF1.3: El sistema debe enviar un correo de confirmación al correo del usuario despues de ser registrado por el sistema.
- RF1.4: El sistema debe permitir a los usuarios recuperar su contraseña mediante el correo electrónico.
Diagrama
2. Administración de solicitudes de Reserva
Descripción: El sistema debe gestionar las solicitudes de reserva de terrenos de los usuarios.
- RF2.1: El sistema debe permitir a los administrador o vendedores crear una solicitud de reserva de lotes, la informacion que debera de porporcionar es el id del lote deseado y el plazo de pago.
- RF2.2: El sistema debe permitir a los usuarios cargar documentos necesarios (como identificación, RTN) para la solicitud de la reserva.
- RF2.3: El sistema debe mostrar el estado de la solicitud de reserva (pendiente, aprobado, rechazado).
- RF2.4: El sistema debe permitir a los administradores listar, revisar y aprobar o rechazar solicitudes de reserva.
Diagrama
3. Gestión de Proyectos
Descripción: El sistema debe gestionar la información de los proyectos disponibles.
- RF3.1: El sistema debe permitir a los administradores agregar nuevos proyectos proporcionando nombre, direccion, cantidad de lotes, precio por vara cuadrada, porcentaje de interes, tamaño de lote, y el id que es un correlativo autogenerado.
- RF3.2: El sistema debe permitir a los administradores editar, eliminar la información de los proyectos existentes.
- RF3.3: El sistema debe permitir a los usuarios buscar proyectos por nombre.
Diagrama
4. Gestión de Pagos de Financiamientos
Descripción: El sistema debe gestionar los pagos realizados por los usuarios.
- RF4.1: El sistema debe calcular y notificar que un pago esta en mora, si dicho pago se encuentra vencido.
- RF4.2: El sistema debe permitir a los usuarios subir comprobantes de pagos de sus cuotas.
- RF4.3: El sistema debe avisar al administrador sobre cada archivo de pago subido por los usuarios, para que que el administrador pueda aprobar dicho pago y asi el sistema pueda actualizar el saldo pendiente del financiamiento del terreno.
- RF4.4: El sistema debe enviar notificaciones al correo a los usuarios cuando el administrador apruebe un pago, tambien cuando se acerque la fecha de vencimiento de una cuota.
- RF4.5: El sistema debe permitir a los usuarios ver un dashboard con desgloce del préstamo, incluyendo la reserva, prima, las cuotas.
Diagrama
5. Reportes y Estados de Cuenta
Descripción: El sistema debe generar reportes y estados de cuenta para los usuarios y administradores.
- RF5.1: El sistema debe permitir a los usuarios generar y descargar estados de cuenta de sus financiamiento en formato PDF.
- RF5.2: El sistema debe permitir a los administradores generar reportes de financiamientos activos, financiamientos pagados y financiamientos en mora.
- RF5.3: El sistema debe permitir a los usuarios ver un historial detallado de todos los pagos realizados.
- RF5.4: El sistema debe permitir a los administradores ver un balance por proyecto y un balance general.
Diagrama
6. Seguridad y Autenticación
Descripción: El sistema debe garantizar la seguridad de los datos y la autenticación de los usuarios.
- RF6.1: El sistema debe requerir autenticación para acceder a las funcionalidades.
- RF6.2: El sistema debe cifrar las contraseñas de los usuarios.
- RF6.3: El sistema debe implementar controles de acceso basados en roles (usuarios, administradores).
Etapa 2:
9. Gestion de Planos
Descripción: El sistema administrar los planos de cada proyecto.
- RF9.1: El sistema debe proporcionar la funcionalidad de subir planos en formato pdf.
- RF9.2: El administrador puede visualizar el plano y crear, editar y eliminar zonas identificadas como lotes.
- RF9.3: El administrador puede asociar cada zona al correlativo de los lotes previamente creados.
10. Gestion de Planos
Descripción: El sistema administrar los planos de cada proyecto.
- RF10.1: El sistema listara todos los proyectos y proporcionara una vista para visualizar el plano.
- RF10.2: El usuario puede seleccionar la zona, identificada como lote, podra ver el detalle de la informacion del lote.
- RF10.3: El usuario tendra una opcion para reservar el lote, si este esta en un estado disponible.
- RF10.3: Si el usuario no posee una cuenta, podra proporcionar un correo electronico y se generara una reserva que dura 72 horas.
Requisitos No funcionales.
1. Rendimiento
- Descripción: El sistema debe responder de manera eficiente a las solicitudes de los usuarios.
- RNF1.1: El sistema debe ser capaz de manejar al menos 5000 usuarios concurrentes sin degradar el rendimiento.
- RNF1.2: El tiempo de respuesta para cualquier operación no debe exceder los 10 segundos bajo carga normal.
2. Escalabilidad
Descripción: El sistema debe poder escalar para manejar un aumento en la carga de trabajo.
- RNF2.1: El sistema debe poder escalar verticalmente para manejar aumentos en el tráfico de usuarios.
- RNF2.2: El sistema debera correr en una nube privada.
3. Seguridad
Descripción: El sistema debe garantizar la seguridad de los datos de los usuarios.
- RNF3.1: Todas las comunicaciones entre el cliente y el servidor deben ser cifradas utilizando HTTPS.
- RNF3.2: Los datos sensibles (contraseña) deben estar cifrados en la base de datos.
4. Disponibilidad
Descripción: El sistema debe estar disponible para los usuarios en todo momento.
- RNF4.1: El sistema debe contar con un plan de recuperación ante desastres que permita restaurar el servicio en menos de 2 hora en caso de fallo.
5. Usabilidad
Descripción: El sistema debe ser fácil de usar y accesible para todos los usuarios.
- RNF5.1: La interfaz de usuario debe ser intuitiva y fácil de navegar, siguiendo las mejores prácticas de diseño de experiencia de usuario (UX).
- RNF5.2: El sistema debe proporcionar una funcionalidad de ayuda en línea y documentación de usuario completa.
6. Mantenibilidad
Descripción: El sistema debe ser fácil de mantener y actualizar.
- RNF6.1: El código fuente del sistema debe seguir las mejores prácticas de codificación y estar bien documentado.
- RNF6.2: El sistema debe contar con pruebas automatizadas que cubran al menos el 70% del código.
7. Compatibilidad
Descripción: El sistema debe ser compatible con diversos dispositivos y navegadores.
- RNF7.1: El sistema debe funcionar correctamente en los navegadores web más comunes (Chrome, Firefox, Safari, Edge).
- RNF7.2: El sistema debe ser responsive y adaptarse a diferentes tamaños de pantalla, incluyendo dispositivos móviles y tablets.