Why Your System is Like Your Love Life: A Comprehensive Guide to Requirements

In this guide, we will explore the differences between functional and non-functional requirements using real-world examples, stories, and system design principles. Whether you’re a seasoned software engineer or a beginner, understanding these concepts is crucial for building effective systems.

Quick Reference for System Design Requirements

• Functional Requirements (FR): What the system should do.
• Non-Functional Requirements (NFR): How well the system should perform.
• Key Difference: Functional requirements define features, while non-functional requirements define the quality attributes of the system.

The Boring Part (But We Have to Start Here)

In traditional software engineering, system requirements are generally defined as follows:

System Requirements: Descriptions of What a System Should Do

These include the services a system must provide and its operational constraints. Sounds dry, right? But stick with us—things get more exciting with a story!

Functional Requirements (FR): What the System Should Do

Functional requirements describe:

• The services the system provides
• How it processes data
• The outputs the system generates

Non-Functional Requirements (NFR): How Well the System Should Perform

Non-functional requirements impose constraints on the services or functions of the system, including:

• Performance metrics
• Security requirements
• Reliability standards
• System availability
• Maintainability criteria

But don’t fall asleep just yet! Let’s bring this to life with a story.

The Love Story: Understanding System Requirements in Real Life

Meet Dev, a software developer who has fallen for Priyanka, a UX designer at his company. Dev decides to approach this challenge like a true engineer—systematically!

Phase 1: The Initial Requirements Gathering

Dev starts by listing the functional requirements of his mission:

• Ask Priyanka out for coffee
• Make her laugh at least once
• Get her phone number
• Secure a second date

But his friend Hemant finds it amusing: “You’re treating this like a CRUD application! Where are your non-functional requirements?”

Dev is confused. Hemant explains that HOW he achieves these goals is just as important as WHAT he does.

Phase 2: The Non-Functional Requirements Revelation

Dev learns the importance of NFRs. He revises his approach:

Original Functional Requirement: Ask Priyanka Out for Coffee

• Failed Implementation: Dev shouted “COFFEE?” across the office.

Missing Non-Functional Requirements:

• Timing: Approach during acceptable social hours (not during Priyanka’s important client meeting).
• Voice Modulation: Use an appropriate volume for the office setting.
• Communication Protocol: Maintain a professional yet casual tone.
• Error Handling: Ability to gracefully handle rejection.

Phase 3: The Implementation Crisis

Dev incorporates both functional and non-functional requirements:

Functional Requirement: Make Priyanka Laugh

• Quality: Joke must be workplace-appropriate.
• Performance: Delivery must feel natural, not forced.
• Reliability: Joke should work consistently (no inside jokes).
• Scalability: Should work even if others are present.

Dev attempts a joke: “Why do Java developers wear glasses? Because they don’t C#!” Priyanka laughs but immediately calls him out for using a generic Google joke.

Learning: Authenticity matters! Simply meeting the functional requirement (making Priyanka laugh) wasn’t enough. The non-functional requirement of authenticity was missing.

Back to Technical Reality: Advanced Requirements Engineering

Let’s dive deeper into non-functional requirements (NFRs), which often have a hierarchical impact structure. Here’s an example from payment processing in e-commerce platforms:

Primary Impact NFRs:

These can be directly measured and tested:

• Response Time: Payment confirmation within 2 seconds.
• Uptime: System must be available 99.999% of the time.
• Error Rate: No more than 0.01% failed transactions.

Secondary Impact NFRs:

These affect multiple system components and create chain reactions:

• Scalability Requirement: Handle 1000 transactions per second.
  • Cascading Effects:
    • Database scaling.
    • Load balancing reconfiguration.
    • Caching system updates.

Architectural Impact NFRs:

These shape the entire system architecture and may require a rebuild:

• Security Requirement: PCI DSS Level 1 compliance.
  • Implications:
    • End-to-end encryption.
    • Specific network segmentation.
    • Particular data storage mechanisms.

Real-World Application: Netflix’s Chaos Monkey

Netflix’s approach to ensuring system availability:

• Primary NFR: 99.99% uptime.
• Secondary NFR: System must continue to function even if multiple servers fail.
• Architectural NFR: Microservices architecture with full service isolation.

This led to the development of Chaos Monkey, a tool that randomly terminates server instances to ensure resilience.

Real-World Failures: When Requirements Go Wrong

Flipkart’s Big Billion Day (2014)

While Flipkart met its functional requirements for product listings, cart functionality, and payment processing, it failed on several non-functional fronts:

• Scalability: Couldn’t handle 1.5M+ concurrent users.
• Performance: Site performance slowed dramatically.
• Availability: Crashed multiple times during peak hours.

As a result:

• Lost sales in the millions.
• Major customer trust issues.
• Public apology from the founders.

Learning: For e-commerce events, NFRs (how the system performs under load) are more critical than FRs (basic functionality).

Back to Dev and Priyanka: A Happy Ending

Dev learned the importance of balancing functional and non-functional requirements. He’s now dating Priyanka and is carefully planning their six-month anniversary—this time with well-documented requirements for both WHAT he wants and HOW WELL he wants to do it.

Common Requirements Questions

How Do You Identify Functional vs Non-Functional Requirements?

• Functional Requirements (FR): Can be answered with “Does it do X?” (Yes/No).
• Non-Functional Requirements (NFR): Can be answered with “How well does it do X?” (Metrics).

Which Type of Requirements Are More Important?

Both types of requirements are equally crucial. Functional requirements define what your system does, while non-functional requirements determine how well it performs in production.

Key Takeaways

• Functional requirements are useless without non-functional requirements.
• NFRs often have hidden interactions and dependencies.
• Some NFRs can’t be retrofitted—they must be designed from the beginning.
• Requirements evolve over time, and the most costly ones are often those you didn’t consider.

Remember: In system design—as in love—it’s not just about WHAT you do, but HOW WELL you do it!

This blog post was written by Hemant Upadhyay, Senior SDE at Emerson, sharing his expertise and insights on the topic.