1). Introducción

Sistema de Gestión de Talleres y Seminarios

1.1 Propósito

La presente Especificación de Requerimientos de Software (SRS, por sus siglas en inglés: Software Requirements Specification) establece de manera exhaustiva y formal los requerimientos funcionales, no funcionales y de interfaz para el desarrollo y despliegue del Sistema de Gestión de Talleres y Seminarios (SGTS), versión 1.0. Este documento sirve como blueprint contractual y técnico que guía el proceso de ingeniería de software, asegurando alineación entre las expectativas de los stakeholders y la implementación final.

El alcance del SGTS abarca la totalidad del sistema integral diseñado para la administración eficiente de eventos educativos, incluyendo módulos para la inscripción de usuarios, procesamiento de pagos en línea, distribución de materiales digitales, gestión de cupos y generación de certificados. No se limita a subsistemas aislados, sino que describe el ecosistema completo, integrando interacciones entre asistentes, ponentes, procesos automatizados y componentes externos como pasarelas de pago y servicios de notificación. Este enfoque holístico garantiza la trazabilidad de requerimientos desde la fase de análisis hasta la validación y mantenimiento.

1.2 Convenciones del Documento

El presente documento adhiere estrictamente a la estructura y nomenclatura estandarizada por el IEEE Std 830-1998 (Recommended Practice for Software Requirements Specifications), promoviendo claridad, consistencia y reutilización en proyectos de software. Los requerimientos se clasifican y priorizan según criterios de criticidad:

• Alta: Esencial para la viabilidad operativa del sistema; su ausencia compromete la funcionalidad principal (ej. inscripciones o pagos).
• Media: Importante para la usabilidad y eficiencia, pero no crítica para el núcleo del sistema.
• Baja: Deseable para mejoras incrementales, con impacto mínimo en el rendimiento general.

Las prioridades de requerimientos de nivel superior (e.g., objetivos del sistema) se heredan automáticamente a los requerimientos derivados, salvo indicación explícita en contrario, facilitando la gestión de dependencias y el análisis de impacto.

Adicionalmente, se emplean las siguientes convenciones tipográficas para mejorar la legibilidad y precisión semántica:

• Texto en negrita: Denota términos clave, entidades del dominio o conceptos centrales (e.g., Asistente, Taller, Certificado).
• Texto en cursivas: Representa acciones específicas del usuario (inscribirse en seminario) o respuestas del sistema (pago confirmado).
• Código en monospace: Indica elementos de interfaz, comandos o fragmentos de datos (e.g., ID_TALLER: 402).

Se utiliza numeración jerárquica secuencial para secciones y subsecciones, con referencias cruzadas (e.g., [ver Sección 3.2]) para navegación eficiente.

1.3 Audiencia Destinada y Sugerencias de Lectura

Este documento está orientado a una audiencia diversa involucrada en el ciclo de vida del proyecto, asegurando accesibilidad y relevancia según el rol. Los destinatarios principales incluyen:

• Desarrolladores y arquitectos de software: Responsables de la implementación técnica, integración de pagos y diseño modular.
• Gerentes de proyecto y stakeholders ejecutivos: Encargados de la planificación, presupuestos y alineación estratégica institucional.
• Personal administrativo y académico (organizadores y ponentes): Usuarios finales que gestionarán los eventos y contenidos en el sistema.
• Probadores y auditores de calidad: Especialistas en verificación y validación de requerimientos.
• Escritores técnicos y documentadores: Colaboradores en la elaboración de manuales de usuario y guías de mantenimiento.

Para una lectura óptima, se recomienda el siguiente itinerario adaptado al perfil:

Perfil del Lector	Secciones Recomendadas	Razón
Visión general (todos)	Secciones 1 y 2	Proporciona contexto, objetivos y definiciones del dominio educativo.
Desarrolladores y probadores	Secciones 3 y 4	Detalla requerimientos funcionales, no funcionales e interfaces.
Gerentes de proyecto	Sección 2	Enfoca en estructura general, suposiciones y dependencias.
Usuarios administrativos	Sección 2.3	Describe perfiles de usuario y flujos de trabajo de gestión de eventos.
Documentadores	Secciones 1 y 5	Cubre convenciones y referencias para consistencia editorial.

Esta estructura modular permite una consulta selectiva, minimizando el tiempo invertido mientras maximiza la comprensión.

1.4 Alcance del Producto

El Sistema de Gestión de Talleres y Seminarios (SGTS) constituye una aplicación web robusta y escalable, desarrollada bajo paradigmas de arquitectura moderna, que facilita la logística académica y financiera entre participantes y organizadores en instituciones educativas. Sus funcionalidades principales habilitan a los usuarios finales en los siguientes ámbitos:

• Para usuarios/asistentes: Inscribirse en talleres mediante un catálogo interactivo; realizar pagos seguros en línea; descargar materiales previos de lectura; y obtener certificados digitales automáticamente al finalizar el evento.
• Para administradores y ponentes: Gestionar cupos y listas de asistencia en tiempo real; publicar perfiles de ponentes y subir recursos educativos; y monitorear el estado de las inscripciones y la recaudación.

Los beneficios clave derivados de su implementación incluyen:

• Eficiencia operativa: Automatización de la emisión de certificados y control de asistencia, reduciendo la carga administrativa manual.
• Optimización de recursos: Gestión precisa de cupos (gestión de aforo) que evita la sobreventa y asegura la disponibilidad de plazas.
• Experiencia de usuario mejorada: Centralización de todo el proceso, desde el registro hasta la certificación, en una plataforma única y accesible.

El objetivo primordial del SGTS es transformar la gestión de eventos académicos en un proceso ágil y transparente. Fuera del alcance se excluyen funcionalidades avanzadas como la transmisión de video en vivo (streaming) dentro de la plataforma o la integración compleja con sistemas de gestión curricular (LMS) externos, las cuales podrán abordarse en iteraciones futuras.

1.5 Referencias

Para fundamentar la metodología y mejores prácticas empleadas en esta SRS, se citan las siguientes fuentes normativas y académicas:

1. IEEE Std 830-1998. Recommended Practice for Software Requirements Specifications. Institute of Electrical and Electronics Engineers, 1998. (Estándar de referencia para la estructura y contenido de SRS).
2. Wiegers, Karl E. Software Requirements, 2nd Edition. Microsoft Press, 2003. (Guía exhaustiva sobre elicitación, análisis y especificación de requerimientos).
3. Wiegers, Karl E. (1999). Software Requirements Specification Template. Process Impact. Disponible en: https://www.processimpact.com/articles/srs-template.shtml. (Plantilla adaptable utilizada como base para el formato actual).
4. Sommerville, Ian. Software Engineering, 10th Edition. Pearson, 2015. (Marco teórico para la ingeniería de requerimientos en sistemas de información).