Answer.

History of the Question

At the start of a large project, there is often a task to quickly gather and structure requirements, as the business demands a fast market entry. This often leads to formalism and loss of details, resulting in increased technical debt and the number of refinements after the MVP.

Problem

The main challenge is balancing speed and quality in processing requirements. Surface-level collection leads to fragmentation and increased changes during the implementation phase, while overly thorough collection slows down work and causes missed market opportunities.

Solution

• Formation of a requirements hierarchy: quick collection of high-level requirements with subsequent phased detailing (rolling wave planning).
• Conducting facilitation sessions and workshops with various stakeholders (Design Sprint, Event Storming).
• Using templates for user story mapping and prioritization matrix for the rapid identification of the product's "core".
• Introducing a transparent pre-grooming process: working out only key scenarios with an indication of risks and unclear areas.
• Focusing on visualizations (process maps, prototypes) to minimize distortion of requirements.

Key Features:

• Utilizing agile approaches for prioritizing and phased detailing of requirements.
• Formalizing unclear areas instead of ignoring unprocessed requirements.
• Regular reviews and involving the development team for timely identification of technical constraints.

Trick Questions.

Is it possible to accelerate the start of requirement collection by refusing to document secondary scenarios?

No. They need to be recorded as areas of risk or unprocessed items; otherwise, they will "surface" at later stages and result in revisions.

Should all identified requirements be validated at the start?

Only the key ones. The others should be marked as "to be clarified" and revisited in the nearest iterations.

Can only business representatives work with the requirements?

No, technical specialists must also be involved, as many constraints and architectural solutions can only be identified collaboratively.

Common Mistakes and Anti-Patterns

• "Digging in" only on happy paths without focusing on exception scenarios.
• Formal approval of undetailed requirements.
• Lack of a re-review phase at the start.

Real-life Example

Negative case: In a large project, to speed up the start, only the main business processes were worked out, ignoring the nuances of secondary scenarios. Pros: Fast prototyping and MVP output. Cons: Many returns for rework, delays in releases, and conflicts with the QA team.

Positive case: The analyst divided the process into phases, recorded risk areas, introduced procedures for weekly clarifications and prototyping confirmations. Pros: Reduction in the number of returns, transparency of uncertainty areas for the team. Cons: Higher workload for analysts in the first weeks.