Software Engineering Principles and Practices / Software Requirement Engineering

Types of Requirement

Requirements are generally split into three main levels: User, System, and Software. However, the most critical distinction for an engineer is between Functional and Non-Functional.


🛠️ Functional Requirements (The "What")

Functional requirements describe the services the software must provide. They define the specific behavior, tasks, and data processing the system must perform.

  • Definition: What the system should do in response to specific inputs.

  • Format: Usually written as "The system shall [do something]."

  • Examples:

    • "The system shall allow users to search for products by category."

    • "The system shall send a confirmation email after a successful purchase."

    • "The system shall allow the admin to delete user accounts."


🚀 Non-Functional Requirements (The "How")

Also known as Quality Attributes or "The -ilities." These don't describe what the system does, but rather the constraints or standards under which it operates.

  • Definition: How the system performs its functions.

  • Categories:

    • Performance: How fast is it? (e.g., "Page must load in < 1s").

    • Scalability: Can it handle 1 million users?

    • Security: Is the data encrypted?

    • Availability: Does it run 24/7 (99.9% uptime)?

    • Usability: Is it easy for a non-technical person to use?


🏢 User vs. System Requirements

We also classify requirements based on who is reading them:

  1. User Requirements: High-level statements in natural language (plain English) for the customers and end-users. They describe the goals from a business perspective.

  2. System Requirements: Detailed descriptions of the software’s functions, services, and operational constraints. Written for developers and testers. These are more technical and precise.


🛡️ Domain Requirements

These are requirements that come from the specific industry or "domain" the software is being built for. They are often not requested by the user because the user assumes you already know them.

  • Example (Banking): "The system must follow federal anti-money laundering regulations."

  • Example (Medical): "The system must comply with HIPAA privacy standards."


📊 Summary: Functional vs. Non-Functional

Feature

Functional

Non-Functional

Focus

User tasks / Features

System properties / Constraints

Requirement

Mandatory for the app to work.

Mandatory for the app to be good.

Evidence

Easy to test (Yes/No).

Measured by metrics (Seconds, %, etc.).

Analogy

A car must have an engine and wheels.

A car must be safe and fuel-efficient.