In software engineering, requirements form the bedrock of the development lifecycle. A requirement is a description of how a system must behave, a service it must perform, or a constraint on its operation . These requirements are traditionally documented in a Software Requirements Specification (SRS) to align stakeholders, developers, and testers.

Requirements are broadly divided into two foundational categories:

1. Functional Requirement (FR) — representing what the system must do.
2. Nonfunctional Requirement (NFR) — representing how well the system must perform those behaviors .

The Architectural Relationship

While functional requirements describe the active business logic, nonfunctional requirements act as systemic constraints that cross-cut and shape the entire software architecture .

Deep Dive: Functional Requirements (FR)

Functional requirements define the specific actions, calculations, data processing steps, and workflows that a system must execute . They are highly dynamic and map directly to user interactions.

Common Categories of Functional Requirements:

• Authentication & Authorization: "The system shall verify user credentials against the database and assign roles."
• Data Entry & Validation: "The system shall validate that the user's email address contains an '@' symbol before submitting the registration form."
• Reporting & Analytics: "The system shall generate a monthly PDF financial report on the first day of every month."

Deep Dive: Nonfunctional Requirements (NFR)

Nonfunctional requirements, often referred to as "quality attributes" or the "-ilities" , do not provide direct functional utility to the user in isolation. Instead, they specify the operational criteria and environmental constraints under which the functional requirements must run .

Key Categories of Nonfunctional Requirements:

• Performance
• Security
• Reliability
• Usability
• Quality Attribute
• Scalability

Differentiating FRs and NFRs: Observable Criteria

To distinguish between functional and nonfunctional requirements, engineers use several observable criteria:

1. Scope of Impact: FRs are usually localized to specific modules or actions (e.g., a checkout button). NFRs are global and cross-cutting, affecting the entire system architecture (e.g., database encryption) .
2. Failure Mode: If an FR fails, a specific feature is broken (e.g., cannot reset password). If an NFR fails, the system may still work but becomes unusable, insecure, or slow (e.g., page takes $30\\text{ seconds}$ to load) .
3. Measurement: FRs are binary (either the feature exists or it does not). NFRs are evaluated along a continuous spectrum using quantitative metrics.

Writing Measurable Nonfunctional Requirements

A common pitfall in software engineering is writing vague NFRs. Statements like "The system must be fast" or "The portal should be highly secure" are subjective and untestable. To make NFRs measurable, we must specify precise metrics and thresholds .

Mathematical Modeling of Nonfunctional Metrics

Let's express some key NFR metrics mathematically:

• Availability ($A$): $A = \\frac{\\text{MTBF}}{\\text{MTBF} + \\text{MTTR}} \\times 100\\%$ where $\\text{MTBF}$ is the Mean Time Between Failures and $\\text{MTTR}$ is the Mean Time To Repair . A typical requirement might state: "The system shall achieve $99.9\\%$ availability ($A \\ge 0.999$)."
• Throughput ($T$): $T = \\frac{N}{t}$ where $N$ is the number of processed transactions and $t$ is the time interval. For example: "The system shall support a minimum throughput of $T \\ge 1500\\text{ transactions per second}$ (TPS)."

The chart above illustrates why getting requirements right—and making them testable—is critical. A defect introduced during the requirements phase that escapes to maintenance can cost up to $150\\times$ more to fix than if it were resolved immediately .

To avoid these costly errors, every requirement must be evaluated against strict quality parameters:

• Testability
• Ambiguity

Application: Requirements for a Library Management System (LMS)

To solidify these concepts, let's look at a practical scenario. Suppose we are building a digital Library Management System (LMS).

Scenario-Based Functional Requirements (FRs)

1. LMS-FR-01 (Book Checkout): "The system shall allow registered members to check out books by scanning the book's barcode, provided the member has no outstanding overdue fines."
2. LMS-FR-02 (Catalog Search): "The system shall allow users to search for books by entering the title, author, or ISBN."
3. LMS-FR-03 (Overdue Notification): "The system shall automatically generate and email an overdue notice to members exactly 24 hours after their checkout period expires."

Scenario-Based Nonfunctional Requirements (NFRs)

1. LMS-NFR-01 (Performance): "The catalog search query shall return matches and render results on screen within $1.5\\text{ seconds}$ for a database containing up to $100,000$ book records."
2. LMS-NFR-02 (Security): "All member passwords stored in the database shall be salted and hashed using the bcrypt algorithm with a work factor of $12$."
3. LMS-NFR-03 (Reliability): "The system shall maintain a mean time between failures ($\\text{MTBF}$) of at least $720\\text{ hours}$ of continuous operation."