Programar no es suficiente
Introducción
Hoy en día, desarrollar software es más rápido que antes. Las herramientas de inteligencia
artificial pueden generar código, proponer soluciones e incluso ayudar a construir sistemas en
poco tiempo. Sin embargo, que un sistema funcione técnicamente no significa que resuelva el
problema para el que fue creado. Antes de programar, el ingeniero necesita comprender el
negocio, los usuarios, sus reglas y necesidades.
De aquí surge una pregunta clave: si el ingeniero puede programar una solución pero no
comprende el problema, ¿realmente está desarrollando el sistema correcto? Para evitar esto,
conocer el dominio del negocio y transformar las necesidades del usuario en requerimientos
adecuados es fundamental. En definitiva, el desarrollo no depende únicamente de escribir
código, sino de entender correctamente el problema desde el principio.
Desarrollo
Cuando un usuario necesita que los ingenieros resuelvan un problema, él ya tiene definido cuál
es su problema, porque conoce su negocio, ha interactuado con sus clientes y sabe todas sus
reglas y restricciones. Cuando transmite sus necesidades, la mayoría de ingenieros no son
expertos en el negocio; el experto es el solicitante. Pero no basta solo con escucharlo, para dar
una buena solución los ingenieros también deben conocer y comprender el negocio. La toma de
requerimientos no debe ser platicar con el cliente y escuchar que quiere un sistema para
monitorear sus ganancias. Los ingenieros deben comprender el área en la que trabaja, conocer
cuáles son sus ingresos y egresos, de qué forma obtiene sus materias primas, cómo las vende al
cliente, entre otras cosas. Solo al comprender estos procesos es posible identificar qué
información necesita realmente el sistema y cuáles son los requerimientos que deben
considerarse durante su desarrollo. El conocimiento del dominio no es un aspecto secundario durante la toma de requerimientos. El
International Institute of Business Analysis establece que, al preparar una actividad de toma de
requerimientos, se debe considerar el dominio del negocio y la participación de expertos en el
área, ya que estos pueden aportar información y orientar sobre las fuentes que deben
consultarse.¹ Esto permite comprender que el trabajo del ingeniero no consiste únicamente en
recopilar lo que el usuario expresa, sino en analizar la información obtenida y transformarla
posteriormente en requerimientos y diseños.²
Ilustración 1. Modelo simplificado del proceso de ingeniería de requisitos. Fuente: Bernárdez, Beatriz; Amador Durán Toro y Miguel Toro (2003), consultado en ResearchGate.
ResearchGate.
Por esta razón, el conocimiento del dominio adquiere importancia durante la toma de
requerimientos, ya que permite al ingeniero comprender las reglas, procesos y restricciones que
existen dentro de un determinado entorno. No se trata únicamente de saber qué sistema quiere el
cliente, sino de comprender por qué lo necesita y cómo funciona el contexto en el que será
utilizado. A partir de esta relación entre el conocimiento del dominio y la ingeniería de
requisitos, se puede analizar hasta qué punto un ingeniero debe involucrarse en el área para la
que desarrolla una solución.
Un requisito puede parecer claro para el usuario, pero resultar ambiguo para quien debe
convertirlo en una solución técnica. Por ejemplo, solicitar “un sistema para monitorear las ganancias” no permite determinar qué
egresos, costos y ventas que deben registrarse y relacionarse para obtener la información
solicitada. Este análisis permite transformar una necesidad general en un requerimiento más
preciso y útil para las siguientes etapas del desarrollo.³
La inteligencia artificial también apoya durante la ingeniería de requerimientos, para organizar
información, analizar historias de usuario, identificar posibles inconsistencias y proponer
elementos relacionados con el dominio. Sin embargo, estas herramientas no sustituyen la
participación del ingeniero, quien debe revisar los resultados y comprobar que la información
obtenida corresponde con las necesidades, reglas y restricciones del negocio.³
Conclusiones
Comprender el problema antes de desarrollar permite que el sistema responda mejor a lo que
realmente necesita el usuario. No se trata únicamente de recopilar solicitudes, sino de entender
cómo funciona el negocio, qué restricciones existen y qué situaciones deben tomarse en cuenta
para convertirlas en requerimientos útiles. El ingeniero no necesita convertirse en experto del
negocio, pero debe comprenderlo lo suficiente para traducir sus necesidades en requerimientos.
Programar sigue siendo una parte fundamental del desarrollo de software, pero por sí sola no
garantiza una buena solución si se parte de una comprensión incompleta del problema. Por eso,
analizar, preguntar y validar antes de diseñar también forma parte del trabajo del ingeniero.
Referencias
● [1] International Institute of Business Analysis. The Business Analysis Standard. Toronto:
International Institute of Business Analysis, 2022.
● [2] International Institute of Business Analysis. IIBA Global Business Analysis Core
Standard. Toronto: International Institute of Business Analysis, 2021.
● [3] Bragilovski, Maxim, Ashley T. van Can, Fabiano Dalpiaz, y Arnon Sturm.
“Leveraging Machines to Derive Domain Models from User Stories.” Requirements
Engineering 30, no. 2 (2025).
Ver diseño original de las páginas
