Para trabajar correctamente con requerimientos es necesario distinguir cuatro conceptos que suelen mezclarse: necesidades, problemas, objetivos y requerimientos. Aunque están relacionados, no significan lo mismo.
Muchas dificultades en proyectos de software aparecen porque se salta demasiado rápido desde una queja o una idea inicial hacia una solución técnica. Por ejemplo, alguien dice "necesitamos una aplicación móvil", pero tal vez el problema real sea que los vendedores no pueden consultar precios fuera de la oficina.
Comprender estas diferencias permite hacer mejores preguntas, evitar soluciones prematuras y construir requerimientos que tengan sentido para el negocio y para los usuarios.
Los conceptos se pueden ordenar como una cadena de razonamiento:
El problema o la necesidad explica por qué se quiere cambiar algo. El objetivo expresa qué resultado se desea lograr. Los requerimientos describen qué debe cumplir el sistema para contribuir a ese objetivo. La solución define cómo se implementará todo eso.
Si se confunden estos niveles, el equipo puede terminar construyendo una solución sin haber comprendido el propósito real.
Un problema es una situación actual que genera dificultad, costo, riesgo, demora, error o insatisfacción. Describe algo que no funciona como debería o que impide alcanzar un resultado deseado.
Ejemplos de problemas:
Un problema bien descrito ayuda a justificar el proyecto. También permite evaluar si la solución propuesta realmente ataca la causa principal o solo trata un síntoma.
Una necesidad expresa algo que una persona, área u organización requiere para trabajar mejor, resolver un problema o alcanzar un objetivo. Puede surgir de una dificultad actual, una oportunidad de mejora, una obligación legal o un cambio en el negocio.
La necesidad suele expresarse en lenguaje del negocio, no en lenguaje técnico. Por ejemplo:
Una necesidad todavía no indica exactamente qué debe hacer el sistema, pero orienta la búsqueda de requerimientos.
Problema y necesidad están muy relacionados. El problema describe una situación no deseada; la necesidad expresa lo que se requiere para mejorarla o resolverla.
| Problema | Necesidad asociada |
|---|---|
| Los pedidos se demoran porque se registran en planillas separadas. | Centralizar el registro y seguimiento de pedidos. |
| Los clientes llaman para preguntar el estado de sus reclamos. | Permitir que los clientes consulten el estado del reclamo por cuenta propia. |
| Los supervisores no detectan tareas atrasadas hasta el final del día. | Contar con información actualizada sobre tareas pendientes y vencidas. |
| Los cálculos manuales de comisiones generan errores. | Automatizar el cálculo de comisiones según reglas aprobadas. |
Esta relación permite pasar de la queja inicial a una necesidad más clara y accionable.
Un objetivo describe el resultado que se quiere alcanzar. Mientras una necesidad indica algo requerido, el objetivo expresa hacia dónde se quiere llegar y, cuando es posible, cómo se medirá el éxito.
Ejemplos de objetivos:
Los objetivos ayudan a priorizar requerimientos. Si un requerimiento no contribuye a ningún objetivo, conviene revisar si realmente es necesario.
Siempre que sea posible, los objetivos deben expresarse de manera medible. Esto permite evaluar si el proyecto produjo el resultado esperado y no solo si se entregó una lista de funciones.
| Objetivo débil | Problema | Objetivo más claro |
|---|---|---|
| Mejorar la atención al cliente. | No indica qué significa mejorar. | Reducir el tiempo promedio de primera respuesta de 24 horas a 4 horas. |
| Hacer más eficiente la carga de datos. | No indica qué proceso se mide. | Reducir el tiempo de carga de una solicitud completa de 15 minutos a 5 minutos. |
| Tener mejor control de stock. | No indica qué control falta ni cómo se evaluará. | Actualizar el stock disponible en menos de 1 minuto después de cada venta confirmada. |
Un requerimiento describe una condición, capacidad, característica o restricción que el sistema debe cumplir. Surge a partir de problemas, necesidades y objetivos, pero tiene un nivel de precisión mayor.
Ejemplos de requerimientos derivados de objetivos:
Un requerimiento debe orientar la construcción y permitir alguna forma de verificación.
El objetivo indica el resultado que se quiere lograr. El requerimiento indica qué debe cumplir el sistema para contribuir a ese resultado.
| Objetivo | Requerimientos posibles |
|---|---|
| Reducir llamadas telefónicas sobre estado de reclamos. | Permitir consultar el estado del reclamo en línea. Enviar notificaciones por correo cuando cambie el estado. Mostrar historial de acciones realizadas. |
| Evitar ventas de productos sin stock. | Validar stock antes de confirmar la venta. Reservar unidades durante el proceso de compra. Actualizar stock al confirmar o cancelar una operación. |
| Disminuir errores en liquidación de comisiones. | Registrar reglas de comisión por categoría. Calcular comisiones automáticamente. Generar reporte de liquidación para revisión. |
Un mismo objetivo puede requerir varias funciones y restricciones. También puede necesitar cambios organizativos que no dependen solamente del software.
Un error habitual es comenzar por la solución. Por ejemplo: "queremos un tablero con gráficos", "necesitamos una aplicación móvil" o "hay que agregar un botón". Estas frases pueden ser útiles como ideas, pero no deben reemplazar el análisis del problema.
Antes de aceptar una solución propuesta conviene preguntar:
Veamos cómo una frase inicial puede transformarse en información más útil.
| Nivel | Ejemplo |
|---|---|
| Frase inicial | Necesitamos una app para los vendedores. |
| Problema | Los vendedores no conocen el precio y stock actualizado cuando visitan clientes. |
| Necesidad | Permitir que los vendedores consulten información comercial actualizada fuera de la oficina. |
| Objetivo | Reducir en un 40% las ventas demoradas por falta de información de stock o precios. |
| Requerimiento | El sistema debe permitir consultar productos por código, nombre o categoría, mostrando precio vigente y stock disponible. |
| Solución posible | Aplicación móvil o sitio web adaptable para uso desde celulares. |
Este ejemplo muestra que la frase inicial no debe tomarse como requerimiento final. Debe analizarse para comprender qué se necesita realmente.
Durante la elicitación y el análisis, las preguntas correctas ayudan a separar problemas, necesidades, objetivos y requerimientos.
Estas preguntas evitan que el equipo documente requerimientos superficiales sin comprender el contexto.
Al trabajar con estos conceptos, suelen aparecer errores como los siguientes:
Estos errores reducen la calidad de los requerimientos y pueden llevar a construir funcionalidades poco útiles.
Una empresa de mantenimiento recibe esta solicitud: "queremos un sistema para que los técnicos carguen fotos". Antes de convertirla en requerimiento, el analista investiga el contexto.
Después de conversar con supervisores y técnicos, descubre lo siguiente:
La solicitud inicial era útil, pero recién el análisis permitió comprender su propósito y formular requerimientos más completos.
Distinguir necesidades, problemas, objetivos y requerimientos permite comprender mejor el sentido de un proyecto de software. Esta separación ayuda a formular mejores preguntas, evitar malentendidos y construir requerimientos que realmente aporten valor.
Un buen analista no se limita a tomar pedidos literalmente. Busca entender qué ocurre, por qué importa, qué resultado se quiere lograr y qué debe cumplir el sistema para contribuir a ese resultado.
En el próximo tema estudiaremos a los interesados del sistema: usuarios, clientes, patrocinadores y equipo técnico, porque los requerimientos dependen de las personas y organizaciones afectadas por la solución.