Analyzing and Decomposing Requirements

Raw elicited requirements are rarely ready to build from directly — this task breaks them down and examines them more closely using techniques like dependency analysis (what relies on what), interface analysis (how a system or process connects to others), and data or process modeling (visualizing how information or work actually flows). The goal is uncovering product options and capabilities that weren't obvious in the original, higher-level statement.

This is explicitly collaborative work, done with stakeholders and the delivery team together, not something a BA does alone and hands over finished — decomposition tends to surface new questions and trade-offs that need real-time stakeholder input to resolve correctly.

Study focus: a scenario where a seemingly simple requirement turns out to have hidden dependencies once decomposed (e.g., a "simple" report that actually depends on three separate, inconsistent data sources) is testing recognition of why this analysis step matters.