Un caso de uso completo: cómo entrevistar a un usuario, analizar sus necesidades, y transformarlas en requerimientos funcionales, no funcionales y OKRs medibles.
Todo proyecto debe nacer de una necesidad detectada en un potencial cliente concreto. Este es el nuestro.
El punto de partida obligatorio del proyecto es un problema real validado con un usuario o cliente concreto. No se admiten proyectos sobre problemas hipotéticos ni sobre situaciones internas de la institución.
La solución debe dirigirse al mercado global o a una organización externa. El equipo debe demostrar que ha diferenciado entre las causas del problema y los simples síntomas.
El usuario será citado físicamente en etapas específicas del proyecto para dar su devolución.
Antes de escribir una sola línea de código, el equipo debe realizar un relevamiento exhaustivo mediante entrevistas estructuradas para diagnosticar la situación actual del cliente.
Definición incorrecta → solución incorrecta.
Todo proyecto requiere al menos dos entrevistas. La primera para conocer al usuario y su entorno. La segunda, con ese contexto, para relevar el problema en profundidad y definir los requerimientos.
Primera entrevista — Conocer al usuario y su entorno. El objetivo no es todavía levantar requerimientos. Es entender quién es Roberto, cómo trabaja, qué siente que está mal y cuál es el contexto general de la ferretería. Se usan los bloques A, B y C. Dura aproximadamente 30 minutos y permite al equipo llegar a la segunda entrevista con contexto real.
Segunda entrevista — Relevar el problema en profundidad. Con el contexto de la primera, el equipo puede hacer preguntas más precisas: cuántos usuarios van a operar el sistema, qué restricciones de acceso necesita, qué datos de accesibilidad condicionan el diseño de la interfaz. Se usan los bloques D, E, F, G y H. Esta entrevista produce los datos que definen los requerimientos funcionales y no funcionales.
Sin esta separación, el equipo llega a la primera reunión con preguntas que el usuario no puede responder porque aún no confía ni entiende para qué sirven.
Primera (bloques A, B, C): perfil de Roberto, dispositivos y tecnología que usa, cantidad de personas en la ferretería. Con esto el equipo sabe si el sistema es mobile-first, si necesita modo offline y cuántos perfiles hay que diseñar.
Segunda (bloques D al H): descripción detallada del problema actual, cuantificación con Likert, condiciones de accesibilidad y visión, profundización por sondeo, y cierre de viabilidad comercial. Con esto el equipo define los RF, los RNF y la línea de base para el Benchmarking.
Los bloques B (tecnología) y F (accesibilidad) son los más frecuentemente omitidos. Sin ellos, el equipo puede diseñar para la plataforma equivocada o para un usuario imaginario.
Entrevistado: Roberto Fernández · Versión 2 · ~45 minutos
Suponemos que Roberto respondió. Ahora transformamos sus respuestas en la línea de base del proyecto y separamos síntomas de causas reales.
El error más común: el equipo construye una solución al síntoma en lugar de a la causa. Si Roberto dice "a veces no tengo lo que el cliente pide" y el sistema solo muestra una alerta cuando el stock llega a cero, el problema no se resuelve.
La solución correcta ataca la causa: no hay actualización automática de stock por venta, y no hay señal de reposición anticipada.
Los números de la entrevista son la línea de base: el punto de partida medible. Al final del proyecto, el equipo tiene que volver con Roberto, repetir las mismas preguntas, y demostrar que los números mejoraron.
Sin línea de base, no hay forma de probar que el sistema funcionó.
Celular como dispositivo principal · WhatsApp y Mercado Libre · WiFi con cortes frecuentes · Dos usuarios (él + Juan) · Le preocupa que Juan vea los precios de costo · Presbicia, usa lentes de lectura · Hace zoom en el celular · La pantalla brillante le cansa la vista · Sin daltonismo · Sin dificultad motriz
Cada requerimiento debe poder trazarse hasta una respuesta concreta de la entrevista. Si no puede, no tiene justificación para estar en el proyecto.
RF Requerimiento Funcional: describe qué hace el sistema. "El sistema debe registrar ventas y descontar el stock automáticamente."
RNF No Funcional: describe cómo lo hace. "El sistema debe funcionar sin internet y sincronizar cuando vuelva la conexión." Los RNF son igual de obligatorios que los RF.
ISW Interfaces de Software: componentes del stack y cómo se articulan entre sí. "El backend Node.js expone una API REST que el frontend React consume." Corresponde a la sección 4.4 del documento.
LIM Limitaciones: lo que el sistema explícitamente no va a hacer en esta entrega. Define el alcance hacia el usuario y evita expectativas incorrectas. Corresponde a la sección 2.2 del documento.
Los RF marcados con nuevo nacen exclusivamente de los bloques B, C y F.
RF Sección 4.1 — Requerimientos funcionales
RNF — plataforma Sección 3.4.2 — Limitaciones de hardware
RNF — conectividad Sección 3.4.6 — Protocolos señalados
RNF — accesibilidad Sección 4.2 — Interfaces de usuario
RNF — seguridad Sección 3.4.9 — Consideraciones de seguridad
ISW Sección 4.4 — Interfaces de software
LIM Sección 2.2 — Alcance del sistema
Un usuario que no sabe qué no hace el sistema asume que lo hace todo. Cuando descubre que no, lo vive como una promesa incumplida.
Documentar las limitaciones no es admitir debilidad del proyecto: es establecer un contrato claro de alcance que protege al equipo y genera confianza en el usuario.
Las limitaciones de esta entrega pueden convertirse en la sección 3.6 — Evolución previsible del sistema (funcionalidades para versiones futuras).
| ID | Nombre | Prioridad | Origen |
|---|---|---|---|
RF01 | Registro de ventas con descuento automático de stock Al registrar una venta, el sistema descuenta la cantidad sin intervención manual. | Alta | "Tardo horas en el control" + "a veces no tengo lo que piden" |
RF02 | Alerta de stock mínimo por producto Notificación cuando un producto llega al umbral configurable. | Alta | 6–15 ventas perdidas por mes |
RF03 | Consulta de stock en tiempo real desde el mostrador Búsqueda optimizada para uso con una mano en celular. | Alta | "El cliente pide y no sé si tengo" + usa celular en el mostrador |
RF04 | Historial de rotación por producto | Media | "Compro de más y no vendo" |
RF05 | Lista de pedido a proveedor exportable | Media | "Pierdo tiempo revisando estantes para hacer pedidos" |
RF06 nuevo | Dos perfiles con permisos diferenciados Dueño: acceso total. Empleado: solo ventas y consulta. Sin precios de costo. | Alta | Bloque C: "Juan no debe ver precios de costo" (nuevo) |
RF07 nuevo | Funcionamiento offline con sincronización automática | Alta | Bloque B: "WiFi con cortes frecuentes" (nuevo) |
RF08 nuevo | Envío de lista de pedido por WhatsApp | Media | Bloque B: usa WhatsApp a diario (nuevo) |
RF09 nuevo | Modo oscuro conmutable por el usuario | Media | Bloque F: pantalla brillante le cansa la vista (nuevo) |
RF10 nuevo | Onboarding guiado en el primer uso | Baja | Bloque B: comodidad tecnológica 2/5 (nuevo) |
| ID | Nombre y descripción | Categoría | Sección doc. |
|---|---|---|---|
RNF-01 | Diseño mobile-first Todos los flujos críticos deben poder completarse con una sola mano en pantalla de 360–430px. | plataforma | 3.4.2 |
RNF-02 | Soporte para escala de texto al 150% El diseño no se rompe con el texto del sistema escalado. Usar unidades relativas (rem/em). | accesibilidad | 3.4.7 |
RNF-03 | Fuente mínima 18px para texto de uso frecuente Todo texto crítico (productos, cantidades, alertas, botones) ≥ 18px. Origen: presbicia. | accesibilidad | 4.2 |
RNF-04 | Contraste mínimo WCAG AA Ratio 4.5:1 para texto normal, 3:1 para texto grande. En ambos modos (claro y oscuro). | accesibilidad | 3.4.9 |
RNF-05 | Estados del sistema nunca solo por color Toda alerta combina color + texto descriptivo o ícono. Buena práctica universal. | accesibilidad | 4.2 |
RNF-06 | Funcionamiento offline sin pérdida de datos Opera sin internet, encola localmente, sincroniza automáticamente sin duplicados. Origen: WiFi con cortes. | conectividad | 3.4.6 |
RNF-07 | Aislamiento de datos entre perfiles El perfil Empleado no puede ver precios de costo. Control implementado en servidor, no solo en frontend. | seguridad | 3.4.9 |
RNF-08 | Tiempo de aprendizaje ≤ 30 minutos Un usuario con comodidad 2/5 completa el flujo principal sin ayuda en ≤30 min desde el primer uso. | usabilidad | 3.4.8 |
| ID | Componente | Tecnología / Stack | Rol en el sistema |
|---|---|---|---|
ISW01 |
Frontend — Interfaz de usuario La app web que Roberto y Juan usan desde el celular o la PC del local para registrar ventas, consultar stock y ver alertas. |
React + Vite (responsive, mobile-first) Tailwind CSS · PWA-ready para instalación en celular |
Capa de presentación. Diseñada en Figma antes de programarse (sección 4.2.1). Debe funcionar correctamente con fuente del sistema operativo escalada al 150%. |
ISW02 |
Backend — API REST Servidor que gestiona la lógica de negocio: registro de ventas, actualización de stock, cálculo de alertas de mínimo y generación de reportes de rotación. |
Node.js + Express Autenticación: JWT · ORM: Prisma |
Expone endpoints REST que el frontend consume. Gestiona la lógica de permisos entre perfiles (Dueño vs. Empleado) a nivel de servidor, no solo de interfaz. |
ISW03 |
Base de datos Almacena productos, stock, ventas con timestamp, usuarios del sistema y umbrales de alerta por producto. |
PostgreSQL Cada venta registrada con fecha, producto, cantidad y usuario que la cargó |
Persistencia central. El historial de rotación (RF04) y los reportes de pedido (RF05) dependen de la integridad de esta capa. |
ISW04 |
Módulo de sincronización offline Cola local en el dispositivo que encola las operaciones realizadas sin conexión y las sincroniza cuando el WiFi se restablece. |
IndexedDB (browser) + Service Worker Estrategia: queue-and-sync con detección automática de reconexión |
Implementa RNF-06. Sin este módulo, una caída del WiFi en el local impide registrar ventas. Es crítico para el funcionamiento en campo. |
ISW05 |
Sistema de alertas Módulo del backend que evalúa el stock de cada producto después de cada venta y dispara una notificación si alguno llega al umbral mínimo configurado. |
Proceso background en Node.js Canal: notificación push vía PWA o WhatsApp API (a confirmar con Roberto) |
Implementa RF02. No requiere que Roberto tenga el dashboard abierto para recibir la alerta. Se dispara automáticamente en el servidor. |
ISW06 |
Integración de compartir — API nativa del SO Permite compartir la lista de pedido a proveedores directamente desde el sistema a través del menú nativo de compartir del celular (WhatsApp, email, etc.). |
Web Share API (nativa del navegador móvil) Sin integración de terceros — usa el menú de compartir del sistema operativo |
Implementa RF08. Roberto ya usa WhatsApp a diario; este mecanismo usa un patrón que ya conoce sin necesidad de configurar nada. |
| ID | Qué NO hace el sistema en esta entrega | Por qué | ¿Versión futura? |
|---|---|---|---|
LIM01 |
No gestiona proveedores ni órdenes de compra El sistema genera la lista de productos bajo mínimo y permite enviarla por WhatsApp. No registra la compra, no gestiona precios de proveedor ni órdenes formales. |
Roberto no lo solicitó en la entrevista y está fuera del alcance funcional de esta versión. Agregarlo requeriría un módulo completo de proveedores. | Sí — v2 puede incluir ABM de proveedores y registro de compras para cerrar el ciclo de stock. |
LIM02 |
No integra con sistemas de facturación ni con AFIP El sistema registra ventas internas para controlar stock. No emite facturas ni se conecta con ningún software contable o sistema fiscal. |
La integración con AFIP requiere certificado digital, conocimiento fiscal específico y pruebas en ambiente de homologación. Está fuera del alcance del proyecto. | Sí — puede integrarse con sistemas de punto de venta como Tienda Nube o Mercado Pago en versiones futuras. |
LIM03 |
No incluye app nativa para iOS o Android El acceso desde el celular se realiza a través del navegador web del celular, no de una app descargada desde la tienda de aplicaciones. |
Desarrollar una app nativa duplica el tiempo de desarrollo y requiere cuentas de desarrollador en App Store y Play Store. El dashboard web responsive y la PWA son funcionalmente equivalentes para el uso de Roberto. | Sí — la PWA (Progressive Web App) ya permite "instalar" el sistema en la pantalla de inicio del celular sin tienda de aplicaciones. |
LIM04 |
No incluye caja ni gestión de pagos de clientes El sistema registra qué se vendió para descontar del stock, pero no procesa pagos, no lleva caja chica ni registra si el cliente pagó en efectivo o con tarjeta. |
Roberto no lo solicitó. La gestión de pagos es un dominio separado con sus propias regulaciones y complejidad técnica. | Sí — v2 puede incorporar módulo de caja con integración Mercado Pago o Modo. |
LIM05 |
No incluye mantenimiento del sistema post-entrega El proyecto contempla el desarrollo, despliegue y documentación. El mantenimiento correctivo y las actualizaciones posteriores no están incluidas en el alcance. |
El alcance del proyecto es académico. Un contrato de mantenimiento requeriría negociación separada si el proyecto se comercializa. | Sí — puede formalizarse como acuerdo de soporte técnico con costo mensual. |
Cada objetivo tiene Key Results medibles con métricas concretas derivadas de la línea de base. Los KRs nuevos (en verde) nacen de los bloques B, C y F.
O (Objective): meta cualitativa e inspiradora. Lo que el equipo quiere lograr para el usuario. No se mide directamente.
KR (Key Result): métrica cuantitativa de progreso. Debe poder responderse con un número. "Reducir el tiempo de control de stock a menos de 10 minutos" es un KR. "Mejorar la experiencia" no lo es.
Los KRs sin números son inútiles.
Los OKRs 4, 5 y 6 son los que más cuesta que los equipos entiendan como obligatorios.
El KR de contraste WCAG se audita con una herramienta. El KR de sincronización se mide con 10 pruebas. El KR del flujo sin zoom se observa en persona con Roberto.
Eso es lo que hace que un KR sea útil: puede verificarse con evidencia, no con una opinión.
Cada persona que interactúa con el sistema es una fila en la tabla de perfiles. Sin esta tabla, los requerimientos funcionales son parciales.
Cada perfil diferente implica: una pantalla de login distinta, una navegación adaptada, posiblemente una versión simplificada de la interfaz, y un conjunto de permisos diferente en el servidor.
Pasar de un usuario a dos no es agregar una pantalla más: es redefinir la arquitectura de acceso del sistema completo.
El perfil del empleado está incompleto. Antes de diseñar su interfaz, hay que hacer una segunda entrevista. Su diseño puede diferir completamente del de Roberto si tiene condiciones de accesibilidad distintas.
No asumir que Juan tiene la misma comodidad tecnológica ni la misma visión que Roberto.
Celular → Frame en Figma: 390×844px. Todo se testea en ese tamaño primero.
Presbicia → Estilos de texto arrancan en 18px. Ningún dato crítico en 14px o menos.
WhatsApp → El patrón de lista de chats puede inspirar la lista de productos. Roberto ya lo sabe navegar.
Fatiga visual → El prototipo incluye dos variantes: modo claro y modo oscuro. Ambas se testean con Roberto antes de programar.
Nivel 2/5 → Sin menú hamburguesa. Sin iconografía sin etiqueta. La acción principal siempre visible como botón grande en la parte inferior.