Requirements

Requirements engineering is the work of finding out what a system must do, writing it down so that it can be built and verified, and keeping that record under control as the project changes. Most troubled projects can trace their problems back to requirements that were missing, ambiguous or never properly agreed, which is why the discipline repays careful study.

This hub is for systems engineers, business analysts and project engineers who write, review or manage requirements. It follows the order of the work: eliciting stakeholder needs, writing requirements that are clear and testable, the main requirement types and specification documents, managing change, baselines and traceability, and the tools and AI assistants now used for requirements management.

Start here

• What is requirements engineering? — complete guide to elicitation, analysis, specification and validation of what a system must do
• Capturing and defining requirements — practical guide to turning vague stakeholder needs into precise, testable requirements, with traps to avoid
• Functional vs non-functional requirements — 20 paired examples across five domains, plus a 4-question test for telling them apart
• INCOSE requirements quality rules — all 42 INCOSE rules explained with before-and-after examples you can copy
• Requirements traceability matrix — what a traceability matrix contains, why it matters, and a worked example

Eliciting stakeholder needs

Good requirements start with a clear scope and an honest picture of what stakeholders actually need.

• Defining scope and stakeholder needs — the upfront scoping work that comes before writing requirements and prevents scope creep
• Stakeholder needs to requirements worksheet — a 7-column worksheet with five real stakeholder statements worked through end to end
• Requirements definition — the practical steps for turning stakeholder needs into clear, complete, verifiable requirements

Writing good requirements

These guides cover the wording rules and quality tests that make a requirement unambiguous and verifiable.

• SMART requirements — what Specific, Measurable, Achievable, Relevant and Time-bound mean, with examples
• Shall vs should vs will vs must — a requirements language rule card and eight bad requirements rewritten into testable ones
• Acceptance criteria for user stories — how to write them in Given-When-Then form, with good and bad examples

Requirement types and specification documents

Different stakeholders and lifecycle stages call for different kinds of requirements and the documents that hold them.

• User requirements — what users actually need, how user requirements differ from system requirements, and how to gather them
• Operational requirements from a CONOPS — how to translate a Concept of Operations into specific, verifiable operational requirements
• Business Requirements Specification (BRS) — what goes in a BRS and how to write one that holds up
• Product Design Specification (PDS) — what to include in a PDS and how to write one that actually gets used
• Requirement vs specification — the difference between what a system must do and how, and which comes first

Managing requirements, change and traceability

Once requirements are written they have to be allocated, baselined, traced and changed under control.

• Systems engineering vs requirements management — how requirements management fits within systems engineering and where the two overlap
• Requirements baseline — what an agreed, frozen requirements set is and how to establish one for change control
• Requirements change management — assessing impact, controlling change and keeping traceability intact when requirements move
• Requirement allocation — how to divide a high-level requirement among the subsystems that deliver it
• Requirements and artifacts — how engineering artifacts differ from requirements and how linking them keeps projects auditable

Requirements tools and AI

Choosing a requirements management tool, and using AI sensibly within it, are now part of the job.

• Best requirements management tools — DOORS, Jama, Polarion, codebeamer and others compared, with guidance on choosing
• IBM DOORS tutorial for beginners — a decoder for eight confusing DOORS terms and a ten-step first-project walkthrough
• Reqi requirements management tool — what Reqi does for capturing and tracing requirements, and how it compares to legacy tools
• Using LLMs to write and review requirements — what large language models do well for drafting and checking requirements, and the risks
• AI in requirements management — which requirements management tasks AI now automates and where humans still lead
• Elicitation, writing and analysis in the AI era — what to automate, what to keep human, and where AI genuinely helps

Related hubs: systems engineering, MBSE and modelling, safety and hazards. See also: safety requirements, verification vs validation, writing a CONOPS.