Functional and Non-Functional Requirements

🧠 Functional vs Non-Functional Requirements — Understanding the Heart and Health of a Software System

(GoProcure Case Study – #CodeTrip Series)

Before we dive into coding, architecture, or deployment, it’s important to understand what we’re really building — not just the features of a system, but also the qualities that make it efficient, reliable, and user-friendly.

These two dimensions are what we call:
👉 Functional Requirements (FRs) and
👉 Non-Functional Requirements (NFRs).

Let’s break them down simply — and make it unforgettable.

---

🧍‍♂️ A Human Being Analogy

Think of a software system as a human being.

👁️ Functional Requirements

These are the actions a person can perform — the capabilities that define what they can do.

• Eyes → to see (vision function)

• Mouth → to talk and eat

• Ears → to hear

• Legs → to walk and move

• Hands → to hold and touch

If a human can perform all these functions correctly, they are functionally complete — just as an app that meets all its use cases is functionally sound.

❤️ Non-Functional Requirements

Now imagine two people: both can see, talk, and walk — but one is fit and healthy, while the other is weak and easily tired.
The difference isn’t in what they can do, but in how well they can do it.

That’s exactly what non-functional requirements define — the quality attributes of the system.

Examples for humans:

• Health condition 🏥 (Reliability)

• Stamina 💪 (Performance)

• Immunity 🛡️ (Security)

• Calmness 😌 (Usability / Stability)

• Adaptability 🌍 (Scalability)

If the person is unhealthy, even though they have all functional parts, they won’t perform optimally.
Likewise, a system can have all required features but still fail if it’s slow, unreliable, insecure, or hard to use.

---

💻 Bringing It Home — GoProcure Example

Let’s apply this to GoProcure, our enterprise procurement system.

⚙️ Functional Requirements (What the system does)

These are the direct features or actions users expect:

• Create and approve purchase requisitions 🧾

• Manage vendors and their compliance documents 🧩

• Generate purchase orders and track approvals 🔁

• Send notifications for pending tasks 🔔

• Display reports and dashboards 📊

If these features exist and work correctly, GoProcure is functionally complete.

But — that doesn’t mean it’s a good system yet.

---

⚡ Non-Functional Requirements (How well the system works)

These define the quality of the GoProcure experience:

• Performance: Pages should load in < 3 seconds even with 5,000 concurrent users.

• Scalability: Should handle growing organizations and vendor data easily.

• Security: Data must be encrypted (TLS 1.3, AES-256).

• Availability: System uptime must be 99.9%.

• Usability: Interface should be intuitive and responsive on any device.

• Maintainability: Code should follow clean architecture and DDD principles.

• Reliability: Actions should not fail or produce inconsistent data.

• Monitoring: Application Insights and Serilog must capture logs and metrics.

In other words, the non-functional side determines whether GoProcure feels like a healthy, high-performing human — or one that’s sluggish, unpredictable, and unreliable.

---

🧩 Quick Comparison Table

---

🚀 Why Both Matter

If you only define functional requirements, your system might technically “work” — but users will hate it.
If you only chase non-functional perfection, you’ll polish an app that does nothing useful.

A great system — and a great engineer — focuses on both the body and the health of the software.

In GoProcure, the goal is to build a system that not only works but also works beautifully: fast, secure, reliable, and scalable.