CAPM Practice: Determine how to gather requirements

In novel domains, traditional elicitation assumptions (stakeholders know what they want) break down. Exploratory techniques — experiments, design thinking workshops, rapid prototyping, market research, and user observation — are essential for discovering what might be valuable.

**Why not A:** Claiming that requirements gathering is identical regardless of domain novelty ignores a fundamental principle of business analysis. When the domain is well-understood, the BA can leverage existing templates, domain models, and established patterns. Novel domains demand more discovery-oriented methods because there are fewer established references to draw from. Treating all domains the same leads to either over-engineering familiar work or under-exploring unfamiliar territory.

**Why not B:** Skipping requirements gathering for novel domains is reckless and contradicts sound BA practice. Novel, innovative products actually need more requirements exploration, not less — the uncertainty demands careful discovery to validate assumptions before committing significant development resources. Moving directly to development without understanding the problem space virtually guarantees costly rework.

**Why not C:** This answer reverses the actual best practice. Novel domains benefit from less structured, more exploratory techniques like prototyping and experimentation because requirements are uncertain and evolving. Rigid structured interviews work better in well-understood domains where the BA can ask precise, informed questions. Reducing prototyping in a novel domain removes one of the most valuable tools for discovering unknown requirements.