Requirements Analysis

Definition

Requirements analysis is the structured practice of eliciting, examining, decomposing, and validating stakeholder needs so that they can be translated into clear, testable statements that guide design, procurement, or process change. In a business architecture context, it goes beyond simply capturing a list of requests from a project sponsor — it involves tracing each requirement back to the business capability, value stream, or strategic objective it serves, so that scope decisions are anchored in business intent rather than personal preference or departmental habit. The discipline sits at the intersection of business analysis and business architecture. Business analysts typically own the detailed elicitation techniques (interviews, workshops, use cases, process walkthroughs), while business architects provide the structural context — the capability map, operating model, and value stream — that requirements should align to. Done well, requirements analysis distinguishes between functional requirements (what the solution must do), non-functional requirements (performance, security, compliance constraints), and business requirements (the outcome or capability gap being addressed), preventing the common failure of solutioning around a symptom rather than the underlying capability weakness. It is important to draw a boundary around what requirements analysis is not. It is not the same as solution design — a requirement states a need, not how that need will be met. It is also not a one-time document; mature organizations treat requirements as living artifacts that get revisited as capabilities, regulations, and strategic priorities shift, particularly on multi-year transformation programs.

Origin & Context

Requirements analysis has roots in systems engineering and software development methodologies from the 1970s onward, formalized later in bodies of knowledge such as the IIBA's Business Analysis Body of Knowledge (BABOK) and reinforced within enterprise architecture frameworks like TOGAF, which positions requirements management as a continuous activity running across every phase of the Architecture Development Method. The Business Architecture Guild's BIZBOK further connects requirements to capability and value stream models, giving business architects a structured way to validate that requirements trace to genuine business need rather than isolated stakeholder wish lists.

Why It Matters

CIOs and program sponsors care about requirements analysis because poorly analyzed requirements are one of the most common root causes of budget overruns, scope creep, and solutions that technically work but fail to move a business outcome. Business architects use it to prevent capability duplication — when requirements are traced to an existing capability map, teams catch it before commissioning a redundant system or process. Enterprise architects rely on rigorous requirements analysis to make sound build-versus-buy and platform consolidation decisions, since ambiguous requirements make vendor evaluation and fit-gap analysis unreliable. Ultimately, it protects the credibility of the transformation function itself: leadership loses confidence quickly when delivered solutions don't match what was actually needed.

Common Misconceptions

Myth: Requirements analysis just means writing down what users ask for.

Reality: Stakeholders describe symptoms and preferences, not always the underlying need. Skilled requirements analysis probes past the stated request to the business capability gap or value stream friction driving it, which is why techniques like the '5 whys' and capability cross-mapping are used alongside interviews.

Myth: Requirements analysis is a business analyst task with no bearing on architecture.

Reality: Without architectural grounding, requirements get validated only against a single project's scope, not the enterprise's existing capability and application landscape. This is exactly how organizations end up funding three different systems that solve the same underlying capability gap in three different business units.

Myth: Once requirements are signed off, the job is done.

Reality: Requirements are living artifacts. Regulatory changes, M&A activity, or capability maturity shifts routinely invalidate previously approved requirements, which is why leading organizations version and re-baseline requirements against their capability model rather than treating sign-off as a final event.

Practical Example

A regional insurer launching a claims modernization initiative assembled a joint team of business analysts and a business architect. Rather than starting from the claims department's system wish list, the business architect first mapped the request against the enterprise capability map, isolating the specific capability — claims adjudication — showing weakness. Analysts then ran structured elicitation sessions with adjusters, underwriters, and compliance staff, decomposing requirements into business, functional, and non-functional categories, and explicitly linking each to the adjudication capability and its supporting value stream. During review, the team discovered two requirements duplicated functionality already delivered by an existing policy administration module, avoiding redundant build effort. The finalized requirements package became the basis for a fit-gap analysis against three vendor platforms, giving procurement a defensible, traceable rationale for the eventual platform selection.

Industry Applications

Financial Services

Requirements are traced to regulatory capabilities such as KYC and AML monitoring, ensuring new system requirements explicitly satisfy compliance obligations rather than generic business convenience.

Healthcare

Clinical and administrative requirements are validated against care delivery and patient management capabilities, helping distinguish EHR configuration needs from genuine capability gaps requiring new investment.

Manufacturing

Requirements for plant floor and supply chain systems are cross-mapped to operations and logistics capabilities, reducing the risk of commissioning point solutions that duplicate ERP functionality already in place.

Related Terms

• Business Analysis: the broader discipline within which requirements analysis is a core practice