ТЗ на мобильное приложение: полное руководство

Коротко: Чтобы составить техническое задание на мобильное приложение, необходимо зафиксировать функциональные требования, архитектуру, требования к безопасности (включая актуальные нормы Минцифры на 2026 год) и технические параметры устройств. Грамотное ТЗ минимизирует риски перерасхода бюджета и позволяет реализовать разработку мобильного приложения под ключ без бесконечных правок в процессе.

Кстати, в AmSales мы делаем разработку мобильных приложений и внедрение и настройку Битрикс24 под ключ. Если нужна помощь - напишите нам.

Фундаментальные разделы технического задания на разработку

Разработка мобильного приложения под ключ - это процесс, который начинается не с дизайна, а с документа. Если вы решите пропустить этап проектирования, вы получите продукт, который не работает с вашей бизнес-логикой. ТЗ - это ваш юридический и технический щит. В нем должны быть четко прописаны не только "кнопки", но и логика взаимодействия между клиентом и сервером.

Первый критический раздел - это описание бизнес-целей и пользовательских сценариев (User Stories). Разработчик должен понимать, зачем пользователь открывает приложение. Он хочет купить товар, проверить статус доставки или записаться на прием? Без этого раздела архитектура будет "раздутой" и перегруженной лишними функциями, которые только удорожают проект.

Что обязательно должно быть в структуре документа:

• Общие сведения о проекте: цели, задачи, целевая аудитория.
• Терминологический словарь: чтобы "заказ" в приложении и в вашей базе данных означал одно и то же.
• Функциональные требования: подробное описание каждой функции.
• Нефункциональные требования: производительность, безопасность, масштабируемость.
• Стек технологий: на каких языках и фреймворках будет строиться решение.

Важно понимать, что требования к мобильному приложению ТЗ должны учитывать не только интерфейс, но и серверную часть (Backend). Часто заказчики забывают указать, как приложение должно вести себя при потере связи. Если в ТЗ не прописана работа в офлайн-режиме, вы получите приложение, которое "зависает" при каждом переходе через тоннель или при слабом сигнале 4G.

Еще один важный момент - интеграции. Приложение редко живет само по себе. Ему нужно обмениваться данными с вашей CRM, учетной системой 1С или внешними сервисами доставки. Если не прописать формат передачи данных (например, через REST API) и частоту синхронизации, этап интеграции превратится в бесконечный процесс переделок.

Выбор поддерживаемых версий iOS и Android

Один из самых болезненных вопросов для бюджета - это охват аудитории. Чем больше старых версий ОС вы поддерживаете, тем дороже обходится разработка и тестирование. Разработчики вынуждены писать код так, чтобы он был совместим со старыми библиотеками, что ограничивает использование современных фишек системы.

На текущий момент, 17 октября 2026 года, рынок четко разделился. Опираться стоит на данные популярных сервисов. Например, если мы посмотрим на требования к государственным сервисам, таким как "Госуслуги Дом", то увидим, что минимальный порог составляет Android 9+ и iOS 13+. Опускаться ниже этого смысла нет - доля пользователей на таких версиях ничтожна, а поддержка обходится слишком дорого.

Как определить порог версий для вашего бизнеса:

Для корпоративных приложений (для сотрудников) можно ставить более высокие требования (например, Android 12+ и iOS 15+), так как вы можете контролировать парк устройств компании. Для массовых потребительских продуктов (B2C) важно не "отрезать" часть аудитории, но и не уходить в глубокое прошлое.

При составлении технического задания на разработку iOS и Android учитывайте специфику обновлений. Apple и Google постоянно меняют правила работы с разрешениями (Permissions) и фоновыми процессами. Если ваше приложение требует работы в фоновом режиме (например, навигатор или трекер), требования к версии ОС будут жестче, чтобы использовать современные API для оптимизации энергопотребления.

Пример из практики: если вы планируете использовать сложные AR-технологии (дополненную реальность), вам придется ориентироваться на устройства не старше 2-3 лет. Игнорирование этого факта в ТЗ приведет к тому, что вы закажете разработку, которая просто не запустится на 70% устройств вашей целевой аудитории.

Авторизация и интеграция с государственными сервисами

Современное мобильное приложение в РФ практически невозможно представить без бесшовного входа. Пользователи не хотят заполнять 20 полей в форме регистрации. Они хотят нажать одну кнопку и войти. Это диктует необходимость интеграции с федеральными системами идентификации.

Одним из ключевых трендов 2026 года является использование "Госуслуг Моя школа". Это единое приложение, которое стало стандартом для образовательной среды. Важно помнить, что вход в подобные системы осуществляется строго через подтвержденную учетную запись. Если ваше приложение предполагает взаимодействие с образовательными или социальными институтами, в ТЗ должен быть четко прописан протокол OAuth для интеграции с ЕСИА.

Также стоит учитывать специфику региональных сервисов. Не все системы работают через единый шлюз, иногда требуется реализация собственных методов авторизации через SMS или Telegram-ботов. В ТЗ должно быть указано, как обрабатывается сценарий, если пользователь не может пройти авторизацию (например, не пришел код или учетная запись заблокирована).

Не забудьте про биометрию. FaceID и TouchID (или их современные аналоги на Android) - это не "фишка", а стандарт удобства. В ТЗ нужно указать, является ли биометрическая авторизация обязательной или это опциональный удобный способ входа после первичного ввода пароля.

Требования к безопасности и защите персональных данных

Безопасность - это не просто "пароль из 8 символов". Это сложная юридическая и техническая надстройка. С 2026 года требования к защите персональных данных (ПДн) стали еще жестче. Несоблюдение норм может привести к оборотным штрафам, которые могут обанкротить бизнес.

Важно опираться на актуальное законодательство. Например, приказ Минцифры России от 24.07.2026 № 676 внес существенные изменения в требования к мобильным решениям и интеграциям. Эти изменения вступили в силу в июле 2026 года и действуют до июня 2029 года. Это означает, что архитектура приложения должна изначально проектироваться с учетом новых протоколов передачи данных и методов шифрования.

При разработке необходимо учитывать:

1. Место хранения данных (серверы должны находиться на территории РФ).
2. Способы обезличивания данных при передаче для аналитики.
3. Механизмы отзыва согласия на обработку персональных данных.
4. Логирование всех действий администраторов и пользователей.

Пример: если вы разрабатываете медицинское приложение, требования к защите ПДн будут соответствовать высшим уровням защищенности. Даже для обычного интернет-магазина важно иметь четкую политику обработки персональных данных, которая соответствует актуальным редакциям приказов Минцифры. Не пытайтесь использовать старые шаблоны 2024 года - они уже не актуальны.

Минимальные характеристики устройств и сетевого оборудования

В ТЗ нельзя просто написать "должно работать на смартфонах". Это не техническое требование. Вы должны четко ограничить круг поддерживаемого оборудования, чтобы разработчики не тратили время на оптимизацию под "калькуляторы".

Для понимания ориентира можно взять требования к специализированным решениям. Например, мобильное приложение "Инспектор" имеет жестко заданные характеристики: экран от 4 дюймов, ОЗУ от 3 ГБ, память от 32 ГБ, разрешение от 1920×1080, поддержка сетей 3G/4G/LTE/Wi-Fi, наличие GPS/ГЛОНАСС и камера не ниже 8 МП. Это пример того, как четко прописанные параметры определяют функционал: если у пользователя камера 5 МП, приложение может просто не запустить функцию сканирования документов.

При проектировании учитывайте следующие параметры:

Также важно прописать требования к сетевому оборудованию. Если ваше приложение предназначено для работы на складах или в удаленных регионах, где связь нестабильна, в ТЗ должны быть прописаны механизмы автоматического переподключения и кэширования запросов. Иначе пользователи будут видеть бесконечные "крутилки" загрузки.

Каналы дистрибуции и требования к сторам

Выбор площадки для распространения приложения напрямую влияет на способ разработки и процесс обновления. В 2026 году ситуация с магазинами приложений в РФ требует гибридного подхода. Вы не можете полагаться только на один канал.

Основной упор сейчас делается на отечественные сторы. Например, для приложений, ориентированных на российский рынок, обязательным каналом является RuStore. Также актуальны AppGallery и другие альтернативные магазины. Если ваше приложение критически важное (например, банковское или государственное), вам нужно закладывать в ТЗ процесс публикации в нескольких сторах одновременно, так как требования к модерации у них различаются.

При подготовке к публикации в App Store и Google Play (если они доступны в вашем регионе) учитывайте их жесткие правила модерации. Apple, например, крайне требовательна к дизайну и прозрачности использования данных. Если в ТЗ не заложен механизм "App Tracking Transparency" (запрос на отслеживание), ваше приложение может быть отклонено при первой же проверке.

Не забудьте про механизмы обновления. В ТЗ должно быть описано, как приложение будет уведомлять пользователя о необходимости обновления. Это критично для безопасности: если вы нашли уязвимость, вам нужно, чтобы пользователи как можно быстрее перешли на новую версию. Для этого стоит закладывать механизм "принудительного обновления" (Force Update) для критических патчей.

Типичные ошибки при постановке задач разработчикам

Даже если вы решили составить техническое задание на мобильное приложение, вы можете совершить ошибки, которые "съедят" бюджет. Самая частая - это отсутствие описания негативных сценариев. Разработчики всегда пишут код для "счастливого пути" (happy path) - когда всё работает правильно. Но в реальности всё ломается именно тогда, когда интернет пропадает, память заканчивается, а пользователь нажимает не на ту кнопку.

Вторая ошибка - избыточность. "Сделайте, чтобы приложение было быстрым и красивым" - это не требование. Это пожелание. Быстро - это сколько? 200 мс на отклик или 2 секунды? Красиво - это по какому гайдбуку? В ТЗ должны быть конкретные метрики: время отклика, объем потребляемого трафика, требования к качеству графики.

Еще одна проблема - игнорирование юридической чистоты. Например, если вы не учли актуальные требования к обработке ПДн (такие как изменения в приказах Минцифры от 2026 года), вам придется переделывать архитектуру базы данных и механизмы шифрования уже после запуска. Это в разы дороже, чем заложить это на старте.

Типичные ошибки кратко:

1. Отсутствие требований к офлайн-режиму.
2. Размытые требования к производительности.
3. Игнорирование специфики различных версий ОС.
4. Недостаточное описание интеграций с внешними сервисами.
5. Неправильный выбор каналов дистрибуции.

Также часто забывают про "Edge Cases" (крайние случаи). Что будет, если пользователь нажал "Оплатить" и в этот момент у него разрядился телефон? Что будет, если у него одновременно включены два VPN? Ответы на эти вопросы должны быть в ТЗ, иначе разработчик будет принимать решения на свое усмотрение, и результат вам вряд ли понравится.

Что запомнить:

• ТЗ должно содержать не только функции, но и требования к безопасности согласно актуальным приказам Минцифры (например, № 676 от 2026 г.).
• Определяйте минимальные характеристики устройств (ОЗУ, память, версия ОС) на этапе проектирования.
• Всегда учитывайте специфику дистрибуции в РФ (RuStore, AppGallery) и требования к авторизации через ЕСИА.
• Избегайте общих слов - используйте метрики и конкретные технические параметры.