Loading learning content...
A system that does everything users need but does it slowly, inconsistently, or insecurely is a failed system. Non-functional requirements (NFRs) define the quality attributes that determine how well a system performs its functions—and they are just as critical as functional requirements to successful design.
While functional requirements describe what a system does, non-functional requirements describe how it does it:
In Low-Level Design, NFRs profoundly influence architectural patterns, class designs, data structure choices, and algorithm selection. A design that ignores NFRs may be functionally correct but operationally useless.
By completing this page, you will master: • The taxonomy of non-functional requirements and their impact on design • How to identify and elicit NFRs from stakeholders and context • Specific techniques for quantifying and measuring NFRs • How different NFRs influence Low-Level Design decisions • Trade-offs between competing quality attributes • Common NFR patterns in LLD interview scenarios
Non-functional requirements specify criteria that judge the operation of a system, rather than specific behaviors. They're sometimes called quality attributes, system properties, or -ilities (because many end in "-ility": reliability, scalability, maintainability).
Consider these pairs of requirements for a book search feature:
| Functional Requirement | Related Non-Functional Requirement |
|---|---|
| Users can search for books by title | Search results return within 200 milliseconds |
| System stores borrowing history | History data must be retained for 7 years minimum |
| Members can update their profile | Profile updates must be protected against CSRF attacks |
| System processes book returns | Return processing must succeed 99.9% of the time |
| Librarians can add new books | Adding a book should require no more than 2 minutes of training |
NFRs often appear as modifiers to functional requirements—adjectives and adverbs that describe HOW something is done: • "Quickly return search results" → Performance • "Securely store passwords" → Security • "Reliably process transactions" → Reliability • "Easily add new book types" → Maintainability
When you encounter these qualitative modifiers, you've found a non-functional requirement.
In Low-Level Design, NFRs drive fundamental decisions:
| NFR Category | Design Impact |
|---|---|
| Performance | Algorithm complexity choices, data structure selection, caching strategies |
| Reliability | Error handling patterns, retry mechanisms, data validation rigor |
| Security | Access control implementations, input sanitization, audit logging |
| Maintainability | Design patterns, separation of concerns, coding standards |
| Scalability | Concurrency handling, resource pooling, stateless design |
Ignoring NFRs leads to designs that seem elegant on paper but fail in production.
NFRs span a wide taxonomy. Understanding this taxonomy ensures you consider all relevant quality attributes during design.
These affect system behavior during execution:
These affect development and evolution:
These connect to business concerns:
In Low-Level Design, certain NFRs have more direct impact than others. Let's explore the most relevant NFRs and their specific influence on class design, patterns, and implementation choices.
Performance NFRs drive algorithm and data structure choices:
| Requirement | Design Response |
|---|---|
| Book search < 100ms for 1M books | Use index-based lookup (HashMap by ISBN, TreeMap for sorted iteration) |
| Simultaneous borrow operations without blocking | Lock-free data structures, optimistic concurrency |
| History queries span 10 years of data | Pagination, lazy loading, efficient date-range queries |
| Peak load: 1000 concurrent users | Connection pooling, stateless design, caching |
Reliability requirements influence error handling and data integrity:
12345678910111213141516171819202122232425262728293031
// NFR: "No borrowing transaction should be partially completed"// Design Response: Atomic operations with rollback capability public class BorrowingService { @Transactional(rollbackFor = Exception.class) public Borrowing borrowBook(String memberId, String bookId) { // All operations succeed together or fail together Member member = memberRepository.findById(memberId) .orElseThrow(() -> new MemberNotFoundException(memberId)); Book book = bookRepository.findById(bookId) .orElseThrow(() -> new BookNotFoundException(bookId)); // Validation - fail fast before any state changes borrowingPolicy.validateBorrowing(member, book); // State changes - atomic unit book.markAsBorrowed(member); Borrowing borrowing = Borrowing.create(member, book, LocalDate.now().plusDays(14)); borrowingRepository.save(borrowing); bookRepository.save(book); // Side effects - after core transaction succeeds eventPublisher.publish(new BookBorrowedEvent(borrowing)); return borrowing; }}Security NFRs influence class visibility, input handling, and access control:
Maintainability NFRs justify design patterns and clean code practices:
| Requirement | Design Response |
|---|---|
| New book types without code changes | Strategy pattern for book-type-specific behavior |
| Easy debugging of borrowing issues | Comprehensive logging, clear exception hierarchy |
| Junior developers can modify fee calculation | Fee rules extracted to configuration or policy classes |
| Safe refactoring of core logic | High test coverage, dependency injection |
Vague NFRs like "the system should be fast" provide no design guidance. Effective NFRs are specific, measurable, and testable. Quantification transforms aspirations into actionable constraints.
Apply SMART criteria to make NFRs actionable:
| Vague NFR | Quantified NFR | Measurement Method |
|---|---|---|
| System should be fast | 95th percentile response time < 200ms for search queries | Response time monitoring, load testing |
| System should be reliable | 99.9% availability (43 minutes downtime/month max) | Uptime monitoring, incident tracking |
| System should handle many users | Support 10,000 concurrent users with <10% performance degradation | Load testing, capacity planning |
| System should be secure | Pass OWASP Top 10 vulnerability assessment, SOC 2 compliance | Security audit, penetration testing |
| System should be easy to modify | New fee type added in < 2 developer-hours, 80% code coverage | Development time tracking, test coverage tools |
In interviews, you won't always get explicit quantified NFRs. Instead, you might hear: • "Assume a large library with many books" → Infer performance requirements • "This is for a banking application" → Infer high reliability and security requirements • "The system needs to grow over time" → Infer extensibility and scalability requirements
Part of your job is to make reasonable inferences and state your assumptions explicitly: "I'm assuming we need to support up to 1 million books with sub-second search times."
Quality attributes often conflict. Optimizing for one may compromise another. Expert designers understand these trade-offs and make informed decisions based on priorities.
| Trade-off | Tension | Resolution Approach |
|---|---|---|
| Performance vs. Maintainability | Optimized code is often more complex | Start simple, optimize only measured bottlenecks |
| Security vs. Usability | More security = more friction for users | Risk-based approach: high security for sensitive operations |
| Performance vs. Reliability | Faster may mean skipping validation/logging | Never sacrifice data integrity for speed |
| Flexibility vs. Simplicity | More configuration = more complexity | YAGNI: add flexibility when needed, not speculatively |
| Consistency vs. Availability | Strong consistency requires coordination overhead | CAP theorem: choose based on domain requirements |
When NFRs conflict, prioritize based on business context:
When discussing trade-offs in interviews, show your reasoning:
"Given that this is a library system, I'll prioritize reliability (no lost transactions) over raw performance. Data integrity is more important than saving 50ms on a checkout. However, for search functionality, I'll prioritize performance since it's a read-only operation with no data integrity risk."
This demonstrates mature engineering judgment—exactly what interviewers seek.
NFRs are rarely stated explicitly. You must skillfully extract them through questions, context analysis, and domain knowledge.
Use this systematic checklist to uncover NFRs:
When explicit answers aren't available, infer from context:
| Context Clue | Inferred NFRs |
|---|---|
| "Large public library system" | High volume (millions of books/members), multi-location access, concurrent users |
| "University library" | Academic calendar spikes (semester start/end), multi-format materials, research access |
| "Small community library" | Lower volume, simpler requirements, limited budget implies simpler solutions |
| "24/7 operation" | High availability, no maintenance windows, automated recovery |
| "Children's section" | Content filtering, age-appropriate access control, simplified UI |
When inferring NFRs, always state your assumptions explicitly:
"Since this is described as a large metropolitan library system, I'm assuming: • 500K+ books in the catalog • 10K+ active members • Peak concurrent users during lunch hours: ~500 • 99.9% availability expectation
Please correct me if these assumptions don't match your expectations."
This prevents misaligned designs and demonstrates thorough thinking.
Well-documented NFRs serve as contracts between stakeholders. They guide design decisions and provide criteria for validation.
Each NFR should capture:
123456789101112131415161718192021222324252627282930313233343536
## NFR-001: Search Response Time ### CategoryPerformance ### RequirementBook search queries must return results within 200 milliseconds at the 95th percentile under normal load conditions. ### RationaleUser research shows abandonment rates increase significantly when search takes longer than 1 second. 200ms provides responsive feel with margin for network latency. ### Measurement- **Metric:** 95th percentile response time- **Target:** ≤ 200ms- **Conditions:** Normal load (up to 500 concurrent users)- **Measurement Point:** End-to-end from API receipt to response sent ### Verification Method- Load testing with representative query patterns- Production monitoring dashboards- Automated alerting when threshold exceeded ### PriorityHigh - Core user experience ### Trade-offs- May require caching infrastructure- May limit query complexity- May require index maintenance overhead ### Related Requirements- NFR-005: Catalog Size (affects search complexity)- FR-004: Search by title, author, ISBNDocument how each NFR influences specific design choices:
| NFR | Design Decision | Implementation |
|---|---|---|
| NFR-001: Search < 200ms | In-memory book index | BookSearchService with HashMap<String, Set<Book>> index by title tokens |
| NFR-002: 99.9% availability | Stateless service design | Services don't hold session state; state externalized to database |
| NFR-003: Secure member data | Encrypted credential storage | PasswordEncoder interface with BCrypt implementation |
| NFR-004: Easy fee rule changes | Configuration-driven fees | FeePolicy interface with database-backed ConfigurableFeePolicy |
Certain NFRs appear frequently in LLD interview problems. Being prepared for these accelerates your requirement gathering.
| Problem Type | Typical NFRs | Design Implications |
|---|---|---|
| Parking Lot | Concurrent access, real-time availability updates | Thread-safe data structures, optimistic locking |
| Library System | Data integrity, search performance, audit trail | Transaction management, indexing, logging |
| Elevator System | Real-time responsiveness, safety, fairness | State machines, scheduling algorithms, priority handling |
| Chess Game | Rule enforcement, undo capability, persistence | Command pattern, validation strategy, serialization |
| Ride Sharing | Real-time matching, location tracking, payment security | Event-driven design, strategy pattern for matching |
| Hotel Booking | Double-booking prevention, pricing flexibility, cancellation | Pessimistic locking, strategy pattern for pricing |
Don't wait for the interviewer to mention NFRs. Proactively address them:
"Before I dive into the class design, let me clarify some non-functional requirements. For a parking lot system: • Concurrent access is critical—multiple cars entering/exiting simultaneously • Real-time accuracy for spot availability is important to avoid frustration • The system should handle peak loads gracefully
I'll keep these in mind as I design the classes."
This demonstrates senior-level thinking.
Non-functional requirements are the quality attributes that transform functional systems into production-ready solutions. Mastery of NFRs elevates your design thinking from "does it work?" to "does it work well?"
What's Next:
With functional and non-functional requirements understood, the next critical skill is asking the right clarifying questions. Effective requirement gathering depends on knowing what to ask, when to ask it, and how to interpret answers. The next page provides a systematic approach to clarifying questions that ensures complete requirement coverage.
You now understand how to identify, categorize, quantify, and prioritize non-functional requirements. Combined with your knowledge of functional requirements, you can now capture the complete picture of what a system needs to be successful. Next, we'll learn the art of asking clarifying questions to ensure no requirement goes undiscovered.