Requirements Engineering

Requirements engineering is the discipline of discovering, analyzing, specifying, validating, and managing what a system must do and how well it must do it. It is the primary input to architecture. Patterns chosen without requirements are fashion; patterns chosen against measured quality attributes are engineering.

This page is the spine of the Architecture & SDLC section. Master it before committing to monoliths, microservices, event-driven designs, or process models. You will learn functional vs non-functional requirements, specification shapes, prioritization, validation, and how each requirement type drives architectural decisions.

Functional requirements (FR) describe behavior: inputs, outputs, business rules, workflows. Non-functional requirements (NFR) — also called quality attributes — describe qualities of that behavior: performance, security, scalability, maintainability, availability, usability, compliance.

Stakeholders often state NFRs vaguely ("make it fast and secure"). Your job is to make them measurable, prioritized, and owned. Unmeasurable NFRs cannot drive architecture — they only drive arguments.

Stories need acceptance criteria to be testable. Use cases shine when multiple actors and alternate flows must be unambiguous (billing disputes, KYC). Both can coexist: use cases as reference, stories as delivery slices.

MoSCoW ranks scope: Must, Should, Could, Won't (this time). Apply to FRs and NFRs. A Must NFR (e.g., PCI controls) can outrank a Should feature.

• Must: release is invalid without it (legal, safety, core journey).
• Should: important but workaround exists short-term.
• Could: nice-to-have if capacity remains.
• Won't: explicit deferral — prevents silent scope creep.

Acceptance criteria turn intent into verification. Prefer Given/When/Then or checklist form. Include failure paths and audit/security expectations where relevant. For NFRs, acceptance is a measurable test or operational objective.

Product Requirements Documents (PRD) and Functional Requirements Documents (FRD) vary by org. A practical shape for architecture-ready specs:

• Problem, goals, non-goals, success metrics.
• Users/personas and primary scenarios.
• FR list with priorities and AC.
• NFR table with metrics, measurement method, owner.
• Constraints: team, budget, timeline, compliance, existing systems.
• Open questions and decision log links (ADRs).
• Rollout / migration / analytics plan.

Validate continuously: walkthroughs, prototype tests, contract examples, and executable acceptance tests. Invalidated requirements should update the backlog and potentially supersede ADRs.

Every significant ADR should cite requirement IDs. This prevents orphan architecture and helps audits.

Requirements change. Manage them:

• Single backlog (or synchronized backlogs) with clear ordering.
• Change impact analysis for Must NFRs and baseline architectures.
• Version requirements in regulated contexts; link to tests and releases.
• Kill outdated requirements explicitly — do not leave zombies.

• Only documenting FRs; NFRs appear as panic during launch week.
• Acceptance criteria that restate the story title.
• Prioritizing by HiPPO (highest paid person's opinion) without MoSCoW evidence.
• Architecture decided in a slide before requirements workshop.
• Requirements that prescribe implementation ('use Kafka') instead of need ('decouple billing from checkout with durable async').

Next: Modular Monolith. Also Choosing, Mastery, System Design.