Requerimientos Funcionales y No Funcionales: La Complejidad Oculta
martes 13 de mayo del 2025
Algo sumamente importante en un proyecto, y que en las últimas semanas han estado super presentes en mi día a día, son los "famosos" requerimientos "funcionales y no funcionales". Son tan importantes que, si no quedan claros ni se les da la prioridad adecuada, pueden concurrir hasta en generar deuda técnica significativa.
Después de superar los primeros obstáculos con el espacio en la máquina que vimos en el primer capítulo, y lograr tener una landing con un diseño que me agradara y que fuera acorde a lo que busco en el proyecto, ahora me adentré en la siguiente fase: la implementación del sistema de blogs, otra tarea que de primera vista parecía relativamente simple. Todo esto, claramente, sumado a todas las actividades que mi día a día conlleva.
De lo simple a lo complejo
Lo que inicialmente parecía un proyecto muy sencillo —crear un blog para publicar artículos— rápidamente se convirtió en una serie de decisiones técnicas y requerimientos no funcionales que, irónicamente, son fundamentales para el funcionamiento adecuado del sistema.
El requerimiento funcional era simple: un blog donde publicar artículos. Sin embargo, los requerimientos no funcionales comenzaron a multiplicarse:
- Seguridad: Implementación de certificados SSL para garantizar conexiones seguras
- Autenticación: Un sistema para que solo usuarios autorizados (yo) puedan publicar contenido
- Base de datos: Decisiones sobre utilizar SQLite local o una base de datos más robusta
- Multilenguaje: Capacidad para publicar contenido en diferentes idiomas
- Notificaciones: Sistema para alertar sobre nuevos artículos publicados
- Almacenamiento: Configuración de Active Storage para manejar imágenes y archivos
- Editor de texto: Implementación de un editor enriquecido para crear contenido
- Y un largo etcétera...
El valor de la experiencia
La experiencia acumulada a lo largo de los años facilita enormemente este proceso. Conocer las herramientas disponibles y sus características me permitió tomar decisiones informadas rápidamente:
- Opté por CSS simple y minimalista (PicoCSS) en lugar de frameworks más complejos (Tailwind, Bootstrapt,...)
- Experimenté con nuevas tecnologías como PicoCSS, que resultó ser una elección acertada
- Configuré servicios de mensajería para notificaciones
- Rails 8 me ayudó bastante en implementar muchos requerimientos no funcionales prácticamente "de volada"
Con ImportMaps pude gestionar los recursos JavaScript sin necesidad de un bundler complejo, mientras que Hotwire me permitió crear interfaces dinámicas sin escribir mucho JavaScript personalizado. La combinación de estas tecnologías modernas con Ruby on Rails 8 resultó ser extremadamente productiva.
La paradoja de lo "no funcional"
Es curioso cómo los llamados "requerimientos no funcionales" resultan imprescindibles para que la funcionalidad principal opere correctamente. Estos aspectos van mucho más allá del código y tienen que ver con proporcionar una experiencia profesional, estable y agradable al usuario.
El problema radica en que de un requerimiento funcional pueden nacer decenas de no funcionales, sobre todo si no sabemos cómo clarificarlos y definirlos de manera abstracta y precisa desde el inicio.
Conclusión: Desarrollando ecosistemas, no solo código
Así, este segundo capítulo de mi proyecto me recordó que el desarrollo de software no se trata solo de codificar la idea y funcionalidad central, sino de construir toda la infraestructura, un ecosistema completo, como un entorno necesario para que esa funcionalidad opere de manera óptima, profesional y eficiente en un entorno real acorde al siglo XXI.
La próxima vez que alguien me diga "solo es un simple blog", sonreiré sabiendo la complejidad que se esconde detrás de esa aparente simplicidad.