Universidad Peruana de Ciencias Aplicadas - Ingeniería de Software - 8 Ciclo

1ASI0732 - Arquitectura de Software Emergentes

Sección - 11821

Docente: Christian Luis De Los Rios Fernández

Informe de Trabajo Final

Startup: Kntro-Soft

Producto: Reqs-AI

Integrantes del equipo:

Estudiante	Código
Gutiérrez Soto, Jhosepmyr Orlando	202317638
Hernández Tuiro, Eric Ernesto	20221C857
Ramirez Mestanza, Salim Ignacio	20201E843
Varela Bustinza, Marcelo Alessandro	202319668
Sulca Gonzales, Paul Fernando	20221C486

Abril 2026

Registro de Versiones del Informe

Versión	Fecha	Autor	Descripción de modificación
1.0	14/04/2026	Eric	Creación de la estructura base del informe, portada, logos y descripción inicial del Startup.
1.1	17/04/2026	Eric	Adición del Background, problemáticas, proceso de Lean UX, Target Segments y perfiles del equipo (Team Profiles).
1.2	22/04/2026	Marcelo, Salim Ramirez	Inclusión del análisis de competidores, diseño preliminar de preguntas para entrevistas y configuración de exclusiones del repositorio (.gitignore).
1.3	23/04/2026	Gutierrez Soto Jhosepmyr, Eric	Estructuración de Epics, User Stories (formato BDD y criterios de aceptación), Product Backlog priorizado y definición de atributos de calidad (Quality Attribute Scenarios).
1.4	24/04/2026	Marcelo, Gutierrez Soto Jhosepmyr	Redacción de estrategias y tácticas, actualización de la sección de competidores, e iteración técnica de historias de usuario (criterios INVEST).
1.5	25/04/2026	Marcelo	Actualización de la información general del proyecto e informe.
1.6	26/04/2026	Paul, Gutierrez Soto Jhosepmyr	Incorporación de la sección de User Personas (Empathy Mapping, User Journey, User Task Matrix) y modelado de escenarios As-Is / To-Be.
1.7	26/04/2026	Eric	Desarrollo de la sección de Domain-Driven Design (Eventstorming, Context Discovery, Context Mapping, Bounded Context Canvases).
1.8	26/04/2026	Marcelo, Salim Ramirez, Paul	Incorporación de análisis y hallazgos de las entrevistas para roles técnicos y funcionales. Adición de sección de Impact Mapping y Student Outcomes.
2.0	26/04/2026	Eric, Gutierrez Soto Jhosepmyr	Inclusión de los diagramas de Arquitectura de Software C4 (System Landscape, System Context, Container y Deployment). Actualización final del Backlog en Jira y sección de conclusiones.
2.1	09/05/2026	Gutierrez Soto Jhosepmyr	Refinamientos por feedback TP1: ampliación uniforme de los 5 patrones de Context Mapping (ACL hacia Jira, ACL hacia LLM/STT, Customer/Supplier Discovery↔Workspace, Conformist Workspace↔Billing, OHS+PL Discovery↔Gateway) con contratos detallados, escenarios de evolución y tradeoffs explícitos; reescritura del Container Diagram con declaración explícita Monolito Modular vs. Microservicios, mapeo Bounded Context → Módulo Maven y reglas de dependencia automatizadas con ArchUnit, en tono orientado a presentación al cliente.
2.2	13/05/2026	Marcelo	Elaboración de wireframes, wireflows y mock-ups iniciales para la aplicación web.
2.3	14/05/2026	Gutierrez Soto Jhosepmyr, Marcelo, Eric	Expansión del inventario de funcionalidades, refinamiento de User Stories y Backlog, inclusión de directrices de estilo de diseño (UI/UX) y corrección de formato.
2.4	15/05/2026	Gutierrez Soto Jhosepmyr, Eric, Paul	Desarrollo detallado del diseño de software a nivel táctico (Capítulo V): estructuración de capas de dominio, infraestructura e interfaz. Actualización de diagramas C4 y modelado detallado para los Bounded Contexts (IAM, Billing, Workspace, Discovery, Gateway).
2.5	16/05/2026	Salim Ramirez, Eric, Gutierrez Soto Jhosepmyr	Diseño UX/UI completo para la aplicación móvil y Landing Page (wireframes, wireflows y prototipos interactivos de alta fidelidad). Refactorización de justificaciones de restricciones e impacto arquitectónico, soporte al cliente en diagrama C4 y actualización final de Student Outcomes para TP.

Project Report Collaboration Insights

En esta sección se documenta la colaboración del equipo en la elaboración del informe, mostrando evidencias gráficas de la actividad en GitHub y su coherencia con el registro de versiones.

• URL del repositorio del Project Report en la organización de GitHub del equipo:
• https://github.com/Kntro-Soft/ReqsAI-Report

TB1:

TP:

Contenido

• Registro de Versiones del Informe
• Project Report Collaboration Insights
• Contenido
• Student Outcome
• Capítulo I: Introducción
  • 1.1. Startup Profile
    • 1.1.1. Descripción de la Startup
    • 1.1.2. Perfiles de integrantes del equipo
  • 1.2. Solution Profile
    • 1.2.1. Antecedentes y problemática
    • 1.2.2. Lean UX Process
      • 1.2.2.1. Lean UX Problem Statements
      • 1.2.2.2. Lean UX Assumptions
      • 1.2.2.3. Lean UX Hypothesis Statements
      • 1.2.2.4. Lean UX Canvas
  • 1.3. Segmentos objetivos
• Capítulo II: Requirements Elicitation & Analysis
  • 2.1. Competidores
    • 2.1.1. Análisis competitivo
    • 2.1.2. Estrategias y tácticas frente a competidores
  • 2.2. Entrevistas
    • 2.2.1. Diseño de entrevistas
    • 2.2.2. Registro de entrevistas
    • 2.2.3. Análisis de entrevistas
  • 2.3. Need finding
    • 2.3.1. User personas
    • 2.3.2. User Task Matrix
    • 2.3.3. User Journey Mapping
    • 2.3.4. Empathy Mapping
    • 2.3.5. As-is Scenario Mapping
  • 2.4. Ubiquitous Language
• Capítulo III: Requirements Specification
  • 3.1. To-Be Scenario Mapping
  • 3.2. User Stories
  • 3.3. Product Backlog
  • 3.4. Impact Mapping
• Capítulo IV: Strategic-Level Product Design
  • 4.1. Strategic-Level Attribute-Driven Design
    • 4.1.1. Design Purpose
    • 4.1.2. Attribute-Driven Design Inputs
      • 4.1.2.1. Primary Functionality (Primary User Stories)
      • 4.1.2.2. Quality attribute Scenarios
      • 4.1.2.3. Constraints
    • 4.1.3. Architectural Drivers Backlog
    • 4.1.4. Architectural Design Decisions
    • 4.1.5. Quality Attribute Scenario Refinements
  • 4.2. Strategic-Level Domain-Driven Design
    • 4.2.1. EventStorming
    • 4.2.2. Candidate Context Discovery
    • 4.2.3. Domain Message Flows Modeling
    • 4.2.4. Bounded Context Canvases
    • 4.2.5. Context Mapping
  • 4.3. Software Architecture
    • 4.3.1. Software Architecture System Landscape Diagram
    • 4.3.2. Software Architecture Context Level Diagrams
    • 4.3.3. Software Architecture Container Level Diagrams
    • 4.3.4. Software Architecture Deployment Diagrams
• Capítulo V: Tactical-Level Software Design
  • 5.1. Bounded Context: IAM
    • 5.1.1. Domain Layer
    • 5.1.2. Interface Layer
    • 5.1.3. Application Layer
    • 5.1.4. Infrastructure Layer
    • 5.1.6. Bounded Context Software Architecture Component Level Diagrams
    • 5.1.7. Bounded Context Software Architecture Code Level Diagrams
      • 5.1.7.1. Bounded Context Domain Layer Class Diagrams
      • 5.1.7.2. Bounded Context Database Design Diagram
  • 5.2. Bounded Context: Billing and Subscriptions
    • 5.2.1. Domain Layer
    • 5.2.2. Interface Layer
    • 5.2.3. Application Layer
    • 5.2.4. Infrastructure Layer
    • 5.2.6. Bounded Context Software Architecture Component Level Diagrams
    • 5.2.7. Bounded Context Software Architecture Code Level Diagrams
      • 5.2.7.1. Bounded Context Domain Layer Class Diagrams
      • 5.2.7.2. Bounded Context Database Design Diagram
  • 5.3. Bounded Context: Workspace Management
    • 5.3.1. Domain Layer
    • 5.3.2. Interface Layer
    • 5.3.3. Application Layer
    • 5.3.4. Infrastructure Layer
    • 5.3.6. Bounded Context Software Architecture Component Level Diagrams
    • 5.3.7. Bounded Context Software Architecture Code Level Diagrams
      • 5.3.7.1. Bounded Context Domain Layer Class Diagrams
      • 5.3.7.2. Bounded Context Database Design Diagram
  • 5.4. Bounded Context: Requirement Discovery
    • 5.4.1. Domain Layer
    • 5.4.2. Interface Layer
    • 5.4.3. Application Layer
    • 5.4.4. Infrastructure Layer
    • 5.4.6. Bounded Context Software Architecture Component Level Diagrams
    • 5.4.7. Bounded Context Software Architecture Code Level Diagrams
      • 5.4.7.1. Bounded Context Domain Layer Class Diagrams
      • 5.4.7.2. Bounded Context Database Design Diagram
  • 5.5. Bounded Context: Integration Gateway
    • 5.5.1. Domain Layer
    • 5.5.2. Interface Layer
    • 5.5.3. Application Layer
    • 5.5.4. Infrastructure Layer
    • 5.5.6. Bounded Context Software Architecture Component Level Diagrams
    • 5.5.7. Bounded Context Software Architecture Code Level Diagrams
      • 5.5.7.1. Bounded Context Domain Layer Class Diagrams
      • 5.5.7.2. Bounded Context Database Design Diagram
• Capítulo VI: Solution UX Design
  • 6.1. Style Guidelines
    • 6.1.1. General Style Guidelines
    • 6.1.2. Web, Mobile & Devices Style Guidelines
  • 6.2. Information Architecture
    • 6.2.2. Labeling Systems
    • 6.2.3. Searching Systems
    • 6.2.4. SEO Tags and Meta Tags
    • 6.2.5. Navigation Systems
  • 6.3. Landing Page UI Design
    • 6.3.1. Landing Page Wireframe
    • 6.3.2. Landing Page Mock-up
  • 6.4. Applications UX/UI Design
    • 6.4.1. Applications Wireframes
    • 6.4.2. Applications Wireflow Diagrams
    • 6.4.2. Applications Mock-ups
    • 6.4.3. Applications User Flow Diagrams
  • 6.5. Applications Prototyping
• Capítulo VII: Product Implementation, Validation & Deployment
  • 7.1. Software Configuration Management
    • 7.1.1. Software Development Environment Configuration
    • 7.1.2. Source Code Management
    • 7.1.3. Source Code Style Guide & Conventions
    • 7.1.4. Software Deployment Configuration
  • 7.2. Solution Implementation
    • 7.2.X. Sprint n
      • 7.2.X.1. Sprint Planning n
      • 7.2.X.2. Sprint Backlog n
      • 7.2.X.3. Development Evidence for Sprint Review
      • 7.2.X.4. Testing Suite Evidence for Sprint Review
      • 7.2.X.5. Execution Evidence for Sprint Review
      • 7.2.X.6. Services Documentation Evidence for Sprint Review
      • 7.2.X.7. Software Deployment Evidence for Sprint Review
      • 7.2.X.8. Team Collaboration Insights during Sprint
  • 7.3. Validation Interviews
    • 7.3.1. Diseño de Entrevistas
    • 7.3.2. Registro de Entrevistas
    • 7.3.3. Evaluaciones según heurísticas
  • 7.4. Video About-the-Product
• Conclusiones
• Bibliografía
• Anexos

Student Outcome

El curso contribuye al cumplimiento del Student Outcome ABET:

ABET - EAC - Student Outcome 3

Criterio: Capacidad de comunicarse efectivamente con un rango de audiencias.

En el siguiente cuadro se describen las acciones realizadas y los enunciados de conclusiones por parte del grupo, los cuales permiten sustentar el haber alcanzado el logro del ABET – EAC - Student Outcome 3.

Criterio específico	Acciones realizadas	Conclusiones
Comunica oralmente sus ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.	TB1 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando oralmente los aspectos generales del proyecto relacionados con el Capítulo I y parte del Capítulo IV. Expliqué la descripción de la startup, la propuesta de solución y los fundamentos estratégicos del producto, procurando presentar las ideas de manera clara, ordenada y comprensible para una audiencia académica. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando oralmente los contenidos vinculados al Capítulo I y Capítulo IV. Presenté ideas relacionadas con el perfil de la solución, el enfoque estratégico del producto y las decisiones generales de diseño, utilizando un lenguaje objetivo y adecuado para explicar la relación entre la problemática identificada y la solución propuesta. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando oralmente los avances desarrollados en el Capítulo II, principalmente los resultados del análisis de requerimientos, entrevistas, competidores y hallazgos del proceso de need finding. Mi participación permitió explicar cómo se identificaron necesidades relevantes para orientar el desarrollo del producto. Varela Bustinza, Marcelo Alessandro – 202319668 Trabajé comunicando oralmente los resultados correspondientes al Capítulo II, especialmente el análisis competitivo, las estrategias frente a competidores, el diseño y análisis de entrevistas, así como los principales hallazgos obtenidos sobre los usuarios. Busqué explicar la información de manera objetiva, conectando los resultados con la definición de requerimientos del proyecto. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando oralmente los contenidos del Capítulo III, relacionados con la especificación de requerimientos, user stories, product backlog e impact mapping. Expliqué cómo los hallazgos obtenidos en etapas anteriores se transformaron en requisitos y elementos priorizados para el desarrollo de la solución. TP Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando oralmente mis ideas con objetividad al presentar la arquitectura y diseño de cada bounded context en el Capítulo V. Adapté mi lenguaje para que perfiles tanto técnicos (desarrolladores) como de negocio (stakeholders) comprendieran cómo los componentes tácticos resuelven los problemas del proyecto de ingeniería. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando oralmente los resultados de la refactorización aplicada al Event Storming y sustenté los diagramas del Capítulo V. Expuse estas ideas con objetividad, asegurándome de que las decisiones de diseño arquitectónico fueran claras para una audiencia de diferentes niveles jerárquicos y especialidades. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando oralmente las especificaciones de la landing page y el diseño y estilos de la versión mobile, correspondientes al Capítulo VI. Presenté mis ideas de forma objetiva, demostrando cómo las decisiones de interfaz de usuario se alinean con los requerimientos técnicos y de ingeniería. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué oralmente los resultados del diseño UX/UI de la aplicación web de Reqs-AI, explicando el flujo completo desde la autenticación y creación del workspace hasta la gestión de proyectos, sesiones de descubrimiento, revisión de historias de usuario, integración con Jira, facturación y configuración del equipo. Además, sustenté la relación entre wireframes, wireflows y mock-ups, destacando cómo cada pantalla mantiene coherencia visual, navegación consistente y alineación con las funcionalidades principales del producto. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando oralmente la refactorización de las User Stories y del Product Backlog, además de sustentar partes del Capítulo V. Mantuve objetividad al explicar cómo las historias guían el desarrollo de la ingeniería, asegurando que el público de diferentes especialidades entendiera su impacto en la arquitectura.	TB1 Como equipo, se logró comunicar oralmente los avances del proyecto de manera clara, organizada y objetiva. Cada integrante explicó los resultados correspondientes a su participación, conectando los capítulos desarrollados con el propósito general de la solución. Asimismo, la exposición permitió adaptar el lenguaje técnico a una audiencia académica, integrando aspectos de negocio, usuarios, requerimientos y diseño de ingeniería. TP Como equipo en esta etapa (TP), logramos sustentar oralmente decisiones arquitectónicas complejas y diseños de interfaz. Comunicamos con objetividad cómo el diseño táctico de los Bounded Contexts y las mejoras en UX/UI resuelven las necesidades del negocio. Adaptamos nuestra exposición para que tanto perfiles gerenciales (enfocados en el valor del producto) como técnicos (enfocados en patrones de ingeniería) comprendieran claramente la evolución y escalabilidad del sistema.
Comunica en forma escrita ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.	TB1 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando de forma escrita los contenidos relacionados con el Capítulo I y parte del Capítulo IV. Redacté información sobre el perfil de la startup, la propuesta de solución y los elementos estratégicos del diseño del producto, procurando mantener una estructura clara y una redacción adecuada para el contexto académico y de ingeniería. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando de forma escrita los apartados vinculados al Capítulo I y Capítulo IV. Mi aporte se centró en organizar y redactar ideas sobre la solución propuesta, su relación con la problemática y los criterios estratégicos del producto, asegurando coherencia entre el enfoque del proyecto y las decisiones de diseño. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando de forma escrita los contenidos del Capítulo II, principalmente en los apartados de análisis de requerimientos, entrevistas, competidores, identificación de necesidades y lenguaje ubicuo. Mi aporte permitió documentar los hallazgos de manera ordenada y orientada a sustentar la definición de requerimientos. Varela Bustinza, Marcelo Alessandro – 202319668 Trabajé comunicando de forma escrita los resultados del Capítulo II, incluyendo el análisis competitivo, estrategias frente a competidores, diseño y análisis de entrevistas, user personas, mapas de empatía y escenarios actuales. Mi trabajo contribuyó a presentar evidencia relevante sobre las necesidades del usuario y su relación con los requerimientos del producto. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando de forma escrita los contenidos del Capítulo III, enfocados en to-be scenario mapping, user stories, product backlog e impact mapping. Mi aporte permitió transformar los hallazgos del análisis en requisitos claros, priorizados y alineados con los objetivos del producto. TP Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando en forma escrita los resultados del diseño táctico de cada bounded context en el Capítulo V. Redacté la estructura de las capas de dominio, aplicación e infraestructura manteniendo objetividad técnica, utilizando diagramas estándar para que equipos de diferentes especialidades puedan comprender la arquitectura. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando en forma escrita las mejoras y la refactorización aplicadas al Event Storming, documentando objetivamente las decisiones tomadas. Apoyé en la redacción técnica del Capítulo V, asegurando que la documentación sea comprensible y útil tanto para desarrolladores como para evaluadores del proyecto. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando en forma escrita los elementos del Capítulo VI, especificando la landing page y el diseño y estilos de la versión mobile del app. Documenté estas decisiones de UX/UI con objetividad, estructurando la información de manera que sea fácilmente interpretable por equipos de distintas disciplinas. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué de forma escrita la documentación del Capítulo VI: Solution UX Design, desarrollando secciones relacionadas con style guidelines, information architecture, wireframes, wireflows y mock-ups de la web application. Redacté subtítulos y descripciones para cada imagen, organicé los recursos visuales con nombres consistentes y expliqué cómo cada pantalla representa una acción o estado funcional dentro del flujo de Reqs-AI. Este trabajo permitió evidenciar la evolución desde la estructura de baja fidelidad hasta la propuesta visual final de la plataforma. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando en forma escrita la refactorización de las User Stories y la actualización del Product Backlog. Redacté estos artefactos con objetividad técnica para que sirvan de puente claro entre las necesidades del negocio y la implementación en ingeniería, apoyando también en la documentación del Capítulo V.	TB1 Como equipo, se logró comunicar por escrito las ideas, resultados y decisiones del proyecto de manera estructurada y objetiva. El documento integra información sobre negocio, usuarios, requerimientos y diseño estratégico, manteniendo una secuencia lógica entre los capítulos. Además, la redacción permitió presentar el proyecto de forma comprensible para audiencias con distintos niveles de conocimiento técnico. TP Para el entregable TP, el equipo demostró la capacidad de documentar formalmente la arquitectura de software (Capítulo V) y el diseño de la experiencia de usuario (Capítulo VI). Se estructuraron los modelos de dominio, diagramas tácticos y wireflows con estricta objetividad técnica. Esta documentación escrita permite que profesionales de diferentes especialidades, desde desarrolladores hasta líderes de proyecto, puedan entender las soluciones de ingeniería propuestas sin ambigüedades.

Capítulo I: Introducción

1.1. Startup Profile

1.1.1. Descripción de la Startup

Kntro-Soft es una startup tecnológica peruana dedicada a la innovación en ingeniería de software mediante el uso de Inteligencia Artificial Generativa y procesamiento de lenguaje natural en tiempo real. Nuestra misión es potenciar la productividad de los equipos de desarrollo y analistas de sistemas, eliminando la pérdida de información durante el levantamiento de requisitos, asegurando que cada necesidad del cliente se convierta en una historia de usuario precisa y completa.

Propuesta de Valor

• Documentación Instantánea: Generación automática de User Stories con criterios de aceptación en formato Gherkin mediante LLM de última generación
• Asistencia de Consulta en Tiempo Real: Recomendaciones de preguntas estratégicas durante las juntas para eludir lagunas de información y contemplar escenarios excepcionales.
• Contexto Inteligente (RAG): Integración con el historial del proyecto para detectar duplicados y asegurar que los nuevos requisitos sean consistentes con la arquitectura existente
• Privacidad Empresarial: Arquitectura multitenancy robusta con Row Level Security, garantizando que los datos y el conocimiento de cada organización permanezcan estrictamente aislados

Visión

Convertirnos en la plataforma estándar de gestión de requisitos para empresas de software en Latinoamérica, liderando la transición hacia un desarrollo de software asistido por IA que sea transparente, eficiente y libre de errores de comunicación.

Valores

• Precisión Técnica: Compromiso con la entrega de requisitos listos para el desarrollo.
• Agilidad: Reducción drástica del tiempo entre la reunión y el inicio de la codificación.
• Seguridad: Protección absoluta de la propiedad intelectual de nuestros clientes.
• Innovación Adaptativa: Evolución constante de nuestros modelos para entender los dialectos y modismos técnicos de la región.

1.1.2. Perfiles de integrantes del equipo

Foto del participante	Nombres y apellidos	Código de estudiante	Carrera	Conocimientos técnicos y habilidades
	Eric Ernesto Hernández Tuiro	20221C857	Ingeniería de Software	Especialista en desarrollo backend con Java/Spring Boot y diseño de arquitecturas de sistemas. Enfocado en tecnologías empresariales y soluciones eficientes.
	Marcelo Alejandro Varela Bustinza	202319668	Ingeniería de Software	Desarrollador con experiencia en Angular/Spring Boot y Vue.js/ASP.NET, enfocado en arquitecturas monolíticas y desarrollo de aplicaciones.
	Jhosepmyr Orlando Gutiérrez Soto	202317638	Ingeniería de Software	Especialista en desarrollo full-stack con Java/Spring Boot y frameworks frontend como Angular y Vue.js. Experiencia en microservicios y servicios cloud (AWS, Azure, GCP). Aporta habilidades de liderazgo técnico, toma de decisiones y coordinación de equipos de desarrollo.
	Paul Fernando Sulca Gonzales	20221C486	Ingeniería de Software	Conocimiento en diseño de software orientado a objetos y modelado UML. Experiencia en implementación de interfaces web adaptativas. Amante de los desafíos de la vida universitaria.
	Salim Ignacio Ramirez Mestanza	20201E843	Ingeniería de Software	Conocimiento en arquitectura de software y control de versiones con Git. Experiencia en documentación técnica y colaboración en equipos ágiles. Desarrollo backend con Java/Spring Boot y Domain-Driven Design.

1.2. Solution Profile

1.2.1. Antecedentes y problemática

Esta sección analiza la desconexión entre la captura de información y la ejecución en el desarrollo de software. Se utiliza la técnica de las 5W2H para desglosar cómo la gestión deficiente de requisitos impacta la rentabilidad y el éxito de los proyectos de TI, estableciendo la base fáctica que justifica la implementación de Kntro-Soft.

Análisis mediante la técnica de las 5 W's y 2 H's:

• WHO - ¿Quién está afectado?: El problema afecta principalmente a los Analistas de Sistemas, Product Owners y Business Analysts, quienes deben alternar entre la escucha activa y la toma de notas. Secundariamente, impacta a los equipos de desarrollo, startups de software, y a las empresas de software en el Perú.

• WHAT - ¿Cuál es el problema?: La pérdida de información crítica durante las reuniones de descubrimiento. A los analistas se les puede dificultar el procesar y documentar simultáneamente la información que brinda el cliente, generando requisitos incompletos y casos de borde ignorados. Esto deriva en una deuda técnica desde la concepción del producto.

• WHERE - ¿Dónde ocurre?: En el entorno de las empresas de servicios de software y startups de desarrollo de software en Perú y Latinoamérica. Se manifiesta tanto en reuniones presenciales como en videollamadas, donde el flujo de información es rápido y desestructurado.

• WHEN - ¿Cuándo sucede?: Ocurre durante la fase de Elicitación de Requisitos. La crisis de documentación se agrava después de la reunion, cuando el analista intenta reconstruir lo conversado, perdiendo varios detalles específicos y dándose cuenta de dudas y preguntas importantes que no resolvió con el cliente durante la reunión.

• WHY - ¿Por qué persiste?: Por la dependencia en métodos manuales. La captura de requisitos sigue siendo un proceso artesanal en una industria automatizada. Según el Project Management Institute (PMI), la comunicación deficiente es la razón principal del fracaso en 1 de cada 3 proyectos de TI.

• HOW - ¿Cómo se manifiesta el problema?: Se evidencia en el retrabajo. Las historias de usuario mal definidas obligan a los desarrolladores a detenerse para pedir aclaraciones o, peor aún, a construir funcionalidades que no cumplen con la expectativa del cliente, generando ciclos de feedback infinitos.

• HOW MUCH - ¿Cuál es la magnitud del impacto?: * Costo de Fallas: El 47% de los proyectos de software fallan o se ven comprometidos debido a una mala gestión de requisitos (Standish Group, 2020). Impacto Económico: Corregir un error de requisitos durante la fase de desarrollo cuesta hasta 10 veces más que hacerlo durante la fase de diseño. Si el error llega a producción, el costo se eleva a 100 veces más (Ver Anexos 1). Desperdicio Financiero: Las organizaciones pierden, en promedio, US$ 97 millones por cada 1,000 millones invertidos debido a un desempeño deficiente de los proyectos (PMI, 2018).

1.2.2. Lean UX Process

Esta sección aplica el Proceso Lean UX para estructurar la visión del negocio del proyecto WasteTrack. Se inicia con la formulación del problema, se desglosan las suposiciones fundamentales que sostienen el modelo de negocio y de producto, y finalmente se traducen estas suposiciones en hipótesis comprobables que guiarán el ciclo de desarrollo y validación.

1.2.2.1. Lean UX Problem Statements

El estado actual de la ingeniería de requisitos en el desarrollo de software depende principalmente en la captura pasiva de información a través de grabaciones de video y transcripciones automáticas, las cuales funcionan como una memoria histórica para que el analista de sistemas revise el contenido después de la reunión.

Lo que los servicios y flujos de trabajo existentes no logran abordar es el desafío del razonamiento y la validación en tiempo real. Actualmente, el analista suele descubrir ambigüedades, casos de borde no considerados y vacíos de lógica recién cuando procesa la grabación horas o días después. Esto genera un ciclo ineficiente de reuniones de seguimiento para aclarar dudas que pudieron resolverse en el momento si se hubiera contado con un soporte analítico inmediato.

Nuestro producto, Reqs-AI, abordará esta brecha mediante un motor de inteligencia artificial que procesa el audio en vivo para generar historias de usuario estructuradas mientras la reunión ocurre. Su valor diferencial reside en un asistente de consulta activa que proporciona sugerencias de preguntas críticas al analista en tiempo real, asegurando que toda duda técnica o de negocio sea resuelta mientras el cliente aún está presente.

Nuestro enfoque inicial serán las Startups tecnológicas y empresas de desarrollo de software que operan bajo metodologías ágiles y necesitan una transición inmediata y sin errores desde la fase de descubrimiento hasta el inicio de la codificación.

Sabremos que hemos tenido éxito cuando observemos una reducción del 40% en las reuniones de seguimiento para aclaración de requisitos, una disminución significativa en el tiempo que el analista dedica al postprocesamiento de la información y una tasa de aceptación de historias de usuario superior al 80% en la primera iteración de revisión con el equipo de desarrollo.

1.2.2.2. Lean UX Assumptions

Esta sección presenta las suposiciones fundamentales del proyecto Reqs-AI, estructuradas bajo el marco de Lean UX. Aquí definimos los resultados de negocio esperados, los perfiles de usuario que enfrentan el problema y los beneficios tangibles que estos obtendrán al utilizar nuestra solución.

Business Outcomes (Resultados de Negocio):

Utilizamos el framework AARRR (Pirate Metrics) para cuantificar el impacto estratégico de Reqs-AI en el mercado de startups y empresas:

• Acquisition (Adquisición): El 25% de las empresas contactadas se registrarán para una prueba gratuita de 14 días.
• Activation (Activación): El 40% de los usuarios registrados procesará al menos 3 reuniones reales y generará un set de User Stories en su primera semana.
• Retention (Retención): El 60% de las Startups que completen la prueba gratuita optarán por una suscripción mensual activa.
• Revenue (Ingresos): Se proyecta un Ingreso Mensual Recurrente (MRR) promedio de $49 por Startup y contratos anuales de 4,000+ para Empresas.
• Referral (Recomendación): 1 de cada 4 usuarios activos recomendará la herramienta a otros colegas en comunidades de Product Management o Ingeniería.

Users (Usuarios) Hemos identificado dos perfiles clave que enfrentan el reto de transformar la voz del cliente en código, adaptados a la realidad de una Startup y una organización corporativa:

Usuario	Perfil	Objetivos	Obstáculos
Alex (Tech Leader)	32 años, Desarrollador Senior que lidera el equipo técnico.	Traducir visiones de negocio a especificaciones técnicas, evitar deuda técnica por requisitos ambiguos, agilizar el inicio del sprint.	Alta carga de trabajo técnico, dificultad para documentar mientras lidera la discusión técnica.
Claudia (Analista Enterprise)	35 años, Business Analyst en una corporación.	Estandarizar requisitos en Gherkin, asegurar que nada quede ambiguo, cumplir con normas de seguridad.	Reuniones largas y densas, dificultad para procesar horas de grabación, burocracia en la documentación.

User Outcomes (Resultados de Usuario) Estos son los resultados esperados por nuestros usuarios, divididos según el valor que perciben al usar Reqs-AI:

• Startup Lead: Funcional: Obtener historias de usuario en Gherkin y restricciones técnicas listas para el backlog inmediatamente al finalizar la sesión. Emocional: Sentir la seguridad de que la arquitectura y los casos críticos están alineados con la expectativa del cliente antes de escribir una sola línea de código Aspiracional: Ser el facilitador de una cultura de ingeniería de alto rendimiento donde la documentación nunca es un cuello de botella para la innovación.

• Analista Enterprise: Funcional: Eliminar el trabajo manual de transcribir grabaciones y redactar Gherkin desde cero. Emocional: Sentir empoderamiento durante la reunión al recibir sugerencias de preguntas que exponen vacíos de lógica del cliente. Aspiracional: Posicionarse como una analista estratégica que garantiza la precisión del proyecto, reduciendo el retrabajo del equipo.

1.2.2.3. Lean UX Hypothesis Statements

Test (Alto valor, alto riesgo)

• Hipótesis 1 (Riesgo de Valor y Comportamiento): El equipo cree que proporcionar sugerencias automáticas de preguntas sobre casos de borde en tiempo real para el Analista de Sistemas logrará una captura de requisitos exhaustiva durante la primera interacción. Se sabrá que esto es cierto cuando el analista plantee al menos el 60% de las sugerencias generadas por la IA durante la sesión en vivo con el cliente, reduciendo la necesidad de reuniones de aclaración posteriores.

• Hipótesis 2 (Riesgo de Confianza Técnica): El equipo cree que la generación instantánea de historias de usuario en formato Gherkin utilizando contexto previo (RAG) para el Líder Técnico de una Startup logrará acelerar el ciclo de inicio del desarrollo (discovery-to-delivery). Se sabrá que esto es cierto cuando el tiempo promedio dedicado por el rol a la edición y corrección manual de las historias generadas sea menor a 15 minutos por sesión.

Ship & Measure (Alto valor, bajo riesgo)

• Hipótesis 3 (Riesgo de Adopción Funcional): El equipo cree que la integración de un botón de exportación directa hacia herramientas de gestión para el Líder Técnico de una Startup logrará una mayor retención de uso de la plataforma. Se sabrá que esto es cierto cuando el 80% de las historias de usuario validadas en Reqs-AI sean sincronizadas con el backlog del proyecto en los primeros 10 minutos posteriores al cierre de la reunión.

• Hipótesis 4 (Riesgo de Cumplimiento y Seguridad): El equipo cree que la implementación de una arquitectura de aislamiento de datos mediante Row Level Security (RLS) para el Analista de Sistemas Enterprise logrará mitigar las preocupaciones de privacidad de la información corporativa. Se sabrá que esto es cierto cuando las organizaciones interesadas completen el proceso de registro y configuración del perfil organizacional tras revisar la documentación de seguridad y multitenancy del sistema.

1.2.2.4. Lean UX Canvas

1.3. Segmentos objetivos

Segmento 1: Líder Técnico de Startup

Descripción:

Este segmento representa al motor técnico y estratégico de empresas tecnológicas en etapa de crecimiento. Son profesionales que cumplen roles híbridos entre la gestión de producto y el desarrollo. Su principal motivación es la velocidad de entrega y la precisión técnica. Se frustran al perder tiempo valioso en la documentación manual tras reuniones intensas y al descubrir "deuda de requisitos" solo cuando ya están en plena fase de codificación. Buscan una herramienta que les permita pasar de la conversación al código sin fricciones.

Características Demográficas (Perfil Inferido):

Aspecto	Detalle
Rango de Edad	30 - 35 años
Nivel Educativo	Universitario o Postgrado (Ingeniería de Software, Sistemas o Computación)
Entorno Laboral	Startups, ambientes ágiles, trabajo remoto o híbrido
Familiaridad Tecnológica	Nativo digital; uso experto de APIs, LLMs, y herramientas como Jira/Notion

Segmento 2: Analista de Sistemas Enterprise

Descripción:

Este segmento representa al profesional encargado de la gobernanza de requisitos en grandes corporaciones o Software Factories. Su enfoque principal es la estandarización y la mitigación de riesgos. Deben asegurar que cada requerimiento del cliente esté perfectamente documentado en formatos rigurosos como Gherkin para su posterior pase a desarrollo y testing (QA). Actualmente, su mayor dolor es la carga operativa de procesar horas de grabaciones para extraer criterios de aceptación, enfrentando el riesgo de malinterpretar la visión del cliente por falta de validación inmediata en la reunión.

Características Demográficas (Perfil Inferido):

Aspecto	Detalle
Rango de Edad	30 - 45 años
Nivel Educativo	Universitario o Postgrado (Gestión de Proyectos, Business Analysis)
Entorno Laboral	Corporativo, grandes departamentos de TI, procesos bajo marcos CMMI o SAFe
Familiaridad Tecnológica	Alta; manejo de herramientas de modelado y gestión empresarial (Azure DevOps, Enterprise Architect)

Capítulo II: Requirements Elicitation & Analysis

2.1. Competidores

2.1.1. Análisis competitivo

Para este análisis, hemos seleccionado a los competidores más relevantes según el tipo de amenaza que representan para Reqs-AI: un competidor directo y especializado (Spinach.io), un competidor sustituto de uso masivo (Otter.ai / Fireflies.ai), y el incumbente o Status Quo de la industria (Jira + Atlassian Intelligence).

Aspecto	Reqs-AI (Nuestro Producto)	Spinach.io (Competidor Directo)	Otter.ai / Fireflies (Sustituto)	Jira + Atlassian AI (Incumbente)
¿Por qué se analiza?	Para identificar brechas de mercado entre los transcriptores genéricos, los asistentes ágiles y las herramientas de ticketing, posicionando a Reqs-AI como el único especialista en Ingeniería de Requisitos.
Logo
Overview	SaaS impulsado por IA especializado en Requirements Elicitation. Captura audio de reuniones, aplica RAG con documentos del proyecto y genera historias de usuario estructuradas (BDD/Gherkin).	"AI Scrum Master". Se une a las reuniones de Zoom/Meet, toma notas, resume stand-ups y crea tickets básicos en Jira.	Asistentes de reuniones por IA de propósito general. Transcriben, hacen resúmenes ejecutivos y extraen "Action Items".	La plataforma líder mundial en gestión ágil. Recientemente, integró IA para ayudar a redactar y mejorar la gramática de los tickets directamente en su interfaz.
Ventaja competitiva	Profundidad Técnica: No hace resúmenes, hace Ingeniería de Software. Detecta edge cases, sugiere preguntas al cliente en vivo y previene historias duplicadas.	Integración nativa: Se comporta como un bot que entra automáticamente a las videollamadas y se integra con múltiples CRM.	Adopción masiva: Son extremadamente fáciles de usar, baratos y sirven para cualquier industria (ventas, legal, educación).	Monopolio del dato: Los equipos ya viven en Jira. No necesitan salir de la plataforma para usar su IA.
Mercado objetivo	Business Analysts, Product Owners, y Software Factories que sufren por requerimientos ambiguos.	Scrum Masters y Project Managers que quieren automatizar la burocracia de las ceremonias ágiles.	Profesionales de cualquier rubro que tienen demasiadas reuniones y necesitan recordar qué se habló.	Equipos de desarrollo de software y corporaciones que ya usan el ecosistema Atlassian.
Estrategia de Marketing	Nicho técnico: "Deja de codificar lo que no es. Reqs-AI convierte reuniones caóticas en requerimientos perfectos."	Productividad ágil: "Tu asistente de IA que actualiza tu tablero Kanban por ti."	Productividad general: "Nunca más tomes notas en una reunión."	Ecosistema cerrado: "Todo el poder de la IA, sin salir de tu entorno seguro de Jira."
Fortalezas	Generación de criterios de aceptación en Gherkin, entendimiento del contexto técnico (RAG con glosarios del cliente) y asistencia consultiva en tiempo real.	Cubre todo el ciclo Scrum (Plannings, Dailies, Retrospectives) no solo el levantamiento de requerimientos.	Transcripción casi perfecta, búsqueda global de palabras clave, reconocimiento de voz (diarización) excepcional.	Confianza corporativa absoluta, seguridad empresarial (Compliance) y cero fricción de adopción para equipos actuales.
Debilidades	Requiere cambiar el hábito del Analista (usar una herramienta externa antes de pasar a Jira). Marca nueva sin confianza corporativa aún.	Sus Historias de Usuario son superficiales. Se enfocan en el "Qué" pero fallan gravemente en los detalles técnicos y reglas de negocio complejas.	No entienden de software. Un "Action Item" para Otter es "Hacer el login", pero no generará los criterios de aceptación técnicos para el desarrollador.	La IA de Jira reacciona a texto, no escucha. El Product Owner todavía tiene que tomar notas en la reunión y luego pedirle a la IA de Jira que las mejore.

2.1.2. Estrategias y tácticas frente a competidores

2.2. Entrevistas

2.2.1. Diseño de entrevistas

El diseño de entrevistas se orienta a comprender en profundidad el trabajo real de cada segmento: su contexto, decisiones, tareas, emociones y restricciones operativas. El guion se organiza de forma progresiva para conocer cómo viven hoy el proceso, qué valoran y dónde encuentran más dificultades.

Segmento 1: Líder Técnico de Startup

Fase A: Perfil y Ecosistema

1. Datos base: Nombre, edad, distrito y con quién vives.

2. Contexto Profesional: ¿Cuál es tu rol, cuánto tiempo llevas en él y cómo es tu equipo (personas, roles y metodología)?

3. Stack de trabajo: ¿Qué herramientas usas para coordinar reuniones, documentar lo que sale de ellas y gestionar el backlog?

4. La "imprescindible": ¿Cuál herramienta no podrías eliminar de tu flujo y por qué?

5. Influencias: ¿Alguna comunidad o recurso que dicte cómo defines tus prácticas?

Fase B: El Flujo y la Ejecución

6. El proceso: Cuéntame el paso a paso desde que se agenda la reunión de requisitos hasta que la historia entra al sprint.

7. Dinámica de reunión: ¿Quién agenda? ¿Cómo se preparan? ¿Qué haces tú exactamente mientras el cliente habla y quién más participa?

8. Post-reunión: Al terminar, ¿cuál es tu primera acción y qué información queda registrada?

9. Foco Técnico: ¿Desarrollas tú mismo lo que se levantó? ¿Cuánto tiempo pasa hasta tener la historia lista?

10. La brecha: Al trabajar con tus notas, ¿qué información sientes que faltó capturar?

Fase C: Dolores, Costos y Éxitos

11. Puntos de quiebre: ¿Qué parte es la más desgastante? ¿Dónde hay más malentendidos o pérdida de información?

12. Casos reales: Cuéntame una reunión que salió mal. ¿Qué detalles suelen omitirse al inicio y por qué crees que pasa?

13. Impacto en código: ¿Con qué frecuencia cambian las decisiones técnicas ya en desarrollo? ¿Cómo lo resuelven?

14. El costo del error: Si una historia queda mal definida, ¿cuántas horas de tu propio desarrollo pierdes? ¿Cómo afecta al sprint y a tu estado de ánimo?

15. El ideal: ¿Cuándo sientes que una reunión salió "perfecta"? ¿Qué cambió?

16. Validación: ¿Han intentado automatizar la documentación? ¿Qué cambiarías del proceso si pudieras?

17. Cierre: En una frase honesta, ¿cómo vives este proceso? ¿Algo más que deba saber?

Segmento 2: Analista de Sistemas Enterprise

Fase A: Perfil y Ecosistema

1. Datos base: Nombre, edad, distrito y con quién vives.

2. Contexto Profesional: ¿Cuál es tu rol, cuánto tiempo llevas en él y cómo es tu equipo (personas, roles y metodología)?

3. Stack de trabajo: ¿Qué herramientas usas para coordinar reuniones, documentar lo que sale de ellas y gestionar el backlog?

4. La "imprescindible": ¿Cuál herramienta no podrías eliminar de tu flujo y por qué?

5. Influencias: ¿Alguna comunidad o recurso que dicte cómo defines tus prácticas?

Fase B: El Flujo y la Entrega

6. El proceso: Cuéntame el paso a paso desde que se agenda la reunión de requisitos hasta que la historia entra al sprint.

7. Dinámica de reunión: ¿Quién agenda? ¿Cómo se preparan? ¿Qué haces tú exactamente mientras el cliente habla y quién más participa?

8. Post-reunión: Al terminar, ¿cuál es tu primera acción y qué información queda registrada?

9. Foco Funcional: ¿A quién le entregas los requisitos, en qué formato y cuánto tiempo inviertes en transformar notas en historias formales?

10. Alineación: ¿Cómo te aseguras de que el equipo técnico entendió lo mismo que tú y el cliente?

Fase C: Dolores, Relaciones y Éxitos

11. Puntos de quiebre: ¿Qué parte es la más desgastante? ¿Dónde hay más malentendidos o pérdida de información?

12. Casos reales: Cuéntame una reunión que salió mal. ¿Qué detalles suelen omitirse al inicio y por qué crees que pasa?

13. Crisis: ¿Qué pasa si el cliente dice que lo entregado no es lo que pidió? ¿Cómo manejas al cliente y al equipo a la vez?

14. El costo del error: Si una historia está incompleta, ¿quién se ve más afectado y cómo daña la relación con el cliente? ¿Cómo te sientes tú?

15. El ideal: ¿Cuándo sientes que una reunión salió "perfecta"? ¿Qué cambió?

16. Validación: ¿Usan templates o checklists? ¿Qué tan bien funcionan en la realidad vs. el papel? ¿Qué cambiarías del proceso?

17. Cierre: En una frase honesta, ¿cómo vives este proceso? ¿Algo más que deba saber?

2.2.2. Registro de entrevistas

Segmento Líder Técnico: Entrevistado 1

Atributo	Detalle
Nombre	Gabriel Reyna
Edad	22
Sexo	Masculino
Distrito	Barranco
Ocupación	Desarrollador full stack
Fecha de entrevista	2026-04-26
Timing	00:00 - 08:44
Video	Ver en Microsoft Stream
Captura
Resumen	Gabriel cuenta con experiencia como desarrollador full stack y participa en reuniones de levantamiento de requisitos dentro de un equipo ágil basado en Scrum. Durante la entrevista, señaló que el proceso actual depende en gran medida de reuniones, notas manuales, documentación en Notion y gestión del backlog en Jira. Identificó como principales dificultades la pérdida de información, la ambigüedad en los requisitos y el retrabajo generado cuando no se definen correctamente los flujos o criterios desde el inicio. Además, considera que una solución que automatice el resumen de reuniones y apoye la generación de historias de usuario podría reducir errores y mejorar la claridad del proceso.

Segmento Líder Técnico: Entrevistado 2

Atributo	Detalle
Nombre	Ronald Peralta
Edad	22
Sexo	Masculino
Distrito	Santiago de Surco
Ocupación	Líder técnico
Fecha de entrevista	2026-04-26
Timing	08:44 - 18:26
Video	Ver en Microsoft Stream
Captura
Resumen	Ronald se desempeña como líder técnico y participa activamente en el proceso de levantamiento de requisitos junto con perfiles como el Product Owner y el Project Manager. Su equipo trabaja con herramientas como Google Meet, Zoom, Notion, Jira y Trello para coordinar reuniones, documentar acuerdos y gestionar el backlog. Durante la entrevista, destacó que uno de los principales problemas ocurre al traducir lo que el cliente solicita en historias de usuario claras y accionables. Señaló que una historia mal definida puede generar entre cuatro y ocho horas de retrabajo, afectar el avance del sprint y producir frustración en el equipo. Para él, el proceso es necesario, pero todavía depende demasiado de la claridad humana y requiere mayor optimización.

Segmento Líder Técnico: Entrevistado 3

Atributo	Detalle
Nombre	Daniela Martínez
Edad	23
Sexo	Femenino
Distrito	San Miguel
Ocupación	Desarrolladora backend y apoyo en levantamiento de requerimientos
Fecha de entrevista	2026-04-26
Timing	18:26 - 28:42
Video	Ver en Microsoft Stream
Captura
Resumen	Daniela trabaja como desarrolladora backend y también apoya en el levantamiento de requerimientos dentro de un equipo Scrum. En su flujo de trabajo utiliza Google Meet, Google Spaces, Notion, Google Docs, notas personales y Jira para organizar la información obtenida en reuniones con clientes. Durante la entrevista, explicó que los principales problemas aparecen cuando el cliente no comunica con claridad sus necesidades o cuando se omiten validaciones y reglas de negocio importantes. Indicó que estos errores pueden generar retrabajo, retrasos en el sprint y frustración en el equipo. Asimismo, considera que una herramienta capaz de transcribir reuniones y generar historias de usuario de manera automática podría optimizar significativamente el proceso, siempre que mantenga una validación humana.

---

Segmento Analista Funcional: Entrevistado 1

Atributo	Detalle
Nombre	Renato Torres
Edad	28
Sexo	Masculino
Distrito	Magdalena
Ocupación	Analista Funcional
Fecha de entrevista	25 de abril de 2026
Timing	28:42 - 44:31
Video	Ver en Microsoft Stream
Captura
Resumen	Esta entrevista presenta a Renato Torres, analista funcional senior con tres años de experiencia en una consultora tecnológica para el sector bancario. Lidera una célula ágil bajo la metodología Scrum adaptada, utilizando herramientas como Jira, Confluence y Microsoft Teams. Su proceso comienza con el discovery y la redacción de historias de usuario, actuando como un "traductor" entre las necesidades de negocio y el equipo técnico. Renato enfatiza que Jira es su única fuente de verdad para evitar malentendidos. Identifica como principales desafíos la falta de claridad en los procesos de los clientes y la omisión de los decisores finales. Finalmente, destaca que el éxito de su rol en el entorno peruano depende en un 80% de la gestión de expectativas.

Segmento Analista Funcional: Entrevistado 2

Atributo	Detalle
Nombre	Valentin Velasquez
Edad	25
Sexo	Masculino
Distrito	Santiago de Surco
Ocupación	Analista de Producto
Fecha de entrevista	25 de abril de 2026
Timing	44:31 - 54:51
Video	Ver en Microsoft Stream
Captura
Resumen	Esta entrevista presenta a Valentín, analista de producto de 25 años con experiencia en una consultora tecnológica. Trabaja en un equipo pequeño de cinco personas bajo una metodología Kanban, priorizando la agilidad sobre la rigidez de Scrum. Su stack incluye Slack, Google Meet, Trello y Notion, siendo esta última su herramienta indispensable para documentar requerimientos. Su proceso se centra en el aspecto visual, utilizando FigJam para crear mapas mentales en vivo y prototipos que reemplazan la documentación extensa. Valentín define su labor como un "caos ordenado" y actúa como puente entre el cliente y los desarrolladores. Entre sus principales desafíos destaca el manejo de cambios imprevistos por stakeholders ausentes y la falta de límites en la comunicación (WhatsApp), subrayando que la empatía con el usuario final es la clave del éxito.

Segmento Analista Funcional: Entrevistado 3

Atributo	Detalle
Nombre	Daniel Franco
Edad	30
Sexo	Masculino
Distrito	Santiago de Surco
Ocupación	Analista de Sistemas
Fecha de entrevista	26 de abril de 2026
Timing	54:51 - 01:05:32
Video	Ver en Microsoft Stream
Captura
Resumen	Esta entrevista presenta a Daniel Franco, analista de sistemas de 30 años en una software factory para el sector bancario. Trabaja bajo el marco SAFe en una célula con roles definidos y procesos rigurosos. Su matriz de trabajo es Azure DevOps, herramienta que considera imprescindible por la trazabilidad y certificación del proceso. Daniel destaca por su enfoque técnico: redacta historias en formato Gherkin, utiliza Enterprise Architect para procesos complejos y se guía por el BABOK Guide. Su mayor desafío operativo es procesar grabaciones de reuniones para evitar ambigüedades, invirtiendo cuatro horas de análisis por cada hora de sesión. Se define como el "guardián de la certidumbre", subrayando que en el entorno corporativo un error de lógica impacta a miles de usuarios financieros.

2.2.3. Análisis de entrevistas

Las entrevistas se realizaron entre el 25 y 26 de abril de 2026 a un total de seis participantes: tres del segmento Líder Técnico de Startup y tres del segmento Analista Funcional/Producto/Sistemas. El objetivo fue comprender sus flujos reales de levantamiento de requisitos, identificar fricciones operativas recurrentes y validar la oportunidad de una solución como Reqs-AI para reducir ambigüedad y retrabajo.

---

Segmento: Líder Técnico de Startup

Total de entrevistados: 3
Edades: 22, 22, 23 años
Distritos: Barranco, Santiago de Surco, San Miguel
Fechas: 26 de abril de 2026

Características objetivas

• Participan directamente en reuniones de levantamiento bajo marcos ágiles (principalmente Scrum): 3/3 (100%)
• Utilizan herramientas colaborativas para reuniones y documentación (Google Meet/Zoom/Notion/Google Docs): 3/3 (100%)
• Gestionan el backlog con Jira como herramienta de trabajo recurrente: 3/3 (100%)
• Reportan problemas de ambigüedad o información incompleta al traducir necesidades del cliente a historias: 3/3 (100%)
• Evidencian impacto operativo en retrabajo y tiempo perdido por historias mal definidas: 3/3 (100%)

Características subjetivas

• Perciben que el proceso actual depende demasiado de la claridad humana durante la reunión: 3/3 (100%)
• Consideran que errores tempranos en requisitos afectan el sprint y generan desgaste del equipo: 3/3 (100%)
• Valoran la automatización de transcripción/resumen y apoyo en generación de historias para mejorar precisión: 3/3 (100%)
• Esperan que cualquier automatización mantenga un criterio de validación por parte del equipo: 2/3 (66%)

---

Segmento: Analista Funcional / Producto / Sistemas

Total de entrevistados: 3
Edades: 25, 28, 30 años
Distritos: Magdalena, Santiago de Surco
Fechas: 25 y 26 de abril de 2026

Características objetivas

• Actúan como puente entre necesidad de negocio y especificación técnica para desarrollo: 3/3 (100%)
• Utilizan plataformas de trazabilidad/documentación como Jira, Notion y Azure DevOps: 3/3 (100%)
• Transforman acuerdos de reunión en artefactos formales (historias de usuario, criterios y procesos): 3/3 (100%)
• Identifican como riesgo frecuente la falta de claridad del cliente o de stakeholders clave: 3/3 (100%)
• Enfrentan una alta carga de postprocesamiento para reducir ambigüedades antes de entregar al equipo: 3/3 (100%)

Características subjetivas

• Priorizan la trazabilidad y la consistencia del registro para evitar malentendidos entre áreas: 3/3 (100%)
• Consideran crítico gestionar expectativas de cliente y equipo para sostener la calidad del requisito: 3/3 (100%)
• Perciben que la ambigüedad en una historia puede escalar a errores de alto impacto operativo: 3/3 (100%)
• Reconocen valor en acelerar el análisis de reuniones si se preserva el rigor técnico y funcional: 3/3 (100%)

---

Conclusión general

El análisis muestra un patrón común en ambos segmentos: el principal cuello de botella no es la captura inicial de la reunión, sino la transformación de conversaciones en requisitos claros, trazables y accionables sin pérdida de contexto. La coincidencia en dolores (ambigüedad, retrabajo, sobrecarga de postprocesamiento e impacto en tiempos de sprint) válida la necesidad de una plataforma que asista en tiempo real con transcripción estructurada, síntesis y generación de historias de usuario. A la vez, los hallazgos refuerzan que la adopción será más sólida si la automatización se diseña como soporte al criterio profesional y no como reemplazo de la validación humana.

2.3. Need finding

2.3.1. User personas

Esta sección presenta los arquetipos de usuario de Reqs-AI, construidos a partir del análisis de entrevistas realizadas a profesionales del levantamiento de requisitos y del estudio del contexto operativo en startups y entornos enterprise. Los user personas sintetizan patrones de comportamiento, objetivos, frustraciones y necesidades clave que luego se conectan con los demás artefactos de need finding (User Task Matrix, Journey Map, Empathy Map y As-Is Scenario Mapping).

User persona del segmento de Líder Técnico de Startup

User persona del segmento de Analista de sistemas Enterprise

2.3.2. User Task Matrix

En este User Task Matrix se detallan las tareas que realizan los dos segmentos objetivos considerados en Reqs-AI: el Líder Técnico de Startup y el Analista de Sistemas Enterprise. Las tareas descritas corresponden al trabajo real de levantamiento, validación y transferencia de requisitos, y se ejecutan independientemente de la existencia de una herramienta de software.

TAREA	Diego Alvarado (Líder Técnico de Startup) - Frecuencia	Diego Alvarado (Líder Técnico de Startup) - Importancia	Analista Enterprise Genérico (Analista de Sistemas Enterprise) - Frecuencia	Analista Enterprise Genérico (Analista de Sistemas Enterprise) - Importancia
Agendar y preparar reuniones de levantamiento de requisitos con stakeholders	always	high	always	high
Escuchar, sintetizar y registrar necesidades funcionales y reglas de negocio durante la reunión	always	high	always	high
Identificar supuestos, restricciones, dependencias y casos de borde	always	high	always	high
Formular preguntas de aclaración para reducir ambiguedad en tiempo real	always	high	always	high
Transformar notas y acuerdos en historias de usuario y criterios de aceptación	always	high	always	high
Estandarizar la redacción de criterios en formato estructurado (por ejemplo, Gherkin)	sometimes	high	always	high
Validar entendimiento con desarrollo y QA antes de comprometer el sprint	always	high	always	high
Gestionar cambios de alcance y negociar prioridades con negocio cuando aparecen nuevas condiciones	sometimes	high	always	high
Mantener trazabilidad de acuerdos, versiones y decisiones para auditoría y control	sometimes	medium	always	high
Revisar grabaciones/minutas y depurar documentación para cerrar vacíos de información	sometimes	medium	always	high
Coordinar reuniones de seguimiento por dudas o contradicciones detectadas después del levantamiento	sometimes	medium	sometimes	high

La principal diferencia está en el enfoque operativo: el Líder Técnico de Startup prioriza velocidad de ejecución y alineación práctica para codificar cuanto antes, mientras que el Analista de Sistemas Enterprise prioriza estandarización, trazabilidad y control de riesgo. Por ello, en el segmento enterprise aumentan la frecuencia e importancia de actividades formales como redacción estructurada, revisión exhaustiva de evidencias y gestión de cambios bajo criterios de gobernanza.

2.3.3. User Journey Mapping

A continuación, se presentan los User Journey Maps As-Is de cada User Persona. Estos mapas permiten visualizar el recorrido end-to-end de ambos segmentos durante el levantamiento y documentación de requisitos en su situación actual (sin la solución), identificando fricciones, puntos de dolor y oportunidades de mejora en cada etapa del proceso.

• User Journey Map de Diego Alvarado (Líder Técnico de Startup):

  

• User Journey Map de Analista Enterprise Genérico (Analista de sistemas enterprise):

  

2.3.4. Empathy Mapping

Se elaboraron los Empathy Maps para los dos user persona priorizados: el Líder Técnico de Startup y el Analista de Sistemas Enterprise. Este proceso permitió profundizar en lo que cada segmento dice, piensa, hace, observa y escucha durante el levantamiento de requisitos, identificando sus principales pains y gains para orientar el diseño de una solución realmente alineada con su contexto operativo.

Líder Técnico de Startup

Analista de sistemas enterprise

2.3.5. As-is Scenario Mapping

El equipo elaboró los As-Is Scenario Mapping mediante preparación, lluvia de ideas individual y revisión conjunta por segmento. Con base en entrevistas y artefactos previos, se definieron las fases del recorrido actual de cada User Persona en las filas Steps, Doing, Thinking y Feeling, representando la situación actual sin la solución propuesta.

Además, se identificaron áreas positivas, negativas y blank áreas para ubicar con precisión los puntos de mayor impacto operativo y emocional en cada segmento.

As-Is Scenario Mapping de Diego Alvarado (Líder Técnico de Startup)

As-Is Scenario Mapping de Analista Enterprise Genérico (Analista de Sistemas Enterprise)

2.4. Ubiquitous Language

En esta sección se presenta el glosario del dominio de negocio de Reqs-AI, redactado con términos en inglés (y su equivalente en español) para mantener una comunicación consistente y sin ambigüedades entre analistas, líderes técnicos, negocio, QA y demás stakeholders. Este lenguaje ubicuo se centra en el proceso de levantamiento, validación y gobernanza de requisitos en entornos startup y enterprise.

Term	Equivalente	Definición
Stakeholder	Interesado / Parte interesada	Persona o área que influye, decide o se ve impactada por un requerimiento del proyecto.
Requirement	Requerimiento	Necesidad del negocio o del usuario que debe quedar descrita de forma clara para guiar la implementación y validación.
Requirement Elicitation	Levantamiento de requerimientos	Proceso de recopilar información con el cliente y actores clave para entender qué problema se debe resolver.
Discovery Session	Sesión de descubrimiento	Reunión inicial en la que se explora el problema, objetivos, contexto y restricciones del requerimiento.
Business Rule	Regla de negocio	Condición o política del negocio que determina cómo debe comportarse un proceso o una funcionalidad.
Acceptance Criteria	Criterios de aceptación	Condiciones verificables que definen cuándo un requerimiento se considera correctamente cumplido.
Edge Case	Caso borde	Situación excepcional o poco frecuente que puede afectar el resultado esperado y debe ser considerada en el análisis.
Assumption	Supuesto	Condición que se da por cierta temporalmente cuando no existe confirmación explícita en la reunión.
Dependency	Dependencia	Elemento externo (área, dato, aprobación o acceso) del cual depende la ejecución de un requerimiento.
Constraint	Restricción	Límite de negocio, tiempo, regulación o presupuesto que condiciona cómo se puede ejecutar una solución.
Scope	Alcance	Conjunto de entregables y límites funcionales acordados para una iniciativa o requerimiento.
Scope Change	Cambio de alcance	Modificación posterior del alcance originalmente acordado que impacta tiempo, costo o prioridades.
Decision Maker	Decisor	Stakeholder con autoridad final para aprobar, rechazar o redefinir un requerimiento.
Approval	Aprobación	Confirmación formal de que un requerimiento y sus criterios están listos para pasar a ejecución.
Requirement Traceability	Trazabilidad de requerimientos	Capacidad de seguir un requerimiento desde su origen hasta su validación final, incluyendo cambios y decisiones.
Minutes of Meeting	Acta de reunión	Registro formal de acuerdos, pendientes y decisiones tomadas durante una sesión con stakeholders.
Clarification Meeting	Reunión de aclaración	Reunión adicional convocada para resolver ambigüedades o contradicciones detectadas después del levantamiento inicial.
Rework	Retrabajo	Esfuerzo adicional causado por requisitos incompletos, ambiguos o mal interpretados en etapas previas.
Requirement Governance	Gobernanza de requerimientos	Conjunto de prácticas para asegurar estandarización, calidad, control de cambios y cumplimiento en la gestión de requerimientos.
Business Alignment	Alineación de negocio	Grado en que todos los stakeholders comparten la misma interpretación sobre el problema y la solución esperada.

Capítulo III: Requirements Specification

3.1. To-Be Scenario Mapping

Para elaborar el To-Be Scenario Mapping, el equipo partió de los recorridos As-Is de ambos segmentos y proyectó un flujo mejorado con apoyo de Reqs-AI. El objetivo fue reducir ambigüedad, retrabajo y carga manual, manteniendo las mismas fases del proceso para comparar claramente los cambios en las filas Steps, Doing, Thinking y Feeling.

El escenario To-Be propone sesiones de levantamiento con mayor validación en tiempo real, mejor estandarización de criterios de aceptación y trazabilidad más sólida para la transferencia hacia desarrollo y QA.

To-Be Scenario Mapping de Diego Alvarado (Líder Técnico de Startup)

To-Be Scenario Mapping de Analista Enterprise Genérico (Analista de Sistemas Enterprise)

3.2. User Stories

El siguiente inventario detalla las funcionalidades del sistema. Nótese la diferenciación entre US (User Stories - Funcionalidades de interfaz/usuario) y TS (Technical Stories - API y Arquitectura backend).

ID	Título de la Historia	Descripción (Como... quiero... para...)	Criterios de Aceptación (BDD)	Épica Asociada
EP00	Landing Page y Captación de Leads	Landing page pública orientada a convertir visitantes en usuarios mediante la exposición de la propuesta de valor y beneficios por segmentos B2B.	--	--
US01	Visualizar Propuesta de Valor (Hero)	Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta.	Feature: Landing Page - Hero Section Scenario: Carga inicial y visibilidad de conversión (Happy Path) Given un visitante que accede a la URL principal de Reqs-AI When la página carga completamente Then visualiza un título claro sobre la automatización de requisitos con IA And un llamado a la acción (CTA) principal visible sin hacer scroll para iniciar el registro Scenario: Acceso desde dispositivo móvil (Edge Case - Responsive) Given un visitante que accede desde un dispositivo móvil (viewport inferior a 768px) When la página carga completamente Then el Hero adapta su diseño al ancho de pantalla sin perder legibilidad And el CTA principal sigue visible y pulsable sin necesidad de hacer scroll Scenario: Visitante ya autenticado (Edge Case) Given un usuario que ya tiene sesión activa en la plataforma When accede a la URL de la landing page Then el sistema lo redirige directamente al panel principal de su organización And no muestra la landing para evitar confusión innecesaria	EP00
US02	Explorar Casos de Uso por Segmento	Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo.	Feature: Landing Page - Segmentación Interactiva Scenario Outline: Alternar entre perfiles de usuario Given un visitante en la sección de 'Construido para tu equipo' When hace clic en la pestaña del perfil <Perfil> Then el contenido dinámico se actualiza sin recargar la página And muestra el beneficio principal <Beneficio> asociado a ese perfil Examples: Perfil Beneficio Consultoras de Software Reducción de horas facturables en análisis y toma de requerimientos. Product Managers / Startups Integración directa con Jira y adopción de metodologías ágiles.	EP00
US03	Visualizar Planes y Precios	Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta.	Feature: Landing Page - Pricing Scenario: Comparativa de planes con toggle (Happy Path) Given un visitante en la sección de Precios When alterna el interruptor entre facturación 'Mensual' y 'Anual' Then los precios de los planes de pago se actualizan dinámicamente mostrando el descuento aplicado And cada tarjeta de plan contiene un CTA que redirige al formulario de registro correspondiente Scenario: CTA de plan gratuito no solicita datos de pago (Edge Case) Given un visitante interesado en el Plan Gratuito When hace clic en el CTA correspondiente Then es redirigido al formulario de registro sin que se le solicite ningún dato de tarjeta ni método de pago Scenario: Visualización sin interacción con el toggle (Edge Case) Given un visitante que no interactúa con el toggle de facturación When llega a la sección de precios Then los planes se muestran en modo mensual por defecto And cada tarjeta expone precio, límites principales y características clave de forma legible	EP00
EP01	Autenticación y Seguridad	Gestión de acceso y protección de identidad para los usuarios de Reqs-AI, garantizando que solo personal autorizado acceda a la plataforma y su historial.	--	--
US04	Registro de cuenta	Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos.	Feature: Registro de cuenta Scenario: Registro exitoso (Happy Path) Given un visitante en la página de registro When ingresa un correo válido y una contraseña segura Then el sistema crea la cuenta en estado 'pendiente de verificación' And envía un correo con el enlace de activación Scenario Outline: Validaciones de registro (Unhappy Paths) Given un visitante en la página de registro When ingresa datos con el problema <Problema> Then el sistema rechaza el registro indicando <Mensaje> Examples: Problema Mensaje El correo ya está registrado en otra cuenta El correo ingresado ya se encuentra en uso. La contraseña tiene menos de 8 caracteres La contraseña debe tener al menos 8 caracteres. El formato del correo es inválido Ingresa un correo electrónico válido.	EP01
US05	Verificación de correo	Como usuario con cuenta pendiente de activación, quiero verificar mi correo haciendo clic en el enlace que recibí, para activar mi cuenta y empezar a trabajar en la plataforma.	Feature: Verificación de correo Scenario: Verificación exitosa (Happy Path) Given un usuario con cuenta pendiente de activación When hace clic en el enlace de verificación recibido por correo Then el sistema activa la cuenta And redirige al usuario al inicio de sesión Scenario: Enlace expirado o inválido (Unhappy Path) Given un usuario con un enlace de verificación When el enlace fue usado previamente o ya expiró su vigencia Then el sistema muestra un error de enlace inválido And ofrece la opción de reenviar un nuevo correo de verificación Scenario: Reenvío de enlace de verificación (Flujo Alternativo) Given un usuario cuyo enlace de verificación ha expirado When solicita el reenvío del enlace desde la notificación de error Then el sistema invalida el enlace anterior And envía un nuevo enlace válido con un tiempo de expiración renovado	EP01
US06	Inicio de sesión	Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización.	Feature: Inicio de sesión Scenario: Autenticación exitosa (Happy Path) Given un usuario con cuenta activa When ingresa sus credenciales correctas Then el sistema le concede acceso And lo redirige al panel principal de su última organización activa Scenario Outline: Fallos de autenticación (Unhappy Paths) Given un usuario intentando iniciar sesión When ocurre la situación <Situacion> Then el sistema deniega el acceso con el mensaje <Error> Examples: Situacion Error Contraseña incorrecta Credenciales inválidas. La cuenta aún no ha sido verificada Debes verificar tu correo antes de iniciar sesión. Demasiados intentos fallidos consecutivos Cuenta bloqueada temporalmente por seguridad.	EP01
US07	Recuperación de contraseña	Como usuario registrado que no recuerda su contraseña, quiero recibir un enlace de restablecimiento en mi correo, para recuperar el acceso a mi cuenta sin perder mi historial de trabajo.	Feature: Recuperación de contraseña Scenario: Solicitar recuperación (Happy Path) Given un usuario que olvidó su contraseña When ingresa su correo en el formulario de recuperación Then el sistema envía un enlace de restablecimiento And muestra un mensaje genérico de confirmación por seguridad Scenario: Prevenir enumeración de usuarios (Edge Case - Seguridad) Given un visitante malintencionado When ingresa un correo que no existe en el sistema Then el sistema no revela que el correo es inexistente And muestra el mismo mensaje genérico de confirmación Scenario: Enlace de restablecimiento expirado al usarlo (Unhappy Path) Given un usuario que recibió el enlace de restablecimiento en su correo When intenta acceder a él después de su período de validez (ej. pasadas 24 horas) Then el sistema rechaza el token indicando que expiró And ofrece la opción de solicitar un nuevo enlace de restablecimiento	EP01
US08	Cerrar sesión	Como usuario autenticado, quiero cerrar mi sesión de forma explícita, para asegurarme de que nadie más pueda acceder a mi cuenta desde el mismo dispositivo.	Feature: Cerrar sesión Scenario: Logout exitoso (Happy Path) Given un usuario autenticado When selecciona la opción 'Cerrar sesión' Then el sistema invalida el token de sesión And redirige al usuario a la pantalla de inicio de sesión Scenario: Cierre de sesión con captura activa (Edge Case) Given un usuario con una sesión de captura en curso When intenta cerrar sesión Then el sistema muestra una advertencia de que hay una sesión activa And requiere confirmar antes de proceder	EP01
US09	Aceptar términos y política de privacidad	Como nuevo usuario completando el registro, quiero leer y aceptar los términos de uso y la política de privacidad antes de activar mi cuenta, para entender cómo se usan mis datos y las grabaciones de audio antes de comenzar a usar el servicio.	Feature: Consentimiento de privacidad Scenario: Aceptar términos durante el registro (Happy Path) Given un visitante completando el formulario de registro When marca la casilla de aceptación y envía el formulario Then el sistema registra la fecha y versión del consentimiento otorgado And procede con la creación de la cuenta Scenario: Intentar registrarse sin aceptar términos (Unhappy Path) Given un visitante en el formulario de registro When intenta crear la cuenta sin marcar la casilla de aceptación Then el sistema bloquea el envío And resalta la casilla indicando que es obligatoria	EP01
US10	Editar perfil de usuario	Como usuario autenticado, quiero actualizar mi nombre y foto de perfil, para que mis compañeros de equipo me identifiquen correctamente en los registros de actividad de las sesiones.	Feature: Editar perfil Scenario: Actualizar nombre y foto (Happy Path) Given un usuario autenticado en su perfil When modifica su nombre y sube una imagen válida Then el sistema actualiza los datos And refleja los cambios en todos los proyectos donde el usuario aparece Scenario: Formato de imagen no soportado (Unhappy Path) Given un usuario editando su perfil When sube un archivo que no es imagen (ej. PDF) Then el sistema rechaza el archivo And muestra un mensaje indicando los formatos aceptados Scenario: Imagen supera el tamaño máximo permitido (Unhappy Path) Given un usuario editando su perfil When intenta subir una imagen que excede el límite de tamaño (ej. mayor de 5 MB) Then el sistema rechaza el archivo antes de procesarlo And muestra el tamaño máximo permitido y los formatos válidos	EP01
EP02	Organizaciones	Gestión de espacios de trabajo independientes para separar la información de diferentes empresas o equipos, garantizando que cada organización acceda únicamente a sus propios datos.	--	--
US11	Crear organización	Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado.	Feature: Crear organización Scenario: Creación exitosa (Happy Path) Given un usuario autenticado sin organización When crea una organización con un nombre válido Then el sistema genera el espacio de trabajo And asigna al usuario el rol inamovible de 'Propietario' Scenario: Nombre de organización vacío (Unhappy Path) Given un usuario creando una organización When deja el nombre en blanco Then el sistema bloquea la creación exigiendo un nombre obligatorio	EP02
US12	Editar organización	Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia.	Feature: Editar organización Scenario: Actualizar datos (Happy Path) Given el Propietario de una organización When modifica el nombre y guarda los cambios Then la organización actualiza sus datos en toda la plataforma Scenario: Intento de edición sin permisos (Unhappy Path) Given un miembro regular de la organización When intenta acceder a la configuración de la organización Then el sistema oculta o bloquea la opción por falta de privilegios	EP02
US13	Cambiar de organización	Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo.	Feature: Cambiar de organización Scenario: Cambio exitoso de contexto (Happy Path) Given un usuario que pertenece a múltiples organizaciones When selecciona una organización distinta desde el menú Then el sistema recarga el contexto de trabajo And muestra únicamente los proyectos de la organización seleccionada Scenario: Eliminación concurrente (Edge Case) Given un usuario intentando cambiar a la Organización B When el propietario de la Organización B lo elimina en ese mismo instante Then el sistema deniega el acceso y lo devuelve a su organización actual	EP02
US14	Política de retención de audios	Como Propietario de la organización, quiero configurar la eliminación automática de los archivos de audio originales X días después de procesarse, para cumplir con las políticas de privacidad y confidencialidad corporativas.	Feature: Política de retención de audios Scenario: Eliminación automática al cumplir plazo (Happy Path) Given una organización con la retención configurada en 7 días When se cumple el plazo desde que un audio fue procesado Then el sistema elimina permanentemente el archivo de audio físico And conserva únicamente las historias generadas en texto Scenario: Intentar acceder a un audio eliminado (Unhappy Path) Given un audio que ya superó su periodo de retención y fue purgado When un usuario intenta reproducirlo o descargarlo desde el historial Then el sistema muestra un aviso de que el archivo fue eliminado por políticas de privacidad corporativa	EP02
EP03	Suscripción y Facturación	Gestión de planes y límites de uso del sistema basados en un modelo de suscripción SaaS. Épica de baja prioridad — no entra en los primeros sprints.	--	--
US15	Plan gratuito automático	Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme.	Feature: Plan gratuito automático Scenario: Asignación por defecto (Happy Path) Given un usuario que acaba de crear una nueva organización When ingresa a su panel por primera vez Then el sistema le asigna el 'Plan Gratuito' And habilita las cuotas iniciales sin solicitar método de pago Scenario: Cuota de sesiones del plan gratuito agotada (Edge Case) Given una organización en Plan Gratuito que ya consumió su límite mensual de sesiones When un analista intenta iniciar una nueva sesión de captura Then el sistema bloquea la acción And muestra un aviso invitando a actualizar al Plan Pro para continuar Scenario: Intento de crear segunda organización en plan gratuito (Edge Case) Given un usuario en Plan Gratuito con una organización activa When intenta crear una segunda organización Then el sistema bloquea la creación And informa que el Plan Gratuito está limitado a un único espacio de trabajo	EP03
US16	Suscripción al plan Pro	Como Propietario de una organización en plan gratuito, quiero contratar el plan Pro, para acceder a sesiones ilimitadas, captura en tiempo real e integración con Jira.	Feature: Suscripción al plan Pro Scenario: Upgrade de plan exitoso (Happy Path) Given el Propietario de una organización en plan gratuito When ingresa un método de pago válido y contrata el Plan Pro Then los límites de la organización se expanden inmediatamente And se emite la factura correspondiente Scenario: Tarjeta rechazada (Unhappy Path) Given un Propietario intentando hacer upgrade When la pasarela de pagos rechaza la tarjeta por fondos insuficientes Then el sistema mantiene el plan gratuito And notifica el error de pago al usuario	EP03
US17	Suscripción al plan Equipo	Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno.	Feature: Suscripción al plan Equipo Scenario: Upgrade a Equipo exitoso (Happy Path) Given el Propietario de una organización en Plan Pro When ingresa un método de pago válido y contrata el Plan Equipo Then el plan se actualiza de inmediato And se habilitan la gestión avanzada de roles y los asientos ilimitados de miembros And se emite la factura correspondiente al nuevo plan Scenario: Intento de upgrade sin plan Pro previo (Unhappy Path) Given el Propietario de una organización en Plan Gratuito When intenta contratar el Plan Equipo directamente Then el sistema bloquea la operación And lo redirige al flujo de upgrade al Plan Pro como paso previo requerido Scenario: Pago rechazado durante upgrade (Unhappy Path) Given el Propietario intentando contratar el Plan Equipo When la pasarela de pagos rechaza el método de pago Then el sistema mantiene el Plan Pro activo sin cambios And notifica el error de pago solicitando actualizar el método de facturación	EP03
US18	Cancelación de suscripción	Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio.	Feature: Cancelación de suscripción Scenario: Cancelar antes de renovación (Happy Path) Given el Propietario de una suscripción paga activa When cancela la suscripción desde el panel Then el sistema desactiva la auto-renovación And mantiene los beneficios premium hasta el final del ciclo de facturación actual Scenario: Reactivar suscripción antes del vencimiento (Flujo Alternativo) Given una suscripción en estado CANCELING con días de acceso premium restantes When el Propietario decide mantener el servicio Then el sistema restaura la auto-renovación And la suscripción vuelve al estado ACTIVE sin interrupciones ni cobros adicionales Scenario: Intentar cancelar un plan gratuito (Edge Case) Given el Propietario de una organización en Plan Gratuito When accede al panel de cancelación Then el sistema informa que el Plan Gratuito no genera cargos And oculta la opción de cancelación para ese plan	EP03
US19	Ver estado del plan y consumo	Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo.	Feature: Ver estado del plan y consumo Scenario: Visualización de cuotas (Happy Path) Given el Propietario de la organización When ingresa a la sección de facturación Then visualiza una barra de progreso con el consumo actual de sesiones frente al límite de su plan Scenario: Límite alcanzado (Edge Case) Given una organización que alcanzó exactamente el 100% de su límite When el usuario visualiza el estado Then el sistema muestra una alerta destacada invitando al upgrade Scenario: Servicio de facturación no disponible (Unhappy Path - Sistema) Given el Propietario accediendo a la sección de facturación When el servicio de datos de suscripción falla temporalmente Then el sistema muestra un mensaje de error con opción de reintento And no expone datos parciales o incorrectos del plan al usuario	EP03
EP04	Gestión de Proyectos	Creación, configuración y ciclo de vida de los proyectos por cliente, incluyendo la carga de conocimiento previo que permite a la IA generar historias más precisas.	--	--
US20	Crear proyecto	Como analista, quiero registrar un proyecto asociado a un cliente específico, para organizar y separar todas las sesiones de levantamiento de requisitos de ese cliente.	Feature: Crear proyecto Scenario: Creación de proyecto válida (Happy Path) Given un analista con permisos para crear proyectos en la organización When registra un nuevo proyecto indicando el nombre del cliente Then el proyecto aparece en el listado activo de la organización Scenario: Proyecto duplicado (Unhappy Path) Given un usuario creando un proyecto When ingresa un nombre que ya existe activo en la misma organización Then el sistema sugiere usar un nombre distinto para evitar confusiones	EP04
US21	Cargar documentos del cliente	Como analista, quiero subir documentos del cliente (PDF, Word) al proyecto, para que el sistema extraiga y clasifique automáticamente su contenido en glosario, restricciones y contexto general, enriqueciendo así las historias que se generen en sesiones futuras.	Feature: Cargar documentos del cliente Scenario: Carga y clasificación exitosa (Happy Path) Given un usuario configurando un proyecto When sube un documento PDF o Word válido Then el sistema extrae el texto del documento And clasifica el contenido en glosario, restricciones y contexto general And lo incorpora a la base de conocimiento del proyecto para futuras sesiones Scenario Outline: Restricciones de carga documental (Unhappy Paths) Given un usuario intentando subir documentos de contexto When ocurre el escenario <Fallo> Then el sistema rechaza el archivo indicando <Error> Examples: Fallo Error El archivo es un ejecutable (.exe) Solo se permiten documentos de texto o PDF. El archivo excede los 50MB El documento es demasiado pesado.	EP04
US22	Configurar perfil técnico del proyecto	Como analista, quiero registrar las tecnologías que usa el equipo del cliente y los tipos de usuarios del sistema, para que los criterios de aceptación generados sean aplicables al contexto real del proyecto.	Feature: Configurar perfil técnico del proyecto Scenario: Guardar perfil técnico (Happy Path) Given un analista configurando el proyecto When define que el stack es 'React + Node' y guarda Then el sistema utiliza esta instrucción como prompt base para la generación de criterios técnicos en las historias de usuario Scenario: Campo de stack vacío al guardar (Unhappy Path) Given un analista en el formulario del perfil técnico When intenta guardar sin haber definido ningún stack tecnológico Then el sistema bloquea el guardado And señala que el campo es obligatorio para la generación contextualizada de criterios Scenario: Actualizar stack con historias ya generadas (Edge Case) Given un proyecto que ya tiene historias generadas con un stack previo When el analista actualiza el stack tecnológico Then el sistema guarda la nueva configuración para futuras sesiones And advierte que las historias existentes reflejan el stack anterior y no se actualizarán automáticamente	EP04
US23	Agregar término al glosario manualmente	Como analista, quiero agregar términos del negocio del cliente directamente al glosario del proyecto sin necesidad de subir un documento, para enriquecer el vocabulario de la IA cuando el cliente solo transmite su conocimiento de forma oral.	Feature: Glosario manual del proyecto Scenario: Agregar término exitosamente (Happy Path) Given un miembro configurando el glosario de un proyecto When ingresa un término y su definición y los guarda Then el término queda disponible para ser utilizado como contexto en futuras sesiones de captura Scenario: Intentar guardar término sin definición (Unhappy Path) Given un miembro en el formulario del glosario When ingresa solo el término sin su definición Then el sistema bloquea el guardado And exige completar la definición antes de continuar Scenario: Término duplicado en el glosario (Unhappy Path) Given un miembro agregando términos al glosario del proyecto When ingresa un término idéntico (ignorando mayúsculas) a uno ya registrado Then el sistema detecta la duplicidad And ofrece la opción de editar la definición del término existente en lugar de crear uno nuevo	EP04
US24	Registrar restricción técnica manualmente	Como analista, quiero registrar restricciones técnicas del cliente (ej. 'sin uso de cookies de terceros', 'máximo 3 segundos de latencia') directamente en el proyecto, para que la IA las considere al generar los criterios de aceptación sin necesidad de incluirlas en cada sesión.	Feature: Restricciones técnicas del proyecto Scenario: Registrar restricción exitosamente (Happy Path) Given un miembro configurando las restricciones del proyecto When ingresa una restricción técnica y la guarda Then la restricción queda registrada And se incorpora al contexto de generación de historias en futuras sesiones Scenario: Restricción duplicada (Unhappy Path) Given un miembro agregando restricciones When ingresa una restricción idéntica a una ya existente en el proyecto Then el sistema alerta sobre la duplicidad And ofrece la opción de editar la existente en lugar de crear una nueva	EP04
US25	Editar proyecto	Como analista, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente.	Feature: Editar proyecto Scenario: Modificar datos del proyecto (Happy Path) Given un analista con permisos de administración del proyecto When cambia el nombre o la descripción del proyecto Then los cambios se reflejan inmediatamente en el panel del equipo Scenario: Nombre vacío al guardar (Unhappy Path) Given un analista editando el nombre del proyecto When borra el nombre por completo e intenta guardar Then el sistema bloquea el guardado And exige que el nombre del proyecto sea obligatorio Scenario: Nombre duplicado en la organización (Unhappy Path) Given un analista renombrando un proyecto When ingresa un nombre igual al de otro proyecto activo en la misma organización Then el sistema alerta sobre la colisión de nombres And sugiere usar un sufijo o nombre alternativo para diferenciarlos	EP04
US26	Archivar proyecto	Como analista, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas.	Feature: Archivar proyecto Scenario: Archivar proyecto finalizado (Happy Path) Given un proyecto activo When el administrador lo archiva Then el proyecto se oculta de las vistas principales pero mantiene su historial intacto Scenario: Operaciones en proyecto archivado (Edge Case) Given un proyecto en estado archivado When un usuario intenta iniciar una nueva sesión de captura Then el sistema bloquea la acción hasta que el proyecto sea desarchivado	EP04
US27	Proyecto de demostración automático	Como nuevo usuario que acaba de registrarse, quiero encontrar un proyecto de demostración pre-cargado con audios e historias ya generadas, para entender inmediatamente el valor de la plataforma sin tener que grabar mi propia reunión primero.	Feature: Proyecto Sandbox de Demo Scenario: Cargar datos de demostración en nueva cuenta (Happy Path) Given un usuario que acaba de registrarse exitosamente en la plataforma When accede a su organización por primera vez Then el sistema genera e inserta un proyecto de demostración pre-poblado (con audios, historias y transcripciones de ejemplo) And lo marca visualmente como 'Sandbox / Demo' para que el usuario experimente de inmediato Scenario: Restaurar proyecto de demostración (Flujo Alternativo) Given un usuario que eliminó su proyecto de demostración When hace clic en 'Restaurar datos de prueba' desde la configuración Then el sistema vuelve a clonar el proyecto de ejemplo en su espacio de trabajo	EP04
EP05	Colaboración y Roles	Gestión de roles personalizados con permisos configurables y administración de los miembros del equipo dentro de la organización y sus proyectos. El Propietario es el único rol fijo del sistema — es quien creó la organización, tiene todos los permisos y es el responsable del contrato. Todos los demás roles son creados y configurados por el Propietario.	--	--
US28	Invitar miembro a la organización	Como Administrador de la organización, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización.	Feature: Invitar miembro Scenario: Enviar invitación (Happy Path) Given un usuario con permisos de gestión de equipo When envía una invitación a un correo válido Then el invitado recibe el correo con el enlace de acceso And aparece en estado 'Pendiente' en el panel Scenario Outline: Fallos de invitación (Unhappy Paths) Given un administrador invitando a un usuario When comete el error <Error_Inv> Then la invitación falla indicando <Aviso> Examples: Error_Inv Aviso El correo ya pertenece a la organización El usuario ya es miembro del equipo. El correo ya tiene una invitación pendiente Ya existe una invitación enviada a este correo.	EP05
US29	Crear rol personalizado	Como Propietario de la organización, quiero crear un rol con un nombre definido por mi equipo, para representar una función real dentro de la organización en lugar de usar etiquetas genéricas del sistema.	Feature: Crear rol personalizado Scenario: Rol creado exitosamente (Happy Path) Given el Propietario de la organización When crea el rol 'QA Lead' con un nombre único Then el nuevo rol queda disponible para ser asignado a cualquier miembro Scenario: Nombre de rol duplicado (Unhappy Path) Given el Propietario creando un nuevo rol When ingresa un nombre que ya existe entre los roles de la organización Then el sistema bloquea la creación And muestra que el nombre ya está en uso Scenario: Nombre de rol vacío (Unhappy Path) Given el Propietario en el formulario de creación de rol When deja el campo de nombre vacío e intenta guardar Then el sistema bloquea la acción And señala que el nombre del rol es obligatorio	EP05
US30	Asignar permisos a un rol	Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales.	Feature: Asignar permisos a un rol Scenario: Configurar permisos (Happy Path) Given el Propietario configurando un rol When activa los permisos de 'Crear Sesiones' y 'Aprobar Historias' Then todos los usuarios con ese rol adquieren dichas capacidades inmediatamente Scenario: Revocar todos los permisos de un rol (Edge Case) Given el Propietario editando los permisos de un rol existente When intenta desactivar absolutamente todos los permisos disponibles Then el sistema bloquea la acción And advierte que un rol debe conservar al menos un permiso para ser funcional Scenario: Cambio de permisos con miembros en sesión activa (Edge Case) Given el Propietario revocando el permiso 'Crear Sesiones' de un rol que tienen analistas con sesiones abiertas When confirma el cambio Then el sistema aplica la restricción de inmediato And notifica en tiempo real a los afectados que ya no pueden iniciar nuevas sesiones	EP05
US31	Asignar rol a un miembro	Como Administrador de la organización, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación.	Feature: Asignar rol a un miembro Scenario: Cambio de rol exitoso (Happy Path) Given un Administrador de la organización When cambia el rol del Usuario A de 'Lector' a 'Editor' Then el Usuario A obtiene acceso a las herramientas de edición en su próxima navegación Scenario: Intentar cambiar el rol del Propietario (Edge Case - Seguridad) Given un Administrador de la organización When intenta asignar un rol diferente al usuario Propietario de la cuenta Then el sistema bloquea la acción And recuerda que el rol de Propietario es fijo e intransferible Scenario: Reasignar a rol con permisos reducidos (Unhappy Path - Confirmación) Given un Administrador que va a reducir los permisos de un miembro activo When cambia su rol a uno con menos privilegios Then el sistema solicita confirmación antes de aplicar el cambio And notifica al miembro afectado que sus permisos han sido actualizados	EP05
US32	Editar permisos de un rol existente	Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades.	Feature: Editar permisos de un rol existente Scenario: Propagación de permisos (Happy Path) Given un rol asignado a 5 usuarios When el Propietario revoca el permiso de 'Exportar' Then los 5 usuarios pierden la capacidad de exportar instantáneamente sin necesidad de re-login Scenario: Editar rol sin miembros asignados (Edge Case) Given un rol personalizado sin ningún miembro asignado actualmente When el Propietario agrega permisos de 'Crear Sesiones' al rol Then el sistema guarda los nuevos permisos sin ningún efecto inmediato And los permisos se aplicarán cuando el rol sea asignado a un miembro Scenario: Intentar dejar rol sin permisos (Unhappy Path) Given el Propietario editando permisos de un rol When revoca el último permiso activo del rol Then el sistema bloquea la acción And exige conservar al menos un permiso por integridad del rol	EP05
US33	Eliminar un rol	Como Propietario de la organización, quiero eliminar un rol que ya no corresponde a ninguna función activa del equipo, para mantener la lista de roles ordenada y evitar asignaciones incorrectas.	Feature: Eliminar un rol Scenario: Eliminar rol sin uso (Happy Path) Given un rol personalizado que no tiene usuarios asignados When el Propietario lo elimina Then el rol desaparece definitivamente de la organización Scenario: Intento de eliminar rol en uso (Unhappy Path) Given un rol que está asignado a al menos un miembro When el Propietario intenta eliminarlo Then el sistema bloquea la eliminación And exige reasignar a esos miembros a otro rol antes de proceder	EP05
US34	Remover miembro de la organización	Como Administrador de la organización, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo.	Feature: Remover miembro de la organización Scenario: Remoción exitosa (Happy Path) Given un administrador de equipo When remueve al Usuario B de la organización Then el Usuario B pierde acceso inmediatamente a todos los proyectos de esa organización Scenario: Intento de remover al Propietario (Edge Case - Seguridad) Given un administrador de equipo When intenta remover al Propietario original de la cuenta Then el sistema bloquea la acción indicando que el rol de Propietario es intransferible e irremovible	EP05
US35	Transferir propiedad de la organización	Como Propietario de la organización, quiero transferir la propiedad a otro miembro activo, para poder desvincularme del equipo sin dejar la cuenta sin responsable cuando abandono el proyecto.	Feature: Transferencia de propiedad Scenario: Transferir propiedad exitosamente (Happy Path) Given el Propietario actual de la organización When selecciona a un miembro activo y confirma la transferencia Then el miembro seleccionado asume el rol de Propietario And el Propietario anterior pasa a tener un rol regular configurable Scenario: Intentar transferir a un miembro pendiente de invitación (Unhappy Path) Given el Propietario intentando transferir la propiedad When selecciona un usuario que aún no aceptó su invitación Then el sistema bloquea la transferencia And exige que el destinatario sea un miembro activo de la organización	EP05
EP06	Captura en Tiempo Real	Funcionalidad principal del producto que procesa audio en vivo para generar historias de usuario de forma automática mientras la reunión con el cliente ocurre. Las sesiones requieren un proyecto existente.	--	--
US36	Iniciar sesión de captura en vivo	Como analista, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US20.	Feature: Captura en vivo Scenario: Iniciar captura exitosamente (Happy Path) Given que el analista tiene permisos y el proyecto está activo When inicia la captura de audio en vivo Then la sesión cambia a estado 'activa' y comienza a registrar el habla Scenario Outline: Validaciones al intentar iniciar captura (Unhappy Paths) Given que el analista intenta iniciar una sesión de captura en vivo When ocurre la situación <Condicion> Then el sistema impide el inicio de la sesión And muestra el mensaje <Mensaje_Error> Examples: Condicion Mensaje_Error El navegador no tiene permisos de micrófono Debes otorgar permisos de micrófono para continuar. El usuario tiene un rol sin permisos de creación No tienes permisos para crear sesiones en este proyecto. El proyecto seleccionado se encuentra archivado El proyecto está archivado y no admite nuevas sesiones. Scenario: Pérdida de conexión al iniciar (Unhappy Path - Flujo Alternativo) Given que el analista inicia la captura When se pierde la conexión a internet antes de confirmar con el servidor Then el sistema cancela la creación de la sesión And notifica al analista que verifique su conexión	EP06
US37	Generación automática de historias	Como analista en sesión activa, quiero que el sistema convierta automáticamente lo que dice el cliente en historias de usuario con criterios de aceptación, para obtener un backlog estructurado al finalizar la reunión sin necesidad de documentar después.	Feature: Generación automática de historias Scenario: Extraer historia desde un requisito claro (Happy Path) Given una sesión activa When el sistema detecta un requisito válido en la intervención del cliente Then genera una historia de usuario con criterios de aceptación And la agrega al backlog de la sesión en tiempo real Scenario: Manejo de audio incomprensible o ruido (Unhappy Path) Given una sesión activa When el cliente habla de temas irrelevantes o hay ruido de fondo Then el sistema ignora la intervención And no genera historias vacías ni interrumpe la captura Scenario: Intervención larga con múltiples requisitos (Edge Case) Given una sesión activa When el cliente menciona varios requerimientos distintos en una sola intervención continua Then el sistema separa lógicamente los temas And crea una historia individual por cada requerimiento detectado	EP06
US38	Descartar historia durante sesión en vivo	Como analista con una sesión activa, quiero descartar una historia recién generada indicando un motivo, para mantener el backlog de la sesión limpio en tiempo real sin interrumpir la reunión.	Feature: Descarte de historia en vivo Scenario: Descartar historia en sesión activa (Happy Path) Given una historia recién generada en el backlog de la sesión activa When el analista la descarta ingresando un motivo válido Then la historia se oculta del backlog activo inmediatamente And queda registrada en el historial de la sesión con su motivo Scenario Outline: Validaciones al descartar (Unhappy Paths) Given que el analista intenta descartar una historia When el formulario presenta el problema <Problema> Then el sistema bloquea el descarte And solicita la corrección con el mensaje <Mensaje> Examples: Problema Mensaje El campo de motivo está completamente vacío Debes ingresar un motivo para descartar la historia. El motivo excede el límite de caracteres (ej. 500) El motivo es demasiado largo. Scenario: Descartar historia ya descartada simultáneamente (Edge Case - Concurrencia) Given dos analistas con la misma sesión activa abierta en paralelo When el analista A descarta una historia y el analista B intenta descartar la misma instantes después Then el sistema rechaza el intento del analista B And refresca su vista indicando que la historia ya fue descartada	EP06
US39	Descartar historia en revisión post-sesión	Como analista revisando el backlog después de cerrar la sesión, quiero descartar una historia indicando un motivo, para depurar el resultado final antes de que el equipo de desarrollo lo utilice.	Feature: Descarte de historia en revisión Scenario: Descartar historia en etapa de revisión (Happy Path) Given una sesión cerrada con historias pendientes de revisión When el analista descarta una historia ingresando un motivo válido Then la historia pasa al estado 'Descartada' And el motivo queda visible en el historial del proyecto Scenario: Descarte concurrente (Edge Case) Given una historia en revisión visible para dos analistas al mismo tiempo When el analista A la descarta y segundos después el analista B intenta hacer lo mismo Then el sistema informa al analista B que la historia ya fue descartada And refresca su vista del backlog con el estado actualizado	EP10
US40	Consentimiento de grabación al iniciar sesión	Como analista que va a iniciar una sesión de captura, quiero que el sistema muestre un aviso claro indicando que se grabará audio antes de comenzar, para que todos los participantes sean informados y puedan dar su consentimiento.	Feature: Consentimiento de grabación Scenario: Mostrar aviso y confirmar inicio (Happy Path) Given un analista a punto de iniciar una sesión de captura When hace clic en 'Iniciar sesión' Then el sistema muestra un modal con el aviso de grabación de audio And solo activa el micrófono después de que el analista confirma que los participantes fueron informados Scenario: Cancelar inicio por falta de consentimiento (Unhappy Path) Given el modal de consentimiento visible When el analista cancela la acción Then la sesión no se inicia And el estado del proyecto permanece sin cambios	EP06
US41	Pausar y reanudar captura	Como analista durante una sesión activa, quiero pausar la captura cuando la conversación se desvía del tema o hay un receso, para evitar que se generen historias a partir de conversaciones que no son requisitos del cliente.	Feature: Pausa y reanudación Scenario: Pausar y reanudar la captura (Happy Path) Given una sesión en estado activa When el analista pausa la sesión Then el sistema detiene temporalmente la generación de historias And al reanudarla, continúa el procesamiento normalmente Scenario: Intentar pausar una sesión ya pausada (Unhappy Path de concurrencia) Given una sesión que fue pausada por el analista A When el analista B intenta pausarla desde otro dispositivo sin haber refrescado Then el sistema ignora la acción And sincroniza el estado de la UI para el analista B informando la pausa	EP06
US42	Cerrar y guardar sesión	Como analista al terminar una reunión, quiero finalizar la sesión de captura, para asegurar que todas las historias generadas queden guardadas en el historial del proyecto.	Feature: Cierre de sesión Scenario: Cerrar sesión con historias guardadas (Happy Path) Given una sesión activa con al menos una historia generada When el analista cierra la sesión de captura Then la sesión pasa a estado 'cerrada' And todas las historias se persisten en el proyecto principal Scenario: Prevenir pérdida de datos al cerrar (Unhappy Path - Flujo de Red) Given una sesión activa con historias sin sincronizar al backend When el usuario intenta cerrar la sesión pero no hay conexión a internet Then el sistema bloquea el cierre temporalmente And muestra una advertencia de sincronización pendiente para evitar pérdida de datos Scenario: Cerrar sesión vacía (Edge Case) Given una sesión activa en la que no se generó ninguna historia When el analista cierra la sesión Then el sistema permite el cierre And muestra el resumen final con contadores en cero	EP06
US43	Abortar sesión sin guardar	Como analista en una sesión de captura, quiero poder abortar y descartar la reunión por completo si hubo un error (ej. reunión cancelada), para no ensuciar el historial del proyecto con datos basura.	Feature: Abortar sesión en vivo Scenario: Cancelar y purgar sesión (Happy Path) Given una sesión activa que no debe ser guardada When el analista selecciona la opción 'Abortar y salir' And confirma la advertencia destructiva Then el sistema purga todas las historias generadas temporalmente And cierra la sesión sin dejar rastro en el historial del proyecto Scenario: Abortar por error sin confirmación (Unhappy Path) Given una sesión activa When el analista hace clic en 'Abortar' Then el sistema muestra un modal de confirmación estricto pidiendo tipear 'ELIMINAR' And no ejecuta el borrado hasta validar el input	EP06
US44	Etiquetar voz del cliente (Diarización)	Como analista revisando una sesión, quiero poder identificar y etiquetar qué voz corresponde al 'Cliente' y cuáles al 'Equipo', para que la IA priorice las necesidades del cliente y no genere historias basadas en nuestras propias preguntas.	Feature: Diarización (Etiquetado de locutor) Scenario: Distinguir locutores automáticamente (Happy Path) Given una sesión de grabación con múltiples participantes (ej. 2 clientes y 1 analista) When el motor procesa el audio de entrada Then el sistema segmenta el audio y asigna la transcripción a etiquetas como 'Speaker 1', 'Speaker 2' And el analista puede renombrar esas etiquetas con los nombres reales de los participantes Scenario: Audio con superposición de voces (Unhappy Path - Modelo) Given una sesión activa donde dos personas hablan exactamente al mismo tiempo y fuerte When el sistema intenta diarizar ese segmento superpuesto Then el sistema agrupa ambas voces como 'Speaker X' And advierte sutilmente en la transcripción sobre 'Superposición de voces detectada'	EP06
EP07	Procesamiento de Audio Grabado	Funcionalidad para procesar grabaciones de reuniones anteriores cuando no fue posible usar la captura en tiempo real.	--	--
US45	Subir grabación de reunión	Como analista, quiero subir el archivo de audio de una reunión pasada dentro de un proyecto específico, para que el sistema extraiga los requisitos aplicando el glosario y contexto técnico de ese proyecto.	Feature: Carga de grabaciones Scenario: Procesar exitosamente una grabación válida (Happy Path) Given que el analista tiene permisos para crear sesiones And la organización tiene minutos de procesamiento disponibles When el analista sube un archivo de audio válido Then el sistema acepta el archivo And inicia la extracción de requisitos automáticamente sin intervención manual Scenario Outline: Rechazar carga de grabaciones inválidas o no permitidas (Unhappy Paths) Given que el analista intenta subir una grabación When ocurre la situación descrita en <Condicion_Invalida> Then el sistema rechaza la carga And muestra el mensaje explicativo <Mensaje_Esperado> And no descuenta minutos del plan de suscripción de la organización Examples: Condicion_Invalida Mensaje_Esperado El archivo tiene un formato no soportado (ej. .pdf, .docx) El formato del archivo no está soportado. El archivo de audio está corrupto o dañado El archivo de audio no se puede leer o está dañado. El archivo supera el límite de tamaño máximo permitido El archivo supera el límite de tamaño permitido. La organización agotó su límite de minutos mensuales Has alcanzado el límite de procesamiento de tu plan actual.	EP07
US46	Ver estado del procesamiento	Como analista que subió una grabación de reunión, quiero ver el avance del procesamiento de forma visible en la pantalla, para saber cuándo las historias están listas sin tener que revisar la sección manualmente cada cierto tiempo. Depende de: US45.	Feature: Estado del procesamiento Scenario: Consultar el avance del procesamiento (Happy Path) Given que el analista subió un archivo de audio exitosamente When consulta la vista de procesamiento Then el sistema muestra el estado actualizado (ej. 'En cola', 'Procesando', 'Completado') And muestra un progreso estimado de ser posible Scenario: Manejo de procesamiento fallido (Unhappy Path - Asíncrono) Given que un archivo está en estado 'Procesando' When el motor de IA falla o agota el tiempo de espera por un error interno Then el estado de la tarea cambia a 'Fallido' And la interfaz permite al analista reintentar el procesamiento sin volver a subir el archivo	EP07
US47	Ver historial de sesiones del proyecto	Como miembro del equipo, quiero ver el listado de todas las sesiones (en vivo y grabaciones) asociadas a un proyecto, para acceder rápidamente al resultado de reuniones anteriores sin tener que recordar fechas exactas.	Feature: Historial de sesiones Scenario: Listar sesiones activas e históricas (Happy Path) Given un miembro accediendo a la vista de un proyecto When navega a la sección de historial de sesiones Then el sistema muestra el listado de sesiones ordenadas por fecha descendente And cada sesión indica su tipo (en vivo / grabación), fecha y número de historias generadas Scenario: Proyecto sin sesiones previas (Edge Case) Given un proyecto recién creado sin sesiones When el miembro accede al historial Then el sistema muestra un estado vacío con un mensaje orientativo Scenario: Sesión con procesamiento de audio en curso (Edge Case) Given un analista consultando el historial de sesiones del proyecto When una grabación subida está todavía en proceso de transcripción y extracción Then el sistema la muestra en el listado con el indicador de estado 'Procesando' And desactiva las acciones de revisión hasta que el procesamiento finalice	EP07
EP08	Asistencia Proactiva de la IA	Capacidad del sistema para sugerir acciones al analista durante o después de la sesión con el fin de mejorar la calidad y completitud de los requisitos capturados.	--	--
US48	Sugerencias de preguntas al cliente	Como analista durante o después de una sesión, quiero recibir una lista de preguntas concretas cuando el sistema detecta partes ambiguas en lo que dijo el cliente, para hacer esas preguntas antes de cerrar la reunión y evitar contactar al cliente después. Depende de: US37.	Feature: Sugerencias de preguntas al cliente Scenario: Sugerir preguntas ante un requisito ambiguo (Happy Path) Given que el sistema generó una historia a partir de la sesión When la IA detecta partes ambiguas o contradictorias en lo dicho por el cliente Then muestra una lista de preguntas concretas sugeridas And vincula las preguntas al punto de ambigüedad específico Scenario: Omitir sugerencias ante requisitos claros (Unhappy Path) Given que el sistema generó una historia When el requisito expresado por el cliente es completamente claro y detallado Then el sistema no muestra sugerencias de preguntas irrelevantes	EP08
US49	Detección de casos no mencionados	Como analista revisando las historias generadas, quiero ver una lista de situaciones concretas que no se mencionaron en la reunión pero que suelen presentarse en ese tipo de módulo, para que el equipo las evalúe antes de empezar a construir y no las descubra durante el desarrollo. Depende de: US37.	Feature: Detección de casos no mencionados Scenario: Proponer escenarios omitidos (Happy Path) Given una historia de usuario estructurada sobre un módulo específico (ej. 'Login') When el sistema analiza el contexto general de la historia Then sugiere casos de uso típicos no mencionados por el cliente (ej. 'Bloqueo de cuenta tras N intentos fallidos') Scenario Outline: Restricciones de sugerencia (Unhappy Paths) Given una historia de usuario estructurada When ocurre el escenario <Escenario> Then el comportamiento del sistema será <Comportamiento> Examples: Escenario Comportamiento El contexto del proyecto y el requisito son excesivamente genéricos No inventa casos de uso sin fundamento ni genera ruido visual. Existen docenas de posibles casos borde asociados al módulo Filtra la lista y muestra únicamente los N casos más críticos y probables.	EP08
EP09	Calidad y Detección de Duplicados	Búsqueda semántica sobre el historial de historias aprobadas del proyecto para mantener la integridad y unicidad del backlog.	--	--
US50	Detección de historias similares	Como analista en una sesión activa, quiero que el sistema me avise con el porcentaje de similitud cuando una historia nueva se parece a una que ya existe en el proyecto, para evitar que el backlog tenga requisitos redundantes o contradictorios entre sí.	Feature: Detección de historias similares Scenario: Alertar duplicidad evidente (Happy Path) Given una nueva historia recién generada When su significado excede el porcentaje de similitud configurado respecto a una historia previamente aprobada Then el sistema muestra una alerta de posible duplicado And enlaza a la historia original para comparación Scenario: Ignorar historias relacionadas pero distintas (Unhappy Path) Given una nueva historia recién generada When comparte palabras clave con historias anteriores pero el objetivo funcional es diferente (no supera el umbral de similitud semántica) Then el sistema no levanta ninguna alerta de duplicidad	EP09
US51	Resolver historia duplicada	Como analista que recibió una alerta de similitud, quiero decidir si fusiono la nueva historia con la existente o la mantengo separada dejando registrada mi justificación, para que el backlog quede limpio con una decisión explícita visible en el historial. Depende de: US50.	Feature: Resolver historia duplicada Scenario: Resolver manteniendo la historia separada (Happy Path) Given una alerta activa de historia similar When el analista elige la opción 'Mantener separada' And escribe una justificación válida de negocio Then la alerta se da por resuelta And la justificación queda documentada en el historial de la historia Scenario Outline: Validaciones al intentar resolver (Unhappy Paths) Given una alerta activa de historia similar When el analista intenta resolverla con la falla <Falla> Then el sistema bloquea la resolución And exige corregir la entrada indicando <Requisito> Examples: Falla Requisito No seleccionó ni 'Fusionar' ni 'Mantener separada' Debe elegir explícitamente una acción. Eligió 'Mantener separada' pero dejó la justificación en blanco La justificación es obligatoria para excepciones. Scenario: Intento de resolución concurrente (Unhappy Path - Concurrencia) Given una alerta de similitud visible para dos analistas simultáneamente When el analista A resuelve la alerta y segundos después el analista B intenta hacer lo mismo Then el sistema rechaza la acción del analista B And notifica que la alerta ya fue resuelta, actualizando la vista	EP09
EP10	Revisión, Edición y Aprobación	Fase final del flujo donde el analista valida y ajusta el trabajo de la IA antes de que las historias queden listas para el equipo de desarrollo.	--	--
US52	Editar historia generada	Como analista, quiero modificar el texto de una historia generada por la IA, para ajustar el lenguaje al estándar que usa mi equipo antes de aprobarla.	Feature: Editar historia generada Scenario: Guardar cambios en el contenido (Happy Path) Given que un analista se encuentra editando una historia generada por la IA When modifica el texto y presiona guardar Then la historia actualiza su contenido And preserva la etiqueta o trazabilidad de que su origen inicial fue generado por IA Scenario Outline: Validaciones del formulario de edición (Unhappy Paths) Given que el analista intenta guardar las modificaciones de una historia When el formulario presenta <Error_Formulario> Then el sistema bloquea el guardado And muestra el mensaje <Mensaje_Error> Examples: Error_Formulario Mensaje_Error El título de la historia se ha borrado por completo El título de la historia es obligatorio. La descripción quedó completamente vacía La descripción no puede estar vacía. Scenario: Conflicto de edición concurrente (Unhappy Path - Flujo Alternativo) Given que dos usuarios abren la misma historia para editarla al mismo tiempo When el usuario A guarda sus cambios y luego el usuario B intenta guardar los suyos Then el sistema bloquea la acción del usuario B And le advierte que la historia fue modificada externamente para evitar sobreescritura accidental	EP10
US53	Aprobar historia	Como analista, quiero marcar una historia como aprobada después de revisarla, para que quede disponible para el equipo de desarrollo y pueda exportarse al gestor de tareas.	Feature: Aprobar historia Scenario: Aprobar historia revisada (Happy Path) Given una historia completa en estado de revisión When un usuario con permisos la marca como 'Aprobada' Then el estado de la historia cambia a 'Aprobada' And queda disponible en la cola para ser exportada a sistemas externos (ej. Jira) Scenario Outline: Impedir aprobación de historias incompletas (Unhappy Paths) Given que el analista intenta aprobar una historia When la historia tiene <Falla_Integridad> Then la aprobación es rechazada And el sistema indica <Razon_Rechazo> Examples: Falla_Integridad Razon_Rechazo Faltan definir los criterios de aceptación La historia debe tener criterios de aceptación antes de ser aprobada. La historia tiene alertas de similitud sin resolver Debes resolver los conflictos de duplicidad pendientes.	EP10
US54	Resumen de cierre de sesión	Como analista al cerrar una sesión, quiero ver un resumen con el total de historias creadas, descartadas y pendientes de revisión, para confirmar con el cliente que los acuerdos quedaron correctamente registrados antes de dar la reunión por concluida.	Feature: Resumen de cierre de sesión Scenario: Presentar totales precisos (Happy Path) Given que una sesión de captura acaba de ser cerrada When el sistema calcula el resumen final de la reunión Then presenta una vista consolidada mostrando el total exacto de historias creadas, descartadas y pendientes de revisión Scenario: Inconsistencia crítica durante cálculo (Unhappy Path - Sistema) Given que una sesión está en proceso de cierre When el backend detecta una discrepancia en el conteo de registros (inconsistencia de datos transaccional) Then interrumpe el cierre de la sesión And alerta al usuario sobre el problema solicitando actualizar la página antes de reintentar el cierre seguro	EP10
US55	Compartir historias con el cliente	Como analista, quiero generar un enlace público y seguro de solo lectura con las historias generadas, para enviarlo al cliente y que pueda validarlas o comentarlas sin necesidad de crearse una cuenta en la plataforma.	Feature: Aprobación externa del cliente Scenario: Generar y visitar enlace público (Happy Path) Given un proyecto con historias en revisión When el analista genera un enlace público y el cliente accede a él Then el cliente puede visualizar las historias en modo de solo lectura And puede marcarlas como 'Aprobadas' o dejar comentarios Scenario: Expiración o revocación del enlace (Unhappy Path) Given un enlace público generado anteriormente When el analista revoca el acceso o expira el tiempo de validez configurado Then cualquier intento de ingresar mostrará un error de enlace no disponible Scenario: Cliente externo sin cuenta accede al enlace (Edge Case - Usuario anónimo) Given un cliente que no tiene cuenta en Reqs-AI y recibió el enlace público por correo When accede a la URL del enlace desde su navegador Then puede visualizar las historias en modo solo lectura sin necesidad de autenticarse And no puede navegar a ninguna otra sección privada de la plataforma desde ese enlace	EP10
US56	Calificar calidad de historia (Feedback Loop)	Como analista revisando las historias generadas, quiero calificar la precisión de la IA (ej. Pulgar arriba/abajo) e indicar si hubo alucinaciones, para generar un registro de retroalimentación que mejore los prompts y el modelo en el futuro.	Feature: Retroalimentación de la IA (Feedback Loop) Scenario: Calificar positivamente una historia (Happy Path) Given una historia generada correctamente por la IA When el analista la califica positivamente (ej. Pulgar arriba) Then el sistema registra la métrica de éxito de forma silenciosa para el dataset de calidad Scenario: Reportar alucinación o error de contexto (Unhappy Path - Mejora continua) Given una historia que contiene datos inventados o malinterpretados por la IA When el analista la califica negativamente (ej. Pulgar abajo) Then el sistema despliega un menú opcional para categorizar el fallo (ej. 'Alucinación', 'Falta contexto') And vincula el texto original generado con la versión final editada por el analista para afinar los modelos futuros	EP10
US57	Buscar y filtrar historias del backlog	Como analista revisando el backlog de un proyecto, quiero buscar historias por texto libre y filtrarlas por estado (generada, aprobada, descartada) o épica, para localizar rápidamente las historias que necesito revisar sin tener que desplazarme por todo el backlog.	Feature: Búsqueda y filtrado de historias Scenario: Búsqueda por texto (Happy Path) Given un analista en la vista del backlog de un proyecto con múltiples historias When ingresa un término en el buscador Then el sistema filtra y muestra únicamente las historias que contienen el término en título o descripción Scenario: Filtrar por estado (Happy Path) Given un analista en la vista del backlog When selecciona el filtro 'Aprobadas' Then el sistema muestra únicamente las historias en ese estado Scenario: Sin resultados (Edge Case) Given un analista aplicando un filtro muy específico When ninguna historia coincide con los criterios Then el sistema muestra un estado vacío con un mensaje claro	EP10
EP11	Integraciones Externas	Conectividad con herramientas del ecosistema de desarrollo para transferir las historias aprobadas al backlog del equipo sin trabajo manual.	--	--
US58	Conectar cuenta de Jira	Como Administrador de la organización, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo.	Feature: Conectar cuenta de Jira Scenario: Autorización segura y exitosa (Happy Path) Given un Administrador de la organización en la sección de integraciones When completa satisfactoriamente el flujo de autorización (OAuth) en la plataforma de Jira Then el sistema de Reqs-AI vincula el proyecto a Jira And muestra un indicador visual de conexión activa y saludable Scenario Outline: Rechazo de autorización (Unhappy Paths) Given que el Administrador inicia el flujo de autorización When ocurre el evento <Evento_Fallo> Then el sistema aborta la integración And muestra el estado <Estado_Final> sin guardar datos espurios Examples: Evento_Fallo Estado_Final El usuario deniega los permisos desde la ventana de Jira Operación cancelada por el usuario, integración inactiva. Fallo de red o timeout durante la comunicación con Jira Error de comunicación, inténtalo nuevamente. Scenario: Token de conexión expirado (Unhappy Path - Flujo Alternativo) Given una integración previamente configurada que estaba operativa When el token de seguridad subyacente caduca (vencimiento de credencial) Then el sistema deshabilita las opciones de exportación And notifica explícitamente al administrador que se requiere una 'Re-autenticación' para reactivar la conexión	EP11
US59	Configurar mapeo de proyecto en Jira	Como Administrador de la organización, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación.	Feature: Mapeo de proyectos externos Scenario: Vincular board destino (Happy Path) Given una integración con Jira activa When el Administrador accede a la configuración de integración del proyecto Then puede seleccionar de una lista desplegable el 'Proyecto de Jira' y 'Tipo de Issue' destino And el sistema guarda este mapeo para las futuras exportaciones Scenario: Intentar exportar sin mapeo previo (Unhappy Path) Given un proyecto sin board de destino configurado When el analista intenta exportar historias a Jira Then la exportación se bloquea And el sistema redirige al Administrador a la pantalla de configuración del mapeo Scenario: Board de Jira eliminado externamente (Edge Case - Servicio externo) Given un mapeo configurado a un board de Jira que fue eliminado desde Atlassian posteriormente When el analista intenta ejecutar una exportación de historias Then el sistema detecta que el destino ya no es accesible And notifica al Administrador que el mapeo está roto y debe reconfigurarse antes de exportar	EP11
US60	Exportar historias a Jira	Como analista, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US53 y US58.	Feature: Exportar historias a Jira Scenario: Exportación exitosa de historias aprobadas (Happy Path) Given un proyecto con una conexión activa a Jira y varias historias en estado 'Aprobada' When el analista ejecuta la acción de exportación masiva Then el sistema transmite únicamente las historias aprobadas a Jira And marca exitosamente dichas historias como 'Exportadas' dentro de Reqs-AI Scenario Outline: Validaciones de prerrequisitos de exportación (Unhappy Paths) Given que el analista intenta ejecutar la exportación masiva When se incumple la condición <Incumplimiento> Then el botón o acción es bloqueado o rechazado indicando <Mensaje_Error> Examples: Incumplimiento Mensaje_Error La integración con Jira no está configurada o el token expiró Debes conectar y autorizar tu cuenta de Jira primero. No existe ninguna historia que se encuentre en estado 'Aprobada' No hay historias válidas listas para exportar. Scenario: Fallo parcial durante la transmisión de lotes (Unhappy Path - Fallo de red) Given un lote de 10 historias aprobadas listas para envío a la API de Jira When la red experimenta intermitencia y 2 de las peticiones fallan Then el sistema marca las 8 historias exitosas como 'Exportadas' And retiene las 2 restantes, marcándolas con error de exportación y habilitando un botón para reintentar el lote fallido	EP11
EP12	Arquitectura y Servicios RESTful API	Endpoints y servicios backend sin interfaz gráfica directa (Technical Stories), necesarios para soportar el procesamiento de IA, integraciones y lógica de negocio del frontend.	--	--
TS01	API: Registro de Usuario (POST /auth/register)	Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos.	Scenario: Registro exitoso Given payload con email y password When POST a /auth/register Then 201 Created	EP12
TS02	API: Login de Usuario (POST /auth/login)	Como Developer, quiero un endpoint que valide credenciales y retorne un JWT.	Scenario: Login válido Given credenciales correctas When POST a /auth/login Then 200 OK con token JWT	EP12
TS03	API: Perfil de Usuario (GET /auth/me)	Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT.	Scenario: Token válido Given header Authorization: Bearer <token> When GET a /auth/me Then 200 OK	EP12
TS04	API: Crear Proyecto (POST /projects)	Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo.	Scenario: Creación de proyecto Given payload con nombre When POST a /projects Then 201 Created	EP12
TS05	API: Listar Proyectos (GET /projects)	Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado.	Scenario: Listar proyectos Given usuario con token válido When GET a /projects Then 200 OK con array de proyectos	EP12
TS06	API: Actualizar Proyecto (PUT /projects/{id})	Como Developer, quiero un endpoint para modificar metadatos de un proyecto.	Scenario: Actualización válida Given ID de proyecto existente When PUT a /projects/{id} Then 200 OK	EP12
TS07	API: Eliminar Proyecto (DELETE /projects/{id})	Como Developer, quiero un endpoint de soft-delete para archivar proyectos.	Scenario: Eliminación lógica Given ID válido When DELETE a /projects/{id} Then 204 No Content	EP12
TS08	API: Subir Audio (POST /sessions/upload)	Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage.	Scenario: Subida exitosa Given archivo MP3 When POST a /sessions/upload Then 200 OK con URL del storage	EP12
TS09	API: Transcribir Audio (POST /sessions/transcribe)	Como Developer, quiero un endpoint que envíe la URL del audio a Whisper/AWS y retorne texto.	Scenario: Transcripción exitosa Given URL de audio válida When POST a /sessions/transcribe Then 200 OK con transcripción	EP12
TS10	API: Extraer Historias (POST /sessions/extract)	Como Developer, quiero un endpoint que procese la transcripción con el LLM y retorne el JSON de historias.	Scenario: Extracción LLM Given texto transcrito When POST a /sessions/extract Then 200 OK con array JSON	EP12
TS11	API: Auth Jira (GET /integrations/jira/auth)	Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian.	Scenario: Redirección OAuth Given petición de integración When GET a /integrations/jira/auth Then 302 Redirect a Jira	EP12
TS12	API: Exportar a Jira (POST /integrations/jira/export)	Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira.	Scenario: Exportación a Webhook Given array de IDs de historias When POST a /integrations/jira/export Then 200 OK confirmando creación	EP12
TS13	Servicio interno: Chunking de audio para ventana de tokens del LLM	Como Developer, quiero que el pipeline de procesamiento divida automáticamente los audios largos en fragmentos semánticos manejables antes de enviarlos al LLM, para evitar errores de límite de tokens y garantizar coherencia en reuniones extensas.	Scenario: Chunking de audio largo Given audio que supera la ventana de contexto del LLM When el pipeline de procesamiento lo recibe Then lo divide en bloques lógicos sin cortar oraciones And los consolida al finalizar sin pérdida de información Scenario: Reintento de fragmento fallido Given un audio dividido en N chunks When un chunk falla por intermitencia de red Then el sistema reintenta únicamente ese fragmento sin relanzar todo el proceso	EP12
TS14	API: Cerrar Sesión de Usuario (POST /auth/logout)	Como Developer, quiero un endpoint que invalide el token JWT activo del usuario.	Scenario: Logout exitoso Given token JWT válido en header When POST a /auth/logout Then 200 OK y token invalidado en blacklist	EP12
TS15	API: Verificar Email (POST /auth/verify-email)	Como Developer, quiero un endpoint que valide el token de verificación enviado por correo.	Scenario: Verificación válida Given token de verificación vigente When POST a /auth/verify-email Then 200 OK y cuenta marcada como verificada	EP12
TS16	API: Recuperar Contraseña (POST /auth/forgot-password)	Como Developer, quiero un endpoint que genere y envíe un enlace de reset de contraseña al email.	Scenario: Solicitud de reset Given email registrado en el sistema When POST a /auth/forgot-password Then 200 OK y email de reset enviado	EP12
TS17	API: Actualizar Perfil de Usuario (PUT /auth/profile)	Como Developer, quiero un endpoint que permita al usuario autenticado editar nombre, avatar y preferencias.	Scenario: Actualización válida Given usuario autenticado con token JWT When PUT a /auth/profile con body válido Then 200 OK con perfil actualizado	EP12
TS18	API: Crear Organización (POST /organizations)	Como Developer, quiero un endpoint que cree una nueva organización y asigne al creador como Owner.	Scenario: Creación exitosa Given usuario autenticado sin organización activa When POST a /organizations con nombre válido Then 201 Created con ID de organización y rol Owner asignado	EP12
TS19	API: Actualizar Organización (PUT /organizations/{id})	Como Developer, quiero un endpoint para modificar nombre, logo y configuraciones de la organización.	Scenario: Actualización válida Given usuario con permiso de Owner en la organización When PUT a /organizations/{id} con datos válidos Then 200 OK con organización actualizada	EP12
TS20	API: Cambiar Contexto de Organización (POST /organizations/switch)	Como Developer, quiero un endpoint que cambie la organización activa en la sesión del usuario.	Scenario: Cambio exitoso Given usuario miembro de múltiples organizaciones When POST a /organizations/switch con el ID destino Then 200 OK con nuevo JWT que refleja el contexto actualizado	EP12
TS21	API: Invitar Miembro (POST /organizations/{id}/invitations)	Como Developer, quiero un endpoint que genere y envíe una invitación por email para unirse a la organización.	Scenario: Invitación enviada Given usuario Owner o Admin con permisos de invitación When POST a /organizations/{id}/invitations con email y rol Then 201 Created y email de invitación enviado	EP12
TS22	API: Crear Rol Personalizado (POST /organizations/{id}/roles)	Como Developer, quiero un endpoint que registre un nuevo rol con nombre y conjunto de permisos.	Scenario: Creación de rol Given usuario Owner de la organización When POST a /organizations/{id}/roles con nombre y permisos Then 201 Created con ID del nuevo rol	EP12
TS23	API: Configurar Permisos de Rol (PUT /organizations/{id}/roles/{roleId})	Como Developer, quiero un endpoint que actualice los permisos asociados a un rol existente.	Scenario: Actualización de permisos Given rol existente en la organización When PUT a /organizations/{id}/roles/{roleId} con nuevos permisos Then 200 OK con rol actualizado	EP12
TS24	API: Eliminar Rol (DELETE /organizations/{id}/roles/{roleId})	Como Developer, quiero un endpoint que elimine un rol personalizado si no tiene miembros asignados.	Scenario: Eliminación válida Given rol sin miembros asignados When DELETE a /organizations/{id}/roles/{roleId} Then 204 No Content Scenario: Rol en uso (Unhappy Path) Given rol con miembros activos When DELETE a /organizations/{id}/roles/{roleId} Then 409 Conflict con mensaje indicando miembros activos	EP12
TS25	API: Crear Sesión en Vivo (POST /sessions)	Como Developer, quiero un endpoint que inicialice una sesión de captura en vivo asociada a un proyecto.	Scenario: Creación exitosa Given proyecto activo y usuario con permiso de edición When POST a /sessions con ID de proyecto Then 201 Created con ID de sesión y estado OPEN	EP12
TS26	API: Cambiar Estado de Sesión (PATCH /sessions/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una sesión entre OPEN, PAUSED y CLOSED.	Scenario: Cierre de sesión Given sesión en estado OPEN When PATCH a /sessions/{id}/status con estado CLOSED Then 200 OK y sesión marcada como CLOSED	EP12
TS27	API: Listar Sesiones de Proyecto (GET /projects/{id}/sessions)	Como Developer, quiero un endpoint paginado que retorne todas las sesiones de un proyecto ordenadas por fecha.	Scenario: Listado exitoso Given proyecto con sesiones registradas When GET a /projects/{id}/sessions Then 200 OK con array paginado de sesiones	EP12
TS28	API: Listar y Buscar Historias (GET /projects/{id}/stories)	Como Developer, quiero un endpoint con filtros por estado, épica y texto para recuperar historias de un proyecto.	Scenario: Búsqueda con filtro Given proyecto con historias generadas When GET a /projects/{id}/stories?status=DRAFT&epic=EP03 Then 200 OK con array filtrado y metadata de paginación	EP12
TS29	API: Editar Historia (PUT /stories/{id})	Como Developer, quiero un endpoint que permita actualizar título, descripción y criterios de aceptación de una historia.	Scenario: Edición válida Given historia existente y usuario con permiso de edición When PUT a /stories/{id} con body actualizado Then 200 OK con historia actualizada y timestamp de modificación	EP12
TS30	API: Cambiar Estado de Historia (PATCH /stories/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una historia entre DRAFT, APPROVED y REJECTED.	Scenario: Aprobación de historia Given historia en estado DRAFT When PATCH a /stories/{id}/status con estado APPROVED Then 200 OK y historia marcada como APPROVED	EP12
TS31	API: Cargar Documento (POST /projects/{id}/documents)	Como Developer, quiero un endpoint multipart que acepte PDF/Word, extraiga el texto con Apache Tika y genere embeddings con el LLM.	Scenario: Carga y procesamiento Given archivo PDF válido When POST a /projects/{id}/documents Then 202 Accepted y procesamiento asíncrono iniciado; webhook notifica al completar	EP12
TS32	API: Agregar Término al Glosario (POST /projects/{id}/glossary)	Como Developer, quiero un endpoint que persista un término con su definición en el contexto de un proyecto.	Scenario: Término agregado Given proyecto activo y usuario autenticado When POST a /projects/{id}/glossary con término y definición Then 201 Created con ID del término	EP12
TS33	API: Agregar Restricción Técnica (POST /projects/{id}/constraints)	Como Developer, quiero un endpoint que registre una restricción técnica asociada al proyecto para enriquecer el contexto del RAG.	Scenario: Restricción registrada Given proyecto activo y usuario autenticado When POST a /projects/{id}/constraints con descripción Then 201 Created con ID de la restricción	EP12
TS34	API: Upgrade de Plan (POST /subscriptions/upgrade)	Como Developer, quiero un endpoint que inicie el flujo de pago con Stripe y actualice el plan al confirmar el webhook.	Scenario: Upgrade exitoso Given organización en plan FREE When POST a /subscriptions/upgrade con plan destino Then 200 OK con URL de checkout de Stripe	EP12
TS35	API: Cancelar Suscripción (DELETE /subscriptions)	Como Developer, quiero un endpoint que marque la suscripción como cancelada al final del período de facturación.	Scenario: Cancelación programada Given organización con suscripción activa When DELETE a /subscriptions Then 200 OK con fecha de expiración y estado CANCELING	EP12

3.3. Product Backlog

A continuación, se presenta el Product Backlog priorizado estrictamente por el Valor de Negocio y la Secuencia Lógica de Construcción (MVP Golden Path).

Esta priorización se rige por el Valor de Negocio: las funcionalidades que generan mayor impacto para el usuario y el negocio ocupan los primeros puestos, independientemente de las dependencias técnicas (que se resuelven durante la planificación del sprint). Las TS (Technical Stories / API backend) se ubican justo antes de las US de su misma épica para reflejar el orden de construcción dentro de cada bloque de valor.

Tabla de Estimación y Priorización

# Orden	User Story Id	Título	Descripción	Story Points (1/2/3/5/8)
1	US01	Visualizar Propuesta de Valor (Hero)	Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta.	3
2	US02	Explorar Casos de Uso por Segmento	Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo.	3
3	US03	Visualizar Planes y Precios	Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta.	2
4	TS01	API: Registro de Usuario (POST /auth/register)	Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos.	2
5	TS02	API: Login de Usuario (POST /auth/login)	Como Developer, quiero un endpoint que valide credenciales y retorne un JWT.	2
6	TS03	API: Perfil de Usuario (GET /auth/me)	Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT.	1
7	TS15	API: Verificar Email (POST /auth/verify-email)	Como Developer, quiero un endpoint que valide el token de verificación enviado por correo.	3
8	TS16	API: Recuperar Contraseña (POST /auth/forgot-password)	Como Developer, quiero un endpoint que genere y envíe un enlace de reset de contraseña al email.	3
9	TS17	API: Actualizar Perfil de Usuario (PUT /auth/profile)	Como Developer, quiero un endpoint que permita al usuario autenticado editar nombre, avatar y preferencias.	3
10	TS14	API: Cerrar Sesión de Usuario (POST /auth/logout)	Como Developer, quiero un endpoint que invalide el token JWT activo del usuario.	3
11	US04	Registro de cuenta	Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos.	3
12	US05	Verificación de correo	Como usuario con cuenta pendiente de activación, quiero verificar mi correo haciendo clic en el enlace que recibí, para activar mi cuenta y empezar a trabajar en la plataforma.	2
13	US06	Inicio de sesión	Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización.	3
14	US07	Recuperación de contraseña	Como usuario registrado que no recuerda su contraseña, quiero recibir un enlace de restablecimiento en mi correo, para recuperar el acceso a mi cuenta sin perder mi historial de trabajo.	2
15	US08	Cerrar sesión	Como usuario autenticado, quiero cerrar mi sesión de forma explícita, para asegurarme de que nadie más pueda acceder a mi cuenta desde el mismo dispositivo.	1
16	US09	Aceptar términos y política de privacidad	Como nuevo usuario completando el registro, quiero leer y aceptar los términos de uso y la política de privacidad antes de activar mi cuenta, para entender cómo se usan mis datos y las grabaciones de audio antes de comenzar a usar el servicio.	1
17	US10	Editar perfil de usuario	Como usuario autenticado, quiero actualizar mi nombre y foto de perfil, para que mis compañeros de equipo me identifiquen correctamente en los registros de actividad de las sesiones.	2
18	TS18	API: Crear Organización (POST /organizations)	Como Developer, quiero un endpoint que cree una nueva organización y asigne al creador como Owner.	3
19	TS19	API: Actualizar Organización (PUT /organizations/{id})	Como Developer, quiero un endpoint para modificar nombre, logo y configuraciones de la organización.	3
20	TS20	API: Cambiar Contexto de Organización (POST /organizations/switch)	Como Developer, quiero un endpoint que cambie la organización activa en la sesión del usuario.	3
21	US11	Crear organización	Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado.	2
22	US12	Editar organización	Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia.	1
23	US13	Cambiar de organización	Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo.	2
24	US14	Política de retención de audios	Como Propietario de la organización, quiero configurar la eliminación automática de los archivos de audio originales X días después de procesarse, para cumplir con las políticas de privacidad y confidencialidad corporativas.	3
25	TS34	API: Upgrade de Plan (POST /subscriptions/upgrade)	Como Developer, quiero un endpoint que inicie el flujo de pago con Stripe y actualice el plan al confirmar el webhook.	3
26	TS35	API: Cancelar Suscripción (DELETE /subscriptions)	Como Developer, quiero un endpoint que marque la suscripción como cancelada al final del período de facturación.	3
27	US15	Plan gratuito automático	Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme.	2
28	US16	Suscripción al plan Pro	Como Propietario de una organización en plan gratuito, quiero contratar el plan Pro, para acceder a sesiones ilimitadas, captura en tiempo real e integración con Jira.	5
29	US17	Suscripción al plan Equipo	Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno.	3
30	US18	Cancelación de suscripción	Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio.	2
31	US19	Ver estado del plan y consumo	Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo.	3
32	TS04	API: Crear Proyecto (POST /projects)	Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo.	2
33	TS05	API: Listar Proyectos (GET /projects)	Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado.	1
34	TS06	API: Actualizar Proyecto (PUT /projects/{id})	Como Developer, quiero un endpoint para modificar metadatos de un proyecto.	1
35	TS07	API: Eliminar Proyecto (DELETE /projects/{id})	Como Developer, quiero un endpoint de soft-delete para archivar proyectos.	1
36	TS31	API: Cargar Documento (POST /projects/{id}/documents)	Como Developer, quiero un endpoint multipart que acepte PDF/Word, extraiga el texto con Apache Tika y genere embeddings con el LLM.	3
37	TS32	API: Agregar Término al Glosario (POST /projects/{id}/glossary)	Como Developer, quiero un endpoint que persista un término con su definición en el contexto de un proyecto.	3
38	TS33	API: Agregar Restricción Técnica (POST /projects/{id}/constraints)	Como Developer, quiero un endpoint que registre una restricción técnica asociada al proyecto para enriquecer el contexto del RAG.	3
39	US20	Crear proyecto	Como analista, quiero registrar un proyecto asociado a un cliente específico, para organizar y separar todas las sesiones de levantamiento de requisitos de ese cliente.	2
40	US21	Cargar documentos del cliente	Como analista, quiero subir documentos del cliente (PDF, Word) al proyecto, para que el sistema extraiga y clasifique automáticamente su contenido en glosario, restricciones y contexto general, enriqueciendo así las historias que se generen en sesiones futuras.	5
41	US22	Configurar perfil técnico del proyecto	Como analista, quiero registrar las tecnologías que usa el equipo del cliente y los tipos de usuarios del sistema, para que los criterios de aceptación generados sean aplicables al contexto real del proyecto.	3
42	US23	Agregar término al glosario manualmente	Como analista, quiero agregar términos del negocio del cliente directamente al glosario del proyecto sin necesidad de subir un documento, para enriquecer el vocabulario de la IA cuando el cliente solo transmite su conocimiento de forma oral.	2
43	US24	Registrar restricción técnica manualmente	Como analista, quiero registrar restricciones técnicas del cliente (ej. 'sin uso de cookies de terceros', 'máximo 3 segundos de latencia') directamente en el proyecto, para que la IA las considere al generar los criterios de aceptación sin necesidad de incluirlas en cada sesión.	2
44	US25	Editar proyecto	Como analista, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente.	1
45	US26	Archivar proyecto	Como analista, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas.	2
46	US27	Proyecto de demostración automático	Como nuevo usuario que acaba de registrarse, quiero encontrar un proyecto de demostración pre-cargado con audios e historias ya generadas, para entender inmediatamente el valor de la plataforma sin tener que grabar mi propia reunión primero.	3
47	TS21	API: Invitar Miembro (POST /organizations/{id}/invitations)	Como Developer, quiero un endpoint que genere y envíe una invitación por email para unirse a la organización.	3
48	TS22	API: Crear Rol Personalizado (POST /organizations/{id}/roles)	Como Developer, quiero un endpoint que registre un nuevo rol con nombre y conjunto de permisos.	3
49	TS23	API: Configurar Permisos de Rol (PUT /organizations/{id}/roles/{roleId})	Como Developer, quiero un endpoint que actualice los permisos asociados a un rol existente.	3
50	TS24	API: Eliminar Rol (DELETE /organizations/{id}/roles/{roleId})	Como Developer, quiero un endpoint que elimine un rol personalizado si no tiene miembros asignados.	3
51	US28	Invitar miembro a la organización	Como Administrador de la organización, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización.	3
52	US29	Crear rol personalizado	Como Propietario de la organización, quiero crear un rol con un nombre definido por mi equipo, para representar una función real dentro de la organización en lugar de usar etiquetas genéricas del sistema.	2
53	US30	Asignar permisos a un rol	Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales.	3
54	US31	Asignar rol a un miembro	Como Administrador de la organización, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación.	1
55	US32	Editar permisos de un rol existente	Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades.	2
56	US33	Eliminar un rol	Como Propietario de la organización, quiero eliminar un rol que ya no corresponde a ninguna función activa del equipo, para mantener la lista de roles ordenada y evitar asignaciones incorrectas.	1
57	US34	Remover miembro de la organización	Como Administrador de la organización, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo.	2
58	US35	Transferir propiedad de la organización	Como Propietario de la organización, quiero transferir la propiedad a otro miembro activo, para poder desvincularme del equipo sin dejar la cuenta sin responsable cuando abandono el proyecto.	3
59	TS13	Servicio interno: Chunking de audio para ventana de tokens del LLM	Como Developer, quiero que el pipeline de procesamiento divida automáticamente los audios largos en fragmentos semánticos manejables antes de enviarlos al LLM, para evitar errores de límite de tokens y garantizar coherencia en reuniones extensas.	3
60	TS25	API: Crear Sesión en Vivo (POST /sessions)	Como Developer, quiero un endpoint que inicialice una sesión de captura en vivo asociada a un proyecto.	3
61	TS26	API: Cambiar Estado de Sesión (PATCH /sessions/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una sesión entre OPEN, PAUSED y CLOSED.	3
62	US36	Iniciar sesión de captura en vivo	Como analista, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US20.	3
63	US37	Generación automática de historias	Como analista en sesión activa, quiero que el sistema convierta automáticamente lo que dice el cliente en historias de usuario con criterios de aceptación, para obtener un backlog estructurado al finalizar la reunión sin necesidad de documentar después.	8
64	US38	Descartar historia durante sesión en vivo	Como analista con una sesión activa, quiero descartar una historia recién generada indicando un motivo, para mantener el backlog de la sesión limpio en tiempo real sin interrumpir la reunión.	2
65	US39	Descartar historia en revisión post-sesión	Como analista revisando el backlog después de cerrar la sesión, quiero descartar una historia indicando un motivo, para depurar el resultado final antes de que el equipo de desarrollo lo utilice.	2
66	US40	Consentimiento de grabación al iniciar sesión	Como analista que va a iniciar una sesión de captura, quiero que el sistema muestre un aviso claro indicando que se grabará audio antes de comenzar, para que todos los participantes sean informados y puedan dar su consentimiento.	2
67	US41	Pausar y reanudar captura	Como analista durante una sesión activa, quiero pausar la captura cuando la conversación se desvía del tema o hay un receso, para evitar que se generen historias a partir de conversaciones que no son requisitos del cliente.	2
68	US42	Cerrar y guardar sesión	Como analista al terminar una reunión, quiero finalizar la sesión de captura, para asegurar que todas las historias generadas queden guardadas en el historial del proyecto.	2
69	US43	Abortar sesión sin guardar	Como analista en una sesión de captura, quiero poder abortar y descartar la reunión por completo si hubo un error (ej. reunión cancelada), para no ensuciar el historial del proyecto con datos basura.	2
70	US44	Etiquetar voz del cliente (Diarización)	Como analista revisando una sesión, quiero poder identificar y etiquetar qué voz corresponde al 'Cliente' y cuáles al 'Equipo', para que la IA priorice las necesidades del cliente y no genere historias basadas en nuestras propias preguntas.	5
71	TS08	API: Subir Audio (POST /sessions/upload)	Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage.	3
72	TS09	API: Transcribir Audio (POST /sessions/transcribe)	Como Developer, quiero un endpoint que envíe la URL del audio a Whisper/AWS y retorne texto.	5
73	TS10	API: Extraer Historias (POST /sessions/extract)	Como Developer, quiero un endpoint que procese la transcripción con el LLM y retorne el JSON de historias.	5
74	US45	Subir grabación de reunión	Como analista, quiero subir el archivo de audio de una reunión pasada dentro de un proyecto específico, para que el sistema extraiga los requisitos aplicando el glosario y contexto técnico de ese proyecto.	3
75	US46	Ver estado del procesamiento	Como analista que subió una grabación de reunión, quiero ver el avance del procesamiento de forma visible en la pantalla, para saber cuándo las historias están listas sin tener que revisar la sección manualmente cada cierto tiempo. Depende de: US45.	2
76	US47	Ver historial de sesiones del proyecto	Como miembro del equipo, quiero ver el listado de todas las sesiones (en vivo y grabaciones) asociadas a un proyecto, para acceder rápidamente al resultado de reuniones anteriores sin tener que recordar fechas exactas.	2
77	US48	Sugerencias de preguntas al cliente	Como analista durante o después de una sesión, quiero recibir una lista de preguntas concretas cuando el sistema detecta partes ambiguas en lo que dijo el cliente, para hacer esas preguntas antes de cerrar la reunión y evitar contactar al cliente después. Depende de: US37.	5
78	US49	Detección de casos no mencionados	Como analista revisando las historias generadas, quiero ver una lista de situaciones concretas que no se mencionaron en la reunión pero que suelen presentarse en ese tipo de módulo, para que el equipo las evalúe antes de empezar a construir y no las descubra durante el desarrollo. Depende de: US37.	3
79	US50	Detección de historias similares	Como analista en una sesión activa, quiero que el sistema me avise con el porcentaje de similitud cuando una historia nueva se parece a una que ya existe en el proyecto, para evitar que el backlog tenga requisitos redundantes o contradictorios entre sí.	5
80	US51	Resolver historia duplicada	Como analista que recibió una alerta de similitud, quiero decidir si fusiono la nueva historia con la existente o la mantengo separada dejando registrada mi justificación, para que el backlog quede limpio con una decisión explícita visible en el historial. Depende de: US50.	3
81	TS28	API: Listar y Buscar Historias (GET /projects/{id}/stories)	Como Developer, quiero un endpoint con filtros por estado, épica y texto para recuperar historias de un proyecto.	3
82	TS29	API: Editar Historia (PUT /stories/{id})	Como Developer, quiero un endpoint que permita actualizar título, descripción y criterios de aceptación de una historia.	3
83	TS30	API: Cambiar Estado de Historia (PATCH /stories/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una historia entre DRAFT, APPROVED y REJECTED.	3
84	TS27	API: Listar Sesiones de Proyecto (GET /projects/{id}/sessions)	Como Developer, quiero un endpoint paginado que retorne todas las sesiones de un proyecto ordenadas por fecha.	3
85	US52	Editar historia generada	Como analista, quiero modificar el texto de una historia generada por la IA, para ajustar el lenguaje al estándar que usa mi equipo antes de aprobarla.	3
86	US53	Aprobar historia	Como analista, quiero marcar una historia como aprobada después de revisarla, para que quede disponible para el equipo de desarrollo y pueda exportarse al gestor de tareas.	2
87	US54	Resumen de cierre de sesión	Como analista al cerrar una sesión, quiero ver un resumen con el total de historias creadas, descartadas y pendientes de revisión, para confirmar con el cliente que los acuerdos quedaron correctamente registrados antes de dar la reunión por concluida.	2
88	US55	Compartir historias con el cliente	Como analista, quiero generar un enlace público y seguro de solo lectura con las historias generadas, para enviarlo al cliente y que pueda validarlas o comentarlas sin necesidad de crearse una cuenta en la plataforma.	3
89	US56	Calificar calidad de historia (Feedback Loop)	Como analista revisando las historias generadas, quiero calificar la precisión de la IA (ej. Pulgar arriba/abajo) e indicar si hubo alucinaciones, para generar un registro de retroalimentación que mejore los prompts y el modelo en el futuro.	2
90	US57	Buscar y filtrar historias del backlog	Como analista revisando el backlog de un proyecto, quiero buscar historias por texto libre y filtrarlas por estado (generada, aprobada, descartada) o épica, para localizar rápidamente las historias que necesito revisar sin tener que desplazarme por todo el backlog.	2
91	TS11	API: Auth Jira (GET /integrations/jira/auth)	Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian.	3
92	TS12	API: Exportar a Jira (POST /integrations/jira/export)	Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira.	5
93	US58	Conectar cuenta de Jira	Como Administrador de la organización, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo.	5
94	US59	Configurar mapeo de proyecto en Jira	Como Administrador de la organización, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación.	2
95	US60	Exportar historias a Jira	Como analista, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US53 y US58.	5

Referencia en Herramienta de Gestión (Jira Software)

Las historias de usuario, junto con sus estimaciones en Story Points, Criterios de Aceptación (BDD) e hitos (Sprints) se encuentran mapeadas y gestionadas en nuestro tablero ágil corporativo.

Enlace Público al Product Backlog:
https://uni-ride.atlassian.net/jira/software/projects/REQ/boards/299/backlog (Enlace de acceso).

Captura del Product Backlog (Priorizado):

3.4. Impact Mapping

En esta sección presentamos el Impact Mapping del modelo de negocio digital de Reqs-AI. Para su elaboración partimos de las user persona definidas previamente, Miguel Ocampo y Diego Alvarado, y conectamos cada objetivo de negocio con los cambios de comportamiento esperados (impacts), los entregables del producto (deliverables) y las historias de usuario del backlog.

El mapa fue estructurado con tres Business Goals SMART para mantener foco estratégico y trazabilidad funcional:

• G1: En 4 meses, aumentar la conversión de visitante a cuenta del 3% al 12%, y lograr que el 70% de nuevos usuarios cree su organización y abra el demo en menos de 15 minutos.
• G2: En 4 meses, reducir en 40% el tiempo de levantamiento y documentación por reunión, y lograr que el 75% de sesiones se cierre el mismo día con backlog utilizable.
• G3: En 6 meses, lograr 100% de organizaciones con control de acceso y retención activa, convertir 15% de organizaciones free a pago y exportar 70% de historias aprobadas a Jira en menos de 5 minutos.

Para cada meta, el mapa diferencia el rol de cada persona: Miguel concentra impactos de gobierno, operación y decisión de negocio; Diego concentra impactos de captura, validación y continuidad del flujo analítico hacia desarrollo. A partir de ello se priorizan deliverables de captación, onboarding, configuración de proyecto, control de calidad y exportación a Jira.

La trazabilidad final se mantiene en formato Goal -> Persona -> Impact -> Deliverable -> User Story, usando únicamente historias US del Product Backlog para asegurar consistencia entre estrategia y planificación de producto.

Ver imagen detallada

Capítulo IV: Strategic-Level Product Design

4.1. Strategic-Level Attribute-Driven Design

4.1.1. Design Purpose

El propósito del proceso de diseño de Reqs-AI es establecer una arquitectura de software capaz de resolver tecnológicamente la desconexión y pérdida de información que ocurre durante el levantamiento de requisitos. El diseño está concebido como un sistema creado desde cero orientado a construir una solución robusta, escalable y en tiempo real que traduzca la voz del cliente directamente en especificaciones técnicas de alto valor.

Este diseño está directamente orientado a satisfacer las necesidades críticas de nuestros dos segmentos objetivos:

• Para el Líder Técnico de Startup: La arquitectura priorizará el rendimiento y la integración (flujos automatizados hacia herramientas como Jira), asegurando agilidad y la reducción del tiempo entre el discovery y el desarrollo.
• Para la Analista Enterprise: El diseño se centrará en la seguridad y la privacidad de los datos, estableciendo una arquitectura Multitenancy con aislamiento de datos estricto (Row Level Security), cumpliendo así con las exigencias corporativas y mitigando los riesgos de fuga de información.

A nivel de negocio para la startup Kntro-Soft, el diseño tiene el propósito de habilitar el modelo de distribución SaaS (Software as a Service). La arquitectura debe soportar el sistema de suscripciones y facturación, gestionar los límites de consumo de los motores de IA (LLM) para mantener la rentabilidad, y asegurar que la plataforma pueda escalar el procesamiento de múltiples organizaciones concurrentes sin degradar la experiencia de usuario.

4.1.2. Attribute-Driven Design Inputs

En esta sección se presentan las entradas fundamentales requeridas para ejecutar el proceso de diseño arquitectónico basado en el método Attribute-Driven Design (ADD). Estos inputs proporcionan el contexto, las metas y los límites que guiarán la toma de decisiones técnicas para la plataforma Reqs-AI. A continuación, el contenido se divide en tres categorías principales dictadas por la metodología: la funcionalidad primaria, los escenarios de atributos de calidad y las restricciones.

4.1.2.1. Primary Functionality (Primary User Stories)

A continuación, se detallan las Historias de Usuario primarias que tienen el mayor impacto arquitectónico en el diseño de Reqs-AI. Estas funcionalidades han sido seleccionadas porque introducen requerimientos complejos de procesamiento asíncrono (análisis de audio en tiempo real), integración con servicios de Inteligencia Artificial (LLM) y aislamiento estricto de datos (Multitenancy), elementos que dictarán la topología base del sistema.

Epic / User Story ID	Título	Descripción	Criterios de Aceptación	Relacionado con (Epic ID)
US11	Crear organización	Como usuario autenticado sin organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar proyectos en un entorno separado.	Given un usuario autenticado sin organización When crea una organización con un nombre válido Then el sistema genera el espacio de trabajo And asigna al usuario el rol inamovible de 'Propietario'	EP02
US21	Cargar documentos del cliente	Como miembro, quiero subir documentos del cliente al proyecto, para que las historias generadas reflejen el vocabulario del negocio (RAG).	Given un usuario configurando un proyecto When sube un glosario en PDF válido Then el sistema debe fragmentar (chunking), vectorizar y persistir el documento en una base de datos vectorial en menos de 10 segundos	EP04
US37	Generación automática de historias	Como analista, quiero que el sistema procese el audio en vivo y redacte automáticamente historias de usuario estructuradas con criterios de aceptación, para ahorrar horas de redacción manual.	Given una sesión de captura de audio activa When el sistema recibe y transcribe el flujo de voz Then el motor de IA procesa el texto generado And redacta una historia de usuario en formato Gherkin And la añade al backlog de la sesión actual	EP06

Justificación del Impacto Arquitectónico:

• US11 (Crear organización): Define el modelo base de multi-tenant y la asignación de ownership; requiere aislamiento de datos, provisión de recursos por organización y reglas consistentes para separar el acceso entre organizaciones.
• US21 (Cargar documentos del cliente): Obliga a definir un pipeline de ingesta asíncrona con chunking, embeddings y almacenamiento vectorial, controlando tiempos de procesamiento, costos y límites por organización.
• US37 (Generación automática de historias): Exige procesamiento en tiempo real con baja latencia, orquestación de STT y LLM, y manejo de estados de sesión y reintentos sin perder datos durante la captura en vivo.

4.1.2.2. Quality attribute Scenarios

En esta sección se definen los escenarios de atributos de calidad más críticos que guiarán las decisiones arquitectónicas de Reqs-AI. Se ha priorizado el Rendimiento (necesario para el procesamiento de audio en tiempo real), la Seguridad (aislamiento de datos), la Disponibilidad (para tolerar fallas externas) y la Modificabilidad (cambio de proveedores de IA).

Atributo	Fuente	Estímulo	Artefacto	Entorno	Respuesta	Medida
Performance (Streaming)	Líder Técnico / Analista Enterprise	El usuario habla durante la sesión de levantamiento de requerimientos.	Motor de Transcripción (STT)	Operación normal del sistema.	El sistema procesa el flujo de audio continuo y renderiza el texto en la interfaz del cliente.	La transcripción parcial debe aparecer en pantalla en menos de 2 segundos.
Performance (Consolidación)	Líder Técnico / Analista Enterprise	El usuario detiene la grabación de la sesión para generar el Gherkin final.	Motor de Procesamiento e Integración LLM	Operación normal del sistema.	El sistema procesa la transcripción, consulta al LLM y retorna el documento estructurado.	El documento final se entrega en menos de 20 segundos tras finalizar la sesión.
Security (Seguridad)	Usuario autenticado del Tenant A	Intenta acceder a través de la API a un ID de proyecto o archivo de audio del Tenant B.	API Gateway / Base de Datos	Operación normal del sistema.	El sistema intercepta la petición, verifica el contexto de seguridad (Row Level Security) y deniega el acceso.	El acceso se bloquea el 100% de las veces y se registra el intento en auditoría.
Availability (Disponibilidad)	Proveedor externo de IA (API)	El servicio del LLM no responde (Timeout) o devuelve un error 500 durante una sesión en vivo.	Motor de Integración de IA	Entorno degradado (Falla de dependencia externa).	El sistema persiste la transcripción con estado Pendiente y encola la solicitud en memoria mediante Eventos de Spring asíncronos para reintentar la conexión.	Se recupera la operación con 0 bytes perdidos.
Modifiability (Modificabilidad)	Arquitecto de Software	El negocio decide cambiar de proveedor de LLM (ej. de OpenAI a Anthropic) por un incremento de precios.	Módulo de Integración de IA	Tiempo de diseño/desarrollo.	El desarrollador implementa un nuevo adaptador (Adapter) para la nueva API sin alterar la lógica de negocio core.	El cambio se completa e integra en menos de 16 horas de desarrollo.

4.1.2.3. Constraints

Esta sección describe las restricciones innegociables impuestas por el modelo de negocio, las capacidades técnicas del equipo y la viabilidad del proyecto. Las principales restricciones incluyen la dependencia de API de LLM externos y el uso del stack tecnológico (Java/Spring Boot y Angular/Vue.js). A continuación, se detallan:

Constraint ID	Título	Descripción	Criterios de Aceptación	Relacionado con (Epic ID)
CON-01	Stack Tecnológico Backend y Frontend	Como equipo de desarrollo, debemos utilizar Java (Spring Boot) para el backend y Angular o Vue.js para el frontend.	Given un nuevo componente a desarrollar When el equipo inicie su construcción Then el código debe estar escrito en Java 17+ usando Spring Boot o TypeScript usando Angular/Vue.js.	EP01, EP02
CON-02	Uso de APIs de LLM externas	Como Arquitecto de Software, debo integrar el sistema con APIs de modelos de terceros (ej. OpenAI, Anthropic), ya que no alojaremos modelos propios.	Given la necesidad de generar Gherkin When el sistema realice una inferencia Then la petición debe enrutarse hacia la API REST del proveedor seleccionado.	EP04
CON-03	Despliegue en Cloud Pública	Como responsable de infraestructura, debo asegurar que los componentes sean desplegados en la nube (AWS, Azure o GCP), para evitar costos on-premise.	Given la liberación de una nueva versión When se ejecute el pipeline de despliegue Then los artefactos deben aprovisionarse en la nube pública seleccionada.	Todas

Justificación de Restricciones:

• CON-01 (Stack Tecnológico Backend y Frontend): El equipo tiene experiencia consolidada en Java/Spring y frameworks web, lo que reduce curva de aprendizaje y riesgo de entrega.
• CON-02 (Uso de API de LLM externas): Los modelos propios no son viables por costos de infraestructura, mantenimiento y talento especializado para entrenamiento y hosting.
• CON-03 (Despliegue en Cloud Pública): La startup necesita reducir costos de inversión inicial y operar con elasticidad sin invertir en infraestructura propia.

4.1.3. Architectural Drivers Backlog

En esta sección se establece el conjunto de Architectural Drivers acordados por el equipo, resultado del proceso iterativo en nuestro Quality Attribute Workshop (QAW). El Architectural Drivers Backlog consolida los Functional Drivers seleccionados (provenientes de las historias de usuario críticas), los Quality Attribute Drivers seleccionados (Performance, Security, Availability, Modifiability) y todos los Constraints del negocio y la tecnología. Todos los Drivers se presentan a continuación, habiendo sido priorizados de forma descendente colocando primero aquellos que representan una Alta importancia para los Stakeholders y un Alto impacto en la Complejidad Técnica de la Arquitectura.

Driver ID	Título de Driver	Descripción	Importancia para Stakeholders (High, Medium, Low)	Impacto en Architecture Technical Complexity (High, Medium, Low)
AD-01	Procesamiento de Audio en Tiempo Real e Integración LLM	El sistema debe ingestar flujos continuos de audio (STT) en <2s y consolidar la inferencia del modelo LLM (Gherkin) en <20s, gestionando operaciones asíncronas durante las reuniones.	High	High
AD-02	Arquitectura Multitenancy y Aislamiento de Datos	El diseño debe garantizar la separación estricta de la información (Row Level Security) entre organizaciones corporativas, denegando el 100% de los accesos cruzados.	High	High
AD-03	Tolerancia a Fallos en Servicios de IA Externos	El sistema debe ser capaz de soportar caídas de las APIs de IA (Timeout/5xx) sin perder datos, procesando las sesiones de forma asíncrona mediante el patrón Observer (Eventos de Spring) y control de estado en la Base de Datos.	High	High
AD-04	Dependencia Estricta de APIs de LLM Externas	Todo el procesamiento de inteligencia generativa dependerá de proveedores externos, lo que obliga al diseño a gestionar rate limits y costos operativos.	High	High
AD-05	Ingesta de Contexto del Cliente y Motor RAG	El sistema debe fragmentar (chunking) y vectorizar los PDFs de contexto de las empresas en <10s para proveer Retrieval-Augmented Generation en las inferencias.	High	Medium
AD-06	Modificabilidad de Proveedores de Inteligencia Artificial	La arquitectura debe ser agnóstica al proveedor del LLM, permitiendo el reemplazo de la API de IA (ej. de OpenAI a Anthropic) en <16 horas de desarrollo mediante adaptadores.	High	Medium
AD-07	Despliegue en Cloud Pública	Todos los componentes deben ser contenerizados y desplegados en una nube pública como AWS o Azure para minimizar costos on-premise y permitir la escalabilidad.	Medium	Medium
AD-08	Stack Tecnológico Base de Desarrollo	El backend debe desarrollarse en Java (Spring Boot) y el frontend en Angular/Vue.js debido al conocimiento técnico previo del equipo, limitando la adopción de otros lenguajes core.	Medium	Low

4.1.4. Architectural Design Decisions

En esta sección se detalla el proceso seguido durante las iteraciones (Stages) del Quality Attribute Workshop para definir la arquitectura de Reqs-AI. En cada etapa, el equipo enfrentó un conjunto específico de Architectural Drivers y evaluó distintos patrones o tácticas de diseño, sopesando sus pros y contras (Trade-offs) para asegurar que la solución cumpla con los atributos de calidad exigidos sin incurrir en over-engineering para la etapa actual de la startup.

Iteración 1: Topología Base y Multitenancy (Drivers: AD-02, AD-07, AD-08) En esta primera iteración se evaluó la estructura general del backend y cómo gestionar el aislamiento de datos. Se descartó la arquitectura de Microservicios por su alta complejidad operativa, optando por un Monolito Modular en Spring Boot (AD-08). Para resolver la separación de datos entre empresas (AD-02), se debatió entre Database-per-Tenant y Shared-Database. Se eligió la base de datos compartida aplicando políticas estrictas de Row Level Security (RLS) a nivel de base de datos (ej. PostgreSQL), lo que garantiza el aislamiento del 100% de la información mientras se optimizan los costos de despliegue en la nube (AD-07).

Iteración 2: Ingesta de Audio en Tiempo Real y Tolerancia a Fallos (Drivers: AD-01, AD-03) El reto principal fue cumplir con la latencia <2 s para la transcripción en vivo (AD-01). Se evaluó REST Polling, Server-Sent Events (SSE) y WebSockets. Se eligió WebSockets por permitir una comunicación bidireccional continua (necesaria para mandar fragmentos de audio al server y recibir texto del STT simultáneamente). Para la tolerancia a fallos ante caídas de las API de IA (AD-03), se descartó la complejidad de un Message Broker externo y se adoptó el uso de Colas en Memoria RAM (Patrón Observer) junto con persistencia de estado en la Base de Datos, optimizando la latencia y reduciendo costos de infraestructura en el MVP.

Iteración 3: Integración RAG y Modificabilidad de IA (Drivers: AD-04, AD-05, AD-06) Finalmente, el equipo abordó cómo evitar el acoplamiento con las API de IA de terceros y cómo lograr el RAG rápido (AD-05). Se descartó la Arquitectura en Capas tradicional a favor de una Arquitectura Hexagonal (Ports and Adapters). Esto permite encapsular las reglas de negocio del Prompt Engineering en el dominio, dejando a OpenAI o Anthropic como simples "adaptadores", cumpliendo la meta de intercambiabilidad en <16 h (AD-06). Para el almacenamiento del contexto del cliente, se eligió una Base de Datos Vectorial (ej. pgvector) superando las limitaciones de búsqueda semántica de las BD relacionales tradicionales.

Candidate Pattern Evaluation Matrix

La siguiente matriz resume la evaluación de los patrones candidatos considerados para los Drivers más críticos, justificando técnica y económicamente la decisión final del equipo.

Driver ID	Título de Driver	Pattern 1	Pattern 2	Pattern 3
AD-01	Procesamiento de Audio en Tiempo Real	REST Long Polling Pro: Fácil implementación inicial. Con: Genera una alta latencia de red e interrumpe el flujo continuo del audio, incumpliendo la meta de <2s. (Descartado)	WebSockets (Elegido) Pro: Comunicación bidireccional y persistente, latencia casi nula para streaming de audio a texto. Con: Añade complejidad al manejo de estados y balanceo de carga.	Server-Sent Events (SSE) Pro: Excelente para enviar texto del servidor al cliente con soporte HTTP nativo. Con: Es unidireccional. No sirve para que el cliente envíe su audio en vivo. (Descartado)
AD-02	Arquitectura Multitenancy y Aislamiento	Database per Tenant Pro: Aislamiento físico de datos impecable. Fácil restauración. Con: Costos exorbitantes para una startup si la plataforma escala a miles de pequeñas empresas. (Descartado)	Shared Database con Row Level Security (Elegido) Pro: Maximiza la economía de infraestructura. El motor (PostgreSQL) asegura que un inquilino jamás vea datos ajenos. Con: Un error en la configuración de la política expone a todos.	(No se evaluó un 3er patrón)
AD-03	Tolerancia a Fallos en Servicios Externos	Cola en Memoria RAM local (Patrón Observer con @Async) (Elegido) Pro: Muy rápido (latencia mínima), simplicidad de código y no requiere aprovisionar infraestructura extra (RabbitMQ/Kafka). Con: Si el servidor se reinicia abruptamente, los eventos en memoria se pierden, por lo que el estado debe respaldarse en Base de Datos.	Message Broker Persistente (ej. RabbitMQ / Kafka) (Descartado) Pro: Garantiza la durabilidad total de los mensajes y retries automáticos si el pod falla. Con: Exceso de ingeniería (Overengineering) para la etapa actual del proyecto. Requiere aprovisionar, configurar y pagar por otro componente pesado en el cloud.	(No se evaluó un 3er patrón)
AD-06	Modificabilidad de Proveedores IA	Arquitectura Monolítica en Capas Pro: Modelo mental simple para el equipo (Controllers, Services, Repositories). Con: Lógica de negocio altamente acoplada al SDK del proveedor de IA. Tomaría semanas migrar. (Descartado)	Arquitectura Hexagonal (Ports & Adapters) (Elegido) Pro: El dominio ignora qué IA se usa. Cambiar a Anthropic solo exige escribir un nuevo Adapter para el Port correspondiente en <16h. Con: Exige escribir más código boilerplate y dominar Inyección de Dependencias.	(No se evaluó un 3er patrón)

4.1.5. Quality Attribute Scenario Refinements

Tras finalizar las iteraciones del Quality Attribute Workshop y definir los patrones arquitectónicos base (WebSockets para el streaming, Shared DB con Row Level Security para el multitenancy, y Arquitectura Orientada Eventos en Memoria para la tolerancia a fallos), procedemos a refinar los escenarios de atributos de calidad priorizados. Estos refinamientos incorporan los artefactos tecnológicos que ahora conocemos y mapean directamente los escenarios con los objetivos de negocio (Business Goals) de la plataforma SaaS, identificando además las preguntas abiertas y riesgos remanentes (Issues).

A continuación, se presenta la versión final de los escenarios refinados en orden de prioridad.

Scenario Refinement for Scenario 1		Procesamiento de Audio en Tiempo Real (Streaming)
Scenario(s):		Procesamiento asíncrono y bidireccional de audio durante la reunión en vivo.
Business Goals:		Garantizar una experiencia de usuario fluida y sin fricciones que posicione a Reqs-AI como una herramienta no intrusiva y veloz, fomentando la adopción temprana por parte de Startups.
Relevant Quality Attributes:		Performance, Usability
	Stimulus:	El usuario habla de forma continua durante la sesión de levantamiento de requerimientos.
Scenario Components	Stimulus Source:	Líder Técnico / Analista Enterprise.
	Environment:	Operación normal del sistema, con conexión a internet estable.
	Artifact (if Known):	Servidor de WebSockets y Motor STT (Speech-to-Text).
	Response:	El sistema ingesta el flujo de audio a través del canal WebSocket abierto y retorna transcripciones parciales asíncronas al cliente.
	Response Measure:	La transcripción parcial aparece en pantalla en < 2 segundos.
Questions:		¿Cuál es el impacto en la memoria RAM del servidor al mantener cientos de conexiones WebSocket concurrentes abiertas durante horas?
Issues:		Posibles desconexiones abruptas de WebSockets en redes corporativas (Enterprise) que utilizan firewalls o proxies estrictos.

Scenario Refinement for Scenario 2		Arquitectura Multitenancy y Aislamiento de Datos
Scenario(s):		Prevención de acceso no autorizado a datos transaccionales de otra organización.
Business Goals:		Cumplir con estrictas normativas de privacidad corporativa para lograr cerrar contratos B2B de alto valor con clientes del segmento Enterprise.
Relevant Quality Attributes:		Security, Data Privacy
	Stimulus:	Intento de lectura/escritura a través de la API hacia un ID de proyecto o archivo de audio que pertenece a otro inquilino (Tenant).
Scenario Components	Stimulus Source:	Usuario autenticado malintencionado o error de enrutamiento en el frontend.
	Environment:	Operación normal, sistema bajo ataque o durante auditoría de seguridad.
	Artifact (if Known):	API Gateway, Spring Security y Base de Datos PostgresSQL (Shared DB con RLS).
	Response:	El filtro RLS de la base de datos deniega la lectura, la API retorna un error 403 Forbidden y el evento se guarda en los logs de auditoría.
	Response Measure:	El acceso se bloquea el 100% de las veces sin fugas de información.
Questions:		¿Cómo afecta la validación de políticas RLS al rendimiento de las consultas complejas (JOIN) cuando la tabla principal supere el millón de registros?
Issues:		Un error humano del DBA al configurar una nueva política RLS podría exponer datos cruzados masivamente si no hay pruebas automatizadas que lo verifiquen.

Scenario Refinement for Scenario 3		Tolerancia a Fallos en Servicios de IA
Scenario(s):		Caída o timeout del proveedor externo de Inteligencia Artificial (OpenAI / Anthropic).
Business Goals:		Evitar la pérdida irreversible de la información capturada en las reuniones para mantener la confianza absoluta de los clientes y minimizar la tasa de abandono (churn rate).
Relevant Quality Attributes:		Availability, Reliability
	Stimulus:	El servicio del LLM no responde (Timeout) o devuelve un error 5xx durante la fase crítica de consolidación de historias.
Scenario Components	Stimulus Source:	Proveedor externo de API de Inteligencia Artificial.
	Environment:	Entorno degradado (Falla crítica de dependencia externa).
	Artifact (if Known):	Módulo de Integración de IA (Adapter Hexagonal) y ApplicationEventPublisher de Spring Boot.
	Response:	El sistema marca el registro como PENDIENTE en base de datos, encola el evento en memoria (@Async), notifica al usuario en la UI ("En proceso diferido") y aplica reintentos.
	Response Measure:	Se recupera la operación y persiste el texto con 0 bytes perdidos.
Questions:		¿Cómo garantizamos que un reinicio no planificado del servidor Spring Boot retome automáticamente las tareas marcadas como PENDIENTES en la Base de Datos?
Issues:		Si el servidor reinicia durante un pico de peticiones concurrentes, los eventos asíncronos en RAM se perderán, requiriendo un job de reconciliación en base de datos al arrancar.

4.2. Strategic-Level Domain-Driven Design

4.2.1. EventStorming

Para establecer una base sólida en el diseño guiado por el dominio (DDD) y facilitar el descubrimiento de nuestros Bounded Contexts, el equipo de Kntro-Soft llevó a cabo una sesión de Design-Level Event Storming utilizando la herramienta colaborativa Miro. La sesión tuvo una duración aproximada de 2 horas. El objetivo principal fue transicionar del espacio del problema (entendido en los capítulos anteriores) al espacio de la solución, mapeando la línea de tiempo completa del negocio de Reqs-AI. Al utilizar un enfoque de nivel de diseño, pudimos no solo explorar los eventos que ocurren en el sistema (como la captura de audio o la generación de Gherkin), sino también agrupar lógicamente las reglas de negocio para descubrir los Agregados (Aggregates) estructurales del código antes de definir las fronteras de los subdominios.

La sesión se estructuró siguiendo una agenda iterativa para construir el modelo de forma progresiva:

1. Domain Events: Iniciamos la sesión identificando en post-its naranjas los hechos relevantes que ocurren en el sistema (escritos como verbos en participio pasado). En esta etapa inicial nos centramos únicamente en la lluvia de ideas de todos los eventos posibles sin preocuparnos por el orden temporal exacto.

2. Timeline: Una vez identificados los eventos, procedimos a organizarlos cronológicamente, creando una línea de tiempo lógica que abarca desde el registro de la organización hasta la exportación de las historias de usuario aprobadas.

3. Pain Points: Con la línea de tiempo establecida, analizamos el flujo para identificar cuellos de botella, problemas potenciales o áreas de fricción (representados visualmente para destacar conflictos en el dominio). Esto nos ayudó a visualizar dónde el sistema requería atención especial.

4. Pivotal Points: Marcamos los eventos cruciales que representan cambios de estado significativos o transiciones importantes en el ciclo de vida del negocio (por ejemplo, el momento en que se completa el pago o se genera la historia de usuario).

5. Commands and Actors: A la izquierda de los eventos, colocamos post-its azules que representan la acción o intención (comandos) que provoca dicho evento. Además, identificamos qué o quién ejecuta estos comandos utilizando post-its amarillos pequeños para los actores humanos (como el Líder Técnico o el Analista Enterprise).

6. Policies: Para las acciones automatizadas o lógicas reactivas del sistema, utilizamos post-its lilas representando las políticas. Es importante destacar que en esta etapa es donde se diseñan las soluciones automáticas y reglas de negocio para resolver los Pain Points identificados anteriormente. Por esta razón, los marcadores de Pain Points desaparecen de los diagramas en los siguientes pasos, ya que el diseño del flujo y las políticas han mitigado esos problemas.

7. Read Models: Insertamos post-its verdes detallando la información necesaria que el usuario debe visualizar antes de tomar una decisión o ejecutar un comando (por ejemplo, el Dashboard de Consumo de Tokens o la vista de transcripción).

8. External Services: Mapeamos las dependencias críticas de Reqs-AI utilizando post-its rosados. Los colocamos entre los comandos y los eventos cuando la acción delega responsabilidad a un tercero (API de IA para LLM, pasarela de pago para Billing, y API de Jira para exportación).

9. Aggregates: Como última capa de agrupación estructural, añadimos post-its amarillos grandes alrededor de los comandos, eventos y modelos de lectura asociados para documentar los Agregados (Aggregates). Estos definen las entidades transaccionales clave y las fronteras de consistencia de datos dentro del dominio.

El resultado de la sesión de Design-Level Event Storming fue un mapa exhaustivo y altamente estructurado del dominio de Reqs-AI. Pasamos de una simple lluvia de ideas a un conjunto de Agregados claramente definidos.

El paso final metodológico del Event Storming, que consiste en agrupar estos Agregados dentro de las fronteras lógicas de los Bounded Contexts correspondientes, se abordará en detalle en la siguiente sección, donde evaluaremos las relaciones semánticas y cohesivas para definir la arquitectura final del dominio.

4.2.2. Candidate Context Discovery

A partir del dominio modelado en nuestra sesión de EventStorming, el equipo llevó a cabo un taller colaborativo de descubrimiento de contextos (Candidate Context Discovery) de aproximadamente 2 horas. El objetivo de esta fase fue trazar fronteras lógicas alrededor de los Agregados identificados previamente, con el fin de descomponer el sistema en módulos altamente cohesivos y con bajo acoplamiento (Bounded Contexts).

Para lograr esto, aplicamos rigurosamente tres heurísticas de Domain-Driven Design recomendadas por la industria (Alberto Brandolini y Nick Tune). Tras una reciente refactorización arquitectónica para evitar el anti-patrón de "Nano-Servicios" y mejorar la cohesión, consolidamos nuestro diseño. A continuación, se explica la aplicación de cada heurística:

1. Aplicación de "Start-with-value" Comenzamos el análisis preguntándonos: ¿Por qué partes del sistema pagarían nuestros clientes? La propuesta de valor radica en capturar reuniones y transformarlas mediante IA en historias de usuario estructuradas.

• Decidimos agrupar los agregados Session (manejo de WebSockets/Audio) y User Story (Prompts y LLM) en un único y potente Core Domain llamado Requirement Discovery. Esto cohesiona todo el flujo de valor principal (Value Stream) bajo un mismo techo, minimizando la latencia de red entre la captura y el análisis.

2. Aplicación de "Look-for-pivotal-events" Buscamos los Eventos Pivote que marcan hitos críticos en la vida del cliente.

• Eventos: "Account Validated", "Organization Created" y "Project Created": Extraímos el agregado User hacia un IAM independiente. Por otro lado, dado que un proyecto solo tiene sentido dentro de la estructura de una empresa, agrupamos Organization y Project en un solo contexto cohesionado llamado Workspace Management.
• Evento: "Upgraded to Pro Plan": Involucra pasarelas de pago y cuotas. Aislamos el agregado Subscription en el Billing & Subscription.

3. Aplicación de "Start-with-simple" Evaluamos las integraciones postprocesamiento.

• Después de que las historias son generadas, deben enviarse a plataformas externas (ej. Jira). Para proteger nuestro Core Domain de los constantes cambios en las API de terceros, aplicamos el patrón Anti-Corruption Layer (ACL) aislando el agregado ExternalConnection en el Integration Gateway.

Resumen de Bounded Contexts Descubiertos A través de este proceso analítico y evolutivo, el sistema quedó dividido arquitectónicamente en los siguientes 5 Candidate Bounded Contexts:

Bounded Context	Tipo de Subdominio	Agregado(s) Principal(es)	Responsabilidad Principal
1. Requirement Discovery	Core Domain	Session, User Story	Ingesta de audio (WebSockets), inferencia mediante LLMs, fragmentación de contexto (RAG) y generación del formato Gherkin.
2. Workspace Management	Generic Subdomain	Organization, Project	Aislamiento Multitenant (Row Level Security), gestión de proyectos, roles corporativos y almacenamiento de glosarios.
3. IAM	Generic Subdomain	User	Autenticación, registro, validación de correo y gestión de credenciales seguras.
4. Billing & Subscription	Generic Subdomain	Subscription	Integración con pasarelas de pago, upgrades/downgrades de planes y monitoreo de consumo de cuotas/tokens.
5. Integration Gateway	Supporting Subdomain	ExternalConnection	Capa Anticorrupción (ACL) para autorizar credenciales (OAuth) y exportar historias hacia herramientas externas como Jira.

4.2.3. Domain Message Flows Modeling

En esta sección, aplicamos una variante técnica de Domain Storytelling enfocado en el flujo de mensajes para evidenciar cómo colaboran los 5 Bounded Contexts consolidados (Requirement Discovery, Workspace Management, IAM, Billing & Subscription, e Integration Gateway) y así resolver los casos principales del negocio.

Utilizamos una notación específica para modelar la interacción:

• Actor: Persona interactuando con el sistema.
• Bounded Context: Módulo lógico de nuestro dominio.
• System: Sistemas o dependencias externas.
• Command: Intención de hacer algo (color azul).
• Event: Hecho que ya ocurrió (color naranja).
• Query: Solicitud de información (color verde).
• Direction of message: Flecha que indica el flujo del emisor al receptor.

A continuación, detallamos los escenarios elaborados.

Escenario 1: Captura de sesión y generación de historias (Core Flow)

Este flujo describe la colaboración principal desde que el usuario inicia la grabación de la reunión hasta que se estructuran las historias de usuario con la Inteligencia Artificial.

1. Inicio y Procesamiento: El Actor Product Owner envía el Command Start Session al Bounded Context Requirement Discovery. Este contexto gestiona el streaming enviando el Command Divide Audio al System STT Service, que retorna progresivamente el Event Speech segments identified.
2. Recopilación de Contexto (RAG): Una vez finalizada la sesión, Requirement Discovery necesita los datos y reglas de negocio del cliente, por lo que envía una Query Request Project Data a Workspace Management, recibiendo el Event Project data sent (que incluye el glosario).
3. Inferencia IA: Con el texto de la reunión y el contexto listos, Requirement Discovery envía el Command Generate User story al System LLM Service. Se consolida el resultado emitiendo el Event final User story generated para que el Product Owner lo revise.

Escenario 2: Suscripción y mejora de organización

Este flujo se enfoca estrictamente en la coreografía arquitectónica que ocurre cuando una organización decide adquirir un plan de pago. Demuestra cómo el sistema reacciona para actualizar las capacidades del entorno sin necesidad de intervención manual de un administrador.

1. Solicitud de Suscripción: El Actor Tech Lead envía el Command Request Pro Upgrade a Billing & Subscription.
2. Procesamiento Externo: Billing & Subscription delega la transacción enviando el Command Process Payment al System Payment Gateway. El sistema externo válido y retorna el resultado.
3. Propagación de Beneficios: Una vez consolidado el pago, Billing & Subscription emite el Event Upgraded to Pro Plan.
4. Aprovisionamiento Automático: El contexto Workspace Management escucha este evento y reacciona automáticamente actualizando los límites operativos de la organización.

Escenario 3: Sincronización Ágil (Exportación a Jira)

Este es un flujo netamente operativo y postprocesamiento. Ocurre después de que el usuario ya utilizó el sistema core y desea llevar el resultado final hacia sus herramientas de gestión de proyectos.

1. Aprobación: Tras haber revisado las historias generadas por la IA, el Actor Tech Lead envía el Command Approve Story a Requirement Discovery.
2. Propagación: El contexto core registra el cambio y emite el Event Story Approved.
3. Capa Anticorrupción: El evento es escuchado por el Integration Gateway. Este contexto actúa como ACL (aislando al core domain de los detalles de API externas), mapea el modelo interno al formato esperado por el sistema externo, y envía el Command Create Issue al System PM Service.
4. Confirmación y Retorno: El System PM Service responde exitosamente con los datos del ticket. El Integration Gateway traduce esta respuesta al lenguaje de nuestro dominio y emite el Event Story Exported.

4.2.4. Bounded Context Canvases

En esta sección el equipo diseña sus candidate bounded contexts, detallando los criterios de diseño. El equipo seleccionó cada bounded context, por orden de importancia, para elaborar su Bounded Context Canvas.

1. Requirement Discovery

Motor central de la plataforma responsable de ingerir el audio de las reuniones en tiempo real, orquestar la transcripción y aplicar Inteligencia Artificial con contexto (RAG) para generar historias de usuario estructuradas en formato Gherkin.

2. Workspace Management

Módulo organizativo que garantiza el aislamiento de datos (Multitenancy), gestiona la jerarquía corporativa (proyectos) y almacena el conocimiento específico del cliente (Glosarios) para contextualizar la IA.

3. Identity and Access Management

Este contexto asegura el acceso a la plataforma mediante autenticación y gestión de usuarios.

4. Billing & Subscription

Este contexto monitorea el uso de las cuotas de IA y gestiona los pagos recurrentes integrando pasarelas externas.

5. Integration Gateway

Capa Anticorrupción (ACL) que protege el Core Domain de los cambios en API de terceros. Se encarga de traducir los eventos del sistema a formatos externos y exportar las historias hacia herramientas como Jira.

4.2.5. Context Mapping

En esta sección evidenciamos el proceso de elaboración de nuestro Context Map. Para llegar al diseño estructural definitivo de nuestros 5 Bounded Contexts, el equipo evaluó el modelo sometiéndolo a un análisis crítico, respondiendo a las preguntas estratégicas de diseño sugeridas. Además, aplicamos rigurosamente los patrones de integración definidos por el repositorio oficial de Context Mapping de DDD Crew.

Evaluación de Alternativas y Diseños Candidatos

• ¿Qué pasaría si agrupamos dos contextos fuertemente acoplados en uno solo? Inicialmente, considerábamos separar la captura de audio (WebSockets) de la generación de la historia (LLM). Sin embargo, al aplicar esta pregunta, nos dimos cuenta de que ambos son parte inseparable del mismo flujo de valor en tiempo real. Agruparlos en un único Core Domain llamado Requirement Discovery eliminó la latencia de red y la serialización innecesaria entre ambos pasos. Aplicamos la misma lógica para fusionar Organización y Proyecto dentro de Workspace Management.
• ¿Qué pasaría si aislamos los core capabilities y movemos los otros a un context aparte? Una vez consolidado el Core, evaluamos el proceso de exportar las historias hacia gestores de proyectos (Jira). Notamos que la integración con terceros es puramente una capacidad de soporte. Por ello, aislamos el core de IA y movimos toda la comunicación externa hacia el Integration Gateway. Esto evita que los cambios constantes en API de terceros contaminen nuestro motor de inferencia.
• ¿Qué pasaría si duplicamos una funcionalidad para romper la dependencia? Evaluamos la validación de cuotas. Si Requirement Discovery tuviera que preguntar sincrónicamente a Billing & Subscription si un usuario tiene saldo antes de cada uso de IA, el sistema sería lento y frágil. Decidimos romper esta dependencia directa. Billing & Subscription emite eventos asíncronos cuando una cuota se actualiza, y Workspace Management duplica y almacena localmente esta capacidad. Así, el Core Domain solo consulta su contexto local sin bloqueos de red.

Patrones de Relación DDD Establecidos

Tras este debate, definimos formalmente los patrones de integración estratégicos. Las relaciones indican quién es el proveedor (Upstream U) y quién es el consumidor (Downstream D).

1. Integration Gateway [D] hacia External PM Service (Jira) [U]

   • Patrón: Anti-Corruption Layer (ACL)
   • Justificación: El Integration Gateway actúa como una barrera traductora unidireccional. Consume los eventos de dominio internos del producto, formulados en nuestro lenguaje ubicuo, y los transforma al esquema propietario y mutable de Atlassian. Nuestro Core jamás adopta las convenciones de modelado de Jira ni se entera de cómo funciona su API, lo que preserva la pureza semántica del dominio de elicitación de requisitos.
   • Naturaleza del contrato traducido por el ACL: El Gateway implementa adaptadores que convierten los conceptos de dominio internos (aprobación de historias, rechazo con motivo, referencias a épicas) a las estructuras propietarias que Atlassian exige: sus tipos de campos, sus formatos de descripción enriquecida, su esquema de identificadores externos y sus convenciones de priorización. Esta traducción es bidireccional cuando se necesita trazabilidad: el identificador interno de cada historia se mapea y persiste junto al identificador externo que Jira asigna, sin contaminar el modelo de dominio del Core.
   • Análisis de Impacto del Patrón ACL en la evolución del sistema: El equipo evaluó tres escenarios concretos donde el ACL demuestra su valor:
     1. Cambios en la API de Atlassian: Si Atlassian modificara la versión de su API o migrara a un esquema completamente distinto, únicamente la implementación interna del Gateway requeriría actualización. Ningún módulo del Core sufriría modificación alguna en su modelo de dominio ni en su lógica de negocio.
     2. Cambio entre variantes de Jira: La migración entre Jira Cloud, Jira Data Center o Jira Server —cada una con mecanismos de autenticación, paginación y límites de tasa distintos— se absorbe completamente dentro del Gateway mediante implementaciones intercambiables del mismo contrato interno, sin exponer esa variabilidad hacia el resto del sistema.
     3. Limitaciones operativas externas: Las restricciones de consumo que Atlassian impone por plan (límites de llamadas por segundo) son gestionadas internamente por el Gateway con políticas de reintento, tolerancia a fallos y encolado, sin contaminar la lógica de los módulos internos con preocupaciones de infraestructura externa.
   • Tradeoff consciente y costo del aislamiento: El equipo asume el costo de mantener un adaptador por cada herramienta de gestión soportada y la duplicación temporal de representaciones (interna vs. externa). Este costo se justifica por la naturaleza heterogénea del mercado objetivo: el roadmap incluye soporte futuro para Trello, Asana, ClickUp y Linear, todas con esquemas radicalmente distintos. Sin el ACL, cada nueva integración obligaría a contaminar el Core con concesiones específicas de cada vendor.

2. Requirement Discovery [D] hacia External AI Services (LLM / STT) [U]

   • Patrón: Anti-Corruption Layer (ACL)
   • Justificación: Para evitar el vendor lock-in con proveedores de IA cuyos contratos de API evolucionan mensualmente (OpenAI, Anthropic, AssemblyAI, Deepgram, entre otros), el ACL traduce las solicitudes de inferencia y los flujos de audio internos del dominio al esquema específico del proveedor activo. El modelo de dominio de Requirement Discovery permanece estable e independiente de los cambios externos, lo que es crítico en un Core Domain donde la inferencia de IA representa la principal propuesta de valor del producto.
   • Naturaleza del contrato traducido por el ACL: El Gateway de IA expone al dominio dos abstracciones bien definidas: una para la inferencia de lenguaje (recibe la transcripción de la reunión, el glosario del proyecto y el historial de historias previas; devuelve historias estructuradas en Gherkin) y otra para la transcripción de audio en tiempo real (recibe fragmentos de audio en streaming; devuelve segmentos de texto con marcas temporales). Cada adaptador concreto es responsable de traducir estas abstracciones al contrato particular del proveedor —con sus formatos de autenticación, sus estructuras de mensaje, sus parámetros de configuración y sus esquemas de respuesta—, sin que el dominio conozca esa especificidad.
   • Análisis de Impacto del Patrón ACL en la evolución del sistema: El equipo evaluó tres escenarios donde el ACL es estratégicamente determinante:
     1. Cambio de proveedor de IA: Migrar el motor de inferencia de un proveedor a otro —motivado por costo, calidad de razonamiento, latencia o regulación de datos en regiones específicas— requiere únicamente desarrollar un nuevo adaptador interno. El modelo de dominio, la lógica de RAG y los flujos de sesiones permanecen completamente inmutables.
     2. Cambio de modelo dentro del mismo proveedor: Las actualizaciones de modelos dentro de un mismo proveedor frecuentemente alteran el comportamiento esperado ante ciertos tipos de instrucciones. El ACL encapsula los ajustes necesarios de construcción de prompts específicos por modelo sin que esos detalles se propaguen al Domain.
     3. Estrategia de continuidad ante degradación: Si el proveedor primario sufre una interrupción del servicio o impone restricciones de consumo agresivas, el ACL puede orquestar un desvío automático hacia un proveedor secundario equivalente, garantizando la continuidad del Core sin que el dominio conozca la sustitución.
   • Tradeoff consciente y costo del aislamiento: Mantener múltiples adaptadores —uno por cada proveedor soportado— representa una carga de mantenimiento real: cada cambio en una API externa exige actualizar el adaptador correspondiente y verificar la paridad funcional. Sin embargo, en una categoría de mercado donde los proveedores liberan modelos disruptivos cada pocos meses y sus políticas de precios pueden cambiar unilateralmente, el costo de quedar atado a un único vendor supera ampliamente el costo de mantener la abstracción.

3. Requirement Discovery [D] hacia Workspace Management [U]

   • Patrón: Customer / Supplier
   • Justificación: Requirement Discovery [Customer] establece una relación de dependencia activa pero negociada con Workspace Management [Supplier]. Como Core Domain, Requirement Discovery exige que el contexto del proyecto —el glosario de términos técnicos del cliente, las restricciones arquitectónicas y el historial de historias previas— se le entregue en un formato canónico, limpio y oportuno para inyectarlo en el motor RAG. Workspace Management, reconociendo la prioridad estratégica de su cliente, adapta sus procesos internos de ingesta, normalización y curación para satisfacer esa necesidad sin imponer su propio modelo interno.
   • Naturaleza del contrato negociado: La relación se materializa en un contrato de contexto de proyecto formalmente versionado y consensuado entre ambos contextos: incluye el glosario de términos con sus definiciones y sinónimos, las restricciones que el cliente ha declarado sobre su arquitectura, y el resumen de historias ya generadas. El contrato incluye acuerdos de frescura de los datos —el contexto entregado debe reflejar el estado más reciente con un desfase máximo aceptable—, de latencia de generación y de política de versionado bilateral, donde cualquier cambio estructural requiere retrocompatibilidad durante al menos un ciclo de desarrollo completo.
   • Análisis de Impacto del Patrón Customer/Supplier en la evolución del sistema: El equipo evaluó tres dinámicas que esta relación introduce:
     1. Priorización del backlog de Workspace: Las solicitudes provenientes de Requirement Discovery —mejoras al procesamiento de documentos del cliente, enriquecimiento del glosario, soporte multiidioma— tienen prioridad operativa sobre el backlog interno de Workspace, lo que ocasionalmente fuerza a Workspace a postergar mejoras propias a la gestión de organizaciones.
     2. Crecimiento del volumen de datos: Si un proyecto enterprise supera ciertos umbrales de tamaño del glosario o del historial de historias, el contrato actual —que entrega un snapshot completo en cada consulta— se vuelve insostenible en términos de latencia y consumo de memoria. Esto obligaría a renegociar el contrato hacia una entrega incremental o paginada, con implicancias de rediseño en ambos contextos.
     3. Evolución del concepto de "contexto": Si el equipo de producto decide enriquecer el RAG con nuevas fuentes de información del cliente —diagramas de arquitectura, documentación de API, transcripciones de reuniones anteriores—, Workspace deberá expandir su capacidad de ingesta y curación para honrar la nueva expectativa del Customer, en cada iteración que el producto agregue una nueva fuente de contexto.
   • Tradeoff consciente y dinámica de poder: El patrón Customer/Supplier reconoce explícitamente una asimetría de prioridades: Workspace cede parte de su autonomía de roadmap a cambio de servir al Core Domain que genera el principal valor del producto. Esta dinámica funciona eficientemente mientras el mismo equipo gestione ambos contextos. Si Reqs-AI escalara con equipos dedicados por contexto, esta relación debería formalizarse