Для первой оценки iOS-приложения опишите одного пользователя, одну задачу и результат, который он должен получить. Затем добавьте данные, состояния ошибок и проверки. Такой бриф помогает обсудить небольшую первую версию ещё до подробного технического задания.
Ниже — шаблон и заполненный учебный пример. Они не устанавливают цену, срок или универсальное число экранов.
Сценарий важнее названия функции
«Добавить список покупок» звучит коротко, но оставляет вопросы: кто его ведёт, нужен ли общий доступ, что происходит без сети, как сохраняются изменения? Эти ответы меняют объём работы.
Запишите путь от начала до результата: «Человек составляет список дома, закрывает приложение, открывает его в магазине и отмечает купленное». После этого можно назвать нужные состояния интерфейса и то, что пока остаётся за границами.
Бриф для копирования
1. Пользователь: кто откроет приложение?
2. Ситуация: где и зачем оно ему понадобится?
3. Начало: что у пользователя есть до первого действия?
4. Результат: что должно получиться в конце сценария?
5. Действия: какой путь ведёт к результату?
6. Состояния: что показываем при пустых данных и ошибках?
7. Данные: что сохраняется и на каком устройстве или сервере?
8. Сеть: какие действия должны работать без подключения?
9. Аккаунты: действительно ли нужны вход и несколько пользователей?
10. Устройства: iPhone, iPad, версии системы, языки?
11. Материалы: какие тексты, изображения и данные уже готовы?
12. Сервисы: какие внешние системы нужны и кто ими управляет?
13. Границы: какие функции не входят в первую версию?
14. Приёмка: как проверить сценарий на рабочей сборке?
15. Передача и выпуск: что получаем и нужен ли App Store?Если ответа нет, пометьте его как открытый вопрос. Не вставляйте в документ пароли, ключи или реальные данные пользователей: для оценки нужны схема и назначение доступа.
Учебный пример: локальный список покупок
Это пример ограничения объёма, не клиентский кейс и не история первого выпуска BAGGO. Все действия ниже — требования к вымышленной первой версии, а не отчёт о выполненной работе.
| Поле | Ответ |
|---|---|
| Пользователь | Человек, который сам составляет покупки и идёт с этим списком в магазин |
| Результат | Добавленные дома товары видны в магазине; купленное отмечено |
| Интерфейс | Список с пустым состоянием и форма добавления названия |
| Действия | Добавить, отменить ввод, отметить, снять отметку, удалить товар |
| Данные | Название и отметка покупки; сохранение на одном устройстве |
| Без сети | Основной сценарий доступен без подключения |
| За границами | Совместный доступ, аккаунты, синхронизация, голос, фото, рецепты, скидочные карты и покупки в приложении |
| До начала работ | Согласовать устройства, версии iOS, язык и способ проверки сборки |
| Выпуск | Подготовку App Store оценить отдельно, если она нужна |
Список и форма добавления — не вся задача сами по себе. В объём входят пустое состояние, отмена, неверный ввод и повторное открытие приложения.
Проверки для этого примера
- Непустое название создаёт одну строку товара.
- Отмена добавления оставляет список прежним.
- Пустое название не сохраняется; понятно, что исправить.
- Отметка покупки включается и снимается.
- Удаляется выбранный товар.
- После закрытия и повторного открытия остаются названия и отметки.
- Сценарий проходит без сети на согласованном устройстве.
- Длинное название и увеличенный текст не скрывают основные действия.
Проверки привязывают к номеру сборки, устройству и версии системы. Скриншот подтверждает внешний вид одного состояния; сохранение данных и работу без сети проверяют действиями.
Что расширит первую версию
Общий доступ. Понадобится определить участников, передачу изменений и поведение при одновременном редактировании.
Фото или голос. Нужно описать разрешения, отмену, неудачное распознавание и исправление результата.
Оплата. Появляются отдельные состояния покупки, отмены, недоступности и восстановления, если оно применимо к выбранному продукту.
Сервер. Нужно определить данные, доступы, работу при недоступности сервиса и расходы на его поддержку. Сервер не следует автоматически из слова «приложение»; его необходимость определяется сценарием.
Каждое расширение сначала добавляют в бриф и оценку. «Сделаем позже» тоже стоит записать, чтобы функция не считалась частью первоначальной договорённости.
Как получить рабочую сборку на проверку
До разработки согласуйте способ установки и круг проверяющих. Один из вариантов — TestFlight: Apple описывает его как способ тестировать сборки и собирать отзывы до публичного выпуска. Конкретный путь зависит от аккаунта и способа распространения.
Зафиксируйте, что именно проверяется в этой сборке. Наличие установленного приложения ещё не подтверждает приёмку всего объёма. Решение о допуске в App Store принимает Apple по своим правилам проверки.
Что записать для передачи проекта
- Где находятся исходники и какая версия соответствует переданной сборке.
- Как собрать проект и какие зависимости нужны.
- Какие устройства, языки и версии системы проверены.
- Какие внешние сервисы подключены и кто управляет аккаунтами.
- Какие проверки выполнены, какие замечания остаются открытыми.
- Входит ли подготовка к публикации и что потребуется от владельца аккаунта.
- Как согласуются исправления и новые функции после передачи.
Не все проекты требуют одинакового набора сервисов и документов. Этот список помогает задать вопросы до оценки, а не автоматически включает их в любую услугу.
Заполненный бриф можно использовать для обсуждения разработки небольшого iOS-приложения. Даже с открытыми вопросами он показывает основной сценарий и границы первой версии.