Requirements Engineering

Definition: Requirements engineering is the disciplined practice of discovering, analyzing, documenting, validating, and managing what a software system must do and what qualities it must exhibit. It sits at the boundary between the messy human world of stakeholders, regulations, and business goals, and the precise world of design and code. Its output is not merely a list of features but a shared, testable understanding of the problem — one that survives contact with change. When it fails, the system is built correctly and still solves the wrong problem.

Requirements engineering is often mistaken for “writing down what the customer said.” That framing is the source of most of its failures. Stakeholders describe solutions rather than problems, omit what they consider obvious, disagree with each other without realizing it, and cannot articulate the qualities — response time, uptime, recoverability — that they will nevertheless judge the system by. The engineering in requirements engineering is the work of converting that raw material into something buildable and verifiable.

How It Works

Requirements engineering is not a phase you exit. Even in a heavyweight Waterfall Model process, the activities described below recur; the difference between methodologies is how tightly the loop is closed and how formally the output is recorded. The five core activities are elicitation, analysis, specification, validation, and management.

Elicitation: Getting at What People Cannot Tell You

Elicitation is deliberately not called “requirements gathering.” Gathering implies the requirements already exist, fully formed, in someone’s head, waiting to be collected like apples. They do not. Requirements are constructed jointly between analyst and stakeholder, and the analyst’s job is to surface knowledge the stakeholder does not know they have.

Three well-documented phenomena make this hard:

Tacit knowledge. Experts perform tasks fluently precisely because the reasoning has been compiled away. A claims adjuster who has processed forty thousand claims cannot enumerate the rules she applies; she can only apply them. Ask her to describe her job and you will get a sanitized textbook version that omits every exception that actually matters.
Solution bias. Asked what they need, stakeholders answer with an interface. “I need a dropdown with the last twelve months in it.” The underlying requirement — comparing this period against the equivalent period last year — is buried inside a UI proposal that may be a bad one.
Conflicting and political interests. Different stakeholder groups want incompatible things, and the incompatibility is often invisible until you write both requirements on the same page. Finance wants strict approval gates; sales wants one-click quoting. Neither will volunteer that the other exists.

Techniques exist because no single one defeats all three problems:

Technique	What it is good at	Where it fails
Structured interviews	Depth on one stakeholder’s mental model; uncovering motivations and exceptions	Scales badly; captures the interviewee’s bias; misses cross-group conflict
Facilitated workshops (JAD)	Surfacing conflict early, building shared ownership, fast convergence	Dominated by loud voices; expensive in calendar time; needs a skilled facilitator
Direct observation / ethnography	Capturing tacit knowledge and real workarounds people never mention	Slow; observer effect; only reveals the current process, not the desired one
Prototyping and wireframes	Making abstract requirements concrete enough to criticize	Anchors thinking on the prototype; risks premature commitment to a design
Document and system analysis	Regulatory constraints, existing business rules, legacy behavior nobody remembers	Documents drift from reality; codifies obsolete decisions
Surveys and analytics	Breadth across large user populations; frequency data	No follow-up questions; measures the current system, not the needed one
Apprenticing / “walk a mile”	Visceral understanding of pain; credibility with users	Very expensive; limited to observable roles

Skilled practice mixes techniques deliberately. Observe first to build a vocabulary, interview to test hypotheses, prototype to force a decision, and workshop to resolve the conflicts that the first three exposed. A prototype is the single most efficient elicitation instrument ever devised, for one reason: people cannot tell you what they want, but they can tell you instantly and precisely what is wrong with the thing in front of them.

Analysis: Turning Statements into Structure

Raw elicitation output is a pile of overlapping, contradictory, ambiguous sentences at wildly different levels of abstraction. Analysis imposes structure on it.

Classification. Separate business goals from user goals from system requirements from constraints. “Reduce claim processing cost by 20%” is a business objective, not a requirement — but it is the justification for a dozen of them, and losing that link makes prioritization impossible later.
Decomposition. Break coarse statements into individually testable ones. “The system shall support reporting” decomposes into a dozen requirements with different costs, owners, and risks.
Conflict resolution. Identify requirements that cannot both hold. Some conflicts are logical (“only managers may approve” vs “any agent may approve urgent claims”); most are resource conflicts across quality attributes — encryption versus latency, redundancy versus cost, flexibility versus simplicity.
Modeling. Use cases, domain models, state machines, and data flow diagrams expose gaps that prose hides. Drawing the state machine for an order forces someone to answer what happens when a refund arrives for a cancelled order — a question no interview ever produced.
Prioritization. Not all requirements are equal, and treating them as equal is a decision to let the schedule prioritize randomly. MoSCoW (Must / Should / Could / Won’t), Kano analysis, and cost-of-delay ranking all beat a flat list. See Prioritization Frameworks.

Specification: Writing It Down So It Cannot Be Misread

A specification is a contract with the future — with the developer six months from now, the tester who never attended the workshop, and the auditor who arrives three years later. Its enemy is ambiguity.

Characteristics of a good individual requirement:

Unambiguous — exactly one reading. Ban “fast,” “user-friendly,” “robust,” “efficient,” “as appropriate,” and “etc.”
Verifiable — someone can design a test that passes or fails. If you cannot describe the test, you do not have a requirement; you have an aspiration.
Necessary — traceable to a stated business or user need. Requirements with no parent are usually somebody’s hobby.
Feasible — implementable within known technical and budget constraints.
Atomic — one requirement per statement. The word “and” in a requirement is usually two requirements wearing a trenchcoat.
Consistent — no contradiction with any other requirement, including in vocabulary. Two words for one concept will eventually become two database tables.

And of the set as a whole: complete (no known gaps), non-redundant, prioritized, and traceable.

Formats vary by context. Traditional projects use a Software Requirements Specification (SRS), often structured along IEEE 830 / ISO 29148 lines. Use-case-driven projects specify actors, preconditions, main flow, and — the part that carries most of the value — exception flows. Agile teams use User Story items with acceptance criteria, frequently in Given/When/Then form. The format matters far less than whether the acceptance criteria are concrete.

Validation: Checking You Wrote Down the Right Thing

Verification asks “did we build the system right?” Validation asks “did we specify the right system?” Validation is the cheapest defect-removal activity in the entire lifecycle, because a requirements defect caught at specification time costs a rewrite of one paragraph, while the same defect caught in production costs redesign, recoding, retesting, data migration, and an apology.

Validation techniques include structured reviews and inspections with the stakeholders who supplied the requirement, walkthroughs of concrete scenarios against the spec, prototype-based confirmation, and — most powerfully — writing the acceptance tests before the code. If the test cannot be written, the requirement is not yet real. This is the same insight that drives Test Pyramid and TDD at the unit level, applied one level up.

Validation is a loop, not a gate. Every validation activity generates new questions, which feed back into elicitation.

Management: Requirements Change, and That Is Not a Failure

The naive model treats change as leakage from a broken process. The realistic model treats change as information arriving — the market moved, a regulation landed, a user tried the beta and hated it. The goal is not to prevent change but to make its cost visible and its propagation controlled.

Requirements management covers baselining, versioning, change control (who may approve a change and against what impact analysis), status tracking, and traceability. On regulated projects this is formal, with a change control board and signed impact assessments. On a Scrum team it is the Product Backlog and Refinement process plus the sprint boundary, which serves as a lightweight change-control mechanism: change the backlog freely, change the sprint’s committed scope rarely.

An individual requirement has its own lifecycle, and tracking that state is what makes status reporting honest. “Eighty percent of requirements are done” means nothing unless “done” is a defined state with an entry condition.

Two states are routinely missing from real projects and both cause damage. Deferred is the honest place for a good idea whose time has not come; without it, such requirements are either rejected (and lost) or approved (and quietly inflate scope). Obsolete is the state that authorizes deletion — of the requirement, its tests, and its code. Systems accumulate weight because nothing is ever allowed to reach it.

The two feedback arrows into elicitation are the point of the diagram. A process where validation only ever confirms is a process where validation is not happening.

Functional vs Non-Functional Requirements

This split is the single most consequential distinction in the discipline, and the one most often handled badly.

A functional requirement describes behavior: given some input or event, the system produces some output or state change. “The system shall email a receipt within one business day of payment capture.” Functional requirements are what stakeholders talk about unprompted, what appears in demos, and what maps cleanly onto features and stories.

A non-functional requirement (NFR), also called a quality attribute, describes how well the system must behave rather than what it does. “Ninety-fifth percentile search latency shall not exceed 300 ms at 2,000 concurrent users.” NFRs are global, cross-cutting, and architecturally decisive. You cannot bolt them on.

The asymmetry is brutal: functional requirements are missed one feature at a time and fixed one feature at a time; non-functional requirements are missed once and fixed by rewriting the architecture.

The Major NFR Categories

Category	The question it answers	Example of a bad statement	Example of a good statement	Who typically owns it
Performance	How fast, under what load?	“The system must be fast.”	“p95 checkout response under 400 ms at 5,000 concurrent sessions; p99 under 1.2 s.”	Architecture, SRE
Scalability	How does it grow?	“It should scale.”	“Sustain 10x current write volume by adding nodes, with no change to the data model.”	Architecture
Availability	How much downtime is tolerable?	“It should always be up.”	“99.95% monthly availability excluding a 2-hour announced maintenance window; RTO 15 min, RPO 1 min.”	Ops, business
Security	Who can do what, and how is that enforced?	“The system must be secure.”	“All PII encrypted at rest with AES-256; access decisions logged immutably for 7 years; MFA required for admin roles.”	Security, compliance
Usability	How easily can a real user succeed?	“It must be user-friendly.”	“A new agent completes their first claim intake unassisted in under 8 minutes, with 90% task success in usability testing.”	Design, research
Accessibility	Can everyone use it?	“Support screen readers.”	“Conform to WCAG 2.2 Level AA; verified by automated scan plus annual manual audit.”	Design, legal
Reliability	How often does it fail, and how badly?	“Minimize errors.”	“Mean time between failures greater than 720 hours; no single component failure causes data loss.”	Engineering
Maintainability	What does the next change cost?	“Write clean code.”	“Any endpoint’s owning team can be identified from the repo; new service scaffolded and deployed in under one day.”	Engineering
Portability	Where must it run?	“Cloud agnostic.”	“No managed-service API used without an abstraction layer; deployable to two named clouds from one manifest.”	Architecture
Compliance	What law or standard binds us?	“Follow the rules.”	“Satisfy GDPR Art. 17 erasure within 30 days across all stores including backups and analytics.”	Legal, data
Observability	Can we tell what happened?	“Add logging.”	“Every request carries a trace ID propagated across all services; retained 30 days and queryable in under 10 s.”	SRE

Notice the pattern in the good column: every one is measurable. An NFR without a number, a threshold, or a named standard is decoration. The test for a well-formed NFR is simple — can you write a script, run a scan, or conduct a study that returns pass or fail?

Why NFRs Are the Ones That Sink Projects

Missed functional requirements produce a disappointed user and a ticket. Missed non-functional requirements produce a rewrite. The reasons are structural:

NFRs determine architecture; features do not. Whether the system is a monolith or a set of services, synchronous or event-driven, single-region or multi-region, is decided almost entirely by availability, latency, and scale targets. Discover the real numbers after those choices are made and the choices are wrong.
Nobody asks for them. No stakeholder opens a meeting by requesting 99.95% availability. They assume it. The assumption is only spoken aloud after it is violated, at which point it is expressed as anger rather than as a requirement.
They are invisible in demos. A demo with three rows of test data looks identical whether the query is $O(n)$ or $O(n^2)$ . The difference appears at production volume, months later, with real customers.
They interact and conflict. Encryption costs latency. Redundancy costs money. Audit logging costs write throughput. Flexibility costs simplicity, which costs maintainability. There is no configuration that maximizes all of them, so the tradeoff must be an explicit, recorded decision rather than an accident of whoever wrote the code.
They resist incremental delivery. You can ship half the features. You cannot ship half the security model. Retrofitting multi-tenancy, auditability, or internationalization into a system that assumed their absence routinely costs more than the original build.
They fail catastrophically rather than gradually. A missing report annoys someone. A missing rate limiter takes down the service on the day of your largest marketing push.

The practical mitigation is to elicit NFRs explicitly and early using a checklist of categories, attach numbers to each, and — critically — make them visible in the delivery process. Mature teams encode NFRs into the Definition of Done (every story ships with tracing and an accessibility check), into the automated pipeline via performance and security gates in CI-CD Best Practices, and into architecture decision records that state the target and the tradeoff accepted to hit it.

Requirements Traceability

Traceability is the ability to follow a requirement forward into the artifacts that implement it and backward to the need that justifies it. It sounds bureaucratic. In regulated domains it is legally mandatory, and in every domain it quietly answers the questions that otherwise consume weeks.

A traceability chain typically links:

Business objective
  → Stakeholder need
    → Requirement (functional or NFR)
      → Design element / architecture decision
        → Code module, service, or commit
          → Test case
            → Test result / verification evidence

Two directions matter, and they answer different questions.

Forward traceability (need → requirement → design → code → test) answers: has everything we promised actually been built and verified? A requirement with no linked test is unverified. A requirement with no linked code is unbuilt. Forward traceability is how you find the gap before the customer does.

Backward traceability (test → code → requirement → need) answers: why does this exist? A module with no traceable parent requirement is either dead weight or an undocumented feature — both are risks. Backward traceability is also what makes deletion safe: you can remove code confidently when you can prove nothing depends on the requirement it serves.

The classic instrument is a requirements traceability matrix (RTM), a grid with requirements on one axis and design elements, code artifacts, or test cases on the other. In practice most teams achieve traceability through tooling conventions rather than a literal spreadsheet:

Requirement or story IDs in branch names and commit messages, so git log becomes a trace query.
Test names that quote the requirement ID or the acceptance criterion verbatim.
Issue tracker links between epics, stories, and defects, with automated linking from commits and pull requests.
Architecture decision records naming the NFRs that drove each decision.
Feature-flag names tied to the requirement they gate, connecting to Feature Flags as a rollout control.

The real payoff appears at three moments. Impact analysis: a regulation changes; which parts of the system are affected? Without traceability this is an archaeological expedition. Coverage assessment: an auditor asks which tests prove that PII erasure works. Change safety: a team wants to delete a legacy path and needs to know what it was for.

The honest cost is maintenance. A traceability matrix maintained by hand goes stale within weeks and then actively misleads, which is worse than having none — a stale matrix produces confident wrong answers. The rule of thumb: traceability should be a byproduct of how work already flows, not a separate document someone updates on Fridays. Where it must be formal (medical devices under IEC 62304, avionics under DO-178C, automotive under ISO 26262), budget for the tooling honestly rather than pretending it is free.

Agile’s Reframing: From Specification to Backlog

Agile methods did not abolish requirements engineering. They relocated it — from a document produced up front to a conversation held continuously — and they made a specific, deliberate bet about where the risk lies.

The Agile Manifesto line “working software over comprehensive documentation” is routinely misquoted as “no documentation.” The actual claim is narrower and sharper: a signed specification creates an illusion of agreement. Two people can read the same sentence, agree enthusiastically, and hold incompatible mental models — and nothing reveals the incompatibility until working software appears. Agile therefore shortens the interval between writing a requirement and testing that shared understanding against reality.

Mechanically, the User Story replaces the specification clause. A story is explicitly not a requirement; it is a placeholder for a conversation, carrying just enough text to remember what to discuss. The three Cs — Card, Conversation, Confirmation — make the priority order clear: the card is a reminder, the conversation carries the real content, and the confirmation (acceptance criteria) is what actually gets verified. Stories live in a Product Backlog and Refinement process that is ordered, continuously reprioritized, and deliberately under-specified toward the bottom, so effort is spent detailing only what is close to being built.

The Genuine Tradeoffs

Agile marketing presents this as pure gain. It is not; it is a trade, and being honest about the cost is what separates a team that runs this well from one that has simply stopped writing things down.

Dimension	Specification-driven	Backlog-driven (Agile)
Primary risk addressed	Building something the contract didn’t cover	Building the wrong thing correctly
When detail is produced	Up front, all of it	Just in time, only for near-term work
Handling of change	Change control board, formal impact analysis	Reprioritize the backlog; change is the default
Basis of agreement	A signed document	Working software plus acceptance criteria
Fixed-price contracting	Natural fit	Awkward; needs different contract structures
Regulatory evidence	Directly reusable as audit evidence	Must be deliberately reconstructed
Knowledge durability	Written, survives staff turnover	Tacit, walks out the door with people
NFR handling	Explicit section in the SRS	Systematically neglected unless forced in
Cost of a wrong assumption	Discovered late, very expensive	Discovered in weeks, cheap

The costs are real:

NFRs get orphaned. A story format built around “as a user, I want…” has no natural slot for “p99 latency under 400 ms.” Teams that do not deliberately create a home for quality attributes — in the Definition of Done, in architectural runway work, in explicit technical stories — simply do not do them, and discover this in production. This is the most common and most damaging failure mode of backlog-driven requirements.
Institutional memory evaporates. Three years and two team turnovers later, “why does the settlement job run at 04:00?” has no answer. The conversation happened; nobody recorded the conclusion. Healthy teams write decisions down after the fact — ADRs, well-written test names, comments on the why — precisely because the conversation-first model has this hole.
Cross-team coherence weakens. One team’s backlog says nothing about another’s. Scaled Agile (SAFe and LeSS) exists largely to reintroduce coordination that the single-team model assumes away, and the friction is genuine, not merely bureaucratic overhead.
Contracting and compliance get harder. A fixed-price bid needs a scope. An auditor needs evidence linking a control to a requirement to a test. Both are obtainable in an Agile process, but only by deliberately producing artifacts the process does not produce naturally.
Emergent architecture can dead-end. Deferring architectural commitment is correct when the decision is cheap to reverse. Data model, tenancy boundary, and security model usually are not. “We’ll refactor later” is a valid strategy only where later refactoring is actually feasible; see Code Refactoring and Technical Debt.

The synthesis practiced by strong teams: keep the backlog and the just-in-time detail for functional scope, but treat quality attributes as durable, written, cross-cutting constraints — reviewed periodically, encoded in automation, and owned explicitly. The functional requirement is a conversation. The non-functional requirement is a contract.

Why It Matters

Requirements defects are the most expensive class of defect. The cost of fixing a defect rises by roughly an order of magnitude per lifecycle phase it survives. A requirement misunderstood at elicitation and discovered in production has passed through every phase.
They set the ceiling on quality. No amount of clean code, testing, or refactoring turns a correctly built wrong system into a right one. Craft cannot compensate for solving the wrong problem.
NFRs decide the architecture. Latency, availability, and scale targets constrain the design space more than any feature list. Discovering them late means rebuilding.
They are the basis of acceptance. “Done” is undefined without a statement of what was required. Disputes at delivery are almost always requirements disputes wearing a different label.
They enable rational prioritization. You cannot sequence work by value without knowing what each item is for. Requirements traced to business objectives make Prioritization Frameworks meaningful instead of political.
They surface conflict while it is still cheap. Writing two stakeholders’ needs on the same page exposes contradictions that would otherwise surface as a production incident or an escalation.
They make change controllable. Traceability converts “what does this change break?” from an investigation into a query.
They govern legal and regulatory exposure. Data retention, consent, accessibility, and auditability are requirements with statutory force. Missing them is not a bug; it is a fine.
They protect scope. A documented, agreed scope is the only defense against uncontrolled scope creep — and equally, against being blamed for omitting something never asked for.
They transfer knowledge. New team members and future maintainers inherit intent, not just code. Intent is the part that cannot be reverse-engineered.

Comparison

Aspect	Requirements Engineering	Business Analysis	Systems Analysis	Product Management
Primary question	What must the system do and how well?	What business problem exists and is software the answer?	How do components and data interact to satisfy requirements?	What should we build, for whom, and why now?
Main output	Validated, testable requirements and NFRs	Business case, process models, gap analysis	Architecture, data and interface models	Strategy, roadmap, prioritized backlog
Time horizon	Current release plus committed scope	Current initiative, business cycle	Design of the system under construction	Quarters to years; see Product Roadmap
Success measure	System accepted; few requirement-caused defects	Business outcome achieved	System is coherent, buildable, meets NFRs	Market outcome; see Product-Market Fit
Overlap	Shares elicitation with BA; shares NFRs with systems analysis	Feeds RE with objectives	Consumes RE output	Owns priority of RE output

And within the requirements artifact family:

Artifact	Level	Lifespan	Signed off?	Typical owner
Business objective	Why	Years	Executive-level	Sponsor
Stakeholder need	Who wants what	Initiative	Informally	Business analyst
Functional requirement	What the system does	Release to permanent	Formally in regulated contexts	Analyst / product owner
Non-functional requirement	How well it does it	Permanent until architecture changes	Should be, often isn’t	Architect + business
User Story	Slice of behavior	Days to weeks	Acceptance criteria only	Product owner + team
Acceptance criterion	Verification condition	Until the test is written	By the team	Team

Real-World Use Cases

Medical device software under IEC 62304. Every requirement traces to a hazard analysis, a design element, and a verification test. Regulators audit the traceability matrix directly; an untraced requirement blocks market approval. Requirements engineering here is not overhead, it is the product’s license to exist.
Payment processing platforms. PCI-DSS turns security into hard, auditable requirements: key rotation intervals, network segmentation, immutable logging. These are elicited from a standard rather than a stakeholder, and they constrain architecture before the first feature is discussed.
Airline reservation and rebooking systems. The functional requirements are famously bounded by exception flows — partial cancellations, interline transfers, involuntary rebooking — that only surface through observation and document analysis. The main flow is a small fraction of the real specification.
Migrating a legacy mainframe billing system. The authoritative requirements exist only as forty-year-old COBOL. Elicitation becomes code archaeology plus interviews with the three remaining people who remember why the March exception exists.
Consumer mobile apps. Functional requirements are elicited through prototypes and A/B tests rather than interviews; the specification that matters is the analytics event schema plus the accessibility and offline-behavior NFRs that nobody requests but everyone judges.
Public sector procurement. A tender document is a requirements specification with legal force, written before any vendor is chosen. Ambiguity here becomes litigation, which is why these specifications are exhaustively formal and why they so often specify a solution that has aged badly by delivery.
Internal enterprise tooling. The hardest elicitation problem in practice, because “the requirement” is an existing spreadsheet with 200 columns embodying a decade of undocumented business rules that no living person can fully explain.
Platform and infrastructure teams. Requirements come from other engineers, expressed almost entirely as NFRs: deploy time, rollback speed, isolation guarantees, cost per environment. See DevOps Culture and CI-CD for how these get operationalized.
Machine learning systems. Requirements must specify acceptable error rates by segment, fairness constraints, data provenance, and retraining cadence — none of which fit the classical “the system shall” template, and all of which are non-functional.
API products. The contract is the requirement. Backward compatibility rules, deprecation windows, and versioning policy are requirements in their own right, formalized through Semantic Versioning.

Common Pitfalls

Treating elicitation as transcription. Writing down what the stakeholder said and calling it a requirement guarantees you have captured a proposed solution, an assumption, and a preference, mixed together and labeled as need. Always ask why at least twice.
Skipping non-functional requirements entirely. The most common and most expensive omission. If no document in the project states a latency target, an availability target, or a security posture, they have not been agreed — they have been assumed, differently, by everyone.
Unverifiable adjectives. “Fast,” “intuitive,” “secure,” “scalable,” “robust.” Each is a placeholder for a number nobody wanted to commit to. Ban them; force the number, or explicitly record that the target is undecided.
Gold-plating the specification. Six months of analysis producing a 400-page document that is obsolete on delivery. Detail has a shelf life; producing it far ahead of implementation destroys most of its value while consuming the schedule.
Confusing the loudest stakeholder with the most important one. Elicitation dominated by whoever is most available and most vocal systematically underweights the actual end user, who is usually too busy doing the job to attend workshops.
No single source of truth. Requirements scattered across email threads, meeting notes, a wiki, three tickets, and a Slack message. Every version is authoritative to someone, and the contradictions surface during acceptance testing.
Letting traceability rot. A traceability matrix updated once, at the start, then abandoned. Stale traceability is worse than none because it answers impact-analysis questions confidently and wrongly.
Treating change as failure. Punishing change requests drives them underground; they reappear as undocumented scope smuggled into implementation. Make change legitimate, visible, and costed.
Requirements written by people who will never use or build the system. Analysts working purely from documents produce specifications that are internally consistent and disconnected from operational reality.
Assuming “the team will figure it out.” The Agile version of the same failure: no acceptance criteria, no conversation, just a title on a card. The team figures out something, and it may not be what anyone wanted.
Ignoring the exception flows. The main flow is ten percent of the work and ninety percent of the discussion. Refunds, partial failures, retries, timeouts, and concurrent edits are where requirements are actually missing.

SDLC (Software Development Life Cycle) — the surrounding lifecycle in which requirements engineering is the first and most recurring activity
Waterfall Model — the process that treats requirements as a signed, up-front baseline
V-Model — pairs each requirement level with a corresponding verification level, making validation structurally explicit
User Story — the Agile unit that replaces the specification clause with a placeholder for a conversation
Product Backlog and Refinement — where requirements live and are progressively detailed in Agile teams
Definition of Done — the practical home for cross-cutting non-functional requirements
Prioritization Frameworks — how requirements are ordered once elicited
Test Pyramid and TDD — the verification counterpart; acceptance criteria are requirements made executable

Example

A regional insurer set out to replace a 22-year-old claims intake system. The stated requirement, agreed in a two-day workshop with the operations directors, was straightforward: replicate the existing intake workflow on a modern web stack, add mobile photo upload, and cut average intake time from eleven minutes to six. Thirty-one functional requirements were written, reviewed, and signed. Nobody wrote a single non-functional requirement, because nobody thought to ask; the old system had never been slow, so speed was invisible.

Two things went wrong, and only one of them was found in time. The analyst spent three days sitting beside adjusters in the Cleveland office instead of relying on the workshop output — and discovered that roughly one intake in six was not a normal intake at all. Adjusters routinely handled multi-vehicle claims by opening the record, abandoning it halfway, phoning the other party’s insurer, and returning hours later to a session the old system had quietly preserved on a local drive. No director mentioned this because no director had done intake in a decade, and the adjusters did not mention it because to them it was not a workaround, it was simply the job. That observation added eleven requirements around draft persistence, concurrent edits by two adjusters on one claim, and a “pending third-party” state that had never appeared in any document. Every one of them came from watching, not asking.

The second failure was not caught. Because no availability or performance requirement was ever recorded, the team chose a synchronous architecture where photo upload blocked claim submission — perfectly acceptable at the volumes seen in staging. On the first Tuesday after a hailstorm in the coverage region, intake volume rose eightfold, upload queues backed up, submissions timed out, and adjusters fell back to paper for two days. The postmortem produced the requirement that should have existed from the start: the system shall accept claim submission independently of media upload, sustaining 3,000 submissions per hour with 99.9% availability during declared weather events, with media attached asynchronously within 30 minutes. That one sentence, written eight months earlier, would have made the queue-based design obvious and cost nothing. Written after the outage, it cost a re-architecture, a delayed roadmap, and a considerable amount of trust — which is the entire argument for requirements engineering in a single anecdote: the functional requirements determine whether the system is useful, and the non-functional ones determine whether it survives.

Referenced by

Dig deeper

Spot an error in this note?