Requirements Analysis Basics: Where Requirements Come From, and How Requirements Differ from Features and Solutions
"Requirements analysis" is one of the most used phrases among product and engineering teams, yet beginners often wonder: what exactly is a requirement? Where does it come from? Can "requirement", "feature", and "solution" be used interchangeably? This article clears it all up.
1. What Is a Requirement
A requirement is essentially "a role, in a specific scenario, wanting to achieve a specific goal". It describes a problem, not a solution.
Example: a user says "I want to quickly see today's stock movement on my phone". That is a requirement (role: user; scenario: on the commute; goal: quickly get price movement). It does not dictate "what interface or how to display it".
A quick way to test whether something is a requirement is to fill this template: "As (who), I want (what), so that (goal)". If you cannot fill all three, the requirement is probably not thought through. For a more formal format, see User Stories and Acceptance Criteria.
2. Where Requirements Come From
Requirements come from roughly three sources, and none should be neglected:
- Users: interviews, feedback, usage data, support tickets. This is the most direct and the most overlooked source — many teams decide "what users need" instead of asking them. Methods: Requirements Gathering and User Research.
- Business: the boss's KPIs, sales targets, operations asks, and compliance requirements. Business requirements answer "why the company should do this".
- Competitors and industry: what competitors shipped and where the market is heading. Competitive analysis tells you whether a demand validated by others is worth following.
The three sources often reinforce each other: users want it, business sees value, and competitors prove it is feasible — that is a requirement worth investing in.
3. Requirement ≠ Feature ≠ Solution
This is the set beginners mix up most. An example:
- Requirement: a user who orders late at night wants to know where the order is (a problem to solve).
- Feature: an order tracking page plus logistics status push (the capability designed to meet the requirement).
- Solution: use a third-party logistics API for real-time query plus in-site notifications (how to do it).
The same requirement can map to different features, and the same feature can be built with different solutions. The requirement has the highest priority; the solution is decided last. Skipping requirements and jumping to solutions most often produces "a flashy feature nobody uses". For the categories of requirements (business, user, functional, non-functional), see Functional vs Non-Functional Requirements.
4. The Full Requirements Analysis Process
Requirements analysis is not "ask around and write it down"; it is a disciplined pipeline:
- Gather: collect raw requests via interviews, surveys, data, and feedback — cast wide first;
- Clarify: use the 5W1H (who, when, where, what, why, how) to turn vague statements into describable problems;
- Break down and classify: split large requirements into items and separate functional from non-functional;
- Prioritize: rank with value x cost or MoSCoW (Must/Should/Could/Won't) — see Requirement Prioritization Frameworks;
- Document: fix the conclusions in a PRD — see PRD Writing Guide;
- Review: walk through with product, engineering, QA, and business to confirm shared understanding;
- Track: requirements change during development; manage them with a traceability matrix — see Requirements Change Management.
Not every project needs every step, but "gather → clarify → prioritize → review" is unavoidable everywhere.
5. One Table for the Concepts
| Concept | Answers | Example |
|---|---|---|
| Requirement | What problem does the user solve | Know where an order is |
| Feature | What capability to provide | Order tracking + push |
| Solution | How to implement it | Logistics API + in-site message |
| Scope | How much to build this time | Tracking only for now |
6. FAQ
Q1: Is requirements analysis only the product manager's job? No. Product organizes and decides, but engineering assesses feasibility, QA defines acceptance, and business confirms value. It is a collaborative activity.
Q2: Is what the user says the requirement? What the user says is an "ask"; the underlying problem is the requirement. A user asking for "a big red button" may really need "an easier way to find the checkout entry".
Q3: Too many requirements to build — what then? Prioritize: look at value, cost, and risk. Do the "must or we die" items first, then the "nice to have".
Q4: Small team with no product role — do we still need analysis? Even more so. Small teams have limited resources; analysis puts scarce effort where it counts, avoiding building something nobody wants.
7. Summary
One line: a requirement is "the problem to solve", a feature is "the capability", and a solution is "how" — don't mix them; requirements come from users, business, and competitors, and moving through gather–clarify–prioritize–review keeps you on target. To study requirements analysis systematically, bookmark the Requirements Analysis category.