Answer.

History of the issue:

With the growth in scale and complexity of IT projects, there have repeatedly been situations where business requirements were received from business stakeholders in the form of abstract wishes, which, when passed to the development team, turned into something else. The cause is the gap in terminology, expectations, and level of abstraction between business and IT.

Problem:

If the decomposition stage is not well thought out, the requirements either become incomplete (critical details are omitted), excessively vague (impossible to estimate and implement), or are outright distorted due to lexical traps, overlooked terminology, and misunderstandings.

Solution:

The system analyst systematically decomposes each requirement: formalizes business terms, translates business goals into functions and tasks, describes user scenarios and system behavior, and ties them to acceptance criteria/test cases. It is important to use models (UML, BPMN), glossaries, checklists, and direct reviews between teams.

Key features:

Building a glossary of terms in collaboration with the client
Using diagrams and atomic formulations of requirements
Translating requirements into the language of acceptance criteria and test cases

Trick Questions.

Can business wishes be left in free form with further refinement during the development phase?

No, there is a high risk of misunderstanding and implementation errors.

Should implementation details (for example, how to store data) be clarified during the analysis phase?

No, analysis is about "what" and "why", not "how". Technical details are the responsibility of architecture and development.

Is one record of a requirement always equal to one module/feature?

No, often decomposition is required—large requirements are divided into sub-functions and user stories with separate acceptance criteria.

Typical Mistakes and Anti-Patterns

Mixing business language and technical terms without a glossary
Describing requirements as "vague wishes"
Violating atomicity—one requirement contains many different entities

Example from Real Life

Negative case: The client provided a list of wishes, "The user should see all sales analytics," which was copied to the technical specifications unchanged.

Pros:

Speed of document preparation

Cons:

Unclear which specific metrics and in what dimension are needed
Constant rework

Positive case: The analyst asked the client, compiled a list of necessary metrics, defined user roles, developed report prototypes, and agreed on the glossary of terms.