Types of requirements, with examples

Published 22 October 2026

Requirements come in types because they answer different questions: why the project exists (business requirements), what users need to do (user requirements), what the system does (functional requirements), how well it does it (non-functional requirements), and which rules, interfaces and constraints it has to respect. Below are the types with one example each from the same project, how the common classifications line up, how to tell a type from what someone says, requirements vs specifications, user vs system requirements, and where each type is written down.

People don’t just tidily tell you, “Here are all my business rules, here are all my use cases” and so forth. Instead, the business analyst is bombarded with a more or less random array of information.

— Karl Wiegers, Software Requirements: Classifying Customer Input

Types of requirements in software engineering, with examples

Every example comes from the customer portal used across these templates, where customers see and pay their company’s invoices.

The first four are a chain: the business requirement says why, the user requirement who needs what, the functional requirement what the portal does about it, the non-functional one how well. The rest apply across the chain, and most of them come from outside the project — the finance department’s policies, the accounting system, the law.

How the classifications line up

There is no single standard list. Two common ones, next to the names this page uses:

Wikipedia’s article on requirements attributes its scheme to the IIBA’s Business Analysis Body of Knowledge (BABOK), and defines transition requirements as “required only to enable the transition from the current state of the enterprise to the desired future state, but that will thereafter no longer be required”. Wiegers describes “nine common requirement categories” in his two articles on classifying what customers say. Systems engineering, following ISO/IEC/IEEE 15288, speaks of stakeholder requirements and system requirements (below).

The names matter less than keeping the types apart: a business rule written as a functional requirement is found only by reading the code.

How to tell which type a requirement is

Wiegers’ cues for what you hear in a conversation, with what it usually is:

The last row is not a requirement at all. “Much of what users present as requirements fits in the category of solution ideas,” Wiegers writes, and “The BA needs to probe below the surface of a solution idea to get to the real requirement.” In the portal, “put a Pay button on every invoice row” is a solution idea; the requirement behind it is FR-014, and the Billing-role rule decides who sees the button.

Requirements vs specifications

The accepted answer to a question viewed over 200,000 times on Software Engineering Stack Exchange: “The sound-bite answer is that requirements are what your program should do, the specifications are how you plan to do it.” And: “Specifications and requirements roughly communicate the same information, but to two completely different audiences” (Stack Exchange, 2011). Another answer adds the catch: “In many places these documents are not separate and are used interchangeably” (Stack Exchange).

In this site’s templates, the BRD and the user stories are requirements; the functional specification, the SRS and the technical specification are specifications, in that order from the user’s view to the developer’s. FR-014 is a requirement; how the portal hands the payment to the provider’s hosted page is in the technical specification.

User requirements vs system requirements

In systems engineering, a system requirement is “A statement that transforms the stakeholder, user-oriented view of desired capabilities into a technical view, of a solution that meets the operational needs of the user” (ISO/IEC/IEEE 15288, via SEBoK). One Stack Exchange answer puts it in Ian Sommerville’s terms: “User requirements talk about the problem domain, the world of the user”, while “System requirements talk about the solution domain, the world of the software logic” (Stack Exchange, 2014).

The difference shows in what the system can promise. The finance team needs overdue invoices paid. The system requirement is FR-016: one reminder, seven days after the due date. The portal can send the reminder; it cannot make the customer pay. That is why the business requirement is measured separately, in days from invoice to payment.

Business, functional and non-functional requirements

A business requirement stays true whatever the software looks like; a functional requirement is one way the software meets it. The BRD template has the table that links them. Functional requirements say what the system does, non-functional ones how well — the non-functional requirements examples page has the full list of quality types.

Some teams split non-functional requirements further into operational and technical ones. One answer explains why they are often grouped together instead: they are grouped as non-functional “mainly to stop silly arguments as to whether ‘system will respond to a user request within 1 second’ is an operational or technical requirement” (Stack Exchange).

Business rules, constraints and assumptions

Three things that are often written as requirements and are not quite:

• A business rule is a policy that exists without the software: only the Billing role can pay. “As stated, though, business rules are not functional requirements,” Wiegers writes; functional requirements enforce them. Keep rules in a list of their own, with a prefix of their own (RULE-07 in the functional specification), because they change when the policy does. More in business rules vs requirements.
• A constraint limits how the requirements may be met: card data is never stored by the portal. “It’s a good idea to record the rationale behind each constraint,” because a constraint without a reason is hard to question when it stops being true.
• An assumption is something taken as true, not demanded: the client opens the payment provider account by 15 February. If it turns out false, the requirements or the plan change. The project scope statement has a place for them.

Where each type of requirement is written down

Wiegers’ own choice for the first row: “I like to document business requirements in a vision and scope document or a project charter.” The vision and scope document template follows his structure. On an agile team, the same types live in the backlog and around it: user stories carry the functional requirements, the definition of done carries some of the non-functional ones, and the product goal carries the business requirement.

Why the types matter when requirements change

Each type changes for a different reason and is decided by a different person. The finance department changes a business rule; the client changes a business requirement; the team changes a specification. When the part payments change (CR-10) arrived, it started as a business need — large invoices stayed on bank transfer — and reached six functional requirements, a data definition and an interface; the change impact analysis shows the chain. Requirements kept apart by type, and linked from each type to the next, are what make that chain possible to follow; the traceability matrix is where the links are kept.

Where Specroot fits

This is the problem Specroot works on: requirements of every type kept linked to the ones they come from, so that when a goal, a rule or a constraint changes, the requirements and the work built on it are found. Specroot for agencies and consultancies.