Functional and Non-Functional Requirements: What a System Does and How Well

A feature can exist and still be unusable.

A photo-upload button may work in a demonstration but take two minutes, expose private images, fail on mobile, and lose files during a restart.

Functional requirements describe what a system does. Non-functional requirements describe the qualities and constraints under which it must do it.

Both shape the design. The phrase "non-functional" does not mean unimportant or optional.

A concrete example: photo upload

Functional requirements:

• A signed-in user can select a photo.
• The system accepts supported image formats.
• The user can remove an uploaded photo.

Quality requirements:

• A 10 MB upload completes within five seconds for 95% of users on a defined connection.
• Only the owner and explicitly authorized viewers can access it.
• The service preserves accepted uploads through a server failure.
• The flow is operable with keyboard and screen reader.

Without the second group, teams can produce incompatible ideas of "done."

Functional requirements describe capabilities

Functional requirements include:

• Create an account
• Search products
• Approve an expense
• Calculate tax
• Export a report
• Send a notification
• Restore a previous document version

They often describe:

Given a state and input,
when an action occurs,
then an observable outcome follows.

Functional behavior should include normal paths, validation, errors, permissions, and state transitions.

"Process payment" hides many functions: authorize, capture, decline, refund, reconcile, and handle duplicate requests.

Performance requirements

Performance can involve:

• Response latency
• Throughput
• Startup time
• Batch duration
• Resource use
• User-perceived rendering

"The page must be fast" is not testable.

A stronger requirement says:

The search API returns the first page within 300 milliseconds at the 95th percentile under 500 requests per second using the agreed production dataset.

This names the operation, threshold, percentile, load, and environment.

Averages are often insufficient because they hide slow experiences.

Availability and reliability

Availability defines when a service must be usable.

Reliability can include:

• Successful request rate
• Data durability
• Correctness over time
• Recovery behavior
• Frequency of failure

An objective might say:

Checkout completes successfully for 99.9% of valid attempts over a rolling 28-day window, excluding documented customer-side failures.

The measure must reflect user value. A server returning 200 OK while failing to save the order is technically responsive and functionally unavailable.

Security requirements

"The system must be secure" is too broad.

Specific security requirements include:

• All administrative access requires phishing-resistant MFA.
• Customers can access only records belonging to their account.
• Data is encrypted in transit using supported TLS configurations.
• Secrets never appear in source repositories or logs.
• Privileged actions are recorded in tamper-resistant audit logs.
• Critical vulnerabilities are remediated within a defined time.

Security requirements follow threat and impact analysis.

They should define verifiable controls and outcomes, not merely name a security product.

Privacy requirements

Privacy requirements can state:

• Which personal data may be collected
• Purpose of collection
• Retention period
• Who can access it
• Where it may be processed
• How users can correct or delete it
• Which secondary uses are prohibited

For example:

Precise location is used only during an active delivery and is deleted from the operational system after 30 days unless a legal hold applies.

Privacy changes architecture because data that is never collected or is automatically deleted cannot later leak from an unnecessary archive.

Accessibility requirements

Accessibility is a quality of functional access.

Requirements may include:

• Keyboard operation
• Screen-reader semantics
• Sufficient contrast
• Captions and transcripts
• Visible focus
• Zoom and reflow
• Error identification
• Reduced-motion support

Referencing an accessibility standard helps, but teams should also test real workflows with assistive technologies and users.

A feature inaccessible to part of its intended audience is functionally incomplete for them.

Scalability and capacity

Scalability requirements define expected growth:

• Concurrent users
• Data volume
• Request rate
• Geographic distribution
• Peak-to-average ratio

Example:

The service supports ten times normal read traffic during ticket release without duplicate reservations and recovers to normal latency within five minutes after the peak.

Capacity numbers need time horizons and assumptions.

Building for one billion users when evidence suggests ten thousand adds complexity. Ignoring a known seasonal peak creates predictable failure.

Maintainability and operability

Quality also affects people who build and operate the system.

Requirements can include:

• A failed deployment can be rolled back within ten minutes.
• Configuration changes are versioned and reviewed.
• Services expose health and diagnostic metrics.
• A new supported tax rule can be added without changing checkout presentation code.
• On-call staff can identify the failed dependency from one alert and trace.

These qualities are harder to measure than API latency, but concrete operational scenarios make them testable.

Maintainability is not simply "clean code." It is the cost and safety of expected change.

Compatibility and portability

Compatibility requirements define supported environments:

• Browsers
• Mobile operating systems
• Screen sizes
• File formats
• API versions
• Hardware
• External systems

"Works on mobile" should identify devices, operating-system versions, orientations, and critical workflows.

Support has cost. Teams need a policy for adding and retiring environments, informed by users and obligations.

Portability should be justified by a real migration or deployment need rather than an abstract desire to run everywhere.

Compliance and auditability

Regulated systems may need:

• Data residency
• Approval separation
• Audit retention
• Consent records
• Reproducible calculations
• Evidence of access review
• Documented change control

Compliance is not identical to security or privacy. It defines obligations, while real risk may require additional controls.

Requirements should connect a rule to system behavior and evidence.

A checkbox without retrievable proof may fail both an audit and an incident.

Cost and sustainability

Cost is a quality constraint.

Examples:

• Monthly infrastructure remains under a defined budget at expected load.
• Cost per completed transaction stays below a threshold.
• Archival data moves to lower-cost storage after 90 days.

Energy, hardware use, and carbon goals can also shape design.

Optimizing latency by running maximum capacity continuously may violate cost and sustainability requirements.

Architecture balances several qualities rather than maximizing one.

Quality attributes interact

Improving one quality can affect another:

• Encryption consumes processing and complicates recovery.
• Strong consistency can reduce availability during network partitions.
• Aggressive caching improves speed but reduces freshness.
• Detailed logging improves diagnosis but can expose private data.
• More redundancy improves availability but raises cost.

Requirements should state priorities and acceptable tradeoffs.

Architecture cannot optimize every quality without limit.

Make requirements measurable

A useful quality requirement includes:

• Subject
• Metric
• Target
• Conditions
• Measurement window
• Exclusions
• Evidence source

Compare:

The app should load quickly.

with:

The main product page reaches its agreed visual-complete state within
2.5 seconds at the 75th percentile for mobile users on the defined
network profile.

The second can guide design, testing, monitoring, and prioritization.

Scenarios expose architecture implications

A quality-attribute scenario asks:

• Source of stimulus
• Stimulus
• Environment
• Affected component
• Expected response
• Measurable response

Example:

During normal operation, if one application instance fails, the load balancer removes it within 30 seconds, active requests may fail once, and new requests continue through healthy instances.

This reveals requirements for health checks, redundancy, retries, and monitoring.

Avoid requirement catalogs without priority

A project can list every desirable quality:

• Fast
• Available
• Secure
• Flexible
• Portable
• Cheap
• Easy to maintain

That list does not guide decisions.

Identify the few architecture-driving qualities and their thresholds.

A medical device, social feed, batch report, and game have different priorities.

The purpose of quality requirements is to make tradeoffs explicit before accidental design choices make them for you.

Knowledge check

1. How do functional and non-functional requirements differ?
2. Why is average response time often a weak performance target?
3. Give one measurable security requirement.
4. How can privacy requirements change data architecture?
5. Why must quality attributes be prioritized rather than merely listed?

The one idea to remember

A feature is not complete because it exists. Functional requirements define capability; quality requirements define the speed, safety, reliability, accessibility, cost, and operating conditions that make the capability genuinely useful.