Requirements Analysis & Specification

Functional vs Non-Functional Requirements

18 min Lesson 1 of 10

Functional vs Non-Functional Requirements

Every software system must do two things well: it must do the right things, and it must do them properly. These two concerns map directly onto the two most fundamental categories in requirements engineering — functional requirements and non-functional requirements. Mastering this distinction is the first step toward writing requirements that developers can build from, testers can verify, and stakeholders can trust.

What Are Functional Requirements?

A functional requirement describes a specific behaviour or function that the system must perform. It answers the question: "What must the system do?" Functional requirements define inputs, outputs, and the transformation that happens in between.

Consider a clinic booking system. Its functional requirements might include:

  • A patient shall be able to search for available appointments by doctor, specialty, and date.
  • The system shall send an SMS confirmation within 60 seconds of a successful booking.
  • A receptionist shall be able to cancel an appointment up to two hours before the scheduled time.
  • The system shall prevent a doctor from being double-booked for the same time slot.

Each of these statements describes a capability. If the system cannot search for appointments, it has failed a functional requirement — full stop. The deficiency is binary: either the feature works or it does not.

What Are Non-Functional Requirements?

A non-functional requirement (NFR) describes a quality attribute of the system — how well it must perform its functions. NFRs answer: "How must the system behave?" They are sometimes called quality attributes or system qualities.

Using the same clinic booking system, non-functional requirements might be:

  • Performance: The appointment search results page shall load in under 2 seconds for 95% of requests under normal load (up to 500 concurrent users).
  • Security: Patient medical records shall be encrypted at rest using AES-256 and in transit using TLS 1.3 or above.
  • Usability: A new receptionist with no prior training shall be able to book an appointment in under 3 minutes after a one-hour onboarding session.
  • Availability: The booking portal shall maintain 99.9% uptime, excluding scheduled maintenance windows.
  • Scalability: The system shall support growth from 10,000 to 100,000 registered patients without architectural changes.

Notice that none of these statements adds a new feature. They all constrain how existing features must work. A slow search that returns correct results still violates the performance NFR. An insecure system that books appointments correctly still violates the security NFR.

Key distinction: Functional requirements define what the system does. Non-functional requirements define how well it does it. You need both. A system that is functionally complete but unusably slow, or fully featured but insecure, is a failed system.
Functional vs Non-Functional Requirements split with examples System Requirements Clinic Booking System Functional What the system does Non-Functional How well it does it Search appointments Send SMS confirmation Prevent double-booking Performance Security Usability Availability Scalability Reliability
Requirements for a clinic booking system split into functional and non-functional categories.

The Major Categories of Non-Functional Requirements

NFRs cover a wide surface area. Every analyst should know these core categories cold:

  • Performance — Response times, throughput, and latency targets. Example: "The checkout page of the online store shall complete payment processing in under 3 seconds for 99% of transactions."
  • Security — Authentication, authorisation, data protection, audit trails. Example: "Only authenticated users with the MANAGER role shall access the salary export function."
  • Usability — Ease of learning, efficiency of use, accessibility. Example: "The logistics driver app shall be usable with a single hand and a gloved finger on a 5-inch screen."
  • Reliability & Availability — Uptime targets, mean time between failures, recovery objectives. Example: "The online store shall tolerate the failure of any single server without user-visible downtime."
  • Maintainability — How easily the system can be updated, extended, or debugged. Example: "Adding a new payment gateway shall require no changes to existing payment processing logic."
  • Scalability — How gracefully the system handles growing load. Example: "The logistics routing engine shall handle 10,000 simultaneous active deliveries."
  • Portability & Interoperability — Ability to run on different platforms and integrate with other systems. Example: "The clinic system shall export appointment data in HL7 FHIR format for hospital integration."
  • Compliance — Regulatory and legal constraints. Example: "The online store shall comply with PCI-DSS Level 1 for all card transactions."

Why the Distinction Matters in Practice

The functional/non-functional split is not just academic — it shapes who you talk to, how you elicit requirements, and when you discover failures.

Functional requirements tend to come from business stakeholders and end users: they know what tasks they need to perform. Non-functional requirements often come from operations teams, security officers, legal/compliance teams, and architects. A clinic manager can tell you they need appointment reminders. Only a security officer will tell you that those reminders cannot contain patient identifiers in plain-text SMS.

Functionally deficient systems are usually caught during user acceptance testing. NFR violations are often silent — a system that degrades under load, leaks data, or becomes unusable on a mobile device may pass all functional tests and still fail in production. This is why NFRs must be specified early, precisely, and with measurable acceptance criteria.

Three axes of NFRs: Performance, Security, and Usability with clinic examples Performance Security Usability Clinic Booking System — example NFRs Search Results Load in < 2 s at 500 concurrent users Measurable ✓ Booking Confirmation SMS within 60 seconds Measurable ✓ Data Encryption AES-256 at rest, TLS 1.3 in transit Measurable ✓ Access Control Role-based; records only to treating doctor Task Completion New receptionist books appt. in under 3 min Measurable ✓ Accessibility WCAG 2.1 AA for all patient-facing screens
Three key NFR categories — Performance, Security, and Usability — illustrated with measurable clinic booking examples.

Common Pitfalls When Identifying Requirements

Even experienced analysts make these mistakes:

  1. Disguised NFRs written as functional requirements. "The system shall be fast" is not a functional requirement — it is a vague NFR. It belongs in the non-functional section with a specific target: "response time shall not exceed 1.5 seconds at the 95th percentile."
  2. Missing NFRs until too late. Developers build for function first. If security and performance requirements are not captured before design begins, retrofitting them is expensive — sometimes requiring a complete re-architecture.
  3. Unmeasurable NFRs. "The system shall be user-friendly" is useless. Every requirement — especially NFRs — needs a measurable acceptance criterion. Replace it with a task completion time, an error rate, a satisfaction score threshold, or an industry standard reference (e.g., WCAG 2.1 AA).
Analyst tip: When reviewing a requirements list, run a quick filter: for every item, ask "Does this describe a feature or a quality?" Features go in the functional section. Qualities go in the non-functional section. If a statement mixes both (e.g., "The payment form shall be secure and fast"), split it into one functional statement and two separate NFRs with measurable criteria.
Pitfall to avoid: NFRs often conflict. A highly secure system (encrypting every field, requiring multi-factor authentication at every step) may violate usability requirements for emergency staff. A maximally scalable architecture may compromise data consistency. Part of your job as an analyst is to surface these tensions early so architects and stakeholders can make informed trade-off decisions — not discover them during a production incident.

Putting It Together: An Online Store Example

Here is a side-by-side view using an online store as the reference system, showing how the two types work together:

  • Functional: A registered user shall be able to add items to a cart and proceed to checkout.
    Non-Functional companion: The cart update action shall complete in under 500 ms for 99% of requests.
  • Functional: The system shall send an order confirmation email after a successful payment.
    Non-Functional companion: Confirmation emails shall be delivered within 2 minutes of purchase in 99.5% of cases.
  • Functional: An admin shall be able to apply a discount code to an order.
    Non-Functional companion: Discount code application shall be restricted to users with the ADMIN or SUPPORT roles (security), and shall not increase checkout completion time by more than 200 ms (performance).

Notice how each functional statement gains depth and verifiability when paired with its NFR companions. This pairing discipline is a hallmark of mature requirements practices and will become natural as you move through this tutorial.

Back to Course System Analysis
Next Lesson Analyzing & Structuring Raw Requirements
Back to Course