As architects and developers, we love talking about technologies.
Microservices. Kubernetes. Event Streaming. AI Agents. MCP. RAG. Vector Databases.
But before we draw architecture diagrams, choose cloud services, or discuss design patterns, there is one question we should answer:
What problem are we actually trying to solve?
Over the years, I have noticed that many projects struggle not because of poor technology choices, but because the requirements were not fully understood.
Some teams focus only on features.
Others focus only on scalability.
The successful ones understand both.
This is where Functional Requirements and Non-Functional Requirements come into the picture.
Although these concepts have been around for decades, they have become even more important in today’s AI-driven world.
Every System Starts with Requirements
Imagine someone approaches an architect and says:
“I want to build a house.”
The first question would not be:
“Should we use concrete or steel?”
Instead, the architect would ask:
“What kind of house do you want?”
The answers may include:
- Three bedrooms
- Two bathrooms
- A kitchen
- A garage
These define what the house should have.
Similarly, when building software, we first need to understand what capabilities the system must provide.
These are called Functional Requirements.
But the discussion doesn’t stop there.
The homeowner may also say:
“The house should withstand earthquakes, remain cool during summers, and provide strong security.”
Now we are talking about quality attributes.
In software, these become Non-Functional Requirements.
Together, these two categories shape the architecture of the system.
Functional Requirements Define What the System Does
Functional Requirements describe the features and capabilities of a system.
Simply put, they answer the question:
“What should the system do?”
For an e-commerce application, some functional requirements might be:
- Users can register and log in.
- Users can search for products.
- Users can place orders.
- Users can make payments.
- Users can track deliveries.
For a banking application:
- Customers can transfer money.
- Customers can view account statements.
- Customers can pay bills.
And for an AI-powered assistant:
- Users can ask questions.
- The system can search enterprise knowledge.
- The assistant can generate responses.
- Users can ask follow-up questions.
These requirements define the business functionality that users can see and interact with.
Without them, there is no product.
Non-Functional Requirements Define How Well the System Works
While Functional Requirements define capabilities, Non-Functional Requirements define the quality of those capabilities.
They answer the question:
“How well should the system perform?”
Let’s take a simple requirement:
“Users can search for products.”
Sounds straightforward.
Now consider these additional expectations:
- Search results should appear within 2 seconds.
- The platform should support 1 million concurrent users.
- The service should be available 99.99% of the time.
- Customer data must remain secure.
Suddenly, the architecture changes.
The feature remains the same.
The design becomes completely different.
This is why experienced architects spend significant time understanding Non-Functional Requirements before discussing technologies.
Why Architects Pay Special Attention to NFRs
One lesson I learned early in my architecture journey is this:
Features rarely drive architecture. Quality attributes do.
Let’s say a business asks for a file upload feature.
At first glance, it sounds simple.
But what happens when they add the following details?
- Files can be up to 50 GB.
- Millions of files may be uploaded every day.
- Users are spread across multiple regions.
- Processing must begin immediately after upload.
Now we need to think about:
- Object Storage
- Event Streaming
- Message Queues
- Auto Scaling
- CDN Integration
- Distributed Processing
The functionality has not changed.
The architecture has.
And the reason is Non-Functional Requirements.
The AI Era Has Changed the Conversation
In traditional applications, Functional Requirements usually dominate early discussions.
In AI systems, the situation is often reversed.
Consider this requirement:
“Build an AI assistant that can answer employee questions.”
That sounds like a single Functional Requirement.
However, the real complexity lies elsewhere.
Questions quickly emerge:
- How accurate should the responses be?
- How fast should answers be generated?
- Can the system explain its reasoning?
- How do we prevent hallucinations?
- How do we secure sensitive information?
- What will be the operational cost?
These are not Functional Requirements.
They are Non-Functional Requirements.
Yet they often determine whether the AI solution succeeds or fails.
A Real-World AI Example
Let’s assume we are designing an enterprise knowledge assistant using RAG and Large Language Models.
The Functional Requirements might be straightforward:
- Employees can ask questions.
- The system can search company documents.
- The assistant can generate answers.
- The assistant can cite sources.
Most architects can design a high-level solution within minutes.
The challenge begins when the Non-Functional Requirements arrive.
The business may expect:
- Responses within 3 seconds.
- Accurate and trustworthy answers.
- Protection of confidential documents.
- Support for thousands of simultaneous users.
- Full auditability of AI interactions.
- Controlled operational costs.
Now the architecture becomes significantly more interesting.
We start discussing:
- Vector databases
- Caching strategies
- Prompt optimization
- Access controls
- Model selection
- Observability platforms
- Cost monitoring
The architecture is no longer being driven by functionality.
It is being driven by quality attributes.
New Non-Functional Requirements Introduced by AI
Traditional applications typically focus on performance, reliability, scalability, and security.
AI systems introduce entirely new dimensions.
Accuracy
An answer that sounds convincing but is incorrect can be more dangerous than no answer at all.
Explainability
Users increasingly want to know where the answer came from.
Source citations and traceability are becoming essential.
Hallucination Control
AI systems should minimize fabricated information.
This requirement often influences decisions around RAG, grounding, and model selection.
Governance
Organizations need visibility into prompts, models, responses, and usage patterns.
Cost Efficiency
Unlike traditional APIs, every interaction with an LLM has a measurable cost.
Architects must design with token consumption in mind.
Responsible AI
Systems must be designed to minimize bias, harmful outputs, and misuse.
These are becoming critical architecture considerations for modern AI platforms.
The Biggest Mistake Teams Make
One of the most common mistakes I see is treating Non-Functional Requirements as something that can be addressed later.
The reality is quite different.
Security cannot be bolted on later.
Scalability cannot be magically added later.
Observability cannot be retrofitted easily.
And in AI systems, accuracy and governance cannot be afterthoughts.
These considerations must be part of the design from day one.
The earlier they are identified, the better the resulting architecture will be.
A Simple Rule I Follow
Whenever I start designing a system, I ask two simple questions.
What should the system do?
These answers become Functional Requirements.
How well should it do it?
These answers become Non-Functional Requirements.
Surprisingly, the second question often drives more architectural decisions than the first.
The next time you begin designing a system, don’t start with the technology stack.
Start with the requirements.
FactorBytes 
Leave a comment