141RF50RNF85RN18CU27HU60DEC19PA

Casos de uso

CU-001 a CU-004 · Proyecto e ingesta

docs/01-requerimientos/casos-de-uso/cu-proyecto-e-ingesta.md · 170 líneas

Casos de uso — Proyecto e ingesta

Estado: Borrador · Última actualización: 2026-08-20 · Índice: README

CU-001 — Importar un proyecto desde Argos Operaciones

Actor principal: Product Manager Objetivo: crear el espacio de QA de un proyecto que ya existe en argos.flagare. Cubre: RF-009, RF-010, RF-011, RF-012, RF-017 · Reglas: RN-014, RN-015

Precondiciones

  • El usuario está autenticado con un JWT válido de Flagare y tiene **rol de plataforma

Product Manager o Admin** (RN-085): es lo que lo autoriza a importar antes de tener rol alguno en el proyecto, que todavía no existe (DEC-060, resuelve PA-019).

  • El proyecto existe en Argos Operaciones y el usuario tiene acceso a él allí.
  • Argos Operaciones está disponible.

Flujo principal

  1. El usuario abre la creación de proyecto y busca por nombre o identificador de Argos Operaciones.
  2. El sistema consulta Argos Operaciones y muestra los proyectos coincidentes a los que el usuario

tiene acceso.

  1. El usuario selecciona uno.
  2. El sistema muestra los datos que se importarán: identificador, nombre, cliente, estado

y responsable.

  1. El usuario confirma.
  2. El sistema crea el proyecto local, lo vincula de forma permanente al identificador de

Argos Operaciones, y asigna al usuario el rol Product Manager.

  1. El sistema registra la creación en auditoría y deja visible el enlace al proyecto en

Argos Operaciones.

Flujos alternativos

  • A1 — La búsqueda no arroja resultados. El sistema informa que no encontró el

proyecto y recuerda que debe existir previamente en Argos Operaciones. No ofrece crearlo localmente.

Flujos de error

  • E1 — El proyecto ya fue importado. El sistema lo indica y ofrece navegar al proyecto

existente en Argos QA. No crea un duplicado (RN-015).

  • E2 — Argos Operaciones no responde. El sistema informa que la importación no está disponible en

este momento e invita a reintentar. No permite una creación manual como alternativa (RN-014).

Postcondiciones

  • Existe un proyecto en Argos QA vinculado de forma permanente a uno de Argos Operaciones.
  • El importador tiene rol Product Manager en él, cumpliendo RN-005.

CU-002 — Gestionar miembros y roles del proyecto

Actor principal: Product Manager Objetivo: definir quién participa en el proyecto y con qué responsabilidades. Cubre: RF-004, RF-005, RF-006, RF-007, RF-008, RF-018 · Reglas: RN-001 a RN-007

Precondiciones

  • El usuario tiene rol Product Manager en el proyecto.

Flujo principal

  1. El usuario abre la administración de miembros del proyecto.
  2. El sistema muestra los miembros actuales con sus roles.
  3. El usuario agrega un miembro y le asigna uno o más roles entre Product Manager, QA,

Developer y Client.

  1. El sistema valida las restricciones de asignación.
  2. El sistema guarda la asignación, la registra en auditoría y notifica al usuario

agregado.

Flujos alternativos

  • A1 — Asignar varios roles. El usuario asigna Developer y QA a la misma persona.

El sistema lo acepta: los permisos resultantes son la unión de ambos (RN-002).

  • A2 — Revocar un rol. El usuario retira un rol. El sistema lo aplica de inmediato;

las sesiones activas pierden el permiso en la siguiente petición.

Flujos de error

  • E1 — Client con otro rol. El sistema rechaza asignar Client a alguien que ya tiene

otro rol en el proyecto, y a la inversa, explicando la exclusividad (RN-006).

  • E2 — Último Product Manager. El sistema impide revocar el rol Product Manager si

es el único del proyecto (RN-005).

Postcondiciones

  • Los permisos efectivos de cada miembro quedan actualizados.
  • Cada cambio queda en el registro de auditoría con su autor.

CU-003 — Cargar un requerimiento

Actor principal: QA Objetivo: incorporar al proyecto el material funcional que originará los casos de uso. Cubre: RF-019, RF-020, RF-021, RF-022, RF-023, RF-024 · Reglas: RN-018, RN-019

Precondiciones

  • El usuario tiene rol Product Manager, QA o Developer en el proyecto.
  • El proyecto está activo.

Flujo principal

  1. El usuario crea un requerimiento indicando título y descripción breve.
  2. El usuario aporta el contenido, pegando texto directamente o cargando un archivo .md

o .txt.

  1. El sistema valida el formato y el tamaño.
  2. El usuario vincula opcionalmente uno o más tickets de Argos Operaciones.
  3. El sistema guarda el contenido como documento de origen inmutable, con su versión,

autor y timestamp.

  1. El sistema emite el evento requirement.ingested.

Flujos alternativos

  • A1 — Corregir el contenido cargado. El usuario carga una versión nueva del

documento. El sistema la registra como versión siguiente y conserva la anterior, que sigue siendo el origen de los artefactos que ya derivaron de ella (RN-019).

Flujos de error

  • E1 — Formato no soportado. Ante un PDF, DOCX u otro binario, el sistema rechaza la

carga indicando que solo acepta texto plano y Markdown. No intenta una extracción parcial (RN-018).

  • E2 — Excede el tamaño máximo. El sistema rechaza el archivo indicando el límite

vigente (RNF-005).

  • E3 — Argos Operaciones no responde al vincular tickets. El requerimiento se guarda igual; la

vinculación queda pendiente y puede completarse después (RN-017).

Postcondiciones

  • Existe un requerimiento con al menos un documento de origen versionado.
  • El requerimiento queda disponible para el análisis con IA.

CU-004 — Analizar un requerimiento con IA

Actor principal: QA Objetivo: extraer del texto la estructura funcional que servirá de base a los casos de uso, y sacar a la luz lo que está ambiguo. Cubre: RF-025, RF-026, RF-027, RF-028, RF-124, RF-126, RF-127, RF-130 · Reglas: RN-064, RN-066, RN-068

Precondiciones

  • Existe un requerimiento con documento de origen.
  • El proveedor de IA está disponible.

Flujo principal

  1. El usuario abre el requerimiento y solicita explícitamente el análisis.
  2. El sistema muestra una estimación del costo si el documento es extenso, y pide

confirmación.

  1. El sistema encola el job y devuelve el control al usuario. El análisis es asíncrono.
  2. Al completarse, el sistema presenta la propuesta: actores, objetivos, restricciones,

reglas de negocio, supuestos, dependencias, ambigüedades y riesgos funcionales.

  1. El usuario revisa cada elemento y lo acepta, edita o descarta.
  2. El sistema registra las ambigüedades aceptadas como preguntas abiertas del

requerimiento, con estado propio.

  1. El sistema registra el job con modelo, tokens de entrada y salida, duración y costo

estimado.

Flujos alternativos

  • A1 — Reanalizar. El usuario solicita un nuevo análisis tras cargar una versión nueva

del documento. El análisis anterior se conserva asociado a su versión.

  • A2 — Resolver una pregunta abierta. El usuario responde una ambigüedad detectada y

la marca como resuelta, dejando la respuesta registrada.

Flujos de error

  • E1 — El proveedor de IA no responde. El sistema reintenta un número acotado de veces

y, si falla, informa el error sin bloquear el requerimiento. El usuario puede continuar creando casos de uso a mano (RN-065, CU-006).

  • E2 — Respuesta que no valida. Si el modelo devuelve una estructura inválida, el

sistema descarta la respuesta completa e informa. No persiste resultados parciales (RN-068).

  • E3 — El usuario cancela ante el costo. El job no se ejecuta y no se registra

consumo.

Postcondiciones

  • El requerimiento tiene su contexto funcional estructurado y revisado por una persona.
  • Las ambigüedades quedan registradas como preguntas abiertas, no perdidas en el texto.
  • El consumo de IA quedó medido y atribuido al proyecto.