Requerimientos funcionales (RF)
Requerimientos no funcionales (RNF)
Diagrama de actividades · atención de objetos perdidos
Flujo operativo propuesto para Makro Chincha. La custodia es opcional; la verificación aprobada es obligatoria antes de entregar.
- Atención al Cliente
Recibir el objeto
Identificar el hallazgo y registrar fecha, hora, lugar, categoría, nombre y descripción. La foto es opcional.
Inicio del proceso · RF-10–11 - Sistema
Validar y registrar
Validar campos y catálogos activos; guardar el objeto como ENCONTRADO y asociar usuario, fecha y movimiento inicial.
Si falla una validación, no crear un registro parcial · RNF-08 - Sistema
Generar código único
Asignar el correlativo OBJ-AAAA-NNNNNN de manera atómica y conservarlo durante toda la vida del objeto.
Registro y trazabilidad · RF-12, RF-18 - Atención al Cliente
Guardar en custodia
Cuando corresponda, mover el objeto de ENCONTRADO a EN_CUSTODIA y dejar constancia del responsable.
La custodia es opcional · RF-17 - Atención al Cliente
Registrar reclamación
Vincular una reclamación activa con el objeto disponible y guardar los datos mínimos del reclamante.
Bloquear duplicados activos y objetos ENTREGADOS · RF-19–21 - Atención al Cliente
Verificar identidad
Registrar documento presentado, resultado, observaciones, responsable y fecha/hora.
❌ Rechazada · Guardar el motivo; bloquear la entrega y mantener la trazabilidad.✅ Aprobada · Autorizar el paso a VERIFICADO y continuar con la devolución.La verificación aprobada es requisito para entregar · RF-22–24 - Atención al Cliente
Autorizar y registrar entrega
Confirmar reclamación aprobada, identidad verificada y permiso del usuario. Registrar receptor, responsable, observaciones y fecha/hora.
Una sola operación: entrega + estado ENTREGADO + historial; revertir todo si falla · RF-25, RF-27 - Sistema
Emitir constancia
Generar un número único después de confirmar la entrega; permitir volver a consultar e imprimir la misma constancia.
El objeto sale de pendientes y disponibles · RF-26, RF-30–31 - Administrador
Actualizar reportes y auditoría
Refrescar indicadores y reportes según permisos; conservar bitácora del sistema e historial inalterable del objeto.
Auditoría de sistema e historial del objeto son trazas distintas · RF-28–32
Equipo: tareas por rol, mejoras y prioridades
- Bloqueos: lo que impide trabajar a otro compañero va primero.
- Valor para Makro: flujo núcleo registrar → reclamar → verificar → entregar (RF-10, RF-19 a RF-27).
- Seguridad e integridad (RF-01 a RF-06, RNF-03, RNF-04 y RNF-11) antes que lo estético.
- Lo que vence esta semana (Gantt) antes que lo adelantado.
- Reportes, administración y pulido visual al final de cada sprint.
Diagrama de Gantt · Semanas 1 a 15
Cronograma depurado de 25 actividades: 24 actividades de trabajo entre las semanas 1 y 14, agrupadas en Sprint 0 y cinco sprints de producto, y una fila en la semana 15 para la ENTREGA FINAL a cargo de María, Product Owner. Cada actividad indica su semana.
Ceremonias, reuniones y evidencias
🗒️ Seguimiento de observaciones del equipo
El Product Owner asigna observaciones; el Developer responsable actualiza su respuesta y estado; el Scrum Master consulta el seguimiento. Los cambios se sincronizan en tiempo real. Solo el Product Owner puede eliminar observaciones; la eliminación masiva incluye únicamente las resueltas.
🎓 Evaluación del docente · Scrum Master
Registro de revisión final del curso. Solo la cuenta con rol Scrum Master puede ver o editar este apartado.
| Aspecto de evaluación | Registro |
|---|---|