технические характеристики мобильного приложения

Документ требованить к мобильному приложению

Каждый бизнес стремится к тому, чтобы стать следующим Airbnb или Uber, но получится это далеко не у всех. Если вы хотите создать продукт, который будет продавать, при его создании учитывайте потребности вашей аудитории, даже не самые очевидные. Отличным помощником в этом станет подробный документ требований к мобильному приложению.

Что такое документ требований?

Документ требований к продукту (на английском PRD — product requirements document) определяет ценность и назначение приложения для вас самих и для команды разработчиков. С помощью этого документа вы сможете объяснить разработчикам для кого предназначен продукт и какую пользу он приносит конечному пользователю. PRD направляет разработку продукта, обеспечивая понимание цели, стоящей за приложением. Документ описывает бизнес-логику продукта, содержит все технические характеристики и помогает команде разработчиков преобразовать раннюю концепцию в полнофункциональное приложение.

В статье мы расскажем, как составить идеальный PRD, который поможет продукту пройти путь от идеи до выхода на рынок.

Потребности бизнеса

Любое мобильное приложение создаётся для решения определённых задач. Потребности бизнеса в PDR описывают как приложение будет отвечать нуждам компании и пользователей.

При составлении бизнес-требований необходимо учитывать следующие моменты:

Цели мобильного приложения

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

Уровень доступа пользователей

В PRD необходимо включить описание уровня доступа и прав для разных групп пользователей (например, администратор, гость, зарегистрированный пользователь). Вы должно чётко понимать, как каждая группа пользователей будет взаимодействовать с приложением, что подстегнёт гостя пройти регистрацию.

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

Каким вы видите ваше мобильное приложение?

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

Составьте список функций

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

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

Стратегия монетизации

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

Реклама — вы получаете доход за счёт продажи рекламного пространства и показа рекламы в приложении.

Оплата за загрузку — самая старая и самая простая модель монетизации приложений. Пользователи оплачивают приложение перед его загрузкой и после установки получают доступ ко всему функционалу продукта.

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

Фримиум — при такой модели пользователи бесплатно загружают приложение, но определённые функции становятся доступны только после оплаты.

Подписка — эта модель похожа на фримиум, только бесплатная версия приложения ограничивает доступ не к функциям, а к контенту.

Технические характеристики

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

В документе требований к мобильному приложению обязательно должны быть указаны следующие параметры:

На каких платформах будет доступно приложение (iOS, Android или Windows)?

Какие версии операционной системы должны его поддерживать?

Каковы ваши потребности в обслуживании? Необходима ли дальнейшая поддержка специалистов?

Есть ли у вас текущая документация по API/сервисам?

Есть ли у вас текущие учётные записи Apple, Google или других разработчиков?

Каковы ваши текущие сервисы, серверы, базы данных?

Выбор платформы

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

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

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

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

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

Техническое обслуживание и модернизация

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

Допущения и ограничения

Допущения, как правило, связаны с прогнозами поведения и взаимодействия пользователей с приложением. Также в этот раздел важно включить предположения, касающиеся технических и бизнес аспектов продукта. Например, какой процент пользователей увидит в продукте достаточно ценности, чтобы регулярно его использовать; будет ли работать приложение на самой последней ОС, в какие сроки продукт будет готов к релизу.

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

Подготовка к загрузке в магазины

В документе требований обязательно должна содержаться информация, необходимая для загрузки приложения в Apple App Store и Google Play. Разработчики знают требования магазинов и смогут подсказать, что именно нужно, какие нюансы следует учитывать в процессе разработки, чтобы облегчить подачу заявки.

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

Краткое и полное описание приложения, а также правильно подобранные ключевые слова помогут в продвижении продукта.

Вместо заключения

Составляя PRD, помните, главная цель документа — обеспечить фундамент для успешного продукта. Чтобы команда разработчиков могла создать продукт мечты, убедитесь, что вы указали все технические и бизнес-требования, ограничения и предположения. Однако будьте готовы к тому, что во время разработки возникнут вопросы. Это неизбежно даже при самом тщательно составленном PRD.

Источник

Каким должно быть ТЗ для мобильного приложения

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

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

Зачем нужно ТЗ, и что это вообще

Начиная наш разговор, давайте уточним, что ТЗ на разработку системы или приложения — это зачастую не единичный документ, шаблон которого можно найти в Интернете, а группа создаваемых документов (“артефактов”).

Хорошее ТЗ максимально четко и однозначно определяет требования к проекту и для команды, и для бизнеса, делая очевидными конечные цели и задачи. Благодаря нему уточнять требования к проекту по ходу разработки нужно существенно реже, а приёмка готового продукта происходит проще и быстрее.

ТЗ бывают крайне разными. Наполнение и содержание напрямую зависит от проекта, процессов разработки и подхода к ней. Например, ТЗ для приложения, которое создается по модели Waterfall, не совпадает с ТЗ приложения, команда которого работает по Agile.

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

Для нас это не так. То, зачем и в каком объёме пишется ТЗ, в каждом случае определяется командой. Мы формируем его на основе конкретных задач проекта, списка пользовательских требований и критериев качества, а не по стандартным лекалам. На выходе это — набор смысловых блоков, разделов документа, который определяет необходимые и достаточные требования бизнеса и команды разработки.

Задача аналитика при создании ТЗ

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

Со стороны бизнеса это, как правило — собственники, руководители, акционеры. Со стороны разработки: разработчики, проджект-менеджеры, QA-специалисты и др. Со стороны внешних систем (от бизнеса или технической команды исполнителя) — архитекторы ПО либо разработчики.

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

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

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

Примером объемного ТЗ является ТЗ, написанное по ГОСТ. С такими мы работаем редко, документы этого типа нечасто требуются клиентам. Они нужны, когда ожидается многоступенчатое согласование деталей. Например, с госструктурами без ТЗ по ГОСТ работать проблематично: слишком много стейкхолдеров участвует в обсуждении проектов.

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

Процесс проработки ТЗ

Каковы границы проекта? Аналитик начинает прорабатывать любое ТЗ с поиска ответа на этот вопрос. Чтобы разобраться, нужно:

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

Этапы проработки ТЗ:

1#

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

Также на этом этапе аналитики определяют основной скоуп фич (набор функционала) и цель создания каждой фичи. Иначе говоря, мы определяем, что надо сделать, а главное — зачем.

2#

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

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

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

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

Выбрав критерии качества, актуальные для проекта, мы снова определяем, какие ожидания есть у стейкхолдеров, вносим технические коррективы и проясняем, что нужно команде, чтобы продолжить работу.

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

3#

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

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

Особенности ТЗ мобильного приложения

Критично важно сразу учесть, на какой платформе будет выпущено приложение. Это задаёт технические ограничения и базовые характеристики. Например, в приложении на Android кнопка “Назад” на экране не обязательна, а в iOS необходима, потому что нет физической кнопки “Назад”.

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

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

Всегда ли нужно детально прорабатывать ТЗ?

Как показывает опыт Azoft, есть случаи, когда важно прорабатывать ТЗ с начала проекта, а есть — когда можно начать с верхнеуровневого описания и динамично стартовать по Agile.

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

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

ТЗ помогает, когда клиент выбирает подрядчика среди множества вариантов, сравнивая условия сотрудничества. Четкое и однозначное ТЗ — возможность убедиться, что все потенциальные подрядчики точно оценивают одно и тоже, и это именно то, что требуется клиенту. Оно позволяет выбрать команду разработки более взвешенно.

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

Детальное ТЗ необязательно, а иногда даже вредно для проекта, когда:

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

Заключение

Аналитику невозможно не делать — для разработки проекта команда в любом случае должна прояснить и уточнить все требования к нему. Часть этого процесса начинается ещё до разработки системы, часть происходит во время неё. Клиент выбирает: либо он контролирует аналитику, либо аналитика протекает стихийно.

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

ТЗ помогает:

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

Источник

ТЕХНИЧЕСКОЕ ЗАДАНИЕ НА РАЗРАБОТКУ МОБИЛЬНОГО ПРИЛОЖЕНИЯ

by Андрей Вакурин · Published 15.08.2017 · Updated 25.02.2021

2.1 Предмет разработки

2.2 Назначение документа

3.1 Требования к дизайну сайта

3.2 Порядок утверждения дизайн-концепции

4.1 Классы пользователей

4.2 Требования к представлению сайта

4.3 Требования к системе управления сайтом

4.4 Требования к разделению доступа

5.1 Требования к информационному обеспечению

5.2 Требования к программному обеспечению

5.3 Требования к техническому обеспечению

5.4 Требования к лингвистическому обеспечению

5.5 Требования к эргономике и технической эстетике

6.1 Требования к наполнению информацией

6.2 Требования к персоналу

6.3 Порядок предоставления дистрибутива

6.4 Порядок переноса сайта на технические средства заказчика