Answer.

In situations of constant change and high uncertainty, it is important to choose flexible and dynamic methods for requirements gathering. The main goal is to quickly obtain information, minimize the risks of misunderstanding, and be prepared for changes at any stage.

The main strategies include:

1. Iterative (Agile) approach: working on requirements goes parallel with implementation, using constant feedback from stakeholders.
2. Incremental gathering: requirements are fixed and clarified step-by-step, starting with the most important and fundamental ones, gradually moving to details.
3. Prototyping: creating quick prototypes or mock-ups of products to validate hypotheses and obtain detailed requirements from users.
4. Regular review of requirements: planned sessions for analyzing and adjusting requirements to update goals and customer expectations.

Key features:

• A developed culture of interaction with the client is required.
• It is necessary to maintain traceability of changes in requirements.
• It is important to keep transparent documentation at every stage.

Trick Questions.

Is it possible to completely abandon formal documentation in flexible approaches to requirements gathering?

No, even in an Agile approach, current documentation is necessary to record agreements, critical acceptance criteria, and minimize the risk of misunderstanding.

Is it enough to rely solely on interviews for gathering requirements in uncertain conditions?

Mistake. Interviews are a useful tool, but for structured work, additional techniques are used: workshops, empathy maps, observation, prototyping. Only a combination gives a complete picture.

Is successful requirements gathering possible without regular feedback from end users?

No, feedback is essential for timely adjustments in the direction of development and fixing new, changed expectations.

Typical Mistakes and Anti-Patterns

• Attempting to implement all requirements at once, without phases.
• Ignoring documentation, relying only on verbal agreements.
• Unsystematic collection of feedback.

Real-Life Example

Negative case: In a startup, lacking formalized requirements, developers worked only on verbal requests from the client.

Pros:

• Quick response to client requests.

Cons:

• Constant reworks.
• Conflicts due to misunderstandings.
• Straying from the original goals of the product.

Positive case: A business analyst at an e-commerce company proposed pilot prototypes and organized feedback sprints, recording results in the documentation system.

Pros:

• Requirements are relevant at each stage.
• Minimization of errors.

Cons:

• Increased number of meetings.
• Additional labor costs on documentation.