ТЗ на iOS-приложение: устройства, состояния и приёмка на iPhone

Зафиксируйте результат первой версии

ТЗ на iOS-приложение должно связывать экраны с законченными действиями пользователя. Список разделов не объясняет, что произойдёт после потери сети, отказа в разрешении или повторного нажатия. Начните с задач, которые человек должен выполнить, и данных, подтверждающих результат. Затем определите границы первой версии и функции, которые сознательно остаются на следующих этапах.

Для каждого сценария укажите роль, исходное состояние, действие и конечный факт. В учебном приложении записи на занятия пользователь выбирает время, подтверждает запись и видит её в расписании. Отдельно разбираются занятое место, отмена, перенос и повторный вход. Это пример подготовки требований, а не описание запущенного клиентского продукта.

Соберите реальные ограничения бизнеса: кто меняет расписание, откуда приходит наличие мест, какая система подтверждает запись. Если серверное API ещё не готово, это зависимость проекта с владельцем и сроком решения. Приложение не может гарантировать корректность данных, которые внешняя система не предоставляет. В брифе полезно различать готовую возможность, гипотезу и требование к смежной команде.

Согласуйте устройства и условия использования

Определите поддерживаемые устройства, версии системы, ориентации, языки и особенности аудитории. Матрица должна соответствовать функциям и реальным пользователям, а не случайному телефону разработчика. Если продукт предназначен только для iPhone, это отдельное решение; если предполагается iPad, нужны соответствующие сценарии и проверка компоновки.

Укажите условия использования: одной рукой, на улице, в помещении со слабой сетью, при увеличенном размере текста. Для важных действий задайте измеряемые требования к отклику в определённой среде. Не используйте абстрактное «работает быстро на всех устройствах». Нужны конкретные операции, тестовые данные и способ фиксировать результат, включая задержки внешних сервисов.

Apple рекомендует проверять совместимые устройства перед отправкой приложения на рассмотрение. Симулятор помогает разработке, но не заменяет реальные проверки аппаратных функций и взаимодействия. В приёмочном плане назовите физические устройства, ответственных и версию сборки. Если часть матрицы не проверена, это должно быть видно в отчёте, а не скрыто общей отметкой «мобильная версия готова».

Опишите данные и поведение без сети

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

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

В учебном приложении пользователь нажимает «записаться», теряет сеть и открывает приложение заново. Требования должны определить, увидит ли он ожидающую проверку операцию, восстановленную запись или понятное предложение повторить действие. Проверьте также смену устройства и одновременные действия в двух сессиях. Конфликты должны разрешаться по согласованному правилу, а не по случайному порядку последних ответов.

Продумайте разрешения и жизненный цикл

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

Проверьте чистую установку, повторный запуск, возврат из настроек и изменение доступа пользователем. Уведомление может не прийти по причинам вне приложения, поэтому важное состояние должно быть доступно внутри продукта. Если человек запретил уведомления, нельзя считать, что он обязательно получил сообщение о переносе занятия; бизнес-процесс должен учитывать согласованные каналы связи.

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

Проверьте доступность на ключевых действиях

Доступность следует описывать через реальные задачи: найти занятие, изменить данные, понять ошибку и подтвердить действие. В документации Apple рассматриваются проверки с VoiceOver, увеличенным текстом и другими средствами взаимодействия. Для проекта важно выбрать применимые сценарии и воспроизвести их на реализованном интерфейсе.

Проверьте смысловые названия элементов, порядок перехода, озвучивание состояния и ошибок. Иконка без понятного имени может выглядеть очевидной в макете и оставаться непонятной при использовании VoiceOver. Увеличение текста должно сохранять доступ к основным действиям и содержанию. Не принимайте экран только по тому, что текст визуально стал крупнее, если кнопка подтверждения ушла за недоступную область.

В учебном сценарии пользователь выбирает дату, получает сообщение о занятом месте и возвращается к доступным вариантам. Проверяется весь маршрут, включая изменение фокуса и объяснение ошибки. Зафиксируйте сочетание устройства, системы и вспомогательной технологии. Автоматическая проверка полезна для части проблем, но не заменяет прохождение задачи человеком по согласованному протоколу.

Разделите сборку, приёмку и распространение

Определите владельцев аккаунтов, идентификаторов приложения, сертификатов и материалов для публикации. Укажите, кто предоставляет описание, изображения, сведения о данных и доступы для проверки, если они нужны. Нельзя оставлять эти зависимости на последний день: технически готовая сборка может оказаться неготовой к выбранному способу распространения.

Согласуйте доставку тестовой сборки, например через предусмотренный Apple канал TestFlight, если он подходит проекту. У каждой проверки должны быть версия приложения, среда сервера и набор данных. Замена сборки во время приёмки без фиксации версии делает отчёт неоднозначным: найденную ошибку трудно связать с конкретной реализацией.

Приёмка заказчиком и рассмотрение App Review — разные этапы. В требованиях фиксируют подготовку к подаче, обработку замечаний и ответственность участников, но не гарантированное решение внешней проверки. Отдельно согласуйте, что считается завершением разработки, публикации и поддержки после релиза. Это позволяет планировать работу без обещания результата, который команда не контролирует напрямую.

Соберите воспроизводимую матрицу испытаний

Для каждого критичного сценария подготовьте положительный путь и значимые исключения. Включите неверные данные, истёкшую сессию, отказ сервера, медленную сеть, повтор операции и изменение разрешения. Привяжите тесты к устройствам и ролям. Набор должен проверять риски продукта, а не состоять из десятков одинаковых открытий экрана.

Учебная проверка записи: два пользователя выбирают последнее место, один получает подтверждение, другой — корректный отказ и доступный следующий шаг. Затем первый открывает приложение после перезапуска и видит согласованное состояние. Сверьте его с сервером. Такой тест обнаруживает проблему, которую не видно на демонстрации с заранее свободным расписанием.

Сохраняйте шаги, время, версию, ожидаемое и фактическое поведение. При необходимости приложите запись экрана без реальных чувствительных данных. После исправления повторите сценарий и соседние операции, на которые повлияло изменение. Завершение проверки должно означать подтверждённое состояние требований; непроверенные устройства и известные ограничения перечисляют отдельно с решением ответственного лица.

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

Второй пример проверяет доступность формы. На согласованном устройстве включают увеличенный текст и VoiceOver, затем проходят выбор занятия, ввод данных и исправление ошибки. Проверяют порядок фокуса, названия кнопок и озвучивание результата. После появления ошибки человек должен понять, какое поле требует действия, и иметь возможность вернуться к нему. В протоколе сохраняют версию системы, сборку и настройки проверки. Если найденное ограничение относится только к одному состоянию, его всё равно описывают точно: общий вывод «экран доступен» не заменяет воспроизводимого результата по цепочке.

В оценке разработки выделите клиентскую часть, серверные изменения, интеграции, тестирование устройств и подготовку распространения. Если API уже существует, проверьте, предоставляет ли оно необходимые состояния и идентификаторы повторных операций. Недостающая серверная возможность не возникает автоматически из мобильного макета. Уточните, кто оплачивает и предоставляет тестовые устройства, кто управляет аккаунтом разработчика и кто готовит материалы для проверки. Отдельно обозначьте работу после замечаний внешнего канала распространения. Список зависимостей должен позволять понять, что блокирует следующую сборку и кто принимает решение. Для функций следующей очереди укажите только необходимые сейчас точки расширения, не заставляя команду реализовывать неизвестный будущий продукт. Тогда первая версия остаётся ограниченной по объёму, но её данные, доступы и процесс выпуска не превращаются в тупик при дальнейшем развитии.

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

Передайте обновляемый продукт, а не архив экранов

Пакет передачи включает исходники, инструкции сборки, настройки окружений, документацию API и перечень внешних зависимостей. Укажите, где хранятся секреты и кто управляет доступом. Проверьте, что другой разработчик может собрать согласованную версию по инструкции. Архив без работоспособного процесса сборки не обеспечивает самостоятельность владельца.

Согласуйте наблюдение после выпуска: ошибки, незавершённые операции, обращения пользователей и изменения совместимости. Метрики должны иметь определения и ограничения; установки приложения не равны активным клиентам, а события открытия не доказывают успешное выполнение задачи. Назначьте владельца разбора и порядок выпуска исправлений, включая проверку совместимости с сервером.

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