Requirement Gathering: Functional, Non-Functional, and Success Criteria

Once the problem is understood, the next step is turning it into requirements — a crisp list of what the solution must do, how well it must do it, and what lines it can't cross. This tutorial covers gathering requirements, the functional / non-functional split, and the success criteria and constraints that keep a project honest.

Table of Contents

• What Is Requirement Gathering?
• Where Requirements Come From
• Functional Requirements
• Non-Functional Requirements
• Functional vs. Non-Functional
• Defining Success Criteria
• Identifying Constraints

What Is Requirement Gathering?

Requirements are clear, testable statements of what a solution must do and how well it must do it. Gathering means pulling those statements out of stakeholders, existing systems, and the discovery work you've already done — then converting wants into statements you could actually test.

Why it matters: the requirements list is the contract between you and the customer. When ambiguity strikes mid-build — and it will — this list is the tie-breaker everyone agreed to earlier, when it was cheap to fix.

Note: gathering is not transcription. You're not copying what people say; you're turning "make it faster" into a threshold, and "we want everything integrated" into a list of systems and what happens between them. Pushing back on vague requests is part of the job.

Where Requirements Come From

The usual sources, roughly in order of usefulness:

• Stakeholders — but always verify their claims against the people doing the daily work (the buyer vs. the user problem from the discovery tutorial).
• Existing workflows and process maps — the mapped process tells you exactly what the new system must support (see the workflows tutorial).
• The problem statement and pain points — each confirmed pain generates one or more requirements.
• System evidence — logs, historical data, edge cases someone hit a hundred times.
• Rules and regulations — legal, security, and industry rules that are non-negotiable.

The pattern: you gather from people, cross-check against evidence, and the requirements list becomes the build's backbone.

Functional Requirements

A functional requirement describes behavior — something the system does. It's a sentence testable with yes/no: either the system does it or it doesn't.

Functional requirements usually take the form "The system shall ..." and each one should be checkable:

• The system shall display a unified customer view combining data from all three source systems.
• The system shall auto-assign incoming tickets by team-capacity ratio.
• The system shall send an email alert when a ticket is unassigned for more than 4 hours.
• The system shall flag a ticket as reopened when the customer replies after resolution.

Explanation: each of these is a behavior you could write a test for. The first one is a little soft, though — "unified customer view" could mean ten things. That's when you push it down: which fields, from which systems, how fresh? A good functional requirement is specific enough to test and to build against without guessing.

Common Mistake: writing solution-shaped requirements. "Use a chatbot" is a solution; "answer 80% of common questions without a human" is a requirement that leaves room for the right implementation. Requirements should say what, not how.

Non-Functional Requirements

Non-functional requirements describe quality attributes — how well the system behaves. Nobody asks for them directly, but everyone notices when they're violated: the page that loads in nine seconds, the system that's down at the worst moment, the data leak.

A real project typically writes these as a short block:

• Performance:      p95 dashboard load < 2 seconds.
• Reliability:      99.5% availability during business hours.
• Security:         role-based access; API keys never written to logs.
• Compliance:       customer data stays in the EU region.

Explanation: these aren't behaviors, they're the standards behaviors must meet. Ship functional requirements alone and you get software that works but is unusably slow, unsafe, or illegal. They're not optional finishing touches.

Functional vs. Non-Functional

One quick comparison to keep the split straight:

Same feature, two requirements: "the system shall send an alert" (functional) and "the alert arrives within one minute" (non-functional). You need both sentences on the list.

Defining Success Criteria

A success criterion is a measurable condition that says the solution works. Typically one per major requirement, and it must connect back to the business numbers from discovery — otherwise you're measuring effort, not success.

The chain from business to success criterion:

Each criterion is metric + threshold + timeframe. "The solution works if..." is a sentence you could run a test against:

The solution is successful when:
• 90% of tickets are first-answered within 4 business hours.
• Agent time per ticket drops from 45 minutes to 15 minutes.
• Reopened tickets stay below 10%.
• No manual copying between the three systems.

Common Mistake: accepting "users like it" as success. "Done" must be checkable. By the end, the customer should be able to look at the list and say "yes, if all four of those are true, we're done" — that agreement is the whole point.

Best Practice: agree success criteria before building and keep them on a single shared page. They double as your acceptance test and your demo script — the demo shows each criterion being met.

Identifying Constraints

Constraints are the boundaries the solution must live inside — requirements you can't negotiate away. Budget, time, stack, data rules, who's available. They're not obstacles; they're the shape of the problem.

Example constraints from a real engagement look like this:

• Timeline: a usable prototype within 2 weeks.
• Budget: no new paid infrastructure.
• Stack: must integrate with existing Salesforce and the in-house warehouse; neither may be replaced.
• Data: PII must not leave the EU; logs retained 90 days.
• People: one engineer, half-time.

Note: map constraints to why where you can. "No cloud migration (because the security review takes six months)" is far more useful than a bare "no cloud" — if the reason ever changes, the constraint may lift, and knowing why shows you where the real boundary is.

Best Practice: surface constraints as early as the first requirement conversation. A constraint discovered mid-build is the most expensive kind: it can reshape the design, puncture a promise, or force a deliverable to be redone.