Un pedido de mejora suele llegar como una solución: agregar un campo, cambiar un reporte o automatizar un paso. El trabajo funcional empieza por entender qué necesita lograr la persona y cómo se realiza hoy el proceso.
Describir la necesidad antes de diseñar
La primera conversación debería aclarar qué tarea se realiza, qué dificultad aparece y cuál sería un resultado útil. Es importante identificar a los usuarios que participan, los datos que necesitan y las situaciones que deben quedar contempladas.
Después se puede revisar cómo el ERP acompaña ese recorrido: configuración, autorizaciones, reportes, integraciones y uso real de las funcionalidades. La solución se define con ese contexto y un alcance acordado.
Cinco elementos del requerimiento
- Objetivo: qué problema se quiere resolver y para quién.
- Regla de negocio: qué condiciones deben cumplirse y cuáles son las excepciones.
- Actores: quién solicita, ejecuta, valida y aprueba.
- Datos: origen, significado, obligatoriedad y controles relevantes.
- Aceptación: qué ejemplos demostrarán que el resultado funciona.
Ejemplo didáctico: una aprobación de compras
El pedido inicial dice: “Necesitamos aprobar determinadas órdenes”. Para convertirlo en un requerimiento, se debe acordar qué órdenes requieren aprobación, cómo se identifica al responsable y qué sucede cuando la solicitud se rechaza o modifica.
También hay que definir qué usuarios pueden crear, aprobar o consultar la orden; qué estados se mostrarán; y qué información quedará disponible para seguimiento. Los importes, roles y condiciones se determinan con la empresa.
Conectar el documento con las pruebas
Cada regla debe relacionarse con uno o más casos de prueba. Conviene incluir un caso habitual, una excepción y un caso que no deba ejecutar la acción. Los usuarios clave validan el resultado con datos preparados para el ejercicio.
Esta relación ayuda a conversar sobre diferencias entre lo pedido, lo diseñado y lo entregado. También facilita documentar cambios de alcance: qué regla cambió, por qué, quién la aceptó y qué pruebas necesitan repetirse.
Qué debería quedar al final
- Una descripción comprensible del proceso y de la necesidad.
- Reglas y excepciones con responsables identificados.
- Datos y autorizaciones necesarios para operar.
- Casos de aceptación que el negocio pueda ejecutar.
- Una decisión documentada sobre el alcance de la entrega.
El requerimiento funcional conecta la conversación del usuario con la configuración o el desarrollo. Su calidad se aprecia cuando el equipo puede implementar, probar y aprobar una mejora con la misma comprensión del resultado esperado.