Requisitos funcionales y no funcionales: la guía del founder que paga la cuenta

Lunes al mediodía. Un founder abrió las inscripciones de un curso con 900 personas en lista de espera. La home cargó; el checkout, no. Vio la conversión de su lanzamiento evaporarse durante cuarenta minutos.

El estudio respondió lo que era técnicamente correcto y comercialmente devastador: “eso no estaba en el alcance”. Y no lo estaba. El documento que él había aprobado describía muy bien lo que el sistema hacía. No decía cuántas personas podían hacerlo al mismo tiempo.

Los requisitos funcionales dicen qué hace el software. Los requisitos no funcionales dicen cómo se comporta mientras lo hace: con qué velocidad, para cuántos usuarios simultáneos, con qué disponibilidad, bajo qué reglas de seguridad. La diferencia entre requisitos funcionales y no funcionales es la diferencia entre un sistema que pasa la prueba y un sistema que sobrevive al lanzamiento.

Todos los founders escriben los funcionales. Casi ninguno escribe los no funcionales. Y son los no funcionales los que deciden el precio del desarrollo, el comportamiento el día del lanzamiento y el tamaño de tu pérdida cuando algo se rompe.

Qué son los requisitos funcionales y no funcionales

Un requisito funcional es algo que el sistema tiene que hacer. Tiene sujeto, verbo y objeto. “El cliente descarga una copia de la factura.” O lo hace, o no lo hace. Es binario, y por eso es fácil de escribir, fácil de probar y fácil de exigir.

Un requisito no funcional es una cualidad que el sistema tiene que tener mientras hace eso. No es una función nueva; es una restricción sobre todas las funciones. “La copia de la factura aparece en menos de 2 segundos, para hasta 300 personas a la vez, el 99,5% del mes.” No es binario. Es un rango, un límite, un número.

La literatura académica llama a los no funcionales “atributos de calidad”, y existe una norma internacional que los organiza: la ISO/IEC 25010, que define las características de calidad de un software (rendimiento, seguridad, fiabilidad, mantenibilidad y otras). No hace falta que memorices la norma. Hace falta que sepas que existe, porque de ahí sale la lista de preguntas que nadie te hizo.

La confusión más común es creer que “no funcional” significa “opcional”, o “cosa técnica que resuelve el dev”. Es al revés. Lo funcional es la parte que el dev resuelve solo, porque tú ya se lo explicaste. Lo no funcional es la parte que va a decidir por ti, en silencio, si tú no dices nada.

Tres ejemplos de requisitos funcionales (la parte fácil)

Tomemos un sistema de agenda para una red de clínicas:

1. “El paciente elige un horario disponible en la agenda del profesional y confirma la cita.” Lo hace o no lo hace.
2. “El sistema envía un recordatorio por WhatsApp 24 horas antes de la cita.” Lo hace o no lo hace.
3. “La recepcionista reprograma una cita y el horario anterior vuelve a quedar disponible.” Lo hace o no lo hace.

Esto es lo que cualquier founder puede escribir en un café, y es lo que contiene casi cualquier documento de requisitos. Está bien. Es necesario. Y es insuficiente, porque ninguna de esas tres frases dice qué pasa cuando 40 recepcionistas de 12 sedes usan el sistema a las 8 de la mañana de un lunes, que es exactamente cuando tiene que funcionar.

Requisitos no funcionales: las siete preguntas que nadie te hace

Aquí está la lista que sustituye a la norma. Siete preguntas. Si tu documento no las responde con números, no tienes requisitos no funcionales; tienes esperanza.

1. Rendimiento. ¿Con qué velocidad?
No “rápido”. Cuántos milisegundos, en qué pantalla, en el peor caso. La búsqueda de pacientes responde en menos de 500ms. El informe mensual puede tardar 30 segundos, y está bien, siempre que avise al usuario de que está trabajando.

2. Carga. ¿Para cuántos a la vez?
El número que faltaba en el lanzamiento del curso. ¿Cuántos usuarios simultáneos en el pico? ¿Y cuál es el pico: el día de la nómina, la apertura de inscripciones, el Black Friday? Los sistemas no se caen en la media. Se caen en el pico.

3. Disponibilidad. ¿Cuánto tiempo fuera de servicio es tolerable?
Un 99% de uptime suena estupendo hasta que haces la cuenta: son más de 7 horas de caída al mes. El 99,9% son 43 minutos. La diferencia entre esos dos números es una decisión de arquitectura y de presupuesto, y es tuya, no del dev. El SRE Book de Google es la referencia de cómo se define esto sin adivinar.

4. Seguridad y privacidad. ¿Quién puede ver qué?
Si manejas datos de salud, financieros o cualquier dato personal, cumplir el RGPD no es un requisito opcional; es una obligación legal con multa. ¿Quién accede al historial? ¿El dato está cifrado en reposo? ¿Hay registro de quién vio qué? Eso es requisito no funcional, y nadie lo va a escribir por ti.

5. Usabilidad y accesibilidad. ¿Usable por quién?
“La recepcionista completa una cita en menos de 4 clics.” “La app funciona en Android 9, porque la mitad de nuestra base está en un móvil viejo.” Un requisito de usabilidad con número es un requisito. Sin número, es decoración.

6. Mantenibilidad. ¿Quién puede tocar esto después?
El requisito que más dinero ahorra en el año 2 y que casi nadie escribe. ¿Otro equipo puede hacerse cargo de ese código? ¿Hay pruebas automatizadas? ¿Hay documentación? O estás comprando un activo, o estás comprando un rehén.

7. Recuperación. ¿Y cuando salga mal?
¿Copias de seguridad cada cuánto? ¿Cuánto se tarda en restaurar? ¿Aceptas perder las últimas 24 horas de datos, o los últimos 5 minutos? Esas dos respuestas cuestan precios muy distintos, y lo único peor que elegir la cara es no elegir y descubrir cuál compraste el día del desastre.

El requisito en blanco no está vacío. Tiene un valor por defecto.

Esta es la frase que vale el artículo entero.

Cuando no especificas cuántos usuarios simultáneos aguanta el sistema, el desarrollador no deja ese campo vacío. Lo rellena. Y lo rellena con el valor que es más rápido de construir y más barato de operar, porque eso fue lo que pediste cuando pediste “lo más rápido y barato posible”. Va a levantar una instancia pequeña, una base de datos sin réplica, sin cola, sin caché. Y va a tener razón, porque tú no pediste otra cosa.

Lo mismo vale para los otros seis. Sin requisito de disponibilidad, compraste “lo que salga”. Sin requisito de copia de seguridad, compraste “probablemente hay una”. Sin requisito de mantenibilidad, compraste un código que entiende exactamente una persona en el mundo, y esa persona no trabaja para ti.

Nada de esto es mala fe del estudio. Es la consecuencia mecánica de un contrato que solo describe funciones. El proveedor entrega lo que está escrito, y lo que está escrito funciona: el checkout de nuestro founder funcionaba. Pasó todas las pruebas. Con un usuario.

Por eso la pregunta “¿cuánto cuesta una app?” casi nunca tiene respuesta honesta antes de esta conversación. El mismo conjunto de funcionalidades puede costar 80.000 € o 300.000 € dependiendo solo de los no funcionales, y ya escribimos sobre por qué el precio de una aplicación depende más de ti que del estudio.

La prueba del número

Si te llevas una sola cosa de este artículo, llévate esta:

Un requisito no funcional sin número no es un requisito. Es un deseo.

“El sistema debe ser rápido” es un deseo. “El sistema debe ser seguro” es un deseo. “El sistema debe ser escalable” es el más caro de todos los deseos, porque suena lo bastante técnico como para que todo el mundo lo firme sin entender qué compró.

Un requisito no funcional de verdad tiene tres partes: número, condición y consecuencia.

Fíjate en lo que hace la columna de la derecha: convierte una opinión en algo que puede ser medido, probado y exigido. Es la misma disciplina de los criterios de aceptación, aplicada a las cualidades del sistema en lugar de a sus funciones.

Y fíjate en la tercera parte, la consecuencia. “Muestra un aviso de espera en lugar de un error” es una decisión de producto que solo tú puedes tomar. El dev puede decirte cuánto cuesta. No puede decirte qué es aceptable para tu cliente.

Por qué los no funcionales deciden el precio

Un estudio serio te va a cobrar más caro cuando le entregues buenos requisitos no funcionales. Parece contraintuitivo y es la mejor señal que existe.

El motivo es simple: aguantar 800 checkouts simultáneos exige infraestructura, colas, caché y pruebas de carga. Eso es trabajo real, y el trabajo real tiene precio. Cuando el presupuesto sube después de que especificas la carga, lo que pasó no fue un aumento. Fue la revelación del precio verdadero, que antes estaba escondido detrás de una premisa que nadie había dicho en voz alta.

El presupuesto barato que recibiste antes de escribir los no funcionales no era más barato. Era el mismo producto con el riesgo transferido a ti.

Esa es, además, la mejor forma de comparar propuestas. Manda los siete números a tres estudios. Quien devuelva el mismo precio de antes no los leyó. Quien suba el precio y explique línea por línea dónde subió, ese lo quieres en la mesa.

Dónde el no funcional se convierte en obligación

Un número que vive en un Google Doc no protege a nadie. Tiene que atravesar tres documentos para convertirse en obligación:

En el levantamiento de requisitos, nace. Es donde descubres que hay un pico a las 8 de la mañana y que la mitad de la base usa un Android viejo. Ese trabajo es tuyo, y ya detallamos cómo escribir un documento de requisitos sin ser técnico.

En el criterio de aceptación, se convierte en prueba. “Prueba de carga con 800 sesiones simultáneas, ejecutada antes del go-live” es una línea que transforma una promesa en un evento verificable, con fecha.

En el contrato, se convierte en consecuencia. Un requisito no funcional que no aparece en el contrato de desarrollo de software es una conversación de pasillo. Si la disponibilidad contratada es del 99,5% y el sistema entrega un 97%, ¿qué pasa? Si la respuesta es “ya lo hablamos”, no tienes un requisito. Tienes un tema.

El founder del curso no perdió el lanzamiento por haber contratado gente mala. Lo perdió porque compró un sistema que hacía todo lo que pidió, y nunca pidió que funcionara para 900 personas a la vez. El documento estaba bien. Solo estaba a medias.

Preguntas frecuentes

¿Qué son los requisitos funcionales?
Son las funciones que el sistema tiene que ejecutar: lo que hace. “El usuario restablece su contraseña por email”, “el gestor exporta el informe en CSV”. Tienen respuesta binaria: el sistema lo hace o no lo hace. Son la parte del alcance que casi cualquier founder puede escribir solo.

¿Qué son los requisitos no funcionales?
Son las cualidades y restricciones que valen para todo el sistema: con qué velocidad, para cuántos usuarios simultáneos, con qué disponibilidad, con qué nivel de seguridad, con qué facilidad de mantenimiento, con qué plan de recuperación. No describen una función nueva; describen el comportamiento de todas ellas bajo presión. Son los requisitos que deciden el precio del desarrollo y el resultado del día del lanzamiento.

¿Cuál es la diferencia entre requisito funcional y no funcional?
El funcional es el qué; el no funcional es cómo de bien. “Emitir la factura” es funcional. “Emitir la factura en menos de 3 segundos, para 500 pedidos simultáneos, con un 99,5% de disponibilidad” añade los no funcionales. El funcional determina si el software sirve; el no funcional determina si aguanta.

¿Cuáles son 3 ejemplos de requisitos funcionales?
(1) “El paciente elige un horario disponible y confirma la cita.” (2) “El sistema envía un recordatorio por WhatsApp 24 horas antes de la cita.” (3) “La recepcionista reprograma una cita y el horario anterior vuelve a quedar disponible.” Todos describen una acción concreta del sistema, con respuesta binaria.

¿Cuáles son los tipos de requisitos no funcionales?
Los que importan a quien contrata un desarrollo son siete: rendimiento (con qué velocidad), carga (para cuántos a la vez), disponibilidad (cuánto downtime es tolerable), seguridad y privacidad (quién ve qué, y qué normativa aplica), usabilidad y accesibilidad (usable por quién, en qué dispositivo), mantenibilidad (quién puede hacerse cargo del código después) y recuperación (copias de seguridad y tiempo de restauración).

¿Quién escribe los requisitos no funcionales: yo o el estudio?
Los números son tuyos; la arquitectura es del estudio. Solo tú sabes que el pico es a las 8 de la mañana, que perder 24 horas de datos es inaceptable y que la mitad de tus usuarios está en un móvil viejo. Cómo entregar eso es problema de quien construye. El error clásico es externalizar la pregunta junto con la respuesta y descubrir, en el lanzamiento, qué valor por defecto compraste sin saberlo.