2 Determinacion de Necesidades - Davidcuama/via-coinogas GitHub Wiki
Sección 2 · Determinación de Necesidades
2.1 Requisitos Funcionales
2.1.1 Proceso de elicitación
Se aplicaron tres técnicas complementarias. La combinación fue deliberada: la entrevista aporta la intención y las prioridades del cliente, el análisis documental aporta la estructura exacta de los datos, y el análisis del proceso actual revela los puntos de fricción que el software debe eliminar.
| Técnica | Participantes | Fecha | Resultado |
|---|---|---|---|
| Entrevista semiestructurada con el cliente | Por Coinogas: Sergio Andrés Quintero Albarracín, Daryi Alejandra Silva López, Gerardo Cuadros Chahín.Por el equipo: David Cuadros, Juan Esteban Villada, Juan Camilo Gómez, Juan Pablo Posso. | 24 de julio de 2026, 14:56 (GMT-05:00) | Sesión virtual donde el cliente describió el proceso actual, sus puntos de dolor y las funcionalidades esperadas. De aquí salieron la mayoría de requisitos y las decisiones de alcance: priorizar funcionalidad sobre complejidad, no construir módulo de proveedores, no permitir reutilización de plantillas. |
| Análisis de documentos | Equipo de desarrollo | Julio – agosto de 2026 | Estudio del formato ADM-F-22 Rev. 02 entregado diligenciado con un caso real (calibración de un Fluke 725 con módulos de presión y RTD). Permitió extraer el modelo de datos completo. |
| Análisis del proceso actual (AS-IS) | Equipo, con base en la descripción del cliente | Julio de 2026 | Reconstrucción del flujo vigente para identificar dónde se pierde información y dónde se duplica el trabajo. De aquí salieron los requisitos de validación, notificación, bandeja centralizada y exportación. |
2.1.2 Evidencias
- Grabación audiovisual completa de la sesión del 24 de julio de 2026, remitida por el cliente.
- Notas y resumen automático de la sesión generados por la herramienta de reunión.
- Archivo ADM-F-22 diligenciado con el caso real de calibración.
Ver Evidencias de las ceremonias para los enlaces a los archivos.
2.1.3 Catálogo de requisitos funcionales
Prioridad en escala MoSCoW: Debe (imprescindible para el MVP), Debería (importante, el producto es utilizable sin ello), Podría (deseable, candidato a versiones posteriores).
| ID | Nombre | Descripción | Prioridad |
|---|---|---|---|
| RF-01 | Crear requerimiento en blanco | Presentar siempre un formulario vacío, sin opción de duplicar o precargar solicitudes anteriores. | Debe |
| RF-02 | Registrar encabezado | Capturar solicitante, área o proyecto y centro de costo; registrar automáticamente la fecha. | Debe |
| RF-03 | Registrar justificación | Permitir redactar en texto libre la justificación del requerimiento. | Debe |
| RF-04 | Definir prioridad | Seleccionar la prioridad entre los valores parametrizados. | Debe |
| RF-05 | Definir fecha requerida | Registrar la fecha de recepción requerida y rechazar fechas anteriores a la de solicitud. | Debe |
| RF-06 | Agregar ítems múltiples | Añadir y eliminar dinámicamente ítems, numerándolos consecutivamente. | Debe |
| RF-07 | Registrar datos del ítem | Capturar cantidad y descripción; marcar si requiere calibración y si es reembolsable. | Debe |
| RF-08 | Calcular totales | Calcular el total por ítem y el total general a partir del precio de referencia. | Debería |
| RF-09 | Registrar especificaciones técnicas | Capturar marca, material, P/N, referencia, color, dimensiones, presentación y otras. | Debe |
| RF-10 | Adjuntar fotografías | Adjuntar al menos dos imágenes en JPG y PNG, validando tamaño y tipo. | Debe |
| RF-11 | Capturar imagen desde móvil | Tomar la fotografía con la cámara del dispositivo al acceder desde un móvil. | Debería |
| RF-12 | Sugerir proveedores | Registrar hasta tres proveedores con nombre y teléfono, como texto libre. | Debe |
| RF-13 | Registrar alternativas | Indicar si existen productos o servicios sustitutos y cuáles. | Debería |
| RF-14 | Validar campos obligatorios | Impedir el envío con campos obligatorios vacíos y señalar cuáles faltan. | Debe |
| RF-15 | Asignar consecutivo único | Generar un número consecutivo único e irrepetible por requerimiento. | Debe |
| RF-16 | Persistir en base de datos central | Almacenar el requerimiento completo con ítems, especificaciones y adjuntos. | Debe |
| RF-17 | Confirmar radicación | Mostrar en pantalla la confirmación con el consecutivo asignado. | Debe |
| RF-18 | Notificar al área de compras | Enviar notificación por correo en cada radicación. | Debería |
| RF-19 | Bandeja centralizada | Ofrecer un listado único con todos los requerimientos radicados. | Debe |
| RF-20 | Filtrar y ordenar | Filtrar y ordenar por área, prioridad, estado y fechas. | Debe |
| RF-21 | Consultar detalle | Mostrar la ficha completa incluidas las fotografías. | Debe |
| RF-22 | Gestionar estados | Cambiar el estado entre Radicado, En revisión, Devuelto, En cotización y Cerrado. | Debería |
| RF-23 | Devolver con observaciones | Devolver al solicitante con un comentario que explique qué corregir. | Debería |
| RF-24 | Consultar histórico propio | Permitir al solicitante ver sus requerimientos y estados. | Debería |
| RF-25 | Registrar bitácora de cambios | Registrar qué usuario modificó qué campo y cuándo. | Podría |
| RF-26 | Exportar consolidado | Exportar los requerimientos filtrados a Excel o CSV. | Debería |
| RF-27 | Parametrizar catálogos | Gestionar áreas, centros de costo y niveles de prioridad. | Debería |
| RF-28 | Administrar usuarios | Crear, modificar y desactivar cuentas desde el panel de Django. | Podría |
| RF-29 | Exponer vistas analíticas | Exponer vistas con requerimientos, ítems y cambios de estado, desnormalizadas para analítica. | Debe |
| RF-30 | Habilitar acceso de solo lectura | Usuario de base de datos restringido, solo lectura sobre las vistas. | Debe |
| RF-31 | Tablero de indicadores | Tablero en Power BI con volumen por periodo, distribución por área y prioridad, tiempo de atención y tasa de devolución. | Debería |
| RF-32 | Actualizar los datos del tablero | Actualización programada al menos una vez al día, sin intervención manual. | Debería |
2.1.4 Requisitos no funcionales preliminares
El tratamiento completo corresponde al entregable de Diseño de la Arquitectura. Se relacionan aquí los que surgieron durante la elicitación y condicionan decisiones de producto.
| ID | Atributo | Descripción |
|---|---|---|
| RNF-01 | Usabilidad | El formulario debe poder diligenciarse sin capacitación previa. Los rótulos deben coincidir con los del ADM-F-22 que los funcionarios ya conocen. |
| RNF-02 | Compatibilidad móvil | Interfaz responsiva y utilizable desde un teléfono, porque la fotografía se toma en campo. |
| RNF-03 | Integridad de datos | Un requerimiento radicado no puede modificarse silenciosamente: todo cambio queda con autor y marca de tiempo. |
| RNF-04 | Desempeño | La bandeja debe cargar en menos de tres segundos con hasta mil registros. |
| RNF-05 | Seguridad del acceso analítico | Power BI se conecta con credenciales distintas a las de la aplicación, limitadas a lectura sobre las vistas. |
| RNF-06 | Mantenibilidad | Versionado en GitHub con flujo de ramas por funcionalidad y revisión por pares antes de integrar a la rama principal. |
2.2 Análisis de la competencia
Se analizaron cuatro soluciones del mercado con funcionalidades equivalentes. El ejercicio no busca demostrar superioridad técnica —ninguna solución académica compite con una plataforma empresarial consolidada— sino justificar por qué un desarrollo a la medida es más adecuado para el caso concreto de Coinogas.
SAP Ariba (módulo Buying / Procurement)
Empresa: SAP SE Costo: suscripción empresarial negociada por módulo y volumen de transacciones. Los análisis públicos sitúan los contratos anuales entre decenas y cientos de miles de dólares, con implementaciones que suelen requerir consultoría externa. Diferenciador: Ariba resuelve el ciclo completo de abastecimiento estratégico para organizaciones globales. Coinogas no necesita ese ciclo: necesita que un formato específico deje de diligenciarse en Excel. VIA Coinogas replica el ADM-F-22 tal como existe, sin obligar a rediseñar el procedimiento ni a asumir un costo desproporcionado frente al problema.
Odoo Purchase
Empresa: Odoo S.A. Costo: la edición Community es de código abierto y sin costo de licencia, pero exige infraestructura e implementación propias. La edición Enterprise se cobra por usuario y por mes, con precios de entrada reportados alrededor de USD 31 por usuario/mes en comparadores de mercado. Diferenciador: el licenciamiento por usuario es el obstáculo. En Coinogas cualquier funcionario de cualquier área puede radicar un requerimiento, de modo que el costo escalaría con toda la planta. Además, adoptar Odoo implica aceptar su modelo de datos de compras, que no contempla campos propios del formato como la marca de calibración o la casilla de reembolsable.
Zoho Forms
Empresa: Zoho Corporation Costo: plan gratuito con límites de envíos y almacenamiento. Los planes pagos van desde aproximadamente USD 12 mensuales en el nivel básico hasta cerca de USD 110 en el nivel Premium. Diferenciador: es un constructor de formularios genérico. Resuelve bien la captura, pero no modela la relación entre un requerimiento y sus múltiples ítems, cada uno con su propio bloque de especificaciones técnicas. Tampoco ofrece estados, devolución con observaciones ni bitácora.
Google Forms + Google Sheets
Empresa: Google LLC Costo: sin costo adicional para organizaciones que ya tengan Google Workspace; las suscripciones parten de alrededor de USD 7 por usuario/mes. Diferenciador: es la alternativa más económica y la más tentadora, pero reproduce el problema que se quiere eliminar. La información sigue viviendo en una hoja de cálculo, sin validaciones relacionales, sin ítems anidados y sin control de estados. Migrar de un Excel a una hoja de Google no resuelve la trazabilidad; solo cambia el archivo de sitio.
Sobre los costos: son valores de referencia de comparadores públicos y análisis de mercado consultados en agosto de 2026. Varían por país, número de usuarios, módulos contratados y condiciones de negociación. Deben tomarse como órdenes de magnitud, no como cotizaciones.
Síntesis del diferenciador
El factor que distingue a VIA Coinogas no es funcional sino de ajuste. Las cuatro alternativas obligan a Coinogas a adaptarse a la herramienta: a su modelo de datos, a su licenciamiento o a su forma de entender el proceso de compras. VIA Coinogas se construye sobre el formato que la organización ya usa y que su gente ya sabe leer, y se limita a resolver los tres problemas concretos que el cliente señaló: la falta de trazabilidad, los errores heredados del copiado y pegado, y la doble digitación hacia la sábana de Excel.