requirements-gathering

Start with stakeholder mapping using an onion model or power/interest grid, then choose techniques by scope: Example Mapping for small features, Story Mapping for epics, and Big-Picture Event Storming for greenfield work. Timebox sessions and capture rules, examples, and open questions.

MoSCoW shortlists items against a fixed timebox, RICE scores Reach times Impact times Confidence divided by Effort for analytics-backed backlogs, and WSJF divides Cost of Delay by job size for large multi-team organizations. Mature teams often combine them, such as MoSCoW to shortlist then RICE to rank.

Use Planguage: define a Scale (unit of measure), Meter (measurement method), Past benchmark, and Goal or Must target levels. Avoid adjective-based requirements like fast or user-friendly, and anchor targets such as 99.9 percent availability or WCAG 2.1 AA accessibility.

A user story follows the format as a role, I want a goal, so that a benefit, and is tested against INVEST criteria. A job story uses when a situation, I want a motivation, so I can an outcome, replacing personas with situations to avoid prescribing solutions prematurely.

Event Storming models domain events on a timeline to discover bounded contexts and business processes, ideal for exploring unfamiliar domains. Story Mapping organizes user activities into a backbone with prioritized slices, best for planning releases from an understood problem space.

AI can draft user stories, detect ambiguity, and generate acceptance criteria, but it cannot replace tacit-knowledge elicitation or live interview probing. Risks include hallucinated requirements and bias propagation, so human-in-the-loop review is mandatory for all AI-assisted requirements work.