Functional Requirements vs Nonfunctional Requirements

Overview

Functional requirements and nonfunctional requirements are two major categories of requirements used in software engineering, product planning, architecture design, and system design interviews.

A functional requirement describes what the system must do. It defines behavior, features, workflows, inputs, outputs, business rules, user actions, system actions, and integration behavior.

Examples:

• Users can register with email and password.
• Customers can add products to a cart.
• The system calculates tax based on region and product type.
• Admins can approve or reject loan applications.
• The API returns order details by order ID.
• The system sends an email after an invoice is generated.

A nonfunctional requirement describes how well the system must operate or what constraints it must satisfy. It defines quality attributes such as performance, scalability, availability, reliability, resilience, security, usability, accessibility, maintainability, observability, compliance, portability, and cost.

Examples:

• Product search must respond within 300 ms at p95 under expected peak load.
• The checkout API must maintain 99.95% monthly availability.
• The system must support 10,000 concurrent users.
• Sensitive customer data must be encrypted in transit and at rest.
• Audit logs must be retained for 7 years.
• New payment providers should be added without changing existing checkout business logic.

A simple way to remember the difference is:

Functional requirements: What should the system do?
Nonfunctional requirements: How well should the system do it?

This topic matters because functional requirements define product scope, while nonfunctional requirements define the quality bar and architecture constraints. A system can be functionally correct but still fail in production if it is too slow, unavailable, insecure, expensive, hard to operate, or unable to scale.

For example, "users can upload files" is a functional requirement. The architecture is very different depending on the nonfunctional requirements: file size, upload throughput, encryption, virus scanning, resumable upload, retention, auditability, and download latency.

This topic is important for interviews because system design discussions usually begin with requirements. A strong candidate does not jump directly to databases, queues, caches, or microservices. They first clarify the functional scope and the quality attributes that shape the design. Interviewers expect candidates to ask about scale, latency, availability, consistency, security, compliance, observability, cost, and operational constraints.

A strong answer should show that requirements are not just documentation. They guide architecture trade-offs, technology choices, API design, database design, testing strategy, deployment strategy, monitoring, and production operations.

Core Concepts

Functional Requirements

A functional requirement defines a behavior or capability the system must provide.

Functional requirements usually describe:

• User actions.
• System actions.
• Business workflows.
• Business rules.
• Input and output behavior.
• API behavior.
• Data creation, update, retrieval, and deletion.
• Permissions and role-specific behavior.
• Notifications.
• Reports.
• Integrations.
• Calculations.
• Validations.
• State transitions.

Example for an e-commerce system:

FR-001: A customer can add a product to the shopping cart.
FR-002: A customer can remove a product from the shopping cart.
FR-003: A customer can place an order using a saved payment method.
FR-004: The system sends an order confirmation email after successful payment.
FR-005: An admin can update product inventory.
FR-006: The system prevents checkout when inventory is insufficient.

These requirements describe what the system does from the user's or business's point of view.

Nonfunctional Requirements

A nonfunctional requirement defines a quality attribute, operational expectation, or constraint.

Nonfunctional requirements usually describe:

• Performance.
• Latency.
• Throughput.
• Scalability.
• Availability.
• Reliability.
• Resilience.
• Security.
• Privacy.
• Compliance.
• Usability.
• Accessibility.
• Maintainability.
• Modifiability.
• Testability.
• Observability.
• Operability.
• Portability.
• Compatibility.
• Cost.
• Data retention.
• Disaster recovery.
• Backup and restore.
• Capacity.
• Technology constraints.
• Deployment constraints.

Example for the same e-commerce system:

NFR-001: Product search must return results within 300 ms at p95 under normal load.
NFR-002: The checkout API must be available 99.95% monthly.
NFR-003: Payment information must never be stored in plain text.
NFR-004: The system must support 5,000 concurrent users during peak campaigns.
NFR-005: Order data must be retained for 7 years.
NFR-006: The system must recover from database failover within 5 minutes.

These requirements describe how well the system must work and what constraints it must respect.

Simple Comparison

Both are required. A system that has only functional requirements may work in a demo but fail in production. A system that focuses only on nonfunctional requirements may be over-engineered without delivering the business features users need.

Functional Requirement Examples

Functional requirements are usually feature-oriented.

Example: banking application

FR-001: A customer can view account balances.
FR-002: A customer can transfer money between their own accounts.
FR-003: A customer can transfer money to an external account.
FR-004: The system validates that the source account has sufficient funds.
FR-005: The system records every successful transfer in transaction history.
FR-006: A bank employee can freeze an account.

Example: course management application

FR-001: An instructor can create a course.
FR-002: A student can enroll in an available course.
FR-003: The system prevents enrollment when the course is full.
FR-004: An instructor can upload course materials.
FR-005: A student can submit assignments.
FR-006: The system calculates final grades from assignment scores.

Example: managed file transfer system

FR-001: A user can upload a file.
FR-002: The system stores file metadata.
FR-003: A user can share a file with another organization.
FR-004: The recipient can download the shared file.
FR-005: The system records download history.
FR-006: The sender can revoke access before download.

Each requirement describes a behavior the system must support.

Nonfunctional Requirement Examples

Nonfunctional requirements should be specific and measurable when possible.

Weak examples:

The system should be fast.
The system should be secure.
The system should be scalable.
The system should be easy to use.
The system should be reliable.

Better examples:

The product search API must return results within 300 ms at p95 under 1,000 requests per second with 100,000 products indexed.

The checkout API must maintain 99.95% monthly availability, excluding planned maintenance windows.

All personally identifiable information must be encrypted at rest using approved encryption mechanisms.

The system must support horizontal scaling to 20 application instances without code changes.

A new payment provider integration should be added by implementing a new provider adapter without changing existing checkout business logic.

The system must retain audit logs for 7 years and allow authorized users to search them by user ID, event type, and date range.

A good nonfunctional requirement has an observable target.

Why Nonfunctional Requirements Drive Architecture

Functional requirements often define product features. Nonfunctional requirements often define architecture.

Example:

Functional requirement:
Users can upload files.

Nonfunctional requirements:
- Files can be up to 10 GB.
- Uploads must resume after network interruption.
- Files must be virus-scanned before download.
- Files must be encrypted at rest.
- Downloads must be audited.
- Files must be retained for 7 years.
- Upload throughput must support 2,000 files per hour.

These nonfunctional requirements affect design choices:

• Use object storage instead of storing files in a relational database.
• Use chunked or resumable upload.
• Use background scanning.
• Use event-driven processing.
• Use encryption and key management.
• Store metadata separately.
• Add audit logging.
• Add lifecycle policies.
• Add queue-based processing.
• Add monitoring and alerting.

The feature "upload files" is simple. The architecture is shaped by the quality attributes.

Quality Attributes

Quality attributes are properties used to evaluate a system.

Common quality attributes include:

In architecture interviews, nonfunctional requirements are often called quality attributes, architecture characteristics, or "ilities."

Constraints vs Quality Attributes

Not all nonfunctional requirements are quality attributes. Some are constraints.

A quality attribute describes a desired quality level.

Example:

The API must respond within 200 ms at p95.

A constraint limits the solution space.

Example:

The system must use Azure SQL Database.
The frontend must be built with React.
The system must integrate with the existing payment gateway.
The application must be deployed to the company's Kubernetes platform.
The system must comply with PCI DSS requirements.

Constraints can be technical, business, legal, operational, organizational, or budget-related.

Constraints are important because they shape what solutions are possible. In interviews, it is useful to ask whether there are required technologies, compliance rules, budget limits, region restrictions, data residency rules, or integration constraints.

Functional vs Nonfunctional vs Business Requirements

Requirements can be viewed at different levels.

They are related but not the same.

Example flow:

Business requirement:
Increase online sales conversion.

Functional requirement:
Customers can check out using saved payment methods.

Nonfunctional requirement:
Checkout must complete within 2 seconds at p95 during peak traffic.

Technical requirement:
Payment tokens must be stored using the approved payment provider tokenization API.

Compliance requirement:
The system must not store raw card numbers.

Strong architecture work connects business goals to functional behavior and quality attributes.

User Stories and Acceptance Criteria

Functional requirements are often written as user stories.

Example:

As a customer,
I want to reset my password,
so that I can regain access to my account.

Acceptance criteria:

Given a registered email address,
When the customer requests a password reset,
Then the system sends a password reset email.

Given an unregistered email address,
When the customer requests a password reset,
Then the system returns a generic success response without revealing whether the email exists.

Given an expired reset token,
When the customer attempts to reset the password,
Then the system rejects the token.

Nonfunctional requirements can be attached to the same user story.

The password reset request must complete within 500 ms at p95.
The reset token must expire after 15 minutes.
The reset token must be single-use.
The system must rate-limit reset attempts by IP address and email.
Reset token values must not be logged.

The user story describes behavior. The nonfunctional requirements define quality and constraints.

Acceptance Criteria vs Nonfunctional Requirements

Acceptance criteria are conditions that must be true for a requirement or story to be accepted. They can include both functional and nonfunctional expectations.

Functional acceptance criterion:

Given a valid order,
When the customer submits payment,
Then the system creates the order and marks it as paid.

Nonfunctional acceptance criterion:

The payment submission must complete within 2 seconds at p95 under expected peak load.

Security acceptance criterion:

The payment endpoint must reject requests without a valid authentication token.

Observability acceptance criterion:

The system must emit a structured audit event for every successful payment.

In practice, teams often write functional acceptance criteria clearly but forget measurable nonfunctional acceptance criteria. This creates ambiguity and hidden architecture risk.

Measurable Requirements

Good requirements are testable and measurable.

Weak:

The system must be fast.

Better:

The product search API must return results within 300 ms at p95 under 1,000 requests per second with 100,000 products indexed.

Weak:

The system must be reliable.

Better:

The order API must maintain 99.95% monthly availability and recover from a single application instance failure without user-visible downtime.

Weak:

The system must be secure.

Better:

All API endpoints that access customer data must require authentication and authorization. Sensitive data must be encrypted in transit using TLS and at rest using platform-managed encryption.

Measurable requirements reduce ambiguity and make testing possible.

SMART Requirements

A practical way to evaluate requirements is to make them SMART:

Example:

The system must process 95% of invoice-generation jobs within 5 minutes of request submission during normal business hours.

This is specific, measurable, relevant, and time-related. Whether it is achievable depends on scale, budget, and architecture.

Ambiguous Requirements

Ambiguous requirements are dangerous because different stakeholders interpret them differently.

Ambiguous:

The system should support many users.

Clarified:

The system must support 20,000 registered users and 2,000 concurrent active users during peak hours.

Ambiguous:

Reports should load quickly.

Clarified:

The monthly sales report must load within 5 seconds at p95 for datasets up to 5 million rows.

Ambiguous:

The system should be secure.

Clarified:

Administrative actions must require multi-factor authentication, be authorized by role, and be recorded in an immutable audit log.

Interviewers often reward candidates who ask clarifying questions before proposing architecture.

Requirements in System Design Interviews

In system design interviews, requirements usually come first.

A good requirements discussion asks:

Who are the users?
What are the main user flows?
What are the read/write patterns?
What scale should we design for?
What latency is acceptable?
What availability target matters?
What consistency is required?
What data must be protected?
What compliance rules apply?
What integrations are needed?
What operations must be auditable?
What can fail gracefully?
What is out of scope?

Functional requirements define the core features. Nonfunctional requirements define the design pressure.

Example: designing a URL shortener

Functional requirements:

Users can create short URLs.
Users can redirect using a short URL.
Users can optionally set expiration time.
Users can view basic analytics.

Nonfunctional requirements:

Redirect latency must be under 50 ms at p95.
The system must support 100 million redirects per day.
Short URL creation must prevent duplicate keys.
Redirects should remain available during analytics outages.
Analytics can be eventually consistent.
The service must be highly available.

These NFRs strongly influence the architecture.

Functional Requirements in API Design

Functional requirements can be mapped to API endpoints.

Example:

FR-001: Customers can create an order.

Possible API:

POST /api/orders

Request:

{
  "customerId": 123,
  "items": [
    {
      "productId": 10,
      "quantity": 2
    }
  ]
}

Response:

{
  "orderId": 456,
  "status": "Created"
}

Additional functional requirements:

FR-002: Customers can get an order by ID.
FR-003: Customers can cancel an order before shipment.
FR-004: Admins can list orders by status.

Functional requirements help define API contracts, UI flows, commands, queries, and business operations.

Nonfunctional Requirements in API Design

Nonfunctional requirements shape API design and infrastructure.

Example:

NFR-001: Create order must respond within 1 second at p95.
NFR-002: Order creation must be idempotent.
NFR-003: The API must reject unauthenticated requests.
NFR-004: The API must log a correlation ID for every request.
NFR-005: The API must handle duplicate client retries safely.
NFR-006: The API must return errors using a consistent ProblemDetails format.

Design implications:

• Add idempotency keys.
• Use authentication and authorization middleware.
• Use structured logging and correlation IDs.
• Add validation.
• Add timeouts.
• Add consistent error handling.
• Add database constraints.
• Add observability.
• Add retry-safe client behavior.

NFRs often turn a basic API into a production-ready API.

Requirements and Architecture Trade-Offs

Nonfunctional requirements often conflict with each other.

Architecture is about making these trade-offs explicit.

Example:

Requirement:
Analytics must be near real-time.

Clarification:
Does "near real-time" mean under 1 second, under 1 minute, or under 15 minutes?

Trade-off:
Under 1 second may require streaming architecture.
Under 15 minutes may work with batch processing.

A strong design answer explains the trade-off, not just the solution.

Architecturally Significant Requirements

An architecturally significant requirement is a requirement that strongly influences architecture.

Examples:

The system must support 1 million concurrent users.
The system must be available across regions.
The system must process payment safely exactly once from the user's perspective.
The system must support tenant-level data isolation.
The system must comply with strict data residency rules.
The system must support offline usage.
The system must support plug-in payment providers.
The system must be deployable without downtime.

Not every requirement changes architecture. Adding one more field to a form may not be architecturally significant. But a requirement for multi-region failover likely is.

In interviews, identify architecturally significant requirements early.

Functional Decomposition

Functional decomposition breaks a large system into smaller capabilities.

Example: e-commerce platform

User management
Catalog browsing
Search
Shopping cart
Checkout
Payment
Inventory
Shipping
Notifications
Order history
Admin management
Reporting

Functional decomposition helps identify:

• Modules.
• Services.
• Use cases.
• APIs.
• Data boundaries.
• Team ownership.
• Test scope.

However, functional decomposition alone is not enough. NFRs determine whether these should be modules in one application, separate services, event-driven components, separate databases, or managed services.

Nonfunctional Decomposition

Nonfunctional decomposition breaks quality expectations into measurable targets.

Example: reliability

Availability target: 99.95% monthly.
Recovery time objective: 15 minutes.
Recovery point objective: 5 minutes.
Failure detection: within 1 minute.
Retry behavior: transient failures retried up to 3 times with backoff.
Degraded mode: users can browse catalog even if recommendations are down.
Backup: database backup every 15 minutes.

Example: performance

Product search p95 latency: 300 ms.
Checkout p95 latency: 1 second.
Report generation p95 completion: 5 minutes.
Maximum supported catalog size: 1 million products.
Peak request rate: 2,000 requests per second.

Breaking NFRs into specific targets makes them testable and designable.

Common Nonfunctional Requirement Categories

Performance

Performance describes speed and resource efficiency.

Examples:

The login API must respond within 500 ms at p95.
The search API must respond within 300 ms at p95 under 1,000 RPS.
The nightly import job must process 1 million rows within 2 hours.

Design implications:

• Caching.
• Database indexing.
• Query optimization.
• Async processing.
• Load balancing.
• CDN.
• Profiling.
• Efficient serialization.
• Avoiding N+1 queries.
• Capacity planning.

Scalability

Scalability describes how well the system handles growth.

Examples:

The system must support 10x traffic growth by adding application instances.
The worker system must process up to 100,000 jobs per hour.
The database design must support 50 million orders.

Design implications:

• Horizontal scaling.
• Stateless services.
• Partitioning.
• Sharding.
• Queue-based load leveling.
• Caching.
• Read replicas.
• Autoscaling.
• Message brokers.

Availability

Availability describes how often the system is usable.

Examples:

The API must achieve 99.9% monthly availability.
Checkout must remain available during a single application instance failure.

Design implications:

• Redundancy.
• Health checks.
• Load balancing.
• Multi-zone deployment.
• Failover.
• Rolling deployments.
• Circuit breakers.
• Graceful degradation.

Reliability

Reliability describes consistent correct operation over time.

Examples:

The system must not lose accepted orders.
Failed background jobs must be retried or moved to a dead-letter queue.
The system must prevent duplicate payment capture.

Design implications:

• Transactions.
• Idempotency.
• Outbox pattern.
• Retry policies.
• Dead-letter queues.
• Data validation.
• Monitoring.
• Error handling.

Security

Security describes protection against unauthorized access, data exposure, abuse, and tampering.

Examples:

All customer data endpoints must require authentication.
Users can access only their own orders.
Administrative actions must require role-based authorization.
Secrets must not be stored in source control.
Sensitive data must be encrypted in transit and at rest.

Design implications:

• Authentication.
• Authorization.
• Secure secret storage.
• Encryption.
• Input validation.
• Audit logging.
• Rate limiting.
• Threat modeling.
• Secure defaults.

Maintainability

Maintainability describes how easy the system is to understand, change, test, and fix.

Examples:

Adding a new payment provider should not require changes to existing provider implementations.
Business rules should be covered by unit tests.
The system should separate domain logic from infrastructure concerns.

Design implications:

• Clean architecture.
• Modularity.
• Dependency inversion.
• Automated tests.
• Clear naming.
• Documentation.
• Code review.
• Observability.
• Refactoring discipline.

Observability

Observability describes how well the system exposes internal behavior.

Examples:

Every request must include a correlation ID.
The system must emit metrics for request rate, error rate, and p95 latency.
Failed payment attempts must be logged with payment provider and error code.

Design implications:

• Structured logging.
• Metrics.
• Distributed tracing.
• Correlation IDs.
• Dashboards.
• Alerts.
• Health checks.
• Audit logs.

How Requirements Affect Testing

Functional requirements are commonly verified with:

• Unit tests.
• Integration tests.
• API tests.
• UI tests.
• Acceptance tests.
• Manual exploratory tests.
• Business rule tests.

Nonfunctional requirements are commonly verified with:

• Load tests.
• Stress tests.
• Performance benchmarks.
• Security tests.
• Penetration tests.
• Static analysis.
• Availability tests.
• Chaos testing.
• Failover drills.
• Disaster recovery tests.
• Accessibility tests.
• Usability tests.
• Observability checks.
• Compliance audits.
• Operational readiness reviews.

Example:

Functional requirement:
A customer can place an order.

Functional test:
Submit a valid order and verify an order is created.

Nonfunctional requirement:
Order placement must complete within 1 second at p95 under 500 concurrent users.

Nonfunctional test:
Run a load test with 500 concurrent users and verify p95 latency is <= 1 second.

Functional correctness does not imply production readiness.

Requirements Traceability

Traceability means linking requirements to design, implementation, tests, and operations.

Example trace:

Business goal:
Reduce checkout abandonment.

Functional requirement:
Customers can save payment methods.

Nonfunctional requirement:
Checkout must complete within 2 seconds at p95.

Design decision:
Use payment provider tokenization and cache shipping rate estimates.

Implementation:
CheckoutService, PaymentTokenService, Orders API.

Tests:
Unit tests for checkout rules.
Integration tests for order creation.
Load tests for checkout p95 latency.
Security tests for payment token handling.

Monitoring:
Checkout latency dashboard.
Payment failure alerts.

Traceability helps teams answer:

• Why was this feature built?
• Which requirement does this test cover?
• Which NFR does this architecture decision support?
• What breaks if this component changes?
• Are all critical requirements verified?

Requirements and Prioritization

Not all requirements have equal importance.

Prioritization methods include:

• Must have / should have / could have / won't have.
• Risk-based prioritization.
• Business value.
• User impact.
• Regulatory requirement.
• Technical dependency.
• Cost of delay.
• Architecture risk.
• Operational risk.

Example:

Must have:
Users can place orders.
Payments are secure.
Order data is durable.

Should have:
Users can save wishlists.
Product recommendations are available.

Could have:
Animated checkout progress.

Won't have for MVP:
Multi-currency checkout.

For NFRs:

Must have:
Checkout must be secure and reliable.

Should have:
Search p95 latency under 300 ms.

Could have:
Personalized recommendations under 100 ms.

A good architect clarifies which requirements are mandatory and which are negotiable.

MVP and Requirements

An MVP should still include essential nonfunctional requirements.

A common mistake is thinking NFRs are only for later.

Example: MVP e-commerce checkout

Functional MVP:

Customers can browse products.
Customers can place orders.
Admins can manage inventory.

Nonfunctional MVP:

Payments must be secure.
Orders must not be lost.
The system must have basic monitoring.
The system must back up order data.
The checkout API must handle expected launch traffic.

Some NFRs can be relaxed for MVP, but critical security, reliability, and data integrity requirements cannot be ignored.

Conflicts Between Requirements

Requirements often conflict.

Example:

Requirement A:
The system must provide real-time analytics.

Requirement B:
The system must minimize infrastructure cost.

Possible trade-off:

Use near-real-time batch processing every 5 minutes instead of streaming every event instantly.

Example:

Requirement A:
The system must provide strong consistency for inventory.

Requirement B:
The system must remain available during regional network partitions.

Possible trade-off:

Use strong consistency for checkout inventory reservation, but eventual consistency for product search inventory display.

Good architecture discussions make conflicts visible and negotiate acceptable trade-offs.

Requirement Quality Checklist

A good requirement should be:

• Clear.
• Unambiguous.
• Testable.
• Measurable when possible.
• Feasible.
• Necessary.
• Traceable.
• Prioritized.
• Consistent with other requirements.
• Owned by a stakeholder.
• Written at the right level of detail.
• Not secretly prescribing implementation unless it is a real constraint.

Weak:

The system should use microservices.

Better if this is a real constraint:

The system must allow independent deployment of the catalog, checkout, and notification capabilities because separate teams own each area and release on different schedules.

The second version explains the actual requirement. Microservices may be a solution, not the requirement.

Distinguishing Requirements from Solutions

A common mistake is confusing a solution with a requirement.

Solution disguised as requirement:

The system must use Kafka.

Possible underlying requirement:

The system must process order events asynchronously and support at least 10,000 events per second with durable delivery and consumer retry support.

Solution disguised as requirement:

The system must use Redis.

Possible underlying requirement:

Product search suggestions must respond within 100 ms at p95, and the system can tolerate suggestions being up to 5 minutes stale.

Sometimes the technology really is a constraint. But in interviews, ask why the technology is required. This shows architectural maturity.

Functional Requirements and Domain Modeling

Functional requirements often reveal domain concepts.

Example:

Customers can place orders.
Admins can approve refunds.
Inventory is reserved during checkout.
Payments can be captured or refunded.
Orders can be shipped in multiple packages.

Possible domain model:

Customer
Order
OrderLine
InventoryReservation
Payment
Refund
Shipment

Functional requirements help identify aggregates, entities, workflows, commands, domain events, and business rules.

Nonfunctional requirements then shape the implementation approach.

Example:

Inventory reservation must prevent overselling under high concurrency.

This may influence transaction design, locking, consistency, and database constraints.

Nonfunctional Requirements and Architecture Patterns

NFRs often point toward architecture patterns.

Patterns should be selected because they satisfy requirements, not because they are trendy.

Example: Requirements for a Notification System

Functional requirements:

Users can choose notification preferences.
The system sends email notifications.
The system sends SMS notifications.
The system sends push notifications.
Admins can view notification delivery status.
The system retries failed notifications.

Nonfunctional requirements:

Notifications should be delivered within 1 minute for 95% of normal events.
The system must handle 500,000 notifications per day.
Failed notifications must be retried up to 3 times with exponential backoff.
Notification content must not expose sensitive data in logs.
Users must be able to opt out of marketing notifications.
Delivery attempts must be auditable for 1 year.

Design implications:

• Use queue-based processing.
• Use provider adapters.
• Use retry and dead-letter handling.
• Store delivery status.
• Use templates and localization.
• Add observability.
• Add opt-out rules.
• Add audit storage.

Example: Requirements for a Chat Application

Functional requirements:

Users can send messages.
Users can receive messages in real time.
Users can create group chats.
Users can upload attachments.
Users can see message history.
Users can mark messages as read.

Nonfunctional requirements:

Messages should be delivered within 500 ms at p95 for online users.
Message history must be durable.
The system must support 1 million daily active users.
Attachments must be scanned for malware.
Messages must be encrypted in transit.
The system must handle temporary disconnects and reconnect users automatically.
Read receipts can be eventually consistent.

Design implications:

• WebSockets or real-time messaging.
• Persistent message store.
• Message broker or event stream.
• Presence service.
• Attachment storage.
• Background scanning.
• Horizontal scaling.
• Eventual consistency for read receipts.

Example: Requirements for a Reporting System

Functional requirements:

Users can request monthly reports.
Users can download completed reports.
Admins can schedule recurring reports.
The system emails users when reports are ready.
Users can filter reports by date range and department.

Nonfunctional requirements:

Report requests must return immediately with 202 Accepted.
95% of monthly reports must complete within 10 minutes.
The report worker must retry transient failures.
Large reports must not block API request threads.
Reports must be retained for 90 days.
Only authorized users can download reports.
Report generation failures must be visible in monitoring.

Design implications:

• Async background jobs.
• Queue.
• Worker service.
• Blob/object storage.
• Status table.
• Authorization checks.
• Retry and dead-letter.
• Monitoring dashboard.
• Expiration cleanup job.

Requirements and Consistency

Consistency is often a nonfunctional requirement.

Example:

When a user completes payment, the order status must not show "Unpaid" after confirmation.

This may require strong consistency between payment and order status.

Other cases can use eventual consistency.

Example:

Product recommendation updates can lag behind purchases by up to 15 minutes.

This allows async processing and simpler scaling.

In interviews, ask:

Which data must be immediately consistent?
Which data can be eventually consistent?
What is the acceptable delay?
What happens if the user sees stale data?

Consistency requirements strongly shape system design.

Requirements and Security

Security can be functional and nonfunctional.

Functional security requirement:

Admins can assign roles to users.
Users can change their password.
The system logs out users after password change.

Nonfunctional security requirement:

Passwords must be hashed using an approved password hashing algorithm.
Sensitive data must be encrypted in transit and at rest.
Admin actions must be audited.
Authentication tokens must expire after a defined period.
The system must rate-limit login attempts.

Security requirements must be explicit. "Secure" is not enough.

Requirements and Compliance

Compliance requirements often appear as constraints or nonfunctional requirements.

Examples:

Customer records must be retained for 7 years.
Users must be able to request data deletion where legally allowed.
Audit logs must be immutable.
Data must remain in a specified geographic region.
Access to regulated data must be logged.
The system must support export of personal data.

Compliance can affect:

• Data model.
• Storage location.
• Retention policies.
• Encryption.
• Audit logging.
• Access control.
• Backup strategy.
• Deletion workflows.
• Vendor selection.
• Operational processes.

In interviews, compliance requirements are especially important for finance, healthcare, insurance, government, education, and payment systems.

Requirements and Cost

Cost can be a nonfunctional requirement.

Examples:

The monthly cloud cost for the MVP must stay under $2,000.
The system should use serverless services where possible to reduce idle cost.
The archive storage tier may be used for data older than 1 year.

Cost requirements create trade-offs.

Example:

Requirement:
99.99% availability across regions.

Trade-off:
Multi-region active-active deployment increases cost and complexity.

A strong architect does not ignore cost. The best design is not always the most scalable design. It is the design that meets requirements within constraints.

Requirements and Operational Readiness

Operational requirements define how the system is supported in production.

Examples:

The system must expose health check endpoints.
The system must emit structured logs.
The system must include dashboards for error rate, latency, and throughput.
Critical alerts must notify the on-call engineer within 5 minutes.
Deployments must support rollback.
Database backups must be tested monthly.

These are nonfunctional requirements because they define how the system is operated and supported.

They are often missed during early design but are critical for production systems.

Quality Attribute Scenarios

A quality attribute scenario makes an NFR concrete.

Template:

Source: Who or what triggers the scenario?
Stimulus: What happens?
Environment: Under what conditions?
Artifact: What part of the system is affected?
Response: What should the system do?
Response measure: How will success be measured?

Example:

Source:
A customer

Stimulus:
Submits an order

Environment:
Peak traffic, 1,000 concurrent users

Artifact:
Checkout API and order database

Response:
The system validates the order, reserves inventory, creates the order, and returns confirmation

Response measure:
p95 response time <= 1 second, error rate < 0.1%

This is much better than "checkout should be fast."

Example Requirement Decomposition

High-level request:

Build a file-sharing system.

Functional requirements:

Users can upload files.
Users can download files.
Users can share files with other users.
Users can revoke access.
Users can view upload and download history.
Admins can manage storage limits.

Nonfunctional requirements:

Files up to 5 GB must be supported.
Uploads must resume after interruption.
Download links must expire after 24 hours.
Files must be encrypted at rest.
Access must be audited.
The system must support 10,000 downloads per hour.
The service must be available 99.9% monthly.
Virus scanning must complete before files are available for download.

Architecture implications:

Use object storage.
Use metadata database.
Use background scanning.
Use signed download URLs.
Use audit logging.
Use queue-based processing.
Use CDN if download traffic is high.
Use encryption and key management.
Use resumable/chunked upload.

This example shows how requirements decomposition turns an idea into architecture.

Common Mistakes

Common mistakes include:

• Treating nonfunctional requirements as optional.
• Writing vague NFRs such as "fast", "secure", or "scalable".
• Focusing only on features and ignoring production qualities.
• Confusing a solution with a requirement.
• Not asking about scale, availability, security, and compliance in system design interviews.
• Assuming all data must be strongly consistent.
• Assuming all features need the same availability target.
• Not prioritizing requirements.
• Not identifying architecturally significant requirements.
• Not measuring NFRs.
• Not mapping requirements to tests.
• Not considering cost trade-offs.
• Writing requirements that are impossible to verify.
• Over-engineering for imaginary NFRs.
• Under-engineering by ignoring likely growth or failure modes.
• Treating "microservices", "Kafka", or "Kubernetes" as requirements without understanding the underlying need.
• Ignoring operational requirements such as logging, monitoring, and backup.
• Forgetting data retention, privacy, and audit requirements.
• Not clarifying MVP vs future requirements.

Best Practices

Separate functional requirements from nonfunctional requirements during discovery.

Ask clarifying questions before designing.

Make nonfunctional requirements measurable.

Identify architecturally significant requirements early.

Connect requirements to business goals.

Distinguish real constraints from preferred solutions.

Prioritize requirements.

Document trade-offs explicitly.

Use quality attribute scenarios for important NFRs.

Define acceptance criteria for both functional and nonfunctional requirements.

Map requirements to tests and monitoring.

Validate NFRs with realistic tests, not assumptions.

Do not over-engineer for requirements that do not exist.

Do not ignore critical security, reliability, compliance, and data integrity requirements even in MVP.

Review requirements with stakeholders, developers, testers, operations, security, and product owners.

Treat requirements as living information that can evolve, but protect critical architecture decisions with clear rationale.