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

UNIVERSIDAD PERUANA DE CIENCIAS APLICADAS

INGENIERÍA DE SOFTWARE

CICLO 8

CURSO:

1ASI0728 – ARQUITECTURAS DE SOFTWARE EN TECNOLOGÍAS EMERGENTES

NRC: 11821

PROFESOR(A):

Christian Luis De Los Rios Fernández

INFORME DE TRABAJO FINAL

CICLO: 2026-10

STARTUP:

Kntro-Soft

PRODUCTO:

Reqs-AI

INTEGRANTES:

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

JULIO - 2026

Registro de Versiones del Informe

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

Project Report Collaboration Insights

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

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

TB1:

TP:

Contenido

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

Student Outcome

El curso contribuye al cumplimiento del Student Outcome ABET:

ABET - EAC - Student Outcome 3

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

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

Criterio específico	Acciones realizadas	Conclusiones
Comunica oralmente sus ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.	TB1 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando oralmente los aspectos generales del proyecto relacionados con el Capítulo I y parte del Capítulo IV. Expliqué la descripción de la startup, la propuesta de solución y los fundamentos estratégicos del producto, procurando presentar las ideas de manera clara, ordenada y comprensible para una audiencia académica. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando oralmente los contenidos vinculados al Capítulo I y Capítulo IV. Presenté ideas relacionadas con el perfil de la solución, el enfoque estratégico del producto y las decisiones generales de diseño, utilizando un lenguaje objetivo y adecuado para explicar la relación entre la problemática identificada y la solución propuesta. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando oralmente los avances desarrollados en el Capítulo II, principalmente los resultados del análisis de requerimientos, entrevistas, competidores y hallazgos del proceso de need finding. Mi participación permitió explicar cómo se identificaron necesidades relevantes para orientar el desarrollo del producto. Varela Bustinza, Marcelo Alessandro – 202319668 Trabajé comunicando oralmente los resultados correspondientes al Capítulo II, especialmente el análisis competitivo, las estrategias frente a competidores, el diseño y análisis de entrevistas, así como los principales hallazgos obtenidos sobre los usuarios. Busqué explicar la información de manera objetiva, conectando los resultados con la definición de requerimientos del proyecto. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando oralmente los contenidos del Capítulo III, relacionados con la especificación de requerimientos, user stories, product backlog e impact mapping. Expliqué cómo los hallazgos obtenidos en etapas anteriores se transformaron en requisitos y elementos priorizados para el desarrollo de la solución. TP Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando oralmente mis ideas con objetividad al presentar la arquitectura y diseño de cada bounded context en el Capítulo V. Adapté mi lenguaje para que perfiles tanto técnicos, como desarrolladores, y de negocio, como stakeholders, comprendieran cómo los componentes tácticos resuelven los problemas del proyecto de ingeniería. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando oralmente los resultados de la refactorización aplicada al Event Storming y sustenté los diagramas del Capítulo V. Expuse estas ideas con objetividad, asegurándome de que las decisiones de diseño arquitectónico fueran claras para una audiencia de diferentes niveles jerárquicos y especialidades. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando oralmente las especificaciones de la landing page y el diseño y estilos de la versión mobile, correspondientes al Capítulo VI. Presenté mis ideas de forma objetiva, demostrando cómo las decisiones de interfaz de usuario se alinean con los requerimientos técnicos y de ingeniería. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué oralmente los resultados del diseño UX/UI de la aplicación web de Reqs-AI, explicando el flujo completo desde la autenticación y creación del workspace hasta la gestión de proyectos, sesiones de descubrimiento, revisión de historias de usuario, integración con Jira, facturación y configuración del equipo. Además, sustenté la relación entre wireframes, wireflows y mock-ups, destacando cómo cada pantalla mantiene coherencia visual, navegación consistente y alineación con las funcionalidades principales del producto. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando oralmente la refactorización de las User Stories y del Product Backlog, además de sustentar partes del Capítulo V. Mantuve objetividad al explicar cómo las historias guían el desarrollo de la ingeniería, asegurando que el público de diferentes especialidades entendiera su impacto en la arquitectura. TB2 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando oralmente los avances relacionados con la evidencia de desarrollo del Sprint Review, explicando las funcionalidades implementadas en el frontend y su relación con los flujos principales de la aplicación. Además, presenté parte de la evidencia de ejecución y despliegue del software, mostrando cómo los avances realizados permitieron validar el funcionamiento del producto en un entorno demostrable. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando oralmente los avances del backend y la documentación de servicios para el Sprint Review. Expliqué la finalidad de los servicios desarrollados, la relación entre los endpoints y las funcionalidades del sistema, así como la forma en que el backend se integra con el frontend y la aplicación mobile. Mi participación permitió presentar información técnica de manera clara para audiencias con distintos niveles de conocimiento. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando oralmente los avances de la aplicación mobile, explicando las funcionalidades implementadas, los flujos principales y su relación con los requerimientos definidos para el sprint. Asimismo, sustenté parte de la Testing Suite Evidence y Execution Evidence for Sprint Review, presentando los resultados de las pruebas realizadas y la validación del funcionamiento de la aplicación desde la perspectiva del usuario final. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué oralmente los avances del frontend de la aplicación web, explicando las vistas, interacciones y flujos implementados durante el sprint. Además, sustenté las secciones relacionadas con Validation Interviews, incluyendo el diseño de entrevistas, el registro de entrevistas y las evaluaciones según heurísticas. También participé en la explicación del Video About-the-Product, destacando la propuesta de valor, las funcionalidades principales y los avances logrados en frontend, backend y mobile. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando oralmente la evidencia de colaboración del equipo durante el sprint, explicando la organización de tareas, la coordinación entre integrantes y el seguimiento de avances. Asimismo, sustenté información relacionada con testing, ejecución, documentación de servicios y despliegue, conectando estos elementos con el trabajo realizado en frontend, backend y mobile para presentar una solución más integrada durante el Sprint Review. TF1 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando oralmente los avances finales relacionados con la evidencia de desarrollo y despliegue del producto, explicando cómo las funcionalidades implementadas en la aplicación web se integran con el backend y permiten demostrar un flujo operativo más completo. Además, sustenté la importancia del despliegue en la nube para presentar Reqs-AI como una solución preparada para validación en un entorno más cercano a producción. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando oralmente la consolidación del backend, la documentación de servicios y los elementos técnicos del despliegue. Expliqué cómo los endpoints, la base de datos, la configuración de infraestructura y los servicios cloud se relacionan con la operación del sistema, utilizando un lenguaje comprensible tanto para perfiles técnicos como para evaluadores del proyecto. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando oralmente los avances finales de la aplicación mobile y la evidencia de pruebas, explicando los flujos principales desde la perspectiva del usuario final. También sustenté cómo las pruebas realizadas y la ejecución de la aplicación permiten validar la estabilidad de las funcionalidades desarrolladas y su relación con los requerimientos del producto. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué oralmente los avances finales del frontend web y las secciones de Validation Interviews, explicando el diseño de entrevistas, el registro de entrevistas y las evaluaciones según heurísticas. Además, sustenté la actualización de la documentación del Sprint 2 y la evidencia de deployment, destacando cómo el flujo de Reqs-AI, las pantallas implementadas y la validación con usuarios permiten demostrar el valor del producto ante diferentes audiencias. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando oralmente la integración final de evidencias del Sprint, incluyendo colaboración del equipo, testing, ejecución, servicios y despliegue. Expliqué cómo la coordinación entre frontend, backend y mobile permitió cerrar el entregable de forma ordenada, conectando los resultados técnicos con los objetivos del Sprint Review y del informe final.	TB1 Como equipo, se logró comunicar oralmente los avances del proyecto de manera clara, organizada y objetiva. Cada integrante explicó los resultados correspondientes a su participación, conectando los capítulos desarrollados con el propósito general de la solución. Asimismo, la exposición permitió adaptar el lenguaje técnico a una audiencia académica, integrando aspectos de negocio, usuarios, requerimientos y diseño de ingeniería. TP Como equipo en esta etapa, logramos sustentar oralmente decisiones arquitectónicas complejas y diseños de interfaz. Comunicamos con objetividad cómo el diseño táctico de los Bounded Contexts y las mejoras en UX/UI resuelven las necesidades del negocio. Adaptamos nuestra exposición para que tanto perfiles gerenciales, enfocados en el valor del producto, como técnicos, enfocados en patrones de ingeniería, comprendieran claramente la evolución y escalabilidad del sistema. TB2 Como equipo, en TB2 logramos comunicar oralmente los avances del producto de forma clara, objetiva y organizada. La exposición permitió sustentar evidencias de desarrollo, testing, ejecución, documentación de servicios, despliegue de software, colaboración del equipo, entrevistas de validación, evaluación heurística y video del producto. Además, se comunicó el avance integral del sistema considerando frontend, backend y mobile, adaptando el lenguaje para que los resultados fueran comprensibles tanto para una audiencia técnica como para evaluadores académicos y stakeholders del proyecto. TF1 Como equipo, en TF1 logramos comunicar oralmente la evolución final del proyecto de manera clara, objetiva y articulada. La sustentación permitió integrar evidencias de desarrollo, testing, ejecución, documentación de servicios, despliegue en la nube, colaboración del equipo, entrevistas de validación y evaluaciones heurísticas. Asimismo, se explicó el avance del producto desde una perspectiva integral, relacionando frontend, backend, mobile e infraestructura para que la propuesta sea comprensible tanto para audiencias técnicas como para evaluadores académicos y stakeholders.
Comunica en forma escrita ideas y/o resultados con objetividad a público de diferentes especialidades y niveles jerárquicos, en el marco del desarrollo de un proyecto en ingeniería.	TB1 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando de forma escrita los contenidos relacionados con el Capítulo I y parte del Capítulo IV. Redacté información sobre el perfil de la startup, la propuesta de solución y los elementos estratégicos del diseño del producto, procurando mantener una estructura clara y una redacción adecuada para el contexto académico y de ingeniería. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando de forma escrita los apartados vinculados al Capítulo I y Capítulo IV. Mi aporte se centró en organizar y redactar ideas sobre la solución propuesta, su relación con la problemática y los criterios estratégicos del producto, asegurando coherencia entre el enfoque del proyecto y las decisiones de diseño. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando de forma escrita los contenidos del Capítulo II, principalmente en los apartados de análisis de requerimientos, entrevistas, competidores, identificación de necesidades y lenguaje ubicuo. Mi aporte permitió documentar los hallazgos de manera ordenada y orientada a sustentar la definición de requerimientos. Varela Bustinza, Marcelo Alessandro – 202319668 Trabajé comunicando de forma escrita los resultados del Capítulo II, incluyendo el análisis competitivo, estrategias frente a competidores, diseño y análisis de entrevistas, user personas, mapas de empatía y escenarios actuales. Mi trabajo contribuyó a presentar evidencia relevante sobre las necesidades del usuario y su relación con los requerimientos del producto. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando de forma escrita los contenidos del Capítulo III, enfocados en to-be scenario mapping, user stories, product backlog e impact mapping. Mi aporte permitió transformar los hallazgos del análisis en requisitos claros, priorizados y alineados con los objetivos del producto. TP Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando en forma escrita los resultados del diseño táctico de cada bounded context en el Capítulo V. Redacté la estructura de las capas de dominio, aplicación e infraestructura manteniendo objetividad técnica, utilizando diagramas estándar para que equipos de diferentes especialidades puedan comprender la arquitectura. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando en forma escrita las mejoras y la refactorización aplicadas al Event Storming, documentando objetivamente las decisiones tomadas. Apoyé en la redacción técnica del Capítulo V, asegurando que la documentación sea comprensible y útil tanto para desarrolladores como para evaluadores del proyecto. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando en forma escrita los elementos del Capítulo VI, especificando la landing page y el diseño y estilos de la versión mobile del app. Documenté estas decisiones de UX/UI con objetividad, estructurando la información de manera que sea fácilmente interpretable por equipos de distintas disciplinas. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué de forma escrita la documentación del Capítulo VI: Solution UX Design, desarrollando secciones relacionadas con style guidelines, information architecture, wireframes, wireflows y mock-ups de la web application. Redacté subtítulos y descripciones para cada imagen, organicé los recursos visuales con nombres consistentes y expliqué cómo cada pantalla representa una acción o estado funcional dentro del flujo de Reqs-AI. Este trabajo permitió evidenciar la evolución desde la estructura de baja fidelidad hasta la propuesta visual final de la plataforma. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando en forma escrita la refactorización de las User Stories y la actualización del Product Backlog. Redacté estos artefactos con objetividad técnica para que sirvan de puente claro entre las necesidades del negocio y la implementación en ingeniería, apoyando también en la documentación del Capítulo V. TB2 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando de forma escrita los avances correspondientes a la Development Evidence for Sprint Review, documentando las funcionalidades implementadas en el frontend y organizando evidencias visuales del progreso realizado. Además, apoyé en la redacción de la Software Deployment Evidence for Sprint Review, describiendo los elementos necesarios para sustentar la puesta en ejecución del producto. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando de forma escrita los avances del backend y la Services Documentation Evidence for Sprint Review. Redacté información sobre los servicios implementados, su propósito dentro del sistema, la relación con las funcionalidades principales y su integración con frontend y mobile. Mi aporte permitió que la documentación técnica sea entendible para desarrolladores, evaluadores y miembros del equipo con distintos niveles de especialización. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando de forma escrita los avances de la aplicación mobile y la Testing Suite Evidence for Sprint Review. Documenté escenarios de prueba, resultados obtenidos y evidencias de ejecución, relacionando cada validación con los flujos principales del producto. También apoyé en la organización de la Execution Evidence for Sprint Review, procurando que la información sea clara, verificable y alineada con los requerimientos definidos para el sprint. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué de forma escrita los avances del frontend web, registrando pantallas, flujos e interacciones implementadas durante el sprint. Además, desarrollé documentación relacionada con Validation Interviews, incluyendo el diseño de entrevistas, el registro de entrevistas realizadas y las evaluaciones según heurísticas. También apoyé en la sección Video About-the-Product, redactando información orientada a explicar la propuesta de valor, las funcionalidades principales y el estado actual del producto de manera comprensible para distintas audiencias. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando de forma escrita los resultados de colaboración del equipo durante el sprint, documentando la organización de tareas, la coordinación entre integrantes y los acuerdos de trabajo. Además, contribuí a la redacción de evidencias relacionadas con testing, ejecución, documentación de servicios y despliegue, asegurando que los avances de frontend, backend y mobile se presenten de manera ordenada y coherente con los objetivos del Sprint Review. TF1 Gutiérrez Soto, Jhosepmyr Orlando – 202317638 Trabajé comunicando de forma escrita los avances finales relacionados con la evidencia de desarrollo y despliegue del software. Documenté funcionalidades implementadas, evidencias visuales y elementos necesarios para explicar cómo el producto pasó de una versión demostrable a una solución con soporte de infraestructura cloud para su validación final. Hernández Tuiro, Eric Ernesto – 20221C857 Trabajé comunicando de forma escrita la consolidación del backend, la documentación de servicios y la evidencia técnica del deployment. Redacté información sobre endpoints, integración con frontend, configuración de servicios cloud, base de datos y componentes de infraestructura, procurando que la documentación sea clara para desarrolladores, evaluadores y perfiles no especializados. Ramirez Mestanza, Salim Ignacio – 20201E843 Trabajé comunicando de forma escrita los avances finales de la aplicación mobile, los escenarios de prueba y las evidencias de ejecución. Organicé la información de manera verificable, relacionando las pruebas realizadas con los flujos principales del producto y con los requerimientos definidos para el cierre del proyecto. Varela Bustinza, Marcelo Alessandro – 202319668 Comuniqué de forma escrita la actualización de las secciones de Validation Interviews, incluyendo el diseño de entrevistas, registro de entrevistas y evaluaciones según heurísticas. Además, apoyé en la documentación del Sprint 2 y en la incorporación de evidencias de deployment, organizando capturas, descripciones y textos para que el informe final presente de manera clara el avance del frontend, la validación de experiencia y el estado funcional de Reqs-AI. Sulca Gonzales, Paul Fernando – 20221C486 Trabajé comunicando de forma escrita la integración final de evidencias de colaboración, testing, ejecución, servicios y despliegue. Documenté la coordinación del equipo, los acuerdos de trabajo y la relación entre los avances de frontend, backend y mobile, asegurando que el informe final mantenga una estructura coherente, verificable y alineada con los objetivos del curso.	TB1 Como equipo, se logró comunicar por escrito las ideas, resultados y decisiones del proyecto de manera estructurada y objetiva. El documento integra información sobre negocio, usuarios, requerimientos y diseño estratégico, manteniendo una secuencia lógica entre los capítulos. Además, la redacción permitió presentar el proyecto de forma comprensible para audiencias con distintos niveles de conocimiento técnico. TP Para el entregable TP, el equipo demostró la capacidad de documentar formalmente la arquitectura de software, correspondiente al Capítulo V, y el diseño de la experiencia de usuario, correspondiente al Capítulo VI. Se estructuraron los modelos de dominio, diagramas tácticos y wireflows con estricta objetividad técnica. Esta documentación escrita permite que profesionales de diferentes especialidades, desde desarrolladores hasta líderes de proyecto, puedan entender las soluciones de ingeniería propuestas sin ambigüedades. TB2 Como equipo, en TB2 logramos comunicar por escrito los avances del proyecto de manera objetiva, estructurada y verificable. La documentación permitió evidenciar el progreso del frontend, backend y mobile, así como las pruebas realizadas, la ejecución del sistema, la documentación de servicios, el despliegue de software, la colaboración del equipo, las entrevistas de validación, las evaluaciones heurísticas y el video del producto. Estos elementos fortalecen la presentación del proyecto ante audiencias de diferentes especialidades, ya que organizan la información técnica y funcional de forma clara y alineada con los objetivos de ingeniería. TF1 Como equipo, en TF1 logramos comunicar por escrito el cierre del proyecto de manera objetiva, organizada y sustentada con evidencias. La documentación integró avances de frontend, backend, mobile, testing, ejecución, documentación de servicios, despliegue cloud, colaboración del equipo, entrevistas de validación y evaluaciones heurísticas. Esto permitió presentar el producto con mayor nivel de madurez, manteniendo una redacción comprensible para audiencias técnicas, académicas y de negocio.

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 aislamiento por esquema (schema-per-tenant), 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 esquema por organización (schema-per-tenant) para el Analista de Sistemas Enterprise logrará mitigar las preocupaciones de privacidad de la información corporativa. Se sabrá que esto es cierto cuando las organizaciones interesadas completen el proceso de registro y configuración del perfil organizacional tras revisar la documentación de seguridad y multitenancy del sistema.

1.2.2.4. Lean UX Canvas

1.3. Segmentos objetivos

Segmento 1: Líder Técnico de Startup

Descripción:

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

Características Demográficas (Perfil Inferido):

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

Segmento 2: Analista de Sistemas Enterprise

Descripción:

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

Características Demográficas (Perfil Inferido):

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

Capítulo II: Requirements Elicitation & Analysis

2.1. Competidores

2.1.1. Análisis competitivo

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

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

2.1.2. Estrategias y tácticas frente a competidores

2.2. Entrevistas

2.2.1. Diseño de entrevistas

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

Segmento 1: Líder Técnico de Startup

Fase A: Perfil y Ecosistema

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

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

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

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

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

Fase B: El Flujo y la Ejecución

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

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

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

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

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

Fase C: Dolores, Costos y Éxitos

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

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

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

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

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

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

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

Segmento 2: Analista de Sistemas Enterprise

Fase A: Perfil y Ecosistema

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

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

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

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

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

Fase B: El Flujo y la Entrega

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

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

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

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

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

Fase C: Dolores, Relaciones y Éxitos

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

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

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

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

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

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

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

2.2.2. Registro de entrevistas

Segmento Líder Técnico: Entrevistado 1

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

Segmento Líder Técnico: Entrevistado 2

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

Segmento Líder Técnico: Entrevistado 3

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

---

Segmento Analista Funcional: Entrevistado 1

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

Segmento Analista Funcional: Entrevistado 2

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

Segmento Analista Funcional: Entrevistado 3

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

2.2.3. Análisis de entrevistas

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

---

Segmento: Líder Técnico de Startup

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

Características objetivas

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

Características subjetivas

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

---

Segmento: Analista Funcional / Producto / Sistemas

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

Características objetivas

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

Características subjetivas

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

---

Conclusión general

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

2.3. Need finding

2.3.1. User personas

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

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

User persona del segmento de Analista de sistemas Enterprise

2.3.2. User Task Matrix

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

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

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

2.3.3. User Journey Mapping

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

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

  

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

  

2.3.4. Empathy Mapping

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

Líder Técnico de Startup

Analista de sistemas enterprise

2.3.5. As-is Scenario Mapping

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

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

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

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

2.4. Ubiquitous Language

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

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

Capítulo III: Requirements Specification

3.1. To-Be Scenario Mapping

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

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

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

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

3.2. User Stories

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

ID	Título de la Historia	Descripción (Como... quiero... para...)	Criterios de Aceptación (BDD)	Épica Asociada
EP00	Landing Page y Captación de Leads	Landing page pública orientada a convertir visitantes en usuarios mediante la exposición de la propuesta de valor y beneficios por segmentos B2B.	--	--
US01	Visualizar Propuesta de Valor (Hero)	Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta.	Feature: Landing Page - Hero Section Scenario: Carga inicial y visibilidad de conversión (Happy Path) Given un visitante que accede a la URL principal de Reqs-AI When la página carga completamente Then visualiza un título claro sobre la automatización de requisitos con IA And un llamado a la acción (CTA) principal visible sin hacer scroll para iniciar el registro Scenario: Acceso desde dispositivo móvil (Edge Case - Responsive) Given un visitante que accede desde un dispositivo móvil (viewport inferior a 768px) When la página carga completamente Then el Hero adapta su diseño al ancho de pantalla sin perder legibilidad And el CTA principal sigue visible y pulsable sin necesidad de hacer scroll Scenario: Visitante ya autenticado (Edge Case) Given un usuario que ya tiene sesión activa en la plataforma When accede a la URL de la landing page Then el sistema lo redirige directamente al panel principal de su organización And no muestra la landing para evitar confusión innecesaria	EP00
US02	Explorar Casos de Uso por Segmento	Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo.	Feature: Landing Page - Segmentación Interactiva Scenario Outline: Alternar entre perfiles de usuario Given un visitante en la sección de 'Construido para tu equipo' When hace clic en la pestaña del perfil <Perfil> Then el contenido dinámico se actualiza sin recargar la página And muestra el beneficio principal <Beneficio> asociado a ese perfil Examples: Perfil Beneficio Consultoras de Software Reducción de horas facturables en análisis y toma de requerimientos. Product Managers / Startups Integración directa con Jira y adopción de metodologías ágiles.	EP00
US03	Visualizar Planes y Precios	Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta.	Feature: Landing Page - Pricing Scenario: Comparativa de planes con toggle (Happy Path) Given un visitante en la sección de Precios When alterna el interruptor entre facturación 'Mensual' y 'Anual' Then los precios de los planes de pago se actualizan dinámicamente mostrando el descuento aplicado And cada tarjeta de plan contiene un CTA que redirige al formulario de registro correspondiente Scenario: CTA de plan gratuito no solicita datos de pago (Edge Case) Given un visitante interesado en el Plan Gratuito When hace clic en el CTA correspondiente Then es redirigido al formulario de registro sin que se le solicite ningún dato de tarjeta ni método de pago Scenario: Visualización sin interacción con el toggle (Edge Case) Given un visitante que no interactúa con el toggle de facturación When llega a la sección de precios Then los planes se muestran en modo mensual por defecto And cada tarjeta expone precio, límites principales y características clave de forma legible	EP00
EP01	Autenticación y Seguridad	Gestión de acceso y protección de identidad para los usuarios de Reqs-AI, garantizando que solo personal autorizado acceda a la plataforma y su historial.	--	--
US04	Registro de cuenta	Como visitante que llega por primera vez a la plataforma, quiero crear una cuenta con mi correo y una contraseña, para poder acceder a mis proyectos y sesiones de captura de requisitos.	Feature: Registro de cuenta Scenario: Registro exitoso (Happy Path) Given un visitante en la página de registro When ingresa un correo válido y una contraseña segura Then el sistema crea la cuenta en estado 'pendiente de verificación' And envía un correo con el enlace de activación Scenario Outline: Validaciones de registro (Unhappy Paths) Given un visitante en la página de registro When ingresa datos con el problema <Problema> Then el sistema rechaza el registro indicando <Mensaje> Examples: Problema Mensaje El correo ya está registrado en otra cuenta El correo ingresado ya se encuentra en uso. La contraseña tiene menos de 8 caracteres La contraseña debe tener al menos 8 caracteres. El formato del correo es inválido Ingresa un correo electrónico válido.	EP01
US05	Verificación de correo	Como usuario con cuenta pendiente de activación, quiero verificar mi correo haciendo clic en el enlace que recibí, para activar mi cuenta y empezar a trabajar en la plataforma.	Feature: Verificación de correo Scenario: Verificación exitosa (Happy Path) Given un usuario con cuenta pendiente de activación When hace clic en el enlace de verificación recibido por correo Then el sistema activa la cuenta And redirige al usuario al inicio de sesión Scenario: Enlace expirado o inválido (Unhappy Path) Given un usuario con un enlace de verificación When el enlace fue usado previamente o ya expiró su vigencia Then el sistema muestra un error de enlace inválido And ofrece la opción de reenviar un nuevo correo de verificación Scenario: Reenvío de enlace de verificación (Flujo Alternativo) Given un usuario cuyo enlace de verificación ha expirado When solicita el reenvío del enlace desde la notificación de error Then el sistema invalida el enlace anterior And envía un nuevo enlace válido con un tiempo de expiración renovado	EP01
US06	Inicio de sesión	Como usuario con cuenta activa, quiero iniciar sesión con mi correo y contraseña, para acceder a mis proyectos y al historial de sesiones de mi organización.	Feature: Inicio de sesión Scenario: Autenticación exitosa (Happy Path) Given un usuario con cuenta activa When ingresa sus credenciales correctas Then el sistema le concede acceso And lo redirige al panel principal de su última organización activa Scenario Outline: Fallos de autenticación (Unhappy Paths) Given un usuario intentando iniciar sesión When ocurre la situación <Situacion> Then el sistema deniega el acceso con el mensaje <Error> Examples: Situacion Error Contraseña incorrecta Credenciales inválidas. La cuenta aún no ha sido verificada Debes verificar tu correo antes de iniciar sesión. Demasiados intentos fallidos consecutivos Cuenta bloqueada temporalmente por seguridad.	EP01
US07	Recuperación de contraseña	Como usuario registrado que no recuerda su contraseña, quiero recibir un enlace de restablecimiento en mi correo, para recuperar el acceso a mi cuenta sin perder mi historial de trabajo.	Feature: Recuperación de contraseña Scenario: Solicitar recuperación (Happy Path) Given un usuario que olvidó su contraseña When ingresa su correo en el formulario de recuperación Then el sistema envía un enlace de restablecimiento And muestra un mensaje genérico de confirmación por seguridad Scenario: Prevenir enumeración de usuarios (Edge Case - Seguridad) Given un visitante malintencionado When ingresa un correo que no existe en el sistema Then el sistema no revela que el correo es inexistente And muestra el mismo mensaje genérico de confirmación Scenario: Enlace de restablecimiento expirado al usarlo (Unhappy Path) Given un usuario que recibió el enlace de restablecimiento en su correo When intenta acceder a él después de su período de validez (ej. pasadas 24 horas) Then el sistema rechaza el token indicando que expiró And ofrece la opción de solicitar un nuevo enlace de restablecimiento	EP01
US08	Cerrar sesión	Como usuario autenticado, quiero cerrar mi sesión de forma explícita, para asegurarme de que nadie más pueda acceder a mi cuenta desde el mismo dispositivo.	Feature: Cerrar sesión Scenario: Logout exitoso (Happy Path) Given un usuario autenticado When selecciona la opción 'Cerrar sesión' Then el sistema invalida el token de sesión And redirige al usuario a la pantalla de inicio de sesión Scenario: Cierre de sesión con captura activa (Edge Case) Given un usuario con una sesión de captura en curso When intenta cerrar sesión Then el sistema muestra una advertencia de que hay una sesión activa And requiere confirmar antes de proceder	EP01
US09	Aceptar términos y política de privacidad	Como nuevo usuario completando el registro, quiero leer y aceptar los términos de uso y la política de privacidad antes de activar mi cuenta, para entender cómo se usan mis datos y las grabaciones de audio antes de comenzar a usar el servicio.	Feature: Consentimiento de privacidad Scenario: Aceptar términos durante el registro (Happy Path) Given un visitante completando el formulario de registro When marca la casilla de aceptación y envía el formulario Then el sistema registra la fecha y versión del consentimiento otorgado And procede con la creación de la cuenta Scenario: Intentar registrarse sin aceptar términos (Unhappy Path) Given un visitante en el formulario de registro When intenta crear la cuenta sin marcar la casilla de aceptación Then el sistema bloquea el envío And resalta la casilla indicando que es obligatoria	EP01
US10	Editar perfil de usuario	Como usuario autenticado, quiero actualizar mi nombre y foto de perfil, para que mis compañeros de equipo me identifiquen correctamente en los registros de actividad de las sesiones.	Feature: Editar perfil Scenario: Actualizar nombre y foto (Happy Path) Given un usuario autenticado en su perfil When modifica su nombre y sube una imagen válida Then el sistema actualiza los datos And refleja los cambios en todos los proyectos donde el usuario aparece Scenario: Formato de imagen no soportado (Unhappy Path) Given un usuario editando su perfil When sube un archivo que no es imagen (ej. PDF) Then el sistema rechaza el archivo And muestra un mensaje indicando los formatos aceptados Scenario: Imagen supera el tamaño máximo permitido (Unhappy Path) Given un usuario editando su perfil When intenta subir una imagen que excede el límite de tamaño (ej. mayor de 5 MB) Then el sistema rechaza el archivo antes de procesarlo And muestra el tamaño máximo permitido y los formatos válidos	EP01
EP02	Organizaciones	Gestión de espacios de trabajo independientes para separar la información de diferentes empresas o equipos, garantizando que cada organización acceda únicamente a sus propios datos.	--	--
US11	Crear organización	Como usuario autenticado que aún no pertenece a ninguna organización, quiero crear un espacio de trabajo con el nombre de mi empresa, para centralizar mis proyectos y gestionar mi equipo en un entorno separado.	Feature: Crear organización Scenario: Creación exitosa (Happy Path) Given un usuario autenticado sin organización When crea una organización con un nombre válido Then el sistema genera el espacio de trabajo And asigna al usuario el rol inamovible de 'Propietario' Scenario: Nombre de organización vacío (Unhappy Path) Given un usuario creando una organización When deja el nombre en blanco Then el sistema bloquea la creación exigiendo un nombre obligatorio	EP02
US12	Editar organización	Como Propietario de la organización, quiero actualizar el nombre o los datos generales de mi organización, para mantener la información correcta cuando el equipo o el negocio cambia.	Feature: Editar organización Scenario: Actualizar datos (Happy Path) Given el Propietario de una organización When modifica el nombre y guarda los cambios Then la organización actualiza sus datos en toda la plataforma Scenario: Intento de edición sin permisos (Unhappy Path) Given un miembro regular de la organización When intenta acceder a la configuración de la organización Then el sistema oculta o bloquea la opción por falta de privilegios	EP02
US13	Cambiar de organización	Como usuario que pertenece a más de una organización, quiero seleccionar con cuál quiero trabajar desde el menú principal, para asegurarme de estar operando en el contexto correcto según el cliente que estoy atendiendo.	Feature: Cambiar de organización Scenario: Cambio exitoso de contexto (Happy Path) Given un usuario que pertenece a múltiples organizaciones When selecciona una organización distinta desde el menú Then el sistema recarga el contexto de trabajo And muestra únicamente los proyectos de la organización seleccionada Scenario: Eliminación concurrente (Edge Case) Given un usuario intentando cambiar a la Organización B When el propietario de la Organización B lo elimina en ese mismo instante Then el sistema deniega el acceso y lo devuelve a su organización actual	EP02
US14	Configurar idioma de las reuniones	Como administrador de la organización, quiero configurar el idioma de las reuniones, para que la transcripción y las sugerencias del asistente salgan en el idioma correcto desde el inicio de cada sesión.	Feature: Configuración de idioma de reuniones Scenario: Guardar idioma exitosamente (Happy Path) Given el administrador de la organización en la configuración When selecciona es-PE como idioma de reuniones y guarda Then las nuevas sesiones usan ese idioma para STT y generación de sugerencias Scenario: Cambio de idioma con sesión activa (Edge Case) Given una organización con una sesión RECORDING en curso When el administrador cambia el idioma Then el cambio aplica únicamente a las sesiones futuras And la sesión activa continúa con el idioma con que fue iniciada	EP02
US15	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.	--	--
US16	Plan gratuito automático	Como usuario que acaba de crear su organización, quiero empezar a usar la plataforma sin ingresar datos de pago, para evaluar si se ajusta a mis necesidades antes de decidir suscribirme.	Feature: Plan gratuito automático Scenario: Asignación por defecto (Happy Path) Given un usuario que acaba de crear una nueva organización When ingresa a su panel por primera vez Then el sistema le asigna el 'Plan Gratuito' And habilita las cuotas iniciales sin solicitar método de pago Scenario: Cuota de sesiones del plan gratuito agotada (Edge Case) Given una organización en Plan Gratuito que ya consumió su límite mensual de sesiones When un analista intenta iniciar una nueva sesión de captura Then el sistema bloquea la acción And muestra un aviso invitando a actualizar al Plan Pro para continuar Scenario: Intento de crear segunda organización en plan gratuito (Edge Case) Given un usuario en Plan Gratuito con una organización activa When intenta crear una segunda organización Then el sistema bloquea la creación And informa que el Plan Gratuito está limitado a un único espacio de trabajo	EP03
US17	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
US18	Suscripción al plan Equipo	Como Propietario de una organización en plan Pro, quiero contratar el plan Equipo, para poder agregar a todos los miembros de mi equipo y definir mediante roles personalizados qué puede hacer cada uno.	Feature: Suscripción al plan Equipo Scenario: Upgrade a Equipo exitoso (Happy Path) Given el Propietario de una organización en Plan Pro When ingresa un método de pago válido y contrata el Plan Equipo Then el plan se actualiza de inmediato And se habilitan la gestión avanzada de roles y los asientos ilimitados de miembros And se emite la factura correspondiente al nuevo plan Scenario: Intento de upgrade sin plan Pro previo (Unhappy Path) Given el Propietario de una organización en Plan Gratuito When intenta contratar el Plan Equipo directamente Then el sistema bloquea la operación And lo redirige al flujo de upgrade al Plan Pro como paso previo requerido Scenario: Pago rechazado durante upgrade (Unhappy Path) Given el Propietario intentando contratar el Plan Equipo When la pasarela de pagos rechaza el método de pago Then el sistema mantiene el Plan Pro activo sin cambios And notifica el error de pago solicitando actualizar el método de facturación	EP03
US19	Cancelación de suscripción	Como Propietario de una suscripción activa, quiero cancelar mi plan antes de que inicie el siguiente período de facturación, para no recibir cargos adicionales después de dejar de usar el servicio.	Feature: Cancelación de suscripción Scenario: Cancelar antes de renovación (Happy Path) Given el Propietario de una suscripción paga activa When cancela la suscripción desde el panel Then el sistema desactiva la auto-renovación And mantiene los beneficios premium hasta el final del ciclo de facturación actual Scenario: Reactivar suscripción antes del vencimiento (Flujo Alternativo) Given una suscripción en estado CANCELING con días de acceso premium restantes When el Propietario decide mantener el servicio Then el sistema restaura la auto-renovación And la suscripción vuelve al estado ACTIVE sin interrupciones ni cobros adicionales Scenario: Intentar cancelar un plan gratuito (Edge Case) Given el Propietario de una organización en Plan Gratuito When accede al panel de cancelación Then el sistema informa que el Plan Gratuito no genera cargos And oculta la opción de cancelación para ese plan	EP03
US20	Ver estado del plan y consumo	Como Propietario de la organización, quiero ver el plan activo, la fecha de renovación y cuántas sesiones o proyectos he usado, para saber cuándo necesito actualizar mi plan antes de quedarme sin cupo.	Feature: Ver estado del plan y consumo Scenario: Visualización de cuotas (Happy Path) Given el Propietario de la organización When ingresa a la sección de facturación Then visualiza una barra de progreso con el consumo actual de sesiones frente al límite de su plan Scenario: Límite alcanzado (Edge Case) Given una organización que alcanzó exactamente el 100% de su límite When el usuario visualiza el estado Then el sistema muestra una alerta destacada invitando al upgrade Scenario: Servicio de facturación no disponible (Unhappy Path - Sistema) Given el Propietario accediendo a la sección de facturación When el servicio de datos de suscripción falla temporalmente Then el sistema muestra un mensaje de error con opción de reintento And no expone datos parciales o incorrectos del plan al usuario	EP03
EP04	Gestión de Proyectos	Creación, configuración y ciclo de vida de los proyectos por cliente, incluyendo la carga de conocimiento previo que permite a la IA generar historias más precisas.	--	--
US21	Crear proyecto	Como analista, quiero registrar un proyecto asociado a un cliente específico, para organizar y separar todas las sesiones de levantamiento de requisitos de ese cliente.	Feature: Crear proyecto Scenario: Creación de proyecto válida (Happy Path) Given un analista con permisos para crear proyectos en la organización When registra un nuevo proyecto indicando el nombre del cliente Then el proyecto aparece en el listado activo de la organización Scenario: Proyecto duplicado (Unhappy Path) Given un usuario creando un proyecto When ingresa un nombre que ya existe activo en la misma organización Then el sistema sugiere usar un nombre distinto para evitar confusiones	EP04
US22	Cargar documentos del cliente	Como analista, quiero subir documentos del cliente (PDF, Word) al proyecto, para que el sistema extraiga y clasifique automáticamente su contenido en glosario, restricciones y contexto general, enriqueciendo así las historias que se generen en sesiones futuras.	Feature: Cargar documentos del cliente Scenario: Carga y clasificación exitosa (Happy Path) Given un usuario configurando un proyecto When sube un documento PDF o Word válido Then el sistema extrae el texto del documento And clasifica el contenido en glosario, restricciones y contexto general And lo incorpora a la base de conocimiento del proyecto para futuras sesiones Scenario Outline: Restricciones de carga documental (Unhappy Paths) Given un usuario intentando subir documentos de contexto When ocurre el escenario <Fallo> Then el sistema rechaza el archivo indicando <Error> Examples: Fallo Error El archivo es un ejecutable (.exe) Solo se permiten documentos de texto o PDF. El archivo excede los 50MB El documento es demasiado pesado.	EP04
US23	Configurar perfil técnico del proyecto	Como analista, quiero registrar las tecnologías que usa el equipo del cliente y los tipos de usuarios del sistema, para que los criterios de aceptación generados sean aplicables al contexto real del proyecto.	Feature: Configurar perfil técnico del proyecto Scenario: Guardar perfil técnico (Happy Path) Given un analista configurando el proyecto When define que el stack es 'React + Node' y guarda Then el sistema utiliza esta instrucción como prompt base para la generación de criterios técnicos en las historias de usuario Scenario: Campo de stack vacío al guardar (Unhappy Path) Given un analista en el formulario del perfil técnico When intenta guardar sin haber definido ningún stack tecnológico Then el sistema bloquea el guardado And señala que el campo es obligatorio para la generación contextualizada de criterios Scenario: Actualizar stack con historias ya generadas (Edge Case) Given un proyecto que ya tiene historias generadas con un stack previo When el analista actualiza el stack tecnológico Then el sistema guarda la nueva configuración para futuras sesiones And advierte que las historias existentes reflejan el stack anterior y no se actualizarán automáticamente	EP04
US24	Agregar término al glosario manualmente	Como analista, quiero agregar términos del negocio del cliente directamente al glosario del proyecto sin necesidad de subir un documento, para enriquecer el vocabulario de la IA cuando el cliente solo transmite su conocimiento de forma oral.	Feature: Glosario manual del proyecto Scenario: Agregar término exitosamente (Happy Path) Given un miembro configurando el glosario de un proyecto When ingresa un término y su definición y los guarda Then el término queda disponible para ser utilizado como contexto en futuras sesiones de captura Scenario: Intentar guardar término sin definición (Unhappy Path) Given un miembro en el formulario del glosario When ingresa solo el término sin su definición Then el sistema bloquea el guardado And exige completar la definición antes de continuar Scenario: Término duplicado en el glosario (Unhappy Path) Given un miembro agregando términos al glosario del proyecto When ingresa un término idéntico (ignorando mayúsculas) a uno ya registrado Then el sistema detecta la duplicidad And ofrece la opción de editar la definición del término existente en lugar de crear uno nuevo	EP04
US25	Registrar restricción técnica manualmente	Como analista, quiero registrar restricciones técnicas del cliente (ej. 'sin uso de cookies de terceros', 'máximo 3 segundos de latencia') directamente en el proyecto, para que la IA las considere al generar los criterios de aceptación sin necesidad de incluirlas en cada sesión.	Feature: Restricciones técnicas del proyecto Scenario: Registrar restricción exitosamente (Happy Path) Given un miembro configurando las restricciones del proyecto When ingresa una restricción técnica y la guarda Then la restricción queda registrada And se incorpora al contexto de generación de historias en futuras sesiones Scenario: Restricción duplicada (Unhappy Path) Given un miembro agregando restricciones When ingresa una restricción idéntica a una ya existente en el proyecto Then el sistema alerta sobre la duplicidad And ofrece la opción de editar la existente en lugar de crear una nueva	EP04
US26	Editar proyecto	Como analista, quiero modificar el nombre o la descripción de un proyecto existente, para corregir o actualizar la información cuando cambian los acuerdos con el cliente.	Feature: Editar proyecto Scenario: Modificar datos del proyecto (Happy Path) Given un analista con permisos de administración del proyecto When cambia el nombre o la descripción del proyecto Then los cambios se reflejan inmediatamente en el panel del equipo Scenario: Nombre vacío al guardar (Unhappy Path) Given un analista editando el nombre del proyecto When borra el nombre por completo e intenta guardar Then el sistema bloquea el guardado And exige que el nombre del proyecto sea obligatorio Scenario: Nombre duplicado en la organización (Unhappy Path) Given un analista renombrando un proyecto When ingresa un nombre igual al de otro proyecto activo en la misma organización Then el sistema alerta sobre la colisión de nombres And sugiere usar un sufijo o nombre alternativo para diferenciarlos	EP04
US27	Archivar proyecto	Como analista, quiero archivar un proyecto cuando termina el trabajo con ese cliente, para mantener el panel principal ordenado sin eliminar el historial de sesiones e historias generadas.	Feature: Archivar proyecto Scenario: Archivar proyecto finalizado (Happy Path) Given un proyecto activo When el administrador lo archiva Then el proyecto se oculta de las vistas principales pero mantiene su historial intacto Scenario: Operaciones en proyecto archivado (Edge Case) Given un proyecto en estado archivado When un usuario intenta iniciar una nueva sesión de captura Then el sistema bloquea la acción hasta que el proyecto sea desarchivado	EP04
US28	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.	--	--
US29	Invitar miembro a la organización	Como Administrador de la organización, quiero invitar a un colega mediante su correo electrónico, para que pueda acceder a los proyectos que le correspondan dentro de la organización.	Feature: Invitar miembro Scenario: Enviar invitación (Happy Path) Given un usuario con permisos de gestión de equipo When envía una invitación a un correo válido Then el invitado recibe el correo con el enlace de acceso And aparece en estado 'Pendiente' en el panel Scenario Outline: Fallos de invitación (Unhappy Paths) Given un administrador invitando a un usuario When comete el error <Error_Inv> Then la invitación falla indicando <Aviso> Examples: Error_Inv Aviso El correo ya pertenece a la organización El usuario ya es miembro del equipo. El correo ya tiene una invitación pendiente Ya existe una invitación enviada a este correo.	EP05
US30	Crear rol personalizado	Como Propietario de la organización, quiero crear un rol con un nombre definido por mi equipo, para representar una función real dentro de la organización en lugar de usar etiquetas genéricas del sistema.	Feature: Crear rol personalizado Scenario: Rol creado exitosamente (Happy Path) Given el Propietario de la organización When crea el rol 'QA Lead' con un nombre único Then el nuevo rol queda disponible para ser asignado a cualquier miembro Scenario: Nombre de rol duplicado (Unhappy Path) Given el Propietario creando un nuevo rol When ingresa un nombre que ya existe entre los roles de la organización Then el sistema bloquea la creación And muestra que el nombre ya está en uso Scenario: Nombre de rol vacío (Unhappy Path) Given el Propietario en el formulario de creación de rol When deja el campo de nombre vacío e intenta guardar Then el sistema bloquea la acción And señala que el nombre del rol es obligatorio	EP05
US31	Asignar permisos a un rol	Como Propietario de la organización, quiero seleccionar qué acciones puede realizar cada rol dentro de los proyectos y la organización, para que el nivel de acceso de cada miembro refleje exactamente sus responsabilidades reales.	Feature: Asignar permisos a un rol Scenario: Configurar permisos (Happy Path) Given el Propietario configurando un rol When activa los permisos de 'Crear Sesiones' y 'Aprobar Historias' Then todos los usuarios con ese rol adquieren dichas capacidades inmediatamente Scenario: Revocar todos los permisos de un rol (Edge Case) Given el Propietario editando los permisos de un rol existente When intenta desactivar absolutamente todos los permisos disponibles Then el sistema bloquea la acción And advierte que un rol debe conservar al menos un permiso para ser funcional Scenario: Cambio de permisos con miembros en sesión activa (Edge Case) Given el Propietario revocando el permiso 'Crear Sesiones' de un rol que tienen analistas con sesiones abiertas When confirma el cambio Then el sistema aplica la restricción de inmediato And notifica en tiempo real a los afectados que ya no pueden iniciar nuevas sesiones	EP05
US32	Asignar rol a un miembro	Como Administrador de la organización, quiero asignar uno de los roles disponibles a un miembro de la organización, para que sus permisos queden definidos en el momento en que acepta la invitación.	Feature: Asignar rol a un miembro Scenario: Cambio de rol exitoso (Happy Path) Given un Administrador de la organización When cambia el rol del Usuario A de 'Lector' a 'Editor' Then el Usuario A obtiene acceso a las herramientas de edición en su próxima navegación Scenario: Intentar cambiar el rol del Propietario (Edge Case - Seguridad) Given un Administrador de la organización When intenta asignar un rol diferente al usuario Propietario de la cuenta Then el sistema bloquea la acción And recuerda que el rol de Propietario es fijo e intransferible Scenario: Reasignar a rol con permisos reducidos (Unhappy Path - Confirmación) Given un Administrador que va a reducir los permisos de un miembro activo When cambia su rol a uno con menos privilegios Then el sistema solicita confirmación antes de aplicar el cambio And notifica al miembro afectado que sus permisos han sido actualizados	EP05
US33	Editar permisos de un rol existente	Como Propietario de la organización, quiero modificar los permisos de un rol ya creado, para ajustar el nivel de acceso de todos los miembros que lo tienen asignado cuando cambian sus responsabilidades.	Feature: Editar permisos de un rol existente Scenario: Propagación de permisos (Happy Path) Given un rol asignado a 5 usuarios When el Propietario revoca el permiso de 'Exportar' Then los 5 usuarios pierden la capacidad de exportar instantáneamente sin necesidad de re-login Scenario: Editar rol sin miembros asignados (Edge Case) Given un rol personalizado sin ningún miembro asignado actualmente When el Propietario agrega permisos de 'Crear Sesiones' al rol Then el sistema guarda los nuevos permisos sin ningún efecto inmediato And los permisos se aplicarán cuando el rol sea asignado a un miembro Scenario: Intentar dejar rol sin permisos (Unhappy Path) Given el Propietario editando permisos de un rol When revoca el último permiso activo del rol Then el sistema bloquea la acción And exige conservar al menos un permiso por integridad del rol	EP05
US34	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
US35	Remover miembro de la organización	Como Administrador de la organización, quiero remover a un miembro de la organización, para revocar su acceso a todos los proyectos de forma inmediata cuando ya no forma parte del equipo.	Feature: Remover miembro de la organización Scenario: Remoción exitosa (Happy Path) Given un administrador de equipo When remueve al Usuario B de la organización Then el Usuario B pierde acceso inmediatamente a todos los proyectos de esa organización Scenario: Intento de remover al Propietario (Edge Case - Seguridad) Given un administrador de equipo When intenta remover al Propietario original de la cuenta Then el sistema bloquea la acción indicando que el rol de Propietario es intransferible e irremovible	EP05
US36	Transferir propiedad de la organización	Como Propietario de la organización, quiero transferir la propiedad a otro miembro activo, para poder desvincularme del equipo sin dejar la cuenta sin responsable cuando abandono el proyecto.	Feature: Transferencia de propiedad Scenario: Transferir propiedad exitosamente (Happy Path) Given el Propietario actual de la organización When selecciona a un miembro activo y confirma la transferencia Then el miembro seleccionado asume el rol de Propietario And el Propietario anterior pasa a tener un rol regular configurable Scenario: Intentar transferir a un miembro pendiente de invitación (Unhappy Path) Given el Propietario intentando transferir la propiedad When selecciona un usuario que aún no aceptó su invitación Then el sistema bloquea la transferencia And exige que el destinatario sea un miembro activo de la organización	EP05
EP06	Captura en Tiempo Real	Funcionalidad principal del producto que captura audio en vivo durante la reunión o procesa grabaciones subidas por el equipo, proponiendo requisitos como sugerencias para revisión del Tech Lead. Incluye gestión del ciclo de vida completo de sesiones (DRAFT → RECORDING → PAUSED → STOPPED → COMPLETED). Las sesiones requieren un proyecto existente.	--	--
US37	Iniciar sesión de captura en vivo	Como analista, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US20.	Feature: Captura en vivo Scenario: Iniciar captura exitosamente (Happy Path) Given que el analista tiene permisos y el proyecto está activo When inicia la captura de audio en vivo Then la sesión cambia a estado 'activa' y comienza a registrar el habla Scenario Outline: Validaciones al intentar iniciar captura (Unhappy Paths) Given que el analista intenta iniciar una sesión de captura en vivo When ocurre la situación <Condicion> Then el sistema impide el inicio de la sesión And muestra el mensaje <Mensaje_Error> Examples: Condicion Mensaje_Error El navegador no tiene permisos de micrófono Debes otorgar permisos de micrófono para continuar. El usuario tiene un rol sin permisos de creación No tienes permisos para crear sesiones en este proyecto. El proyecto seleccionado se encuentra archivado El proyecto está archivado y no admite nuevas sesiones. Scenario: Pérdida de conexión al iniciar (Unhappy Path - Flujo Alternativo) Given que el analista inicia la captura When se pierde la conexión a internet antes de confirmar con el servidor Then el sistema cancela la creación de la sesión And notifica al analista que verifique su conexión Scenario: Consentimiento de grabación (Edge Case) Given un analista que inicia captura en un proyecto con política de consentimiento habilitada When el sistema detecta que no se ha registrado la autorización de los participantes Then solicita confirmación explícita antes de activar el micrófono And no inicia la grabación hasta que el analista confirma que todos los participantes autorizaron ser grabados	EP06
US38	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
US39	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 Scenario: Abortar sesión sin guardar (Flujo Alternativo) Given una sesión activa con sugerencias pendientes When el analista selecciona 'Abortar y salir' y confirma la acción Then el sistema descarta todas las sugerencias no confirmadas And cierra la sesión sin persistir ningún dato en el proyecto Scenario: Mostrar resumen al cerrar (Happy Path - complementario) Given una sesión activa que el analista está cerrando exitosamente When el cierre se confirma Then el sistema muestra un resumen con el total de historias aceptadas, pendientes y descartadas antes de redirigir al panel del proyecto	EP06
US40	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
US41	Subir grabación de reunión	Como analista, quiero subir el archivo de audio de una reunión pasada dentro de un proyecto específico, para que el sistema extraiga los requisitos aplicando el glosario y contexto técnico de ese proyecto.	Feature: Carga de grabaciones Scenario: Procesar exitosamente una grabación válida (Happy Path) Given que el analista tiene permisos para crear sesiones And la organización tiene minutos de procesamiento disponibles When el analista sube un archivo de audio válido Then el sistema acepta el archivo And inicia la extracción de requisitos automáticamente sin intervención manual Scenario Outline: Rechazar carga de grabaciones inválidas o no permitidas (Unhappy Paths) Given que el analista intenta subir una grabación When ocurre la situación descrita en <Condicion_Invalida> Then el sistema rechaza la carga And muestra el mensaje explicativo <Mensaje_Esperado> And no descuenta minutos del plan de suscripción de la organización Examples: Condicion_Invalida Mensaje_Esperado El archivo tiene un formato no soportado (ej. .pdf, .docx) El formato del archivo no está soportado. El archivo de audio está corrupto o dañado El archivo de audio no se puede leer o está dañado. El archivo supera el límite de tamaño máximo permitido El archivo supera el límite de tamaño permitido. La organización agotó su límite de minutos mensuales Has alcanzado el límite de procesamiento de tu plan actual. Scenario: Ver estado del procesamiento de la grabación (Happy Path) Given una grabación subida recientemente que el sistema está transcribiendo When el analista consulta el historial de sesiones del proyecto Then el sistema muestra el estado actualizado del procesamiento (Transcribiendo → Extrayendo requisitos → Completado) And notifica al analista cuando las sugerencias de la grabación están listas para revisar	EP06
US42	Ver historial de sesiones del proyecto	Como miembro del equipo, quiero ver el listado de todas las sesiones (en vivo y grabaciones) asociadas a un proyecto, para acceder rápidamente al resultado de reuniones anteriores sin tener que recordar fechas exactas.	Feature: Historial de sesiones Scenario: Listar sesiones activas e históricas (Happy Path) Given un miembro accediendo a la vista de un proyecto When navega a la sección de historial de sesiones Then el sistema muestra el listado de sesiones ordenadas por fecha descendente And cada sesión indica su tipo (en vivo / grabación), fecha y número de historias generadas Scenario: Proyecto sin sesiones previas (Edge Case) Given un proyecto recién creado sin sesiones When el miembro accede al historial Then el sistema muestra un estado vacío con un mensaje orientativo Scenario: Sesión con procesamiento de audio en curso (Edge Case) Given un analista consultando el historial de sesiones del proyecto When una grabación subida está todavía en proceso de transcripción y extracción Then el sistema la muestra en el listado con el indicador de estado 'Procesando' And desactiva las acciones de revisión hasta que el procesamiento finalice	EP06
EP07	Asistencia Proactiva de la IA	Capacidad del sistema para sugerir nuevas historias (Modo A), proponer modificaciones a historias existentes (Modo B) y detectar casos borde (Modo C) durante la sesión; detectar necesidades duplicadas; y gestionar el flujo completo de revisión, edición y aprobación de sugerencias (PENDING → ACCEPTED / REJECTED) antes de publicarlas en el backlog.	--	--
US43	Sugerir nueva historia durante la reunión	Como analista, durante la reunión quiero que el asistente me proponga una nueva historia cuando el cliente menciona una necesidad, para capturar requisitos sin dejar de escuchar la conversación.	Feature: Sugerencia de nueva historia en vivo Scenario: Necesidad nueva detectada (Happy Path) Given una sesión en estado RECORDING When el cliente expresa una necesidad no cubierta por ninguna historia existente Then el asistente propone una nueva historia en estado PENDING con rol, acción y beneficio Scenario: Conversación sin requisito (Edge Case) Given una sesión RECORDING When el diálogo es trivial (saludos, pausas, temas fuera de alcance) Then el asistente no genera sugerencias y no interrumpe la reunión Scenario: Visibilidad del panel según permiso RBAC (Edge Case) Given un participante de la sesión sin el permiso CONFIRM_SUGGESTION When hay sugerencias PENDING activas en el panel durante la sesión Then las sugerencias se muestran en modo solo lectura And los botones de aceptar y descartar no son visibles para ese usuario	EP08
US44	Proponer modificación a historia existente	Como analista, cuando el cliente pide cambiar algo ya acordado, quiero que el sistema identifique la historia existente y me proponga la modificación, para mantener el backlog actualizado en tiempo real sin perder contexto.	Feature: Sugerencia de modificación de historia Scenario: Petición de cambio detectada (Happy Path) Given una historia existente sobre la funcionalidad que el cliente menciona When el cliente pide ampliarla o cambiarla Then aparece una sugerencia de modificación (diff) sobre esa historia en estado PENDING Scenario: Dos candidatas similares (Edge Case) Given dos historias similares que podrían ser el target When el sistema genera la propuesta de modificación Then el sistema presenta ambas opciones y pide al Tech Lead elegir cuál modificar	EP08
US45	Sugerir casos borde y escenarios	Como analista, quiero que el asistente sugiera casos borde y preguntas del tipo "¿qué pasaría si…?, para levantar requisitos completos durante la reunión sin necesidad de recordarlos después.	Feature: Sugerencia de casos borde Scenario: Caso borde detectado (Happy Path) Given una historia o necesidad en discusión When el asistente detecta un flujo no contemplado (ej. error, timeout, usuario sin permiso) Then propone un criterio de aceptación adicional de tipo unhappy/edge en estado PENDING Scenario: Sin casos borde relevantes (Edge Case) Given una historia cuyo contexto es excesivamente genérico When el asistente analiza la conversación Then no inventa casos sin fundamento y no genera ruido visual Scenario: Sugerir pregunta aclaratoria por ambigüedad (Happy Path) Given que el cliente describe una necesidad con términos imprecisos o contradictorios When el asistente detecta ambigüedad en el enunciado Then sugiere al Tech Lead una pregunta del tipo '¿Qué debería pasar si…?' para aclarar el caso antes de generar la historia Scenario: Detectar caso no mencionado por el cliente (Edge Case) Given un flujo discutido que omite un escenario habitual (ej. error de red, usuario sin permisos, estado vacío) When el asistente analiza la conversación Then propone ese caso borde como sugerencia PENDING para que el Tech Lead evalúe añadirlo o descartarlo	EP08
US46	Controlar cuándo analiza el asistente	Como analista, quiero decidir si el asistente analiza automáticamente o solo cuando yo lo pida, para que no interrumpa el flujo de la reunión en momentos inconvenientes.	Feature: Control de disparo del análisis Scenario: Análisis bajo demanda (Happy Path) Given una sesión RECORDING con el modo manual activo When el Tech Lead presiona "Analizar ahora" Then el asistente analiza la conversación reciente y puede emitir sugerencias Scenario: Análisis automático periódico (Happy Path) Given el modo automático activo When transcurre el intervalo configurado o se detecta una pausa de silencio Then el asistente ejecuta el análisis sin intervención del usuario	EP08
US47	Evitar historias duplicadas en tiempo real	Como analista, quiero que el sistema me avise cuando la necesidad que expresa el cliente ya está cubierta por una historia existente en el proyecto, para no duplicar el backlog durante la reunión.	Feature: Detección de duplicados en vivo Scenario: Necesidad ya existente detectada (Happy Path) Given un proyecto con una historia equivalente ya registrada When el cliente expresa esa misma necesidad durante la sesión Then el sistema muestra una alerta de similitud vinculando a la historia existente And no crea una sugerencia de historia nueva redundante Scenario: Necesidad parecida pero distinta (Edge Case) Given historias relacionadas pero con objetivo funcional diferente When el cliente expresa la necesidad Then el sistema no levanta alerta de duplicidad y sugiere una nueva historia Scenario: Resolver alerta de similitud (Happy Path) Given una alerta de similitud activa vinculando una nueva necesidad a una historia existente en el proyecto When el Tech Lead confirma que son la misma necesidad y descarta la sugerencia nueva Then la alerta se resuelve y el backlog conserva únicamente la historia original sin duplicar datos Scenario: Similitud en lote (Edge Case) Given varias necesidades similares expresadas en rápida sucesión durante la reunión When el asistente analiza el contexto acumulado Then muestra una alerta agrupada en lugar de múltiples alertas individuales para no saturar el panel del Tech Lead	EP08
US48	Editar historia generada	Como analista, quiero modificar el texto de una historia generada por la IA, para ajustar el lenguaje al estándar que usa mi equipo antes de aprobarla.	Feature: Editar historia generada Scenario: Guardar cambios en el contenido (Happy Path) Given que un analista se encuentra editando una historia generada por la IA When modifica el texto y presiona guardar Then la historia actualiza su contenido And preserva la etiqueta o trazabilidad de que su origen inicial fue generado por IA Scenario Outline: Validaciones del formulario de edición (Unhappy Paths) Given que el analista intenta guardar las modificaciones de una historia When el formulario presenta <Error_Formulario> Then el sistema bloquea el guardado And muestra el mensaje <Mensaje_Error> Examples: Error_Formulario Mensaje_Error El título de la historia se ha borrado por completo El título de la historia es obligatorio. La descripción quedó completamente vacía La descripción no puede estar vacía. Scenario: Conflicto de edición concurrente (Unhappy Path - Flujo Alternativo) Given que dos usuarios abren la misma historia para editarla al mismo tiempo When el usuario A guarda sus cambios y luego el usuario B intenta guardar los suyos Then el sistema bloquea la acción del usuario B And le advierte que la historia fue modificada externamente para evitar sobreescritura accidental	EP08
US49	Aprobar historia	Como analista, quiero marcar una historia como aprobada después de revisarla, para que quede disponible para el equipo de desarrollo y pueda exportarse al gestor de tareas.	Feature: Aprobar historia Scenario: Aprobar historia revisada (Happy Path) Given una historia completa en estado de revisión When un usuario con permisos la marca como 'Aprobada' Then el estado de la historia cambia a 'Aprobada' And queda disponible en la cola para ser exportada a sistemas externos (ej. Jira) Scenario Outline: Impedir aprobación de historias incompletas (Unhappy Paths) Given que el analista intenta aprobar una historia When la historia tiene <Falla_Integridad> Then la aprobación es rechazada And el sistema indica <Razon_Rechazo> Examples: Falla_Integridad Razon_Rechazo Faltan definir los criterios de aceptación La historia debe tener criterios de aceptación antes de ser aprobada. La historia tiene alertas de similitud sin resolver Debes resolver los conflictos de duplicidad pendientes.	EP08
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.	Feature: Aprobación externa del cliente Scenario: Generar y visitar enlace público (Happy Path) Given un proyecto con historias en revisión When el analista genera un enlace público y el cliente accede a él Then el cliente puede visualizar las historias en modo de solo lectura And puede marcarlas como 'Aprobadas' o dejar comentarios Scenario: Expiración o revocación del enlace (Unhappy Path) Given un enlace público generado anteriormente When el analista revoca el acceso o expira el tiempo de validez configurado Then cualquier intento de ingresar mostrará un error de enlace no disponible Scenario: Cliente externo sin cuenta accede al enlace (Edge Case - Usuario anónimo) Given un cliente que no tiene cuenta en Reqs-AI y recibió el enlace público por correo When accede a la URL del enlace desde su navegador Then puede visualizar las historias en modo solo lectura sin necesidad de autenticarse And no puede navegar a ninguna otra sección privada de la plataforma desde ese enlace	EP08
US51	Buscar y filtrar historias del backlog	Como analista revisando el backlog de un proyecto, quiero buscar historias por texto libre y filtrarlas por estado (generada, aprobada, descartada) o épica, para localizar rápidamente las historias que necesito revisar sin tener que desplazarme por todo el backlog.	Feature: Búsqueda y filtrado de historias Scenario: Búsqueda por texto (Happy Path) Given un analista en la vista del backlog de un proyecto con múltiples historias When ingresa un término en el buscador Then el sistema filtra y muestra únicamente las historias que contienen el término en título o descripción Scenario: Filtrar por estado (Happy Path) Given un analista en la vista del backlog When selecciona el filtro 'Aprobadas' Then el sistema muestra únicamente las historias en ese estado Scenario: Sin resultados (Edge Case) Given un analista aplicando un filtro muy específico When ninguna historia coincide con los criterios Then el sistema muestra un estado vacío con un mensaje claro	EP08
US52	Revisar y confirmar sugerencias del asistente	Como analista, quiero revisar, editar, aceptar o descartar cada sugerencia del asistente antes de que se guarde en el backlog, para mantener el control total sobre los requisitos capturados.	Feature: Confirmación de sugerencias Scenario: Aceptar sugerencia con edición (Happy Path) Given una sugerencia en estado PENDING visible en el panel When el Tech Lead la edita y confirma Then la historia se guarda con el contenido editado y la sugerencia pasa a ACCEPTED Scenario: Descartar sugerencia (Happy Path) Given una sugerencia PENDING When el Tech Lead la descarta Then la sugerencia pasa a REJECTED y desaparece del panel activo Scenario: Sin permiso de confirmación (Unhappy Path) Given un usuario sin el permiso CONFIRM_SUGGESTION When intenta aceptar una sugerencia Then el sistema bloquea la acción y la sugerencia permanece en estado PENDING Scenario: Revisar sugerencias post-sesión (Flujo Alternativo) Given una sesión ya cerrada con sugerencias en estado PENDING no resueltas durante la reunión When el Tech Lead accede al historial de sugerencias de esa sesión Then puede aceptar, editar o descartar cada sugerencia PENDING desde la vista de revisión post-sesión And los cambios se persisten en el backlog del proyecto de la misma manera que durante la sesión en vivo	EP08
EP08	Integraciones Externas	Conectividad con herramientas del ecosistema de desarrollo para transferir las historias aprobadas al backlog del equipo sin trabajo manual.	--	--
US53	Conectar cuenta de Jira	Como Administrador de la organización, quiero autorizar la conexión con Jira a través de un proceso seguro, para que la exportación de historias no requiera compartir credenciales con nadie del equipo.	Feature: Conectar cuenta de Jira Scenario: Autorización segura y exitosa (Happy Path) Given un Administrador de la organización en la sección de integraciones When completa satisfactoriamente el flujo de autorización (OAuth) en la plataforma de Jira Then el sistema de Reqs-AI vincula el proyecto a Jira And muestra un indicador visual de conexión activa y saludable Scenario Outline: Rechazo de autorización (Unhappy Paths) Given que el Administrador inicia el flujo de autorización When ocurre el evento <Evento_Fallo> Then el sistema aborta la integración And muestra el estado <Estado_Final> sin guardar datos espurios Examples: Evento_Fallo Estado_Final El usuario deniega los permisos desde la ventana de Jira Operación cancelada por el usuario, integración inactiva. Fallo de red o timeout durante la comunicación con Jira Error de comunicación, inténtalo nuevamente. Scenario: Token de conexión expirado (Unhappy Path - Flujo Alternativo) Given una integración previamente configurada que estaba operativa When el token de seguridad subyacente caduca (vencimiento de credencial) Then el sistema deshabilita las opciones de exportación And notifica explícitamente al administrador que se requiere una 'Re-autenticación' para reactivar la conexión	EP11
US54	Configurar mapeo de proyecto en Jira	Como Administrador de la organización, quiero vincular un proyecto local de Reqs-AI con un Board/Proyecto específico de Jira, para que el sistema sepa exactamente a qué destino enviar las historias durante la exportación.	Feature: Mapeo de proyectos externos Scenario: Vincular board destino (Happy Path) Given una integración con Jira activa When el Administrador accede a la configuración de integración del proyecto Then puede seleccionar de una lista desplegable el 'Proyecto de Jira' y 'Tipo de Issue' destino And el sistema guarda este mapeo para las futuras exportaciones Scenario: Intentar exportar sin mapeo previo (Unhappy Path) Given un proyecto sin board de destino configurado When el analista intenta exportar historias a Jira Then la exportación se bloquea And el sistema redirige al Administrador a la pantalla de configuración del mapeo Scenario: Board de Jira eliminado externamente (Edge Case - Servicio externo) Given un mapeo configurado a un board de Jira que fue eliminado desde Atlassian posteriormente When el analista intenta ejecutar una exportación de historias Then el sistema detecta que el destino ya no es accesible And notifica al Administrador que el mapeo está roto y debe reconfigurarse antes de exportar	EP11
US55	Exportar historias a Jira	Como analista, quiero enviar las historias aprobadas directamente al backlog de Jira, para que el equipo de desarrollo pueda planificar el sprint sin copiar ni pegar nada manualmente. Depende de: US53 y US54.	Feature: Exportar historias a Jira Scenario: Exportación exitosa de historias aprobadas (Happy Path) Given un proyecto con una conexión activa a Jira y varias historias en estado 'Aprobada' When el analista ejecuta la acción de exportación masiva Then el sistema transmite únicamente las historias aprobadas a Jira And marca exitosamente dichas historias como 'Exportadas' dentro de Reqs-AI Scenario Outline: Validaciones de prerrequisitos de exportación (Unhappy Paths) Given que el analista intenta ejecutar la exportación masiva When se incumple la condición <Incumplimiento> Then el botón o acción es bloqueado o rechazado indicando <Mensaje_Error> Examples: Incumplimiento Mensaje_Error La integración con Jira no está configurada o el token expiró Debes conectar y autorizar tu cuenta de Jira primero. No existe ninguna historia que se encuentre en estado 'Aprobada' No hay historias válidas listas para exportar. Scenario: Fallo parcial durante la transmisión de lotes (Unhappy Path - Fallo de red) Given un lote de 10 historias aprobadas listas para envío a la API de Jira When la red experimenta intermitencia y 2 de las peticiones fallan Then el sistema marca las 8 historias exitosas como 'Exportadas' And retiene las 2 restantes, marcándolas con error de exportación y habilitando un botón para reintentar el lote fallido	EP11
EP09	Arquitectura y Servicios RESTful API	Endpoints y servicios backend sin interfaz gráfica directa (Technical Stories), necesarios para soportar el procesamiento de IA, integraciones y lógica de negocio del frontend.	--	--
TS01	API: Registro de Usuario (POST /auth/register)	Como Developer, quiero un endpoint para registrar usuarios hasheando su contraseña, para asegurar sus accesos.	Scenario: Registro exitoso Given payload con email y password When POST a /auth/register Then 201 Created	EP12
TS02	API: Login de Usuario (POST /auth/login)	Como Developer, quiero un endpoint que valide credenciales y retorne un JWT.	Scenario: Login válido Given credenciales correctas When POST a /auth/login Then 200 OK con token JWT	EP12
TS03	API: Perfil de Usuario (GET /auth/me)	Como Developer, quiero un endpoint que retorne los datos del usuario logueado según su JWT.	Scenario: Token válido Given header Authorization: Bearer <token> When GET a /auth/me Then 200 OK	EP12
TS04	API: Crear Proyecto (POST /projects)	Como Developer, quiero un endpoint para crear un nuevo espacio de trabajo.	Scenario: Creación de proyecto Given payload con nombre When POST a /projects Then 201 Created	EP12
TS05	API: Listar Proyectos (GET /projects)	Como Developer, quiero un endpoint para listar los proyectos del usuario autenticado.	Scenario: Listar proyectos Given usuario con token válido When GET a /projects Then 200 OK con array de proyectos	EP12
TS06	API: Actualizar Proyecto (PUT /projects/{id})	Como Developer, quiero un endpoint para modificar metadatos de un proyecto.	Scenario: Actualización válida Given ID de proyecto existente When PUT a /projects/{id} Then 200 OK	EP12
TS07	API: Eliminar Proyecto (DELETE /projects/{id})	Como Developer, quiero un endpoint de soft-delete para archivar proyectos.	Scenario: Eliminación lógica Given ID válido When DELETE a /projects/{id} Then 204 No Content	EP12
TS08	API: Subir Audio (POST /sessions/{id}/upload)	Como Developer, quiero un endpoint que reciba un archivo de audio en multipart/form-data, lo transcriba mediante Whisper API y guarde el texto resultante en el campo transcript de la sesión, para que el transcript quede disponible sin Cloud Storage propio ni pasos intermedios.	Scenario: Subida exitosa Given archivo MP3/WAV y sessionId válido When POST a /sessions/{id}/upload Then 202 Accepted; sesión transiciona a STOPPED; session.transcript guardado	EP12
TS09	API: Procesar Transcript (POST /sessions/{id}/process)	Como Developer, quiero un endpoint que lea el transcript guardado en la sesión, lo envíe a Gemini para extraer historias de usuario y las persista en estado DRAFT, para desacoplar la transcripción de la extracción de IA y permitir reintentos sin volver a subir el audio.	Scenario: Extracción exitosa Given sesión en STOPPED con transcript When POST a /sessions/{id}/process Then 202 Accepted; sesión transiciona a PROCESSING → COMPLETED; historias creadas en DRAFT Scenario: Reintento sin re-subir Given sesión en FAILED con transcript ya guardado When POST a /sessions/{id}/process Then 202 Accepted; nueva extracción sin necesidad de subir el audio nuevamente	EP12
TS10	API: Ver Transcript (GET /sessions/{id}/transcript)	Como Developer, quiero un endpoint que retorne exclusivamente el texto transcrito de una sesión, para evitar incluir un campo de texto extenso en la respuesta base de sesión.	Scenario: Transcript disponible Given sesión con transcript guardado When GET a /sessions/{id}/transcript Then 200 OK con texto del transcript Scenario: Sin transcript Given sesión en DRAFT (audio aún no subido) When GET a /sessions/{id}/transcript Then 404 TRANSCRIPT_NOT_FOUND	EP12
TS11	API: Auth Jira (GET /integrations/jira/auth)	Como Developer, quiero un endpoint para iniciar el flujo OAuth2 con Atlassian.	Scenario: Redirección OAuth Given petición de integración When GET a /integrations/jira/auth Then 302 Redirect a Jira	EP12
TS12	API: Exportar a Jira (POST /integrations/jira/export)	Como Developer, quiero un endpoint que mapee y envíe las historias al Webhook de Jira.	Scenario: Exportación a Webhook Given array de IDs de historias When POST a /integrations/jira/export Then 200 OK confirmando creación	EP12
TS13	Servicio interno: Chunking de audio para ventana de tokens del LLM	Como Developer, quiero que el pipeline de procesamiento divida automáticamente los audios largos en fragmentos semánticos manejables antes de enviarlos al LLM, para evitar errores de límite de tokens y garantizar coherencia en reuniones extensas.	Scenario: Chunking de audio largo Given audio que supera la ventana de contexto del LLM When el pipeline de procesamiento lo recibe Then lo divide en bloques lógicos sin cortar oraciones And los consolida al finalizar sin pérdida de información Scenario: Reintento de fragmento fallido Given un audio dividido en N chunks When un chunk falla por intermitencia de red Then el sistema reintenta únicamente ese fragmento sin relanzar todo el proceso	EP12
TS14	API: Cerrar Sesión de Usuario (POST /auth/logout)	Como Developer, quiero un endpoint que invalide el token JWT activo del usuario.	Scenario: Logout exitoso Given token JWT válido en header When POST a /auth/logout Then 200 OK y token invalidado en blacklist	EP12
TS15	API: Verificar Email (POST /auth/verify-email)	Como Developer, quiero un endpoint que valide el token de verificación enviado por correo.	Scenario: Verificación válida Given token de verificación vigente When POST a /auth/verify-email Then 200 OK y cuenta marcada como verificada	EP12
TS16	API: Recuperar Contraseña (POST /auth/forgot-password)	Como Developer, quiero un endpoint que genere y envíe un enlace de reset de contraseña al email.	Scenario: Solicitud de reset Given email registrado en el sistema When POST a /auth/forgot-password Then 200 OK y email de reset enviado	EP12
TS17	API: Actualizar Perfil de Usuario (PUT /auth/profile)	Como Developer, quiero un endpoint que permita al usuario autenticado editar nombre, avatar y preferencias.	Scenario: Actualización válida Given usuario autenticado con token JWT When PUT a /auth/profile con body válido Then 200 OK con perfil actualizado	EP12
TS18	API: Crear Organización (POST /organizations)	Como Developer, quiero un endpoint que cree una nueva organización y asigne al creador como Owner.	Scenario: Creación exitosa Given usuario autenticado sin organización activa When POST a /organizations con nombre válido Then 201 Created con ID de organización y rol Owner asignado	EP12
TS19	API: Actualizar Organización (PUT /organizations/{id})	Como Developer, quiero un endpoint para modificar nombre, logo y configuraciones de la organización.	Scenario: Actualización válida Given usuario con permiso de Owner en la organización When PUT a /organizations/{id} con datos válidos Then 200 OK con organización actualizada	EP12
TS20	API: Cambiar Contexto de Organización (POST /organizations/switch)	Como Developer, quiero un endpoint que cambie la organización activa en la sesión del usuario.	Scenario: Cambio exitoso Given usuario miembro de múltiples organizaciones When POST a /organizations/switch con el ID destino Then 200 OK con nuevo JWT que refleja el contexto actualizado	EP12
TS21	API: Invitar Miembro (POST /organizations/{id}/invitations)	Como Developer, quiero un endpoint que genere y envíe una invitación por email para unirse a la organización.	Scenario: Invitación enviada Given usuario Owner o Admin con permisos de invitación When POST a /organizations/{id}/invitations con email y rol Then 201 Created y email de invitación enviado	EP12
TS22	API: Crear Rol Personalizado (POST /organizations/{id}/roles)	Como Developer, quiero un endpoint que registre un nuevo rol con nombre y conjunto de permisos.	Scenario: Creación de rol Given usuario Owner de la organización When POST a /organizations/{id}/roles con nombre y permisos Then 201 Created con ID del nuevo rol	EP12
TS23	API: Configurar Permisos de Rol (PUT /organizations/{id}/roles/{roleId})	Como Developer, quiero un endpoint que actualice los permisos asociados a un rol existente.	Scenario: Actualización de permisos Given rol existente en la organización When PUT a /organizations/{id}/roles/{roleId} con nuevos permisos Then 200 OK con rol actualizado	EP12
TS24	API: Eliminar Rol (DELETE /organizations/{id}/roles/{roleId})	Como Developer, quiero un endpoint que elimine un rol personalizado si no tiene miembros asignados.	Scenario: Eliminación válida Given rol sin miembros asignados When DELETE a /organizations/{id}/roles/{roleId} Then 204 No Content Scenario: Rol en uso (Unhappy Path) Given rol con miembros activos When DELETE a /organizations/{id}/roles/{roleId} Then 409 Conflict con mensaje indicando miembros activos	EP12
TS25	API: Crear Sesión en Vivo (POST /sessions)	Como Developer, quiero un endpoint que inicialice una sesión de captura en vivo asociada a un proyecto.	Scenario: Creación exitosa Given proyecto activo y usuario con permiso de edición When POST a /sessions con ID de proyecto Then 201 Created con ID de sesión y estado OPEN	EP12
TS26	API: Cambiar Estado de Sesión (PATCH /sessions/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una sesión entre OPEN, PAUSED y CLOSED.	Scenario: Cierre de sesión Given sesión en estado OPEN When PATCH a /sessions/{id}/status con estado CLOSED Then 200 OK y sesión marcada como CLOSED	EP12
TS27	API: Listar Sesiones de Proyecto (GET /projects/{id}/sessions)	Como Developer, quiero un endpoint paginado que retorne todas las sesiones de un proyecto ordenadas por fecha.	Scenario: Listado exitoso Given proyecto con sesiones registradas When GET a /projects/{id}/sessions Then 200 OK con array paginado de sesiones	EP12
TS28	API: Listar y Buscar Historias (GET /projects/{id}/stories)	Como Developer, quiero un endpoint con filtros por estado, épica y texto para recuperar historias de un proyecto.	Scenario: Búsqueda con filtro Given proyecto con historias generadas When GET a /projects/{id}/stories?status=DRAFT&epic=EP03 Then 200 OK con array filtrado y metadata de paginación	EP12
TS29	API: Editar Historia (PUT /stories/{id})	Como Developer, quiero un endpoint que permita actualizar título, descripción y criterios de aceptación de una historia.	Scenario: Edición válida Given historia existente y usuario con permiso de edición When PUT a /stories/{id} con body actualizado Then 200 OK con historia actualizada y timestamp de modificación	EP12
TS30	API: Cambiar Estado de Historia (PATCH /stories/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una historia entre DRAFT, APPROVED y REJECTED.	Scenario: Aprobación de historia Given historia en estado DRAFT When PATCH a /stories/{id}/status con estado APPROVED Then 200 OK y historia marcada como APPROVED	EP12
TS31	API: Cargar Documento (POST /projects/{id}/documents)	Como Developer, quiero un endpoint multipart que acepte PDF/Word, extraiga el texto con Apache Tika y genere embeddings con el LLM.	Scenario: Carga y procesamiento Given archivo PDF válido When POST a /projects/{id}/documents Then 202 Accepted y procesamiento asíncrono iniciado; webhook notifica al completar	EP12
TS32	API: Agregar Término al Glosario (POST /projects/{id}/glossary)	Como Developer, quiero un endpoint que persista un término con su definición en el contexto de un proyecto.	Scenario: Término agregado Given proyecto activo y usuario autenticado When POST a /projects/{id}/glossary con término y definición Then 201 Created con ID del término	EP12
TS33	API: Agregar Restricción Técnica (POST /projects/{id}/constraints)	Como Developer, quiero un endpoint que registre una restricción técnica asociada al proyecto para enriquecer el contexto del RAG.	Scenario: Restricción registrada Given proyecto activo y usuario autenticado When POST a /projects/{id}/constraints con descripción Then 201 Created con ID de la restricción	EP12
TS34	API: Upgrade de Plan (POST /subscriptions/upgrade)	Como Developer, quiero un endpoint que inicie el flujo de pago con Stripe y actualice el plan al confirmar el webhook.	Scenario: Upgrade exitoso Given organización en plan FREE When POST a /subscriptions/upgrade con plan destino Then 200 OK con URL de checkout de Stripe	EP12
TS35	API: Cancelar Suscripción (DELETE /subscriptions)	Como Developer, quiero un endpoint que marque la suscripción como cancelada al final del período de facturación.	Scenario: Cancelación programada Given organización con suscripción activa When DELETE a /subscriptions Then 200 OK con fecha de expiración y estado CANCELING	EP12
TS36	WebSocket: Stream de Audio Bidireccional (audio-in / transcript-out)	Como Developer, quiero un canal WebSocket binario bidireccional con heartbeat, reconexión automática e idempotencia de segmentos numerados, para garantizar entrega sin duplicados ante cortes de red.	Scenario: Reconexión sin pérdida de segmentos Given sesión activa con lastSequence=10 y corte de red When el cliente reconecta y reenvía segmentos 8-12 Then 201 y segmentos 8-10 se descartan por idempotencia y 11-12 se procesan And la secuencia queda en 12 sin duplicados	EP12
TS37	STT: Integración AssemblyAI tras TranscriptionPort con Token Efímero	Como Developer, quiero integrar AssemblyAI detrás de TranscriptionPort usando token de corta duración y diarización de hablantes activada, para aislar la dependencia STT del dominio sin exponerla.	Scenario: Rotación de token efímero expirado Given token STT con TTL de 60s When han pasado 61s y llega un nuevo segmento de audio Then el sistema rota el token automáticamente And la transcripción continúa sin interrupción visible para el usuario	EP12
TS38	LLM: Integración Gemini tras RequirementGenerationPort (Modos A/B/C)	Como Developer, quiero invocar Gemini detrás de RequirementGenerationPort en los modos A (nueva historia), B (modificar existente) y C (caso borde) con embeddings de 768 dimensiones, para sustituir el adaptador sin tocar el dominio.	Scenario: Adaptador sustituido por fake en tests Given FakeRequirementGenerationAdapter registrado en contexto de test When se invoca el servicio con modo A Then el dominio recibe la sugerencia estructurada And no se realiza ninguna llamada real a la API de Gemini	EP12
TS39	pgvector: Índice HNSW Coseno mayor-igual 0.85 sobre Embeddings 768d	Como Developer, quiero un índice HNSW sobre embedding vector(768) en user_story y un SimilaritySearchPort que devuelva vecinos con similitud coseno mayor o igual a 0.85, para detectar duplicados en tiempo real con latencia menor a 200ms.	Scenario: Búsqueda de historias similares Given backlog con 500 historias indexadas en pgvector When se buscan vecinos del embedding de una nueva sugerencia Then se retornan hasta 5 historias con score mayor o igual a 0.85 And la latencia de la query es menor a 200ms	EP12
TS40	Multitenancy: Schema-per-Tenant con TenantResolver y Flyway por Schema	Como Developer, quiero que TenantResolver extraiga el tenant del JWT y enrute el datasource al schema correspondiente, ejecutando Flyway por schema al crear una organización, para aislar datos de cada tenant sin RLS.	Scenario: Nueva organización provisiona su schema Given organización nueva con id ORG-42 When se confirma el registro de la organización Then Flyway crea el schema tenant_org42 y ejecuta todas las migraciones And las queries del tenant solo leen de ese schema	EP12
TS41	Motor de Disparo IA: Intervalo + Silencio + Manual + CONFIRM_SUGGESTION	Como Developer, quiero un SuggestionTriggerStrategy con tres implementaciones (intervalo, silencio, manual) y un guard que valide CONFIRM_SUGGESTION antes de persistir sugerencias, para que ninguna historia se cree sin aprobación explícita.	Scenario: Sugerencia bloqueada por falta de permiso Given usuario sin permiso CONFIRM_SUGGESTION When el motor dispara un análisis y genera una sugerencia Then la sugerencia queda en estado PENDING And confirmar la sugerencia lanza InsufficientPermissionException	EP12
TS42	API: Gestión de Sugerencias (POST /analyze, GET /suggestions, PATCH)	Como Developer, quiero endpoints para iniciar análisis de transcript, listar sugerencias por sesión y cambiar su estado a ACCEPTED o REJECTED, para que el frontend gestione el ciclo PENDING sin lógica de negocio en el cliente.	Scenario: Flujo completo de sugerencia Given sesión con transcript disponible When POST /sessions/{id}/analyze genera una sugerencia Then GET /suggestions la retorna en estado PENDING And PATCH /suggestions/{id}/status con ACCEPTED la persiste como historia definitiva	EP12
TS43	API: Share Links (POST /projects/{id}/share-links, GET /share/{token})	Como Developer, quiero endpoints para generar un enlace de solo lectura con token firmado y TTL configurable, y servir la vista pública autenticando por token, para que el cliente externo acceda sin necesitar cuenta.	Scenario: Token de enlace compartido expirado Given share-link con TTL de 24h creado hace 25h When GET /share/{token} es invocado por el cliente externo Then 410 Gone con mensaje de enlace expirado And ningún dato del proyecto es expuesto	EP12

3.3. Product Backlog

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

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

Tabla de Estimación y Priorización

# Orden	User Story Id	Título	Descripción	Story Points (1/2/3/5/8)
1	US01	Visualizar Propuesta de Valor (Hero)	Como visitante, quiero entender inmediatamente qué es Reqs-AI y su propuesta de valor principal en la cabecera (Hero), para decidir en los primeros segundos si me interesa continuar explorando la herramienta.	3
2	US02	Explorar Casos de Uso por Segmento	Como visitante, quiero alternar entre diferentes perfiles (ej. Consultoras vs Startups) en una sección interactiva, para ver beneficios y ejemplos específicos que se adapten a la realidad de mi equipo.	3
3	US03	Visualizar Planes y Precios	Como visitante evaluando la viabilidad financiera, quiero comparar los planes de suscripción (Gratuito, Pro, Equipo) de forma transparente, para determinar cuál se ajusta a mi presupuesto antes de crearme una cuenta.	2
4	TS40	Multitenancy: Schema-per-Tenant con TenantResolver y Flyway por Schema	Como Developer, quiero que TenantResolver extraiga el tenant del JWT y enrute el datasource al schema correspondiente, ejecutando Flyway por schema al crear una organización, para aislar datos de cada tenant sin RLS.	8
5	TS25	API: Crear Sesión en Vivo (POST /sessions)	Como Developer, quiero un endpoint que inicialice una sesión de captura en vivo asociada a un proyecto.	3
6	TS26	API: Cambiar Estado de Sesión (PATCH /sessions/{id}/status)	Como Developer, quiero un endpoint que cambie el estado de una sesión entre OPEN, PAUSED y CLOSED.	3
7	TS36	WebSocket: Stream de Audio Bidireccional (audio-in / transcript-out)	Como Developer, quiero un canal WebSocket binario bidireccional con heartbeat, reconexión automática e idempotencia de segmentos numerados, para garantizar entrega sin duplicados ante cortes de red.	5
8	TS37	STT: Integración AssemblyAI tras TranscriptionPort con Token Efímero	Como Developer, quiero integrar AssemblyAI detrás de TranscriptionPort usando token de corta duración y diarización de hablantes activada, para aislar la dependencia STT del dominio sin exponerla.	5
9	US37	Iniciar sesión de captura en vivo	Como analista, quiero activar la captura de audio durante la reunión dentro de un proyecto existente, para que el sistema identifique quién habla en cada momento y genere las historias a partir de lo que dice el cliente sin que yo tenga que tomar notas. Depende de: US20.	3
10	US38	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
11	US39	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.	3
12	US40	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.	2
13	TS08	API: Subir Audio (POST /sessions/{id}/upload)