CAPM Practice: Determine how to gather requirements

The three-part user story format ensures completeness: the user type clarifies who the story serves (preventing generic requirements), the feature describes the need (not the solution), and the benefit articulates why it matters (enabling priority decisions). Each part serves a specific requirements quality purpose.

**Why not A:** The "As a / I want / So that" format does not imply interchangeable or modular parts. The three clauses serve distinct purposes: identifying the user role, stating the desired capability, and articulating the business value. Each clause is essential and specific; removing or swapping them would break the structure's intent.

**Why not B:** User stories are not legal or contractual documents. The "As a / I want / So that" format is a lightweight communication tool designed to capture user needs and foster conversation. Treating user stories as binding contract requirements misunderstands their purpose and contradicts agile principles of collaboration over contract negotiation.

**Why not D:** The user story format is not exclusive to Scrum. It is widely used across agile methodologies including Kanban, SAFe, and XP, as well as in hybrid and predictive environments where teams want a concise way to express requirements from the user's perspective. Limiting it to Scrum artificially narrows its applicability.