Answer

Background:
At the beginning of a project, clients often articulate tasks insufficiently clearly: goals can be general, and details may be unwritten. This is typical at the start of new directions or digitalizing traditional processes. The analyst encounters conflicting desires and fragmented ideas about the future product.

Problem:
Uncertainty in requirements leads to a risk of design errors, conflicts, delays in timelines, and increased budgets. Bottlenecks stem from contradictions among stakeholders and the inability to assess workload.

Solution:
The analyst should organize a phased approach to requirements elicitation:

1. Conduct interviews and facilitation sessions with key stakeholders to uncover not only explicit but also hidden expectations.
2. Use prototyping techniques and MVP creation for rapid feedback.
3. Apply analytical tools: user stories, business process diagrams, as well as methods for clarifying questions (5 Whys, clarifying "what does success mean" etc.).
4. Document all assumptions and align them with the business — this helps reduce the level of uncertainty.

Key features:

• Structured approach to clarifying incomplete requirements
• Use of various techniques to gather hidden information
• Mandatory documentation and bringing assumptions for agreement

Tricky Questions.

What documentation is required for implicit requirements: is it enough to just record a user story?

User stories are a useful tool, but they do not reveal all nuances if requirements are vague. It is necessary to develop additional artifacts: screen prototypes, examples of use cases, and business rules tables.

What is more important at the start — to quickly achieve results (MVP) or to fully gather requirements?

The balance between speed and completeness depends on the situation. At the start, a minimally viable product (MVP) that provides feedback and helps quickly adjust vision is more valuable than a lengthy agreement on the entire spectrum of requirements.

Can decisions be made based only on the client’s words?

No. The client expresses wishes that may not take into account technical details and constraints. The analyst must validate wishes through an understanding of processes, seek alternative opinions, and analyze consequences.

Common Mistakes and Anti-Patterns

• Blindly trusting the client’s words without detailed process analysis
• Directly translating vague requirements into development tasks
• Neglecting feedback on intermediate results

Real-Life Examples

Negative Case: The analyst recorded only the client’s wishes and handed them to developers. Result: functionality was implemented that did not address actual business tasks. Pros: Development started quickly. Cons: The product was not used, much rework was needed.

Positive Case: The analyst held a series of meetings with users, built a prototype, and agreed on scenarios. Requirements were clarified — the MVP quickly brought value to the business. Pros: Rapid value, positive feedback, minimal rework. Cons: A bit more time was spent on the requirements gathering stage.