Cuando diseñas una aplicación móvil o web, lo primero que necesitas entender es qué cosas la hacen funcionar y qué cosas definen cómo se comporta. Ahí entran los requerimientos funcionales y no funcionales, dos categorías que describen desde las acciones del usuario hasta las características internas del sistema.

Esta distinción es clave para cualquier persona que esté empezando en desarrollo de software, arquitectura de aplicaciones o diseño de productos digitales, porque marca la diferencia entre lo que el usuario hace y lo que la aplicación garantiza por debajo.

¿Qué son los requerimientos en una aplicación?

Los requerimientos son las condiciones necesarias para que una aplicación funcione correctamente [0:05]. No se trata solo de pantallas o botones: también incluyen reglas internas, tiempos de respuesta y comportamientos automáticos que el usuario nunca ve.

Existen dos grandes tipos y conviene tenerlos claros desde el inicio del proyecto.

¿Cuáles son los dos tipos de requerimientos? Los funcionales, que describen cómo el usuario interactúa con la aplicación, y los no funcionales, que definen cómo se comporta internamente sin intervención directa del usuario.

¿Qué es un requerimiento funcional y cómo identificarlo?

Un requerimiento funcional describe una acción concreta que el usuario realiza dentro de la aplicación [0:20]. Si puedes imaginar a alguien tocando un botón, llenando un campo o eligiendo una opción, probablemente estás frente a uno.

Algunos ejemplos claros que aparecen en la clase:

• El usuario debe poder darle like a un post.
• El usuario puede ver diferentes tipos de servicio al pedir un conductor.
• El usuario puede cambiar su foto de perfil.

En los tres casos hay algo en común: el usuario decide, el usuario actúa. Esa es la pista para reconocerlos.

¿Qué es un requerimiento no funcional?

Un requerimiento no funcional define características de la aplicación que ocurren de forma automática y que el usuario no elige [1:25]. Son reglas internas, decisiones técnicas o comportamientos que afectan la experiencia sin que nadie las active manualmente.

Tres ejemplos que ilustran bien la idea:

• La aplicación debe mostrar información sin conexión.
• El sistema debe guardar los 100 primeros posts.
• El sistema debe guardar la información por tres días.

Este último caso conecta con un concepto importante: el manejo de caché y la estrategia offline first, donde la app guarda datos por un tiempo limitado para evitar mostrar información obsoleta.

¿Por qué guardar información por tres días es un requerimiento no funcional? Porque el usuario no decide ese tiempo. Es una regla del sistema pensada para mantener los datos frescos sin depender de la conexión.

¿Cómo clasificar requerimientos en una app real como Mercado Libre?

La mejor forma de entrenar el ojo es practicar con aplicaciones que ya usas. Tomemos cuatro casos de Mercado Libre y clasifiquémoslos [2:35].

1. El usuario debe poder hacer login: funcional, porque hay una acción directa del usuario.
2. El usuario debe navegar sin conexión: no funcional, porque es una característica del sistema, no una elección.
3. La velocidad para traer datos del servidor no debe exceder tres segundos: no funcional, porque el usuario no controla los tiempos de respuesta.
4. El usuario debe poder compartir un producto por redes sociales: funcional, porque es una acción que el usuario decide ejecutar.

La pregunta guía siempre es la misma: ¿el usuario lo elige o el sistema lo impone?

¿Qué habilidades desarrollas al separar requerimientos?

Clasificar requerimientos te entrena en varias competencias clave del desarrollo de software:

• Pensamiento de producto: distinguir entre lo que el usuario percibe y lo que el sistema garantiza.
• Diseño de arquitectura: anticipar restricciones técnicas como tiempos de respuesta o almacenamiento.
• Comunicación con equipos: traducir necesidades de negocio en especificaciones claras para desarrollo y QA.

Estas habilidades son la base para el siguiente paso natural: el diseño de alto nivel de una aplicación, donde estos requerimientos se convierten en decisiones de arquitectura concretas.

Ahora te toca a ti. Cuéntame en los comentarios tres requerimientos funcionales y tres no funcionales que identifiques en la aplicación de Platzi.