Functional and Non-Functional Requirements: The Hidden Complexity
Tuesday May 13, 2025
Something extremely important in a project, and that has been very present in my day-to-day life in recent weeks, are the "famous" "functional and non-functional requirements." They are so important that if they are not clearly defined or given the appropriate priority, they can even lead to significant technical debt.
After overcoming the initial obstacles with machine space that we saw in the first chapter, and managing to create a landing page with a design that I liked and that aligned with what I'm looking for in the project, I now delved into the next phase: implementing the blog system, another task that at first glance seemed relatively simple. All of this, clearly, in addition to all the activities that my daily life entails.
From Simple to Complex
What initially seemed like a very simple project—creating a blog to publish articles—quickly turned into a series of technical decisions and non-functional requirements that, ironically, are fundamental for the proper functioning of the system.
The functional requirement was simple: a blog where I could publish articles. However, the non-functional requirements began to multiply:
- Security: Implementation of SSL certificates to ensure secure connections
- Authentication: A system so that only authorized users (me) can publish content
- Database: Decisions about using local SQLite or a more robust database
- Multilanguage: Ability to publish content in different languages
- Notifications: System to alert about newly published articles
- Storage: Configuration of Active Storage to handle images and files
- Text editor: Implementation of a rich editor to create content
- And a long list of others...
The Value of Experience
The experience accumulated over the years greatly facilitates this process. Knowing the available tools and their features allowed me to make informed decisions quickly:
- I opted for simple and minimalist CSS instead of more complex frameworks
- I experimented with new technologies like PicoCSS, which turned out to be a good choice
- I configured messaging services for notifications
- Rails 8 helped me implement many non-functional requirements practically "on the fly"
With ImportMaps, I was able to manage JavaScript resources without needing a complex bundler, while Hotwire allowed me to create dynamic interfaces without writing a lot of custom JavaScript. The combination of these modern technologies with Ruby on Rails 8 proved to be extremely productive.
The Paradox of the "Non-Functional"
It's curious how the so-called "non-functional requirements" turn out to be essential for the main functionality to operate correctly. These aspects go far beyond the code and have to do with providing a professional, stable, and pleasant experience to the user.
The problem lies in the fact that dozens of non-functional requirements can arise from a single functional requirement, especially if we don't know how to clarify and define them in an abstract and precise manner from the beginning.
Conclusion: Developing Ecosystems, Not Just Code
Thus, this second chapter of my project reminded me that software development is not just about coding the central idea and functionality, but about building the entire infrastructure, a complete ecosystem, as a necessary environment for that functionality to operate optimally, professionally, and efficiently in a real environment in line with the 21st century.
The next time someone tells me "it's just a simple blog," I'll smile knowing the complexity that hides behind that apparent simplicity.