update
This commit is contained in:
parent
3d9b2d9bb3
commit
37da6197f9
29
.gitignore
vendored
29
.gitignore
vendored
@ -5,11 +5,18 @@
|
||||
/tmp
|
||||
/out-tsc
|
||||
/bazel-out
|
||||
/build
|
||||
backend/dist
|
||||
backend/build
|
||||
|
||||
# Node
|
||||
/node_modules
|
||||
backend/node_modules
|
||||
npm-debug.log
|
||||
yarn-error.log
|
||||
pnpm-debug.log*
|
||||
yarn-debug.log*
|
||||
lerna-debug.log*
|
||||
|
||||
# IDEs and editors
|
||||
.idea/
|
||||
@ -33,9 +40,13 @@ yarn-error.log
|
||||
.sass-cache/
|
||||
/connect.lock
|
||||
/coverage
|
||||
backend/coverage
|
||||
backend/.nyc_output
|
||||
/libpeerconnection.log
|
||||
testem.log
|
||||
/typings
|
||||
.temp
|
||||
.tmp
|
||||
|
||||
# System files
|
||||
.DS_Store
|
||||
@ -44,3 +55,21 @@ Thumbs.db
|
||||
.vscode
|
||||
.scannerwork
|
||||
package-lock.json
|
||||
backend/package-lock.json
|
||||
**/.claude/settings.local.json
|
||||
|
||||
# Environment variables
|
||||
.env
|
||||
.env.development.local
|
||||
.env.test.local
|
||||
.env.production.local
|
||||
.env.local
|
||||
|
||||
# Runtime data
|
||||
pids
|
||||
*.pid
|
||||
*.seed
|
||||
*.pid.lock
|
||||
|
||||
# Diagnostic reports
|
||||
report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
|
||||
276
HU - definiciones(1).txt
Normal file
276
HU - definiciones(1).txt
Normal file
@ -0,0 +1,276 @@
|
||||
*********************************************************************
|
||||
EP01 – Ingresar al Sistema
|
||||
El objetivo es comprobar la autenticidad del usuario. Los usuarios serán los analistas técnicos de la unidad de concesiones, la jefatura de dicha unidad y un usuario de la Unidad de Información.
|
||||
---------------------------------------------------------------------
|
||||
EP01.HU01 – Implementar servicio validación de usuario
|
||||
COMO Desarrollador
|
||||
QUIERO crear un servicio que valide usuario
|
||||
PARA Permitir acceder al sistema
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- Debe recibir como parametros USUARIO (correo electronico) y CONTRASEÑA.
|
||||
- Debe validar formato correo electronico.
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/login).
|
||||
- El servicio debe conectarse a una fuente de datos (LDAP).
|
||||
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||
- La respuesta debe entregar el ROL del usuario validado dentro del sistema.
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
---------------------------------------------------------------------
|
||||
EP01.HU02 – Autenticar usuario
|
||||
COMO Usuario
|
||||
QUIERO Ingresar mi correo electronico institucional y mi contraseña en un formulario de acceso
|
||||
PARA Que el sistema valide mi identidad y me permita acceder a mi cuenta personal de manera segura.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
1. Debe existir un formulario con campos obligatorios de usuario y contraseña.
|
||||
2. El sistema debe validar que ninguno de los campos esté vacío.
|
||||
3. Si el usuario o la contraseña son incorrectos, se mostrará un mensaje de error (por definir)
|
||||
4. Si las credenciales son válidas, el usuario será redirigido al panel principal del sistema.
|
||||
5. Si las credenciales son válidas, el sistema deberá desplegar las opciones de MENÚ habiltadas para el ROL del usuario logueado.
|
||||
*********************************************************************
|
||||
EP02 – Pantalla de Usuario Administrador Unidad de Concesiones
|
||||
El objetivo es mostrar de forma consolidada las cargas temporales del PR047, para que un usuario administrador asigne cronogramas a los analistas y se notifique. Además, que permita realizar solicitud de carga a la Unidad de Información y notifique a la empresa.
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU01. Implementar servicio asignación de cronograma
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que asigne cronogramas
|
||||
PARA Perimtir asignar cronogramas a un analista.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- Debe recibir como parametros el identificador del cronograma y del analista.
|
||||
- Debe generar los registros que sean necesarios en la base de datos.
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/cronogramas/asignar).
|
||||
- El servicio debe conectarse a la fuente de datos correspondiente (base de datos, API externa, etc.).
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU02. Implementar servicio de solicitudes de carga
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que solicite la carga de ¿cronogramas?
|
||||
PARA Perimtir solicitar la carga de nuevos ¿cronogramas? a la unidad de información.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- Debe recibir como parametros el identificador del ¿cronograma? que se desea cargar.
|
||||
- Debe generar los registros que sean necesarios en la base de datos.
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, POST /api/cronogramas/solicitudcarga).
|
||||
- El servicio debe conectarse a la fuente de datos correspondiente (base de datos, API externa, etc.).
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU03. Cargar cronogramas
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU04. Implementar filtros
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU05. Asignar cronograma
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU06. Implementar semaforo
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU07. Solicitar carga de cronogramas
|
||||
---------------------------------------------------------------------
|
||||
EP02.HU08. Notificar a Unidad de Información
|
||||
*********************************************************************
|
||||
EP03 – Vista de Carga de Cronograma Temporal por Actualización de PD
|
||||
El objetivo es desplegar la carga temporal de los cronogramas de actualización de PD o nuevas concesiones para cada analista, aprobar o rechazar la carga, añadir comentarios generales y/o por cada glosa, notificar a la empresa cuando se rechace la carga y exportar los datos a un archivo pdf.
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU01. Implementar servicio de gestión de glosas (aprobación/rechazo)
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU02. Implementar servicio para exportar datos a Excel
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU03. Cargar cronogramas
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU04. Implementar filtros
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU05. Aprobar carga
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU06. Rechazar carga
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU07. Ingresar observación
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU08. Exportar a Excel
|
||||
---------------------------------------------------------------------
|
||||
EP03.HU09. Notificar a empresa
|
||||
*********************************************************************
|
||||
EP04 – Vista de Carga de Cronograma Temporal por Ajuste de PD
|
||||
EP04.01. Implementar servicio para obtener listado de ajustes y amplicaciones
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU02. Cargar cronogramas
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU03. Cargar ajustes PD y ampliación TO
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU04. Implementar filtros
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU05. Ingresar observación
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU06. Aprobar carga
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU07. Rechazar carga
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU08. Exportar a Excel
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU09. Exportar a PDF
|
||||
---------------------------------------------------------------------
|
||||
EP04.HU10. Notificar a empresa
|
||||
*********************************************************************
|
||||
EP05 – Vista de Resumen
|
||||
EP05.HU01. Implementar switch vistas
|
||||
---------------------------------------------------------------------
|
||||
EP05.HU02. Cargar cronogramas aprobados
|
||||
---------------------------------------------------------------------
|
||||
EP05.HU03. Cargar cronogramas rechazados
|
||||
---------------------------------------------------------------------
|
||||
EP05.HU04. Implementar filtros
|
||||
---------------------------------------------------------------------
|
||||
EP05.HU05. Generar PDF para firma digital (x2)
|
||||
---------------------------------------------------------------------
|
||||
EP05.HU06. Notificar a empresa
|
||||
*********************************************************************
|
||||
EP06 – Vista para Usuario de Unidad de Información
|
||||
EP06.HU01. Cargar cronogramas pendientes de carga
|
||||
---------------------------------------------------------------------
|
||||
EP06.HU02. Cargar cronogramas aprobados
|
||||
---------------------------------------------------------------------
|
||||
EP06.HU03. Cargar cronogramas rechazados
|
||||
*********************************************************************
|
||||
EP07. Servicios transversales
|
||||
EP07.HU01. Implementar servicio listado de cronogramas por estado
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que devuelva una lista de cronogramas por estado
|
||||
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- El servicio debe retornar todos los registros
|
||||
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/cronogramas/listado).
|
||||
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||
- Debe permitir filtros opcionales mediante parámetros (por ejemplo, 'estado').
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||
---------------------------------------------------------------------
|
||||
EP07.HU02. Implementar servicio listado empresas
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que devuelva una lista de empresas
|
||||
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- El servicio debe retornar todos los registros
|
||||
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /empresas).
|
||||
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||
- Debe permitir filtros opcionales mediante parámetros (por ejemplo, 'estado').
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||
---------------------------------------------------------------------
|
||||
EP07.HU03. Implementar servicio listado ajustes PD
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que devuelva una lista de ajustes de PD
|
||||
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- El servicio debe retornar todos los registros
|
||||
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /ajustespd).
|
||||
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||
---------------------------------------------------------------------
|
||||
EP07.HU04. Implementar servicio listado ampliación TO
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que devuelva una lista de ampliación de TO
|
||||
PARA Ser cargados/consultados por la funcionalidad que lo requiera.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- El servicio debe retornar todos los registros
|
||||
- El servicio debe retornar el registro completo (todos los campos y descripciones si corresponde)
|
||||
- Se debe crear un endpoint accesible vía HTTP (por ejemplo, GET /api/ cronogramas /ampliacionto).
|
||||
- El servicio debe conectarse a la fuente de datos correspondiente.
|
||||
- La respuesta debe estar en formato (POR DEFINIR) con una estructura clara.
|
||||
- Debe implementar paginación para manejar grandes volúmenes de datos.
|
||||
- El servicio debe retornar códigos HTTP de respuestas adecuados (200, 400, 500, etc.).
|
||||
- Los errores además, deben presentar mensajes descriptivos.
|
||||
- Considerar seguridad (token, roles, etc.) si aplica.
|
||||
- Aplicar principios de clean code y separación de responsabilidades.
|
||||
- Evaluar rendimiento si el volumen de datos es alto (índices, consultas optimizadas, etc.).
|
||||
---------------------------------------------------------------------
|
||||
EP07.HU05. Implementar servicio notificaciones
|
||||
COMO Desarrollador
|
||||
QUIERO Crear un servicio que envie correos electronicos
|
||||
PARA Notificar a quien corresponda respecto de alertas o confirmaciones.
|
||||
|
||||
CRITERIOS DE ACEPTACIÓN
|
||||
- El servicio debe aceptar al menos los siguientes parámetros:
|
||||
- Destinatario(s)
|
||||
- Asunto
|
||||
- Cuerpo del mensaje (HTML o texto plano)
|
||||
- Remitente (opcional, configurable)
|
||||
- Debe realizar validaciones básicas (formato de email, campos requeridos).
|
||||
- Debe manejar errores como correos inválidos, errores de red, o problemas con el servidor SMTP.
|
||||
- El servicio debe retornar respuestas con códigos HTTP claros (200, 400, 500, etc.).
|
||||
- El envío debe ser asincrónico si se anticipa alto volumen (opcional).
|
||||
- Debe registrar los envíos en logs o base de datos (para trazabilidad, opcional).
|
||||
|
||||
---------------------------------------------------------------------
|
||||
*********************************************************************
|
||||
|
||||
generar epica de servicios transversales
|
||||
por cada HU generar su propio exportar a excel
|
||||
generar servicio por cada pdf a generar
|
||||
no incluir botonera de switch de vistas
|
||||
generar matriz de autorizaciones (perfil, pantalla)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
### ✅ **Criterios de Aceptación:**
|
||||
|
||||
- Se debe crear un endpoint (por ejemplo, `POST /api/email/send`) que reciba los datos del correo.
|
||||
|
||||
---
|
||||
|
||||
### 🔁 **Flujo Básico de Desarrollo:**
|
||||
|
||||
1. Diseñar el endpoint REST (por ejemplo, en .NET, Node.js, Spring Boot).
|
||||
2. Configurar un proveedor de correo (SMTP, SendGrid, Mailgun, etc.).
|
||||
3. Implementar la lógica de envío y validación.
|
||||
4. Manejar errores y respuestas.
|
||||
5. Agregar logs y/o almacenamiento de eventos.
|
||||
6. Probar con diferentes escenarios y correos de prueba.
|
||||
|
||||
---
|
||||
|
||||
### 🛠️ **Notas Técnicas:**
|
||||
|
||||
- Se recomienda usar una biblioteca estándar de envío de correo según el lenguaje (ej. Nodemailer en Node.js, MailKit en .NET, JavaMail en Java).
|
||||
- Usar plantillas de email si se requiere formato HTML.
|
||||
- Considerar seguridad: autenticación con el proveedor, evitar inyecciones, validar origen de llamadas.
|
||||
- Considerar colas de mensajes si se requiere alta disponibilidad (ej. RabbitMQ, Azure Service Bus).
|
||||
|
||||
---
|
||||
|
||||
¿Te gustaría que prepare una versión adaptada para .NET Core, Node.js o algún otro stack específico?
|
||||
BIN
Requerimientos_vista PR047.docx
Normal file
BIN
Requerimientos_vista PR047.docx
Normal file
Binary file not shown.
Loading…
x
Reference in New Issue
Block a user