A client comes to you with a request: “I want an app like Uber, but for dog walking.”
You sit down to create the estimate. You list the features:
- User Login
- Map View
- Payment Processing
- Review System
You calculate the hours, apply your rate, and send a quote for $40,000.
Another agency sends a quote for the exact same project. Their price is $120,000.
Is the other agency ripping the client off? Or did they see something you missed?
The likely answer is that you estimated only the Functional Requirements (what the app does), while the other agency estimated the Non-Functional Requirements (how the app performs).
You estimated a car that has wheels and an engine. They estimated a car that can drive 200 mph safely, has airbags, and is fuel-efficient.
Ignoring Non-Functional Requirements (NFRs) is the most common reason software projects go over budget. You build the features, but the system crashes under load, or the pages load too slowly, and you spend months fixing it for free.
This guide will explain the critical difference between these two types of requirements using simple analogies, and show you how to capture the hidden costs of “quality” in your estimates.
Table of Contents
- The “It’s just a simple app” Trap
- What are Functional Requirements? (The “What”)
- What are Non-Functional Requirements? (The “How”)
- The Iceberg Theory of Cost
- The Big Three NFR Cost Drivers
- How to estimate NFRs without scaring the client
- How devtimate ensures you don’t forget NFRs
- Checklist
- FAQ
The “It’s just a simple app” Trap
Clients often say, “It’s just a simple database app.”
To a client, “simple” means “it doesn’t have many buttons.” To a developer, “simple” means “it doesn’t have complex architecture.”
These are not the same thing. Google Search has only one button. It is functionally simple. But the architecture required to search billions of pages in 0.2 seconds is incredibly complex.
If you only ask the client “What features do you want?”, you are setting yourself up for failure. You must also ask “How many users will be on it?”, “How fast must it load?”, and “What happens if the server goes down?”
These questions uncover the NFRs, the hidden constraints that determine the true engineering effort.
What are Functional Requirements? (The “What”)
The Definition: Functional Requirements define specific behaviors or functions of the system. They describe the interaction between the user and the software.
The Format: They are often written as “The system shall…” or as User Stories (“As a user, I want to…”).
Examples:
- “The system shall allow users to reset their password via email.”
- “The user can add a product to the shopping cart.”
- “The admin can export sales reports to PDF.”
- “The app sends a push notification when the driver arrives.”
How to Estimate: These are relatively easy to estimate. You can break them down into a Work Breakdown Structure (WBS), assign hours to the logic and UI work, and sum it up.
The Car Analogy: Functional requirements are: The car has a steering wheel. It has four seats. It has an engine. It drives forward and backward. It has air conditioning.
What are Non-Functional Requirements? (The “How”)
The Definition: Non-Functional Requirements (often called Quality Attributes) define criteria that can be used to judge the operation of a system, rather than specific behaviors. They describe how the system works.
The Format: They are usually written as constraints or performance metrics.
Examples:
- Performance: “The dashboard must load in under 2 seconds.”
- Scalability: “The system must support 10,000 concurrent users without crashing.”
- Security: “All user data must be encrypted at rest and in transit (SOC2 compliant).”
- Availability: “The system must have 99.9% uptime.”
How to Estimate: These are hard to estimate because they affect every feature. Making a login page is 4 hours. Making a login page that withstands a DDoS attack is 40 hours.
The Car Analogy: Non-Functional requirements are: The car can go from 0 to 60 mph in 3 seconds (Performance). It has a 5-star safety rating (Security). It gets 50 miles per gallon (Efficiency). It can be driven for 200,000 miles without breaking down (Reliability).
Key Takeaway: Both a Ferrari and a Toyota Corolla meet the same Functional Requirements (they both drive). The price difference ($300k vs $20k) is almost entirely due to the Non-Functional Requirements.
The Iceberg Theory of Cost
Think of a software project as an iceberg.
- Above the Water (30%): The Functional Requirements. This is what the client sees (screens, buttons, emails). This is what they describe in the Request for Proposal (RFP).
- Below the Water (70%): The Non-Functional Requirements. This is the engineering required to make the app secure, fast, scalable, and maintainable.
If you quote based only on what you see above the water, you will crash the ship.
The danger is that clients imply NFRs. They don’t explicitly say “I want the app to be fast.” They assume it will be fast. If you deliver a slow app, they will say it is “broken,” even if it meets every functional requirement in the contract.
This is why a thorough Discovery Phase is essential - to drag these hidden expectations to the surface before you set the price.
The Big Three NFR Cost Drivers
There are dozens of NFR types, but these three are the biggest budget destroyers if missed.
1. Scalability (The “Viral” Risk)
- The Request: “We are launching to 100 beta users, but we plan to have 1 million users next year.”
- The Cost: Building for 100 users requires a $50/month server. Building for 1 million users requires a complex microservices architecture, load balancers, and database sharding. The engineering effort might be 10x higher.
- The Estimate Tip: Explicitly define the “Supported Load” in your Acceptance Criteria. “The estimate covers up to 5,000 concurrent users.”
2. Security (The “Compliance” Risk)
- The Request: “We need to store patient records.”
- The Cost: Suddenly, you aren’t just building a database; you are building a HIPAA-compliant fortress. You need audit logs, encryption key management, and regular penetration testing.
- The Estimate Tip: Never simply say “Secure.” Specify the standard (e.g., “OWASP Top 10 protection”).
3. Performance (The “Speed” Risk)
- The Request: “The search needs to be instant.”
- The Cost: “Instant” usually means <100ms. To achieve this on a large dataset, you can’t just query SQL. You might need to implement Elasticsearch or Redis caching layers.
- The Estimate Tip: Use specific numbers. “Search results will appear in under 2 seconds on a standard 4G connection.”
How to estimate NFRs without scaring the client
If you list “Non-Functional Requirements” on a proposal, the client’s eyes will glaze over. You need to frame them as Quality Assurance and Risk Management.
There are two ways to include NFR costs in your estimate:
Method 1: Explicit Line Items (Better for large tasks) For major architectural work, add specific tasks to your WBS.
- Task: “Setup Redis Caching Layer for High Performance” - 40 hours.
- Task: “Security Audit and Encryption Implementation” - 30 hours.
- Task: “Load Testing for 10k Users” - 20 hours.
Method 2: The Complexity Multiplier (Better for general quality) If the NFR affects everything (e.g., “High Code Quality for Maintainability”), increase the estimate of every functional task.
- Instead of estimating the “User Profile” at 10 hours (optimistic), estimate it at 15 hours to account for writing unit tests and clean code.
- Note: Read our guide on Three-Point Estimation (Optimistic/Pessimistic) to handle this math.
Pro-Tip: Always explain the Cost of Inaction. “We can skip the caching layer to save $5,000, but the site will likely crash if more than 50 people use it at once. Do you want to take that risk?”
How devtimate ensures you don’t forget NFRs
When you are rushing to create a ballpark estimate, it is easy to just list the screens and forget the architecture.
devtimate helps you capture the full scope:
- Architecture Templates: You can start with a template that already includes standard NFR line items like “DevOps Setup,” “Security Configuration,” and “Performance Testing.”
- Global Risk Factors: You can apply a project-wide difficulty multiplier if you know the client has strict security requirements (e.g., Banking or Healthcare).
- Section-Level Notes: You can define the Acceptance Criteria for each module directly in the tool, ensuring the scope of “quality” is agreed upon before you generate the proposal.
Don’t let hidden requirements eat your profit margin.
Build comprehensive estimates that cover both Form and Function with devtimate.
Checklist
✅ During discovery, specifically ask about “The -ilities”: Scalability, Reliability, Availability.
✅ Define “Done” not just by features, but by performance (load time, uptime).
✅ Use the “Iceberg” analogy to explain to clients why the backend costs so much.
✅ Explicitly list major NFRs (like Load Testing) as billable line items in the WBS.
✅ If a client insists on cutting the budget, warn them that NFRs (speed, stability) are usually the first things to suffer.
✅ Document the assumed constraints (e.g., “Estimated for 1,000 users”) to protect yourself from Scope Creep.
FAQ
1. Can I add NFRs later?
You can, but it is expensive. Adding security or scalability to an app after it is built is like trying to put a basement under a house that is already built. It costs 10x more than doing it from the start. This is why Technical Debt accumulates.
2. My client says they don’t care about performance, they just want it cheap. What do I do?
Get it in writing. In the proposal, explicitly state: “This estimate assumes a standard architecture suitable for MVP traffic (up to X users). High-performance optimization is excluded.” This protects you when they complain later that it’s slow.
3. Are UI/UX designs Functional or Non-Functional?
They sit in the middle. The existence of a button is Functional. The usability and accessibility (e.g., color contrast for visually impaired users) are Non-Functional requirements (Usability).
4. How do NFRs affect the timeline?
Heavily. High NFRs require more testing. If you need 99.99% reliability, your QA phase might need to be as long as your development phase. Ensure your project timeline reflects this.
5. What is the most expensive NFR?
Usually Offline Capability (data sync). If a client says, “The app must work perfectly without internet and sync when back online,” double your estimate immediately. Sync logic is incredibly hard.
A software estimate that only covers Functional Requirements is not an estimate; it is a fantasy.
By identifying and pricing the Non-Functional Requirements early, you move from being a “feature factory” to being a true engineering partner. You build software that doesn’t just work on Day 1, but survives Day 100.
Capture the invisible costs. Use devtimate to build professional, complete estimates.
