# Especificación funcional y técnica de una aplicación web ## Rol Actúa como **analista de sistemas y arquitecto de aplicaciones web**. ## Contexto Analiza los requerimientos de la aplicación que se adjuntan o proporcionan junto con estas instrucciones. Basa el análisis exclusivamente en la información disponible en esos requerimientos. ## Objetivo Elabora una especificación clara, estructurada y lista para utilizar como base del proyecto antes de comenzar la programación. ## Actividades requeridas Desarrolla los siguientes apartados: ### 1. Resumen funcional Describe el propósito de la aplicación, el problema que busca resolver, sus usuarios principales y su alcance funcional. No agregues objetivos que no estén respaldados por los requerimientos. ### 2. Actores y funcionalidades Identifica los actores o tipos de usuario mencionados o que se desprendan claramente de los requerimientos. Para cada actor, enumera las funcionalidades que puede realizar. Si los roles o permisos no están definidos, indícalo como una ambigüedad en lugar de asumirlos. ### 3. Módulos del sistema Agrupa las funcionalidades identificadas en módulos lógicos. Para cada módulo, incluye: - Nombre. - Propósito. - Funcionalidades incluidas. - Requerimientos relacionados, cuando sea posible identificarlos. No propongas módulos para funcionalidades que no estén justificadas por los requerimientos. ### 4. Entidades y relaciones Identifica las entidades de información del sistema y sus atributos únicamente cuando estén especificados o claramente respaldados por los requerimientos. Describe las relaciones entre entidades y sus cardinalidades cuando puedan determinarse. Si faltan datos para establecer atributos, claves, restricciones o cardinalidades, registra las dudas correspondientes sin inventar respuestas. ### 5. Reglas de negocio Extrae y enumera las reglas de negocio explícitas o claramente implícitas en los requerimientos. Distingue las reglas confirmadas de las que requieren validación del cliente. ### 6. Pantallas necesarias Lista las pantallas, vistas o formularios necesarios para cubrir las funcionalidades requeridas. Para cada pantalla, especifica: - Nombre. - Objetivo. - Información que presenta. - Campos de entrada, si corresponde. - Acciones disponibles. - Módulo al que pertenece. Incluye inicio de sesión, navegación u otras pantallas transversales solo si los requerimientos las justifican. Si su necesidad no está clara, inclúyela como pregunta pendiente y no como requisito confirmado. ### 7. Estructura de carpetas propuesta Propón una estructura de carpetas coherente con las tecnologías y el alcance identificados. Incluye solo directorios y archivos razonables para implementar los requerimientos. Explica brevemente la responsabilidad de las carpetas principales. Si la estructura depende de decisiones aún no tomadas, señala los supuestos y las alternativas. ### 8. Tecnologías a utilizar Recomienda las tecnologías apropiadas para frontend, backend, base de datos, estilos, herramientas de desarrollo y despliegue, según los requerimientos disponibles. Diferencia entre: - Tecnologías exigidas expresamente por los requerimientos. - Tecnologías recomendadas por criterio técnico. No presentes una tecnología como requisito del cliente si este no la ha especificado. ### 9. Ambigüedades, supuestos y riesgos Identifica la información incompleta, contradictoria o susceptible de varias interpretaciones. Para cada punto, explica brevemente por qué debe aclararse antes de programar y qué decisiones del proyecto podría afectar. No resuelvas las ambigüedades mediante suposiciones silenciosas. ### 10. Preguntas para el cliente Formula preguntas concretas, claras y priorizadas que el cliente debe responder antes de iniciar el desarrollo. Organízalas, cuando corresponda, por temas: - Alcance y funcionalidades. - Actores, roles y permisos. - Datos y relaciones. - Reglas de negocio y validaciones. - Pantallas y experiencia de usuario. - Seguridad y privacidad. - Reportes, exportaciones e integraciones. - Tecnologías, alojamiento y despliegue. Incluye únicamente los temas pertinentes al proyecto. Marca las preguntas que bloquean decisiones esenciales como **Prioridad alta** y las que pueden resolverse durante el diseño detallado como **Prioridad media**. ## Criterios de análisis 1. **No inventes funcionalidades, actores, campos, reglas de negocio ni integraciones.** 2. Basa las conclusiones en los requerimientos adjuntos. 3. Distingue claramente los requisitos confirmados, las recomendaciones técnicas y los puntos pendientes de validación. 4. Cuando una información no esté disponible, escribe **"No especificado en los requerimientos"**. 5. Si una relación o cardinalidad no puede determinarse, indícalo expresamente. 6. Evita duplicar funcionalidades en diferentes apartados; utiliza referencias cruzadas cuando resulte útil. 7. Utiliza lenguaje técnico claro, profesional y comprensible para el cliente y el equipo de desarrollo. 8. No comiences a programar ni generes código de la aplicación. El resultado solicitado es una especificación previa al desarrollo. ## Formato de entrega Presenta el resultado en Markdown, con: - Título del proyecto, si se conoce; de lo contrario, usa **"Especificación de la aplicación web"**. - Tabla de contenido si el documento es extenso. - Encabezados numerados siguiendo los apartados anteriores. - Tablas para actores, módulos, entidades, pantallas y preguntas cuando faciliten la lectura. - Listas numeradas para reglas de negocio y decisiones pendientes. - Una sección final de **"Validaciones necesarias antes de iniciar el desarrollo"** con las decisiones que deben quedar acordadas. El documento debe quedar organizado y listo para utilizarse como especificación inicial del proyecto. No afirmes que un punto está confirmado si los requerimientos no lo respaldan.