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.

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:

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.X. Bounded Context:
    • 5.X.1. Domain Layer
    • 5.X.2. Interface Layer
    • 5.X.3. Application Layer
    • 5.X.4. Infrastructure Layer
    • 5.X.6. Bounded Context Software Architecture Component Level Diagrams
    • 5.X.7. Bounded Context Software Architecture Code Level Diagrams
      • 5.X.7.1. Bounded Context Domain Layer Class Diagrams
      • 5.X.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.	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.
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.	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.

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 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.	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	Validar Credibilidad (Social Proof)	Como visitante escéptico, quiero ver testimonios, métricas de éxito o logos de empresas que ya usan la herramienta, para sentir confianza antes de invertir mi tiempo o dinero en la plataforma.	Feature: Landing Page - Social Proof Scenario: Visualización de respaldo social Given un visitante explorando los beneficios de la herramienta When llega a la sección de confianza (Social Proof) Then el sistema le presenta un carrusel de testimonios o métricas de horas ahorradas And no permite avanzar hacia el final sin antes exponer estas validaciones de mercado.	EP00
US04	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 (Toggle Mensual/Anual) 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.	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.	--	--
US03	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
US04	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	EP01
US05	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
US06	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	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.	--	--
US07	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
US32	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
US33	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
US41	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.	--	--
US42	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	EP03
US43	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
US44	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 (Happy Path) Given el Propietario de una organización en Plan Pro When contrata el Plan Equipo Then se habilitan las funciones de gestión avanzada de roles y miembros múltiples	EP03
US45	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	EP03
US46	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	EP03
US47	Dashboard de valor y ahorro de tiempo	Como Propietario de la organización, quiero ver un panel que traduzca las historias generadas en 'horas de trabajo manual ahorradas', para justificar el pago de la suscripción y entender el retorno de inversión mensual de la herramienta.	Feature: Dashboard de ROI Scenario: Calcular ROI exitosamente (Happy Path) Given una organización con proyectos y sesiones generadas When el administrador ingresa al dashboard principal Then el sistema calcula el tiempo humano ahorrado en base a las horas de audio procesadas vs redacción manual And muestra gráficas de productividad y métricas clave de retorno de inversión Scenario: Organización sin historial (Unhappy Path) Given una organización recién creada sin sesiones activas When el administrador visita el dashboard Then el sistema muestra un estado vacío con un mensaje orientativo sobre cómo comenzar a capturar valor	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.	--	--
US08	Crear proyecto	Como miembro con permiso para crear proyectos, 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 usuario con permisos de creación When crea un 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
US10	Cargar documentos del cliente	Como miembro con permiso para configurar proyectos, quiero subir documentos y glosarios del cliente al proyecto, para que las historias generadas reflejen el vocabulario y las reglas del negocio de ese cliente de forma observable en cada historia producida.	Feature: Cargar documentos del cliente Scenario: Carga de contexto exitosa (Happy Path) Given un usuario configurando un proyecto When sube un glosario en PDF válido Then el sistema procesa el documento y lo incorpora a la base de conocimiento de la IA 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
US11	Configurar perfil técnico del proyecto	Como miembro con permiso para configurar proyectos, 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 usuario con permisos en 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	EP04
US30	Editar proyecto	Como miembro con permiso para administrar proyectos, 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 usuario administrador del proyecto When cambia la descripción del proyecto Then los cambios se reflejan inmediatamente en el panel del equipo	EP04
US31	Archivar proyecto	Como miembro con permiso para administrar proyectos, 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
US09	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.	--	--
US34	Invitar miembro a la organización	Como miembro con permiso para gestionar el equipo, 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
US35	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' Then el nuevo rol queda disponible para ser asignado a cualquier miembro	EP05
US36	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	EP05
US37	Asignar rol a un miembro	Como miembro con permiso para gestionar el equipo, 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. Depende de: US19 y US20.	Feature: Asignar rol a un miembro Scenario: Cambio de rol (Happy Path) Given un administrador de equipo 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	EP05
US38	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	EP05
US39	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
US40	Remover miembro de la organización	Como miembro con permiso para gestionar el equipo, 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
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.	--	--
US32	Iniciar sesión de captura en vivo	Como miembro con permiso para crear sesiones, 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: US13.	Feature: Captura en vivo Scenario: Iniciar captura exitosamente (Happy Path) Given que el usuario tiene permisos y el proyecto es válido 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 usuario 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 usuario 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 usuario que verifique su conexión	EP06
US33	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
US19	Descartar historia (Componente Unificado)	Como analista, quiero descartar una historia generada indicando un motivo, tanto durante la sesión en vivo como en la etapa de revisión posterior, utilizando una misma interfaz para mantener el backlog limpio.	Feature: Descarte de historias en vivo Scenario: Descartar historia correctamente (Happy Path) Given una historia recién generada en el backlog de la sesión When el analista la descarta ingresando un motivo válido Then la historia se oculta del backlog activo And queda registrada en el historial 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: Descarte concurrente (Unhappy Path - Flujo Alternativo) Given una historia visible en pantalla When el analista intenta descartarla pero otro usuario ya lo hizo segundos antes Then el sistema alerta que el estado de la historia ha cambiado And refresca la vista del backlog	EP06
US15	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
US16	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
US18	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
US13	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.	--	--
US39	Subir grabación de reunión	Como miembro con permiso para crear sesiones, 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 usuario tiene permisos para crear sesiones And la organización tiene minutos de procesamiento disponibles When el usuario 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 usuario 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
US12	Manejo de límite de tokens (Chunking) en IA	Como sistema de procesamiento, quiero dividir los audios grandes en fragmentos manejables (Chunking) antes de enviarlos al LLM, para evitar errores de 'límite de tokens excedido' cuando las reuniones son muy largas.	Feature: Manejo de tokens y chunking Scenario: Procesar audio extremadamente largo (Happy Path) Given un archivo de audio que excede la ventana de contexto del LLM (ej. reunión de 2 horas) When el sistema inicia el proceso de transcripción y análisis Then divide internamente el audio en bloques lógicos (chunks) sin cortar oraciones por la mitad And los procesa en lote para consolidar los requisitos sin error de límite de tokens Scenario: Error al ensamblar chunks (Unhappy Path - Backend) Given un audio dividido en 5 fragmentos When el motor de IA procesa exitosamente 4 pero falla en 1 por intermitencia de red Then el sistema reintenta exclusivamente el fragmento fallido en lugar de reiniciar todo el procesamiento And garantiza que no se pierda la información ensamblando el resultado final de forma consistente	EP07
US14	Ver estado del procesamiento	Como miembro que subió un archivo de audio, 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: US30.	Feature: Estado del procesamiento Scenario: Consultar el avance del procesamiento (Happy Path) Given que un archivo de audio se subió exitosamente When el usuario 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 usuario reintentar el procesamiento sin volver a subir el archivo	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.	--	--
US22	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: US26.	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
US23	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: US26.	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
US24	Sugerencias de funcionalidades relacionadas	Como analista en una sesión activa, quiero recibir una lista de funcionalidades que otros sistemas del mismo sector suelen incluir y que el cliente no mencionó, para presentarlas como opciones concretas durante la reunión y que el cliente decida si las quiere o no.	Feature: Funcionalidades relacionadas Scenario: Sugerir funcionalidades típicas del dominio (Happy Path) Given un proyecto con un dominio de negocio bien definido (ej. E-commerce) When el sistema procesa los requerimientos actuales Then sugiere funcionalidades complementarias comunes en el mercado (ej. 'Recuperación de carrito') Scenario: Omitir repeticiones durante la sesión (Edge Case) Given una sesión larga en curso When el sistema genera un nuevo lote de sugerencias relacionadas Then filtra cualquier funcionalidad que ya haya sido sugerida o descartada previamente en la misma sesión	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.	--	--
US20	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
US21	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: US35.	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.	--	--
US47	Editar historia generada	Como miembro con permiso para editar historias, 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 usuario con permisos 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 usuario 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
US48	Aprobar historia	Como miembro con permiso para aprobar historias, 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 usuario 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
US17	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
US26	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	EP10
US25	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
EP11	Integraciones Externas	Conectividad con herramientas del ecosistema de desarrollo para transferir las historias aprobadas al backlog del equipo sin trabajo manual.	--	--
US27	Conectar cuenta de Jira	Como miembro con permiso para configurar integraciones, 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 usuario administrador 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 usuario 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
US28	Configurar mapeo de proyecto en Jira	Como administrador, 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 usuario accede a la configuració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 usuario a la pantalla de mapeo de configuración	EP11
US29	Exportar historias a Jira	Como miembro con permiso para exportar historias, 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: US38 y US41.	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 usuario 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 usuario 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.	--	--
TS55	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
TS56	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
TS57	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
TS58	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
TS59	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
TS60	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
TS61	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
TS62	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
TS63	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
TS64	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
TS65	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
TS66	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

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	Validar Credibilidad (Social Proof)	Como visitante escéptico, quiero ver testimonios, métricas de éxito o logos de empresas que ya usan la herramienta, para sentir confianza antes de invertir mi tiempo o dinero en la plataforma.	2
4	US04	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.	3
5	US35	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
6	US36	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
7	US34	Descartar historia (Componente Unificado)	Como analista, quiero descartar una historia generada indicando un motivo, tanto durante la sesión en vivo como en la etapa de revisión posterior, utilizando una misma interfaz para mantener el backlog limpio.	3
8	US37	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
9	TS62	API: Subir Audio (POST /sessions/upload)	Como Developer, quiero un endpoint que reciba un multipart/form-data y lo suba a Cloud Storage.	3
10	TS63	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
11	TS64	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
12	US38	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
13	US40	Manejo de límite de tokens (Chunking) en IA	Como sistema de procesamiento, quiero dividir los audios grandes en fragmentos manejables (Chunking) antes de enviarlos al LLM, para evitar errores de 'límite de tokens excedido' cuando las reuniones son muy largas.	8
14	US41	Ver estado del procesamiento	Como miembro que subió un archivo de audio, 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: US30.	2
15	US45	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
16	US46	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: US35.	3
17	US42	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: US26.	5
18	US43	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: US26.	3
19	US44	Sugerencias de funcionalidades relacionadas	Como analista en una sesión activa, quiero recibir una lista de funcionalidades que otros sistemas del mismo sector suelen incluir y que el cliente no mencionó, para presentarlas como opciones concretas durante la reunión y que el cliente decida si las quiere o no.	3
20	US21	Configurar perfil técnico del proyecto	Como miembro con permiso para configurar proyectos, 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
21	US20	Cargar documentos del cliente	Como miembro con permiso para configurar proyectos, quiero subir documentos y glosarios del cliente al proyecto, para que las historias generadas reflejen el vocabulario y las reglas del negocio de ese cliente de forma observable en cada historia producida.	5
22	US24	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
23	US22	Editar proyecto	Como miembro con permiso para administrar proyectos, 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
24	US23	Archivar proyecto	Como miembro con permiso para administrar proyectos, 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
25	US49	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
26	US50	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
27	US51	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
28	TS65	API: Auth Jira (GET /integrations/jira/auth)	Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian.	3
29	TS66	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
30	US52	Conectar cuenta de Jira	Como miembro con permiso para configurar integraciones, 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
31	US53	Configurar mapeo de proyecto en Jira	Como administrador, 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
32	US54	Exportar historias a Jira	Como miembro con permiso para exportar historias, 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: US38 y US41.	5
33	US25	Invitar miembro a la organización	Como miembro con permiso para gestionar el equipo, 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
34	US26	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
35	US27	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
36	US28	Asignar rol a un miembro	Como miembro con permiso para gestionar el equipo, 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. Depende de: US19 y US20.	1
37	US29	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
38	US30	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
39	US31	Remover miembro de la organización	Como miembro con permiso para gestionar el equipo, 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
40	TS55	API: Registro de Usuario (POST /auth/register)	Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos.	2
41	TS56	API: Login de Usuario (POST /auth/login)	Como Developer, quiero un endpoint que valide credenciales y retorne un JWT.	2
42	TS57	API: Perfil de Usuario (GET /auth/me)	Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT.	1
43	US05	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
44	US06	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
45	US07	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
46	US08	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
47	US09	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
48	US10	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
49	US11	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
50	TS58	API: Crear Proyecto (POST /projects)	Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo.	2
51	TS59	API: Listar Proyectos (GET /projects)	Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado.	1
52	TS60	API: Actualizar Proyecto (PUT /projects/{id})	Como Developer, quiero un endpoint para modificar metadatos de un proyecto.	1
53	TS61	API: Eliminar Proyecto (DELETE /projects/{id})	Como Developer, quiero un endpoint de soft-delete para archivar proyectos.	1
54	US12	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
55	US13	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
56	US14	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
57	US15	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
58	US16	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
59	US17	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
60	US18	Dashboard de valor y ahorro de tiempo	Como Propietario de la organización, quiero ver un panel que traduzca las historias generadas en 'horas de trabajo manual ahorradas', para justificar el pago de la suscripción y entender el retorno de inversión mensual de la herramienta.	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)
US05	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
US16	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
US29	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

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 como Technical Stories:

Technical Story ID	Título	Descripción	Criterios de Aceptación	Relacionado con (Epic ID)
TS01	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, debido a la experiencia técnica previa del equipo.	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
TS02	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
TS03	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

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 mediante contratos de integración automatizados y verificables (consumer-driven contract testing) para mantener la salud del acuerdo sin depender de la coordinación informal entre personas.

4. Workspace Management [D] hacia IAM [U] y Billing & Subscription [U]

   • Patrón: Conformist (CF)
   • Justificación: Workspace Management se conforma al modelo de identidad que IAM define y al modelo de suscripción que Billing establece —ambos dictados en gran medida por los estándares de los sistemas externos que integran (pasarelas de identidad y de pago). Al adoptar el patrón Conformist, Workspace acepta que es un consumidor pasivo: no puede negociar ni alterar el esquema de ninguno de estos dos contextos proveedores.
   • Naturaleza del acoplamiento por contagio: Workspace Management replica internamente un subconjunto del modelo de Billing para poder evaluar si una organización tiene cuotas disponibles sin depender de llamadas sincrónicas a Billing en cada operación. Esto significa que Workspace almacena localmente la categoría de plan activo, el estado de la suscripción y los saldos de consumo disponibles, actualizando esa información de forma reactiva cada vez que Billing emite eventos de cambio de estado. De forma análoga, Workspace incorpora los identificadores y roles de identidad que IAM define, sin cuestionarlos ni adaptarlos a su propia semántica interna.
   • Análisis de Impacto del Patrón Conformist en la evolución del sistema: Asumir el rol de Conformist genera un acoplamiento estructural unidireccional con consecuencias evolutivas concretas que el equipo ha evaluado en tres escenarios:
     1. Cambio en el modelo de monetización: Si Billing evolucionara de un esquema de planes fijos a un modelo de consumo por uso —por minutos de reunión procesada o por volumen de historias generadas—, Workspace deberá reescribir completamente su lógica de validación de cuotas para adaptarse al nuevo esquema de medición, sin poder influir en cómo Billing decide estructurarlo. Esto implicaría una migración de datos no trivial y la actualización coordinada de toda la lógica de control de acceso en Requirement Discovery.
     2. Cambio de pasarela de pago: Si Billing migrara a una pasarela de pagos distinta —motivado por el mercado local peruano o latinoamericano—, los identificadores externos de suscripción que Workspace almacena por trazabilidad quedarían obsoletos. Esto forzaría una migración de datos coordinada entre ambos contextos, con riesgo de pérdida de histórico de auditoría y la necesidad de mantener temporalmente ambas representaciones durante el período de transición.
     3. Despliegue acoplado: Cualquier evolución en el contrato de los eventos que Billing pública para notificar cambios de estado de suscripción requiere despliegues coordinados de ambos contextos. Esto rompe el principio de despliegue independiente que buscaríamos en una arquitectura modular madura y obliga a versionar cuidadosamente los eventos compartidos con políticas de retrocompatibilidad explícitas.
   • Tradeoff consciente y umbral de migración a ACL: El equipo acepta esta deuda arquitectural mientras Billing siga siendo un Generic Subdomain estable y la startup priorice la velocidad de entrega sobre la autonomía evolutiva de Workspace. Sin embargo, se establecen tres condiciones de disparo que justificarían introducir un Anti-Corruption Layer entre Workspace y Billing en futuras iteraciones: (a) que el modelo de negocio de Billing cambie más de una vez por trimestre, (b) que se incorpore una segunda pasarela de pago para soportar mercados regionales con métodos locales de cobro, o (c) que Workspace deba soportar estructuras de planes diferenciadas por geografía o tipo de organización. Mientras estos disparadores no se activen, el costo de construir y mantener un ACL supera el costo del re-trabajo ocasional sobre Workspace.

5. Requirement Discovery [U] hacia Integration Gateway [D]

   • Patrones: Open Host Service (OHS) y Published Language (PL)
   • Justificación: El Core Domain Requirement Discovery actúa como un host abierto que emite eventos de dominio estandarizados a través de un canal público bien definido, expresados en un Published Language compartido y versionado. Cualquier contexto o sistema externo puede suscribirse a este canal sin requerir modificaciones en el Core. Esta arquitectura desacopla completamente al productor de los consumidores y permite la evolución independiente de ambos lados de la integración.
   • Naturaleza del lenguaje publicado y del canal abierto: El equipo formalizó el contrato del OHS en tres dimensiones: los tipos de eventos que Requirement Discovery pública —relacionados con los cambios de estado del ciclo de vida de cada historia de usuario y de cada sesión de elicitación—, la estructura común que todos los eventos comparten —con metadatos de trazabilidad, versionado semántico y contexto de tenant para soportar el multitenancy— y el canal de transporte —actualmente en memoria dentro del monolito modular, pero diseñado con la abstracción suficiente para migrarlo a un bus de eventos distribuido si la arquitectura evoluciona en el futuro.
   • Análisis de Impacto del Patrón OHS+PL en la evolución del sistema: El equipo evaluó tres beneficios concretos que esta arquitectura habilita:
     1. Incorporación de nuevos consumidores sin modificar el Core: En futuras iteraciones podrán incorporarse consumidores adicionales —notificaciones hacia plataformas de colaboración del cliente, exportaciones hacia otros gestores de proyectos, servicios de analítica de productividad— simplemente suscribiéndose al canal publicado, sin que Requirement Discovery requiera modificación alguna.
     2. Evolución interna del Core sin disrupción externa: Mientras el Published Language permanezca estable, Requirement Discovery puede refactorizar libremente su modelo interno, cambiar de proveedor de IA, optimizar su motor RAG o rediseñar su capa de persistencia, sin afectar a ningún consumidor downstream.
     3. Política de versionado retrocompatible: Los cambios aditivos al Published Language —incorporación de campos opcionales— son retrocompatibles y no requieren coordinación con los consumidores. Los cambios disruptivos —renombrado, eliminación o cambio de cardinalidad de elementos del contrato— requieren publicar el evento bajo una nueva versión y mantener la versión anterior activa durante un período de transición acordado, para dar tiempo a los consumidores a migrar sin interrupciones.
   • Tradeoff consciente y rigidez del contrato público: Adoptar OHS+PL convierte al Published Language en un activo crítico cuya estabilidad es responsabilidad del Core Domain. Cada cambio en el contrato debe ser deliberado, comunicado y documentado, lo que reduce la velocidad de iteración interna sobre los tipos y estructuras de eventos publicados. Sin embargo, esta rigidez es exactamente el tipo de disciplina que se espera de un Core Domain maduro: el costo de esa lentitud en el contrato público se compensa ampliamente al habilitar un ecosistema de consumidores extensible, desacoplado y robusto a largo plazo.

Diagrama de Context Map Final

A continuación presentamos la visualización de las relaciones estructurales consolidadas tras aplicar los patrones descritos. Las líneas conectan los Bounded Contexts indicando los roles U y D y los patrones aplicados sobre ellas.

4.3. Software Architecture

En este capítulo, el equipo detalla la arquitectura de software de Reqs-AI aplicando el modelo C4. Este modelo jerárquico permite documentar el sistema desde su ecosistema más amplio hasta sus componentes desplegables y su entorno de infraestructura final. Todas las decisiones reflejadas en estos diagramas están alineadas con los Atributos de Calidad y Restricciones analizados previamente, como el uso del Monolito Modular, la tolerancia a fallos en memoria y el multitenancy seguro.

4.3.1. Software Architecture System Landscape Diagram

El System Landscape Diagram proporciona una vista panorámica del ecosistema tecnológico en el que habita Reqs-AI. A diferencia de un simple diagrama de contexto que solo mira hacia adentro, este diagrama ilustra cómo nuestro sistema principal (agrupado dentro de los límites de la empresa Kntro-Soft Enterprise) interactúa no solo con los usuarios, sino también con el entorno de herramientas de terceros que el usuario final ya utiliza en su día a día corporativo.

A continuación, se presenta la topología del paisaje del sistema:

Análisis de Interacciones en el Ecosistema:

1. Límite Empresarial Kntro-Soft Enterprise: Agrupa a nuestros actores principales (Technical Lead y Enterprise Analyst) interactuando centralmente con el ReqsAI System. Este es el núcleo de valor donde se graban las reuniones, se analizan los requerimientos y se estructuran en historias de usuario.
2. Proveedores de Inteligencia y Procesamiento (Core Dependencies): En la parte inferior, observamos las dependencias críticas (SaaS) que Reqs-AI delega para cumplir sus objetivos complejos:
   • STT API (Speech-to-Text): Recibe los fragmentos de audio en tiempo real y devuelve el texto.
   • LLM API (Large Language Model): Recibe el contexto del RAG y la transcripción para inferir historias en formato Gherkin.
   • Payment Gateway: Procesa las transacciones de las suscripciones B2B corporativas.
3. Herramientas de Ecosistema del Cliente (The Landscape Effect): La verdadera amplitud del ecosistema se observa en los bordes laterales:
   • Project Management Tool Jira: El diagrama evidencia que el Technical Lead gestiona sus Sprints directamente en Jira. ReqsAI actúa como un puente inteligente que exporta las historias de usuario aprobadas hacia esta herramienta, cerrando la brecha entre el levantamiento de requerimientos y la ejecución ágil.
   • Email Service Provider: El Enterprise Analyst recibe notificaciones de su organización a través de su proveedor de correo, alimentadas por los eventos disparados desde nuestro sistema.

4.3.2. Software Architecture Context Level Diagrams

Mientras que el Diagrama Landscape nos mostró el panorama del negocio, el Diagrama de Contexto (Context Level Diagram) del modelo C4 cambia el foco hacia el interior, centrando toda la atención arquitectónica exclusivamente en el Reqs-AI System. Este diagrama responde a la pregunta de "¿Cuáles son las fronteras inmediatas de nuestra solución?".

A nivel de contexto, eliminamos las interacciones directas entre los usuarios y los sistemas de terceros (ej. el Technical Lead consultando Jira por su cuenta) y nos limitamos a mapear cómo nuestro sistema es el único orquestador responsable de comunicarse con el mundo exterior para cumplir sus objetivos.

Análisis de Entradas y Salidas del Sistema Central:

• Actores Primarios (Inbound):
  • El Technical Lead envía los comandos principales: inicia grabaciones de audio en tiempo real y aprueba las historias generadas.
  • El Enterprise Analyst administra las organizaciones corporativas (Workspaces), los pagos B2B y sube los glosarios de términos que contextualizan la IA.
• Sistemas de Soporte (Outbound Operacional):
  • Payment Gateway: Recibe los datos de transacción para habilitar el uso ilimitado o cuotas Pro de la inteligencia artificial.
  • Email Service Provider: Recibe peticiones vía REST API para enviar los correos transaccionales de recuperación de contraseña y validación de cuentas.
• Sistemas Core (Outbound Tecnológico):
  • STT API (Speech-to-Text): Recibe el streaming continuo de audio de las reuniones y retorna texto fragmentado con latencia inferior a 2 segundos.
  • LLM API (Inteligencia Generativa): Recibe un Prompt complejo inyectado con el texto de la reunión y el glosario del proyecto, devolviendo un bloque JSON estructurado en Gherkin.
  • Project Management Tool: Recibe las historias de usuario aprobadas y formateadas para crear automáticamente Issues en el backlog del equipo (por ejemplo en Jira).

4.3.3. Software Architecture Container Level Diagrams

En esta sección presentamos el diagrama de contenedores para el sistema Reqs-AI. Este nivel hace un enfoque al sistema principal para revelar los contenedores de software que lo componen (aplicaciones móviles, web, API, bases de datos), mostrando cómo se distribuyen las responsabilidades, las decisiones tecnológicas de alto nivel y cómo estos componentes se comunican entre sí y con los sistemas externos.

El sistema Reqs-AI está compuesto por los siguientes contenedores principales:

1. Interfaces de Usuario (Frontend):

   • Web Application: Es la plataforma principal para los usuarios. Permite una visualización completa para el análisis profundo de datos, revisión de historias de usuario, configuración de proyectos y gestión general del sistema. Se eligió Angular por ser un framework robusto, ideal para aplicaciones empresariales escalables.
   • Mobile App: Proporciona accesibilidad móvil a los usuarios, permitiéndoles interactuar con el sistema, grabar reuniones o revisar el estado de los requerimientos desde cualquier lugar. Se optó por Flutter para asegurar un desarrollo multiplataforma eficiente (iOS y Android) con una base de código unificada.

2. Distribución y Enrutamiento Perimetral (Edge):

   • CDN & Reverse Proxy: Se posiciona como el intermediario absoluto entre las interfaces de usuario (Internet) y la infraestructura interna. Actúa como proxy inverso interceptando todas las peticiones web y móviles. Su función es servir los archivos estáticos de la Web App a alta velocidad desde ubicaciones globales, almacenar respuestas en caché, mitigar ataques (DDoS) y enrutar las peticiones dinámicas (API) hacia el Gateway. En el entorno AWS, la tecnología elegida es Amazon CloudFront.
   • API Gateway: Actúa como la puerta de entrada para todas las peticiones dinámicas (Requests) enrutadas desde el Reverse Proxy. Su responsabilidad es dirigir estas solicitudes hacia los servicios de backend correspondientes, gestionando el throttling, métricas de consumo y terminación SSL.

3. Lógica Core (Backend — Monolito Modular):

   • Reqs-AI Backend Application: Desarrollado en Java 25 con Spring Boot 3, se despliega como una única unidad de ejecución que concentra toda la inteligencia de negocio del producto. Está estructurado internamente como un Monolito Modular: los 5 Bounded Contexts operan como módulos independientes con fronteras de acceso estrictas, comunicándose entre sí mediante interfaces públicas y eventos en memoria —sin tráfico de red interno—, lo que elimina la latencia distribuida y garantiza la coherencia transaccional durante las sesiones de elicitación en tiempo real. Esta decisión prioriza la simplicidad operativa y el Time-to-Market en la etapa actual, manteniendo la arquitectura preparada para una migración selectiva a servicios independientes si el volumen futuro lo justifica.

   #	Bounded Context	Responsabilidad principal
   1	Requirement Discovery	Captura de audio en tiempo real, transcripción, motor RAG y generación de historias en Gherkin.
   2	Workspace Management	Jerarquía de organizaciones y proyectos, glosarios técnicos y aplicación de Row Level Security multitenant.
   3	IAM	Identidad, autenticación, autorización por roles y gestión de permisos corporativos.
   4	Billing & Subscription	Planes de suscripción, control de cuotas e integración con la pasarela de pagos.
   5	Integration Gateway	Exportación de historias aprobadas hacia las herramientas de gestión que el cliente ya utiliza.

4. Almacenamiento de Datos:

   • Database: Es la base de datos principal de Reqs-AI. Almacena toda la información del dominio. La elección de PostgreSQL con la extensión pgvector es una decisión estratégica crítica, ya que permite almacenar y consultar embeddings vectoriales, facilitando el procesamiento avanzado de IA (RAG) y las búsquedas semánticas.

Comunicación e Integración de Contenedores

La arquitectura define un flujo de comunicación moderno y orientado a servicios:

• Comunicación Cliente-Servidor (Internet): Tanto la aplicación móvil como la web interactúan inicialmente con el CDN & Reverse Proxy (CloudFront) a través de HTTPS. El proxy inverso sirve la Web App (Angular) y enruta las llamadas de datos hacia el API Gateway. Todo el tráfico utiliza conexiones seguras (REST y WebSockets para el streaming de audio).
• Comunicación Interna: La API Gateway enruta las llamadas procesadas hacia el Reqs-AI Backend Application. Internamente, los Bounded Contexts se comunican mediante eventos en memoria (Domain Events) y persisten su estado de manera síncrona en la base de datos compartida (PostgreSQL).
• Integración con Sistemas Externos: En lugar de centralizar todas las salidas, las integraciones están descentralizadas y asignadas al Bounded Context correspondiente que las necesita:
  • IAM envía credenciales y alertas a través del Email Service Provider.
  • Billing & Subscription procesa transacciones a través del Payment Gateway.
  • Requirement Discovery envía los audios de las reuniones al STT API para convertirlos a texto, y delega la inferencia de inteligencia artificial al LLM API para la generación de Gherkin.
  • Integration Gateway exporta finalmente las historias de usuario hacia la herramienta de gestión mediante la Project Management API (Jira).

4.3.4. Software Architecture Deployment Diagrams

En esta sección se presenta el diagrama de despliegue, el cual ilustra cómo los contenedores de software de Reqs-AI se mapean a la infraestructura de la nube. Este diagrama detalla los nodos de ejecución, los entornos operativos y la topología de red, priorizando una arquitectura viable, escalable y optimizada en costos.

Nodos de Despliegue y Distribución de Componentes

La infraestructura de despliegue se divide en los entornos de cliente, la red de entrega perimetral (Edge), la infraestructura de procesamiento core y la persistencia de datos.

1. En el lado del cliente:

   • Dispositivos físicos (iOS/Android): Dentro opera el Flutter Engine, entorno encargado de ejecutar la aplicación mobile.
   • Computadoras de los usuarios: Utilizan un navegador web como nodo de ejecución para renderizar la aplicación web (Angular).

2. Entorno de Nube - Red Perimetral (AWS Edge Location): Para garantizar baja latencia y alta seguridad antes de que el tráfico llegue a los servidores principales, se utilizan los nodos Edge de AWS distribuidos globalmente.

   • Amazon CloudFront (CDN & Reverse Proxy): Actúa como el primer punto de contacto (Proxy Inverso). Almacena en caché los archivos estáticos de la Web App en ubicaciones cercanas al usuario para cargas instantáneas, y enruta de forma segura y eficiente el tráfico dinámico hacia la región principal de AWS.

3. Entorno de Nube - Procesamiento (Server-Side - AWS North America): La lógica de negocio se aloja en AWS North America (us-east-1, Virginia), elegida por su alta disponibilidad y ecosistema completo de servicios.

   • AWS API Gateway: Recibe el tráfico dinámico enrutado desde CloudFront y funciona como el orquestador de las peticiones REST y WebSockets hacia el backend.
   • AWS Elastic Beanstalk: Es el entorno PaaS (Platform as a Service) encargado de alojar el Reqs-AI Backend Application. Elastic Beanstalk abstrae la complejidad de la infraestructura, aprovisionando servidores EC2 subyacentes, autoescalado y monitoreo, permitiendo al equipo enfocarse únicamente en el código del runtime de Java.

4. Entorno de Nube - Persistencia (Database as a Service):

   • Supabase Cloud (PostgreSQL): Se delegó el almacenamiento a Supabase, una plataforma BaaS (Backend as a Service). Esta decisión permite aprovechar una base de datos PostgreSQL robusta, gestionada y con la extensión pgvector nativa (esencial para los embeddings y RAG de los requerimientos), reduciendo drásticamente la carga operativa y los costos.

Comunicación e Interacción de Nodos

• Las aplicaciones (Mobile y Web) se comunican vía internet mediante HTTPS con el Amazon CloudFront ubicado en el Edge Location más cercano.
• CloudFront sirve los recursos estáticos web directamente y enruta las solicitudes API hacia el AWS API Gateway en la región de AWS North America.
• La API Gateway enruta el tráfico internamente hacia el entorno de AWS Elastic Beanstalk, donde reside la lógica del Monolito Modular.
• El backend de Spring Boot se conecta de manera externa y segura hacia el clúster gestionado en Supabase Cloud para realizar operaciones transaccionales (Reads and writes) sobre la base de datos compartida.

Capítulo V: Tactical-Level Software Design

5.X. Bounded Context:

5.X.1. Domain Layer

5.X.2. Interface Layer

5.X.3. Application Layer

5.X.4. Infrastructure Layer

5.X.6. Bounded Context Software Architecture Component Level Diagrams

5.X.7. Bounded Context Software Architecture Code Level Diagrams

5.X.7.1. Bounded Context Domain Layer Class Diagrams

5.X.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

El equipo concluye que el problema abordado es real, recurrente y de alto impacto en el ciclo de vida del software: la ambigüedad en el levantamiento de requisitos y la sobrecarga de postprocesamiento generan retrabajo, retrasos y riesgo de construir funcionalidades incorrectas. La evidencia obtenida en entrevistas confirma un patrón consistente en ambos segmentos objetivo (Líder Técnico de Startup y Analista de Sistemas/Producto): transformar conversaciones en requisitos claros, trazables y accionables sigue siendo el principal cuello de botella.

Sobre esta base, Reqs-AI se consolida como una propuesta de valor pertinente al combinar asistencia en tiempo real, generación estructurada de historias de usuario y criterios de aceptación, y mecanismos de integración con herramientas de gestión del backlog. El enfoque del producto no reemplaza el criterio profesional del analista o líder técnico, sino que lo potencia para reducir omisiones, acelerar la claridad funcional y mejorar la calidad de entrada hacia desarrollo y QA.

Asimismo, el trabajo desarrollado en el informe demuestra coherencia metodológica entre descubrimiento, análisis y diseño de solución. Los artefactos de Lean UX, entrevistas, need finding, user stories, backlog e impact mapping se enlazan con decisiones arquitectónicas estratégicas (DDD, EventStorming, Bounded Contexts y lineamientos de seguridad multitenancy con RLS), aportando trazabilidad desde la necesidad del usuario hasta la estructura técnica propuesta.

Respecto a las hipótesis planteadas, el equipo considera que cuentan con validación inicial de problema y de deseabilidad, debido a la convergencia de hallazgos cualitativos y cuantitativos en las entrevistas. Sin embargo, su validación de desempeño y negocio permanece parcial, ya que métricas objetivas como reducción de reuniones de aclaración, tiempo de edición manual por sesión, retención de uso y sincronización efectiva al backlog deben medirse con el producto en operación real.

La principal limitación actual del proyecto es que aún no se presenta evidencia completa de implementación, pruebas de campo y resultados longitudinales de adopción. En consecuencia, aunque la arquitectura y el diseño funcional están sólidamente fundamentados, todavía es necesario contrastar el comportamiento del sistema en escenarios productivos con usuarios reales y condiciones de carga, seguridad y dependencia de servicios externos de IA.

Como siguientes pasos, se recomienda priorizar un MVP enfocado en el flujo crítico end-to-end (captura de reunión, síntesis guiada, generación de historias con criterios de aceptación y exportación a backlog), ejecutar pilotos controlados en startups y entornos enterprise, y definir un tablero de métricas para validar hipótesis de valor, eficiencia y confianza. Con ello, Reqs-AI podrá transitar de una solución bien diseñada en el plano estratégico a una plataforma validada en impacto operativo y escalabilidad de negocio.

Bibliografía

Pulse of the Profession (2018) Success in Disruptive Times. Project Management Institute. Recuperado el 15 de Abril de 2025, de https://www.pmi.org/learning/thought-leadership/pulse/pulse-of-the-profession-2018

Jhonson J (2020) CHAOS Report: Beyond Infinity. Standish Group. Recuperado el 15 de Abril de 2025, de https://www.standishgroup.com/products/copy-of-chaos-report-beyond-infinity-digital-version

Anexos

1. Relative Cost of Fixing Defects (IBM System Science Institute)