Быстрый старт

• Документ построен как use-case постановка: вы должны предложить архитектуру и реализацию, которая решает описанные сценарии.
• В ТЗ намеренно не фиксируются конкретные API-контракты, алгоритмы и внутренняя архитектура: это часть инженерного решения участника.
• Маркер «В истории:» — это сюжетный контекст/пример, который объясняет какую проблему закрывает требование. Это не требование само по себе.
  • Требования формулируются явно: «Система должна…», «Требование: …», «Ожидание: …».
• Структура документа:
  • Часть A — контекст, цели и единая картина.
  • Часть B — основной функционал (обязательно). (Эта часть описывает обязательный минимум, по которому жюри проверяет работоспособность и воспроизводимость решения.)
  • Часть C — расширения и усложнения (на выбор участника).
  • Часть D — что считается результатом участника.