2  Anexo A

2.1 Requerimientos y alcance de AdminG Systems

Eduardo Martínez

2.2 Proposito del anexo

Este anexo organiza los requerimientos funcionales y no funcionales de AdminG Systems, una plataforma de administracion general orientada a pequenas, medianas y grandes empresas, publicas, privadas y mixtas. Su funcion dentro del conjunto documental es definir que necesita resolver el sistema antes de explicar como se estructura, como persiste la informacion, como se valida su calidad y como se implementa en un entorno real. Por esa razon, este documento se conecta directamente con el Chapter 3 , donde se traduce el alcance en arquitectura, con el Chapter 4, donde se concreta el modelo de datos, con el Chapter 5, donde se verifican criterios de calidad, y con el Chapter 6, donde se documenta la evidencia de implementacion y despliegue en adming-systems.online.

AdminG combina autenticacion, gestion de usuarios, clientes, citas, servicios, pagos, inventario, reportes, documentos, autorizaciones, CRM, onboarding y control de planes. El objetivo no es construir un modulo aislado, sino una base SaaS progresiva: una aplicacion que pueda empezar con operaciones pequenas y crecer hacia control financiero, trazabilidad documental, gestion de equipos y reglas de negocio por plan.

2.3 Alcance funcional

El sistema debe permitir registro e inicio de sesion mediante credenciales seguras, emision de tokens JWT, refresh tokens y control de acceso por usuario, rol y plan. Una vez autenticado, el usuario accede a un tablero de trabajo donde puede consultar metricas operativas, administrar clientes, programar citas, registrar servicios, manejar pagos, emitir facturas, controlar inventario y revisar reportes.

Tambien se requiere un esquema comercial flexible. AdminG no debe tratar a todos los usuarios igual: un plan gratuito o basico puede habilitar clientes y agenda, mientras que planes superiores pueden activar inventario, pagos, reportes avanzados, CRM, facturacion, documentos o funciones de equipo. Esta regla exige que la autorizacion no dependa solo del rol, sino tambien del plan contratado, del estado de prueba, de los limites definidos y de las caracteristicas habilitadas.

2.4 Requerimientos funcionales y no funcionales

A continuación se detallan los requerimientos con su clasificación explícita como funcional o no funcional.

#	Categoria	Tipo	Requerimiento
1	Autenticacion	Funcional	Registro, login, recuperacion de contrasena, JWT, refresh token, usuario activo y cierre seguro de sesion.
2	Usuarios y roles	Funcional	Administrador, manager, miembros de equipo, subusuarios, permisos y jerarquia por organizacion.
3	Clientes y CRM	Funcional	CRUD de clientes, seguimiento, historial, datos de contacto, mascotas o entidades relacionadas segun tipo de negocio.
4	Operacion	Funcional	Agenda de citas, servicios, paquetes, pagos, facturas, caja, inventario y movimientos.
5	Planes	Funcional	Catalogo Free, Basic, Plus, Start, Max o equivalentes, limites y caracteristicas activables.
6	Reportes	Funcional	Dashboard, metricas de clientes, citas, productos, ingresos y comportamiento operativo.
7	Documentos	Funcional	Facturas, autorizaciones, documentos trazables y posibilidad de evolucionar hacia QR o auditoria formal.
8	Seguridad	No funcional	Hash de contrasenas, CORS estricto, secretos fuera del codigo, validacion Pydantic y control de acceso por recurso.
9	Disponibilidad	No funcional	Despliegue en VM Ubuntu con backend FastAPI sirviendo API y frontend estatico.
10	Mantenibilidad	No funcional	Arquitectura modular, pruebas automatizadas, migraciones, documentacion viva y ramas Git controladas.

2.5 Mapa de requerimientos

2.6 Criterios de aceptacion

Un requerimiento se considera aceptado cuando existe una ruta o vista que lo soporte, un modelo o esquema que lo represente, una regla de permisos que limite su uso si aplica y una evidencia documental que lo conecte con los anexos. Por ejemplo, el login requiere pantalla visible, endpoint de autenticacion, hash de contrasena, token emitido, usuario persistido y evidencia de acceso al dashboard. El inventario requiere categorias, items, cantidades, movimientos, validaciones y reglas por plan.

El despliegue en Oracle Free Tier agrega un requerimiento operativo: la aplicacion debe poder ejecutarse en una VM Micro Ubuntu con recursos limitados, por lo que el diseño debe ser prudente con memoria, procesos, logs, base de datos y dependencias. Para desarrollo en produccion controlada, SQLite puede ser aceptable como etapa inicial si se acompana de backups, pero el crecimiento natural del sistema debe contemplar PostgreSQL.

2.7 Cierre

El Anexo A define a AdminG como una plataforma modular, segura y escalable. Su valor esta en integrar funciones administrativas que suelen estar separadas: clientes, agenda, pagos, inventario, reportes y documentos. La evidencia visual del login y dashboard demuestra que el alcance no es solo teorico; ya existe una interfaz desplegada y operable. Los anexos siguientes explican como esa necesidad se convierte en arquitectura, datos, calidad e implementacion.