Requirements Capture Phase of the Systems Development Lifecycle (SDLC)

Defines the IF4IT SDLC phase in which stakeholder needs, business outcomes, functional behavior, non-functional qualities, data and information needs, interfaces, operational obligations, supplier commitments, constraints, and acceptance criteria are captured, analyzed, validated, prioritized, and placed under controlled change.

Purpose

The Requirements Capture phase converts approved lifecycle intent into an authoritative and testable basis for Design, acquisition, Build, Verification, Validation, operations, and acceptance. It should explain what outcomes are required, for whom, under which conditions, within which constraints, and how the enterprise will determine whether each requirement has been satisfied.

Typical Inputs

Inputs may include the approved intake and planning records, research findings, prototype results, stakeholder needs, business processes, Architecture principles, applicable Standards, Risks, regulatory and contractual obligations, current-state capabilities, data definitions, supplier information, operational experience, Technical Debt, and the approved SDLC Utilization Profile.

Core Activities

Identify requirement sources and owners; elicit and analyze needs; distinguish business, stakeholder, functional, non-functional, data, interface, transition, operational, supplier, Security, Privacy, accessibility, resilience, and retirement requirements; define assumptions and constraints; remove ambiguity and duplication; prioritize requirements; establish acceptance criteria and at least one validation method for each material requirement; trace requirements to enterprise outcomes, affected capabilities, Risks, Designs, and planned evidence; and establish an approved requirements baseline or governed iterative equivalent.

Requirement Quality and Validation

Requirements should be necessary, clear, singular where practical, feasible, consistent, appropriately bounded, attributable, prioritized, testable or otherwise verifiable, and understandable to the authorities who own them. Validation should confirm that the requirement reflects the actual stakeholder or enterprise need, while Verification planning should confirm that objective evidence can demonstrate conformance. Unresolved conflicts, assumptions, and interpretation decisions should remain explicit.

Outputs and Evidence

Outputs may include an approved requirements set or structured backlog, requirement ownership and source, definitions and business rules, non-functional requirements, data and interface requirements, supplier obligations, acceptance criteria, validation methods, traceability, assumptions, constraints, priorities, change history, open issues, Risks, and the requirements baseline. Evidence should identify which requirements are approved, deferred, rejected, superseded, or subject to exception.

Decision and Exit Criteria

Exit requires sufficient requirements coverage and quality to support the next Design or acquisition decision, accountable ownership, resolved or governed conflicts, defined acceptance and validation methods, traceability to the Release and intended outcomes, and an approved basis for managing change. Requirements may continue to evolve in Agile and Hybrid delivery, but the applicable state for each Design, Build, test, and Release decision must remain identifiable.

Application Across Solution Types and Methods

For Custom-Built Solutions, requirements provide the authoritative basis for Architecture, Design, engineering, and test. For Acquired Solutions, they provide the enterprise criteria for market evaluation, contract obligations, configuration, integration, acceptance, and exit. For Composite Solutions, component requirements must align with end-to-end outcomes and shared interfaces. Waterfall may establish broader formal baselines, Agile may refine requirements iteratively through governed backlogs, and Hybrid may combine both approaches without losing ownership, traceability, or evidence.

Crawl-Walk-Run Maturity

At Crawl maturity, use an approved template or backlog structure, named requirement owners, basic quality review, and explicit acceptance criteria. At Walk maturity, integrate requirements with Architecture, Design, V&V, suppliers, Risks, Releases, and change control. At Run maturity, use semantic models, automated consistency and traceability checks, reusable requirement patterns, evidence links, and generative AI assistance while preserving accountable human approval and validation.

Common Antipatterns

Enterprises should avoid treating requirements volume as requirements quality. An exhaustive requirements document can look complete while ambiguity, conflicting assumptions, and unvalidated stakeholder needs survive underneath it, only to surface as costly rework once Design or Build has already committed to one interpretation.

Connections to Related IF4IT Practices and Inventories

Use Enterprise Capability Models and the Capabilities Inventory and Attributes to trace stakeholder needs and solution decisions to the enterprise capabilities they enable, change, protect, or retire. Use the Data and Information Inventory and Attributes and the Integrations Inventory and Attributes to identify authoritative data, semantics, interfaces, lineage, ownership, quality expectations, and integration dependencies before design decisions are finalized.

Use the Non-Functional Requirements (NFRs) Framework for Software Systems to define measurable quality, security, resilience, usability, interoperability, maintainability, and operational requirements, together with explicit validation methods and evidence.

Use Release Management guidance alongside IT Operating Environments Best Practices and Agile, Waterfall, or Hybrid: An IF4IT Framework for Choosing Delivery Methodology to govern how Release scope, environment progression, deployment evidence, cutover, rollback, and closure are actually managed.