Cómo Escribir Requisitos de Software Sin Ser Técnico

Introducción

Un proyecto de siete años y quinientos millones de euros fue cancelado no porque el software fuera malo, sino porque nadie logró explicar con claridad qué debía hacer. Eso fue lo que le pasó a Lidl, una de las cadenas de supermercados más grandes del mundo. El proyecto se construyó sobre SAP, un sistema que miles de otras empresas usan sin este tipo de problema. El error no estaba en la tecnología. Estaba en cómo el negocio explicó lo que necesitaba construir. Ese mismo error se repite, a menor escala, cada vez que un gestor sin formación técnica intenta describir un sistema, una aplicación o una funcionalidad a un equipo de desarrollo. Este artículo enseña cómo escribir requisitos de software con un método de cinco preguntas que no exige ni una línea de código.

Por qué los requisitos mal escritos cuestan tan caro: el caso Lidl

Un estudio de BCG entrevistó a ejecutivos de veinticinco sectores distintos para entender por qué los proyectos de tecnología se atrasan y exceden el presupuesto. BCG es una consultora global de estrategia. La respuesta no fue falta de buena tecnología. Fue falta de alineación entre quien pide el sistema y quien lo construye. Cuando el objetivo de negocio no queda claro desde el inicio, el equipo técnico llena los vacíos como puede: con suposiciones. Y suposición en un proyecto de software tiene otro nombre, que todo gestor ya sintió en carne propia: retrabajo.

Eso es exactamente lo que le pasó a Lidl. Cada equipo interno interpretó los requisitos a su manera, porque las reglas de negocio nunca se documentaron de forma unificada. Sin esa alineación, el proyecto fue acumulando personalizaciones sobre personalizaciones hasta que nadie pudo seguir controlando qué debía hacer el sistema. Siete años después, la solución fue cancelar el proyecto por completo.

La buena noticia para quien lee este artículo es que la mayoría de los gestores no necesita aprender a programar para evitar ese escenario. Necesita aprender a describir lo que quiere con suficiente claridad para que el equipo técnico no tenga que adivinar. Ese es el núcleo de cualquier buen levantamiento de requisitos de software, y es una habilidad que se desarrolla con práctica, no con un curso de programación.

El error más común: describir la solución en vez del problema

El error más común que aparece cuando un cliente llega con una necesidad de software es este: describir la solución que imaginó, en vez del problema que necesita resolver. Es uno de los errores comunes al escribir requisitos que sale más caro, porque el pedido parece claro cuando en realidad esconde preguntas sin respuesta.

El ejemplo clásico es el pedido: "necesito un botón que genere un reporte en PDF." Parece objetivo, pero no lo es. ¿Cuál reporte? ¿Con qué datos? ¿Para quién? ¿Con qué frecuencia? ¿Qué hace esa persona con el PDF después de generarlo? Sin esas respuestas, el equipo técnico solo tiene dos opciones: preguntar todo de nuevo o construir exactamente lo que se pidió, aunque no resuelva el problema real.

Tal vez la respuesta correcta para ese pedido ni siquiera sea un botón que genera un PDF. Tal vez sea un panel que muestra la información en tiempo real, sin necesidad de generar nada. Eso solo aparece cuando alguien pregunta cuál es el problema detrás del pedido, en vez de aceptar de inmediato la solución que el cliente ya trajo lista en la cabeza. Describir el problema es lo que abre espacio para que el equipo técnico encuentre el mejor camino, y casi nunca ese camino es el primero que se le ocurrió a quien pidió.

Cuando describes la solución que imaginaste, limitas las opciones del equipo técnico. Cuando describes el problema, abres espacio para que aparezca la mejor solución.

Cómo escribir requisitos de software: las cinco preguntas que ordenan cualquier requisito

Existe un método simple para no caer en ese error, y en la práctica es una guía de requisitos de software para gestores no técnicos que funciona antes de cualquier reunión de alcance. Cada vez que necesites describir una funcionalidad, un sistema o una aplicación para un equipo de desarrollo, puedes recorrer las cinco preguntas de abajo. Las respuestas no tienen que ser perfectas. Tienen que ser honestas, y eso es lo que transforma un pedido vago en un briefing de proyecto de software que cualquier equipo puede ejecutar sin adivinar nada.

• 1¿Qué problema estoy tratando de resolver? No es lo que el sistema debe hacer, es qué dolor existe hoy. "Mi equipo pasa cuatro horas al día consolidando datos de ventas en planillas manuales" es un problema claro que cualquier equipo técnico puede atacar.
• 2¿Quién va a usar esto en el día a día? Un gerente de operaciones tiene necesidades distintas a las de un analista financiero. Describe qué hace hoy esa persona, paso a paso, para resolver el problema sin el sistema: eso cambia por completo cómo debe diseñarse la solución.
• 3¿Qué existe hoy? Qué sistema, planilla o proceso manual está en uso actualmente. Un proyecto de software casi nunca parte de cero, y mapear esto desde el inicio evita la sorpresa de una integración que nadie previó.
• 4¿Cómo voy a saber si funcionó? "El sistema tiene que ser rápido" no es un criterio de éxito. "El reporte tiene que generarse en menos de tres segundos" sí lo es. Definir qué significa terminado antes de empezar evita el ciclo infinito de ajustes donde nadie queda satisfecho.
• 5¿Qué no puede pasar bajo ningún concepto? A veces es más fácil definir los límites que el destino. "El sistema no puede aprobar un pedido sin la firma del gestor" protege una regla de negocio que no puede romperse, y restricciones así son tan importantes como cualquier funcionalidad nueva.

Cómo aplicar el método en la práctica: el caso de una red de clínicas

Hace algunos meses, el director de operaciones de una red de clínicas llegó pidiendo "una aplicación para los pacientes", en sus propias palabras. Al aplicar las cinco preguntas en esa primera reunión, el alcance del proyecto cambió por completo de forma.

El problema real no era la falta de una aplicación: era que los pacientes llamaban a la clínica para confirmar citas, reprogramar horarios y pedir el resultado de un examen, y la recepción no daba abasto con el volumen. El usuario real tampoco era solo el paciente. Era la recepcionista, que necesitaba un panel para gestionar todo eso en un solo lugar. Además, el sistema tenía que integrarse con la historia clínica electrónica que la clínica ya usaba, porque crear un registro paralelo de pacientes generaría más problemas que soluciones.

El criterio de éxito definido fue reducir en al menos cuarenta por ciento las llamadas recibidas por recepción. La restricción innegociable fue que ningún dato de paciente podía quedar almacenado fuera de los servidores de la propia clínica. Esa restricción salió directamente de la pregunta sobre qué no podía pasar bajo ningún concepto.

Con esas respuestas en mano, el alcance quedó claro antes de escribir una sola línea de código, y eso es lo que permite definir el alcance de un proyecto de software con previsibilidad. El proyecto se entregó dentro del plazo y la clínica alcanzó la meta de reducción de llamadas ya en el segundo mes de operación, sin que el equipo de desarrollo tuviera que adivinar nada en el camino.

Requisito de negocio vs. requisito técnico: cuál es la diferencia

Las respuestas a las cinco preguntas forman lo que se llama requisito de negocio: el problema y el contexto que el gestor describe, sin necesidad de ningún vocabulario técnico. Es el material que cualquier director de operaciones, product owner o founder puede producir solo, en una reunión o en un documento simple.

A partir de ahí entra el trabajo del equipo técnico: traducir ese requisito de negocio en requisito funcional y no funcional. El requisito funcional describe lo que el sistema debe hacer. El requisito no funcional describe cómo el sistema debe comportarse mientras lo hace, como el tiempo de respuesta, el nivel de seguridad de los datos o la disponibilidad del servicio.

Entender esta diferencia evita una trampa común: gestores tratando de escribir requisito funcional y no funcional sin tener el vocabulario técnico para hacerlo, y terminando con un documento confuso que mezcla ambos. El papel de quien no es técnico es entregar un buen requisito de negocio. Traducir eso a términos de ingeniería es trabajo del equipo de desarrollo, no del gestor que abrió el proyecto.

Cómo transformar las respuestas en un documento que el equipo técnico entiende

Después de responder las cinco preguntas para cada funcionalidad, el siguiente paso es organizar esas respuestas en un documento de requisitos de software que no dependa de que alguien tenga que explicarlo todo de nuevo en una llamada. El error más común aquí es mezclar todo en un único texto, donde resulta difícil saber qué respuesta pertenece a qué funcionalidad.

1. 1Separa por funcionalidadTrata cada funcionalidad, pantalla o flujo como un bloque independiente, con sus propias cinco respuestas, en vez de describir el sistema entero de una sola vez.
2. 2Estructura cada bloque en el mismo ordenProblema, usuario, contexto actual, criterio de éxito y restricción, siempre en esa secuencia, para que el equipo técnico sepa dónde buscar cada información.
3. 3Usa lenguaje simpleEscribe con los mismos términos que usarías en una conversación, sin forzar un vocabulario técnico que ni el propio gestor domina. Un ejemplo concreto vale más que una definición abstracta.
4. 4Comparte el documento antes de la reunión de alcanceEnvía el documento al equipo técnico con anticipación. Las preguntas de seguimiento llegan más enfocadas cuando todos ya leyeron el mismo material.

Este mapeo de requisitos, de hecho, es exactamente el punto de partida de la metodología de Agence, que organiza cada proyecto desde el levantamiento de requisitos hasta la entrega continua, en vez de tratar esta etapa como un documento burocrático más al inicio del proyecto.

Cuándo vale la pena llamar a una consultoría para el levantamiento de requisitos

No todo levantamiento de requisitos necesita ayuda externa, pero algunas señales indican que vale la pena buscar apoyo especializado antes de abrir el proyecto. Los proyectos que implican integración con varios sistemas existentes suelen esconder reglas de negocio que solo aparecen cuando alguien con experiencia pregunta en los lugares correctos. Esto es común en integraciones con ERP o historia clínica electrónica, por ejemplo. Los equipos que nunca condujeron un levantamiento de requisitos estructurado también se benefician de un método ya validado, en vez de aprender por prueba y error en medio de un proyecto real, especialmente en proyectos de desarrollo web que necesitan conectarse a sistemas legados sin repetir los errores del pasado.

Un historial reciente de retrabajo es otra señal clara de que vale la pena buscar apoyo para evitar el retrabajo en proyectos de TI. Lo mismo aplica a proyectos anteriores que se pasaron de plazo por falta de alineación inicial. Los plazos y presupuestos ajustados pesan todavía más en esos casos, porque el costo de un requisito mal escrito solo aparece después de que el desarrollo ya comenzó. Cuando falta gente disponible para conducir ese levantamiento internamente, un equipo de outsourcing de TI puede asumir el mapeo de requisitos junto con el resto del desarrollo, sea en proyectos web o de aplicaciones.

Preguntas frecuentes sobre requisitos de software

Empieza el proyecto con el alcance claro, antes de la primera reunión técnica

El método de las cinco preguntas es el mismo mapeo de requisitos que Agence usa como primera etapa en proyectos de desarrollo web, aplicaciones y outsourcing de TI. Si estás planeando un sistema, una aplicación o una nueva funcionalidad, habla con nuestros especialistas antes de abrir el proyecto.

Hablar con un especialista