Have you encountered projects where the requirements were not formulated as a technical specification?

Yes, in real projects, it is common to encounter situations where requirements are not documented as formal technical specifications (TS). Instead, they can be:

• User stories or use cases — descriptions of functionality from the user's perspective.
• Dialogues with the customer or verbal agreements — requirements are formed during communication.
• Prototypes and mockups — visual representations used for development.
• Agile approaches — requirements evolve during sprints and iterations.

In such cases, it is important to:

• Actively communicate with the customer to clarify details.
• Document agreements as they appear.
• Use flexible requirements management methods.

This helps to avoid misunderstandings and ensure the quality of the final product.