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

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

Содержание:

1. Почему вам следует написать документ с требованиями к продукту для мобильного приложения
2. Типы требований
3. Бизнес-требования
4. Требования пользователя
5. Системные Требования
6. Способы разработки требований и управления ими
7. Характеристики хорошего документа с требованиями к разработке мобильных приложений
8. Шаблон документа с требованиями к мобильному приложению

Зачем нужно писать документ с требованиями к продукту для мобильных приложений (PRD)?

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

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

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

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

• Получите оперативную разработку и поставку. Имея в поле зрения задокументированные требования к мобильному приложению, ваша команда разработчиков может лучше понять ваш проект, установить приоритеты и сократить количество переделок.

• Убедитесь, что окончательная версия приложения соответствует вашим ожиданиям по качеству. Благодаря критериям приемлемости, изложенным в PRD, ваша команда может легко определить, удовлетворены ли вы поставленным приложением.

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

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

Согласно исследованию Боэма, переделка может стоить от 40% до 50% общей стоимости разработки всего программного обеспечения. И большая часть доработок вызвана ошибками требований.

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

Типы требований

Когда у вас появляется идея создать приложение, вы должны задать себе три основных вопроса:

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

Ответы на эти вопросы формируют три основных уровня требований к разработке мобильных приложений: бизнес-требования, требования пользователей и системные требования.

На каждом уровне также есть набор функциональных и нефункциональных требований.

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

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

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

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

Бизнес-требования

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

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

Основываясь на документе о видении и объеме, предложенном Карлом Вигерсом в третьем издании требований к программному обеспечению , мы подготовили следующую структуру BRD:

Вы можете представить объем своего проекта с помощью различных инструментов. Самый полный - это тощий холст . Он представляет собой сегменты бизнес-плана, имеющие решающее значение для разработки документации для всех мобильных приложений: группы пользователей и их основные проблемы, решения, которые ваше приложение собирается предоставить, а также уникальное ценностное предложение (UVP) и другие преимущества. В модели бережливого холста вы можете описать каналы, которые вы будете использовать для привлечения целевых пользователей, и ключевые показатели, которые скажут вам, как обстоят дела у вашего бизнеса. Экономичный холст также помогает вам определить модель монетизации вашего мобильного приложения вместе с другими потенциальными потоками дохода.

Чтобы способствовать четкому общению между всеми заинтересованными сторонами проекта, в Mind Studios мы дополнительно используем интеллект-карту . Этот инструмент отражает логику мобильного приложения и взаимосвязи между его основными компонентами.

Вот простой пример карты разума для приложения для медитации, такого как Headspace:

Помните, что в составлении бизнес-требований участвуют все участники проекта. Это всегда совместные усилия.

Требования пользователя

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

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

Когда дело доходит до требований пользователя, разумно начать с этих трех шагов:

Шаг 1 - Классифицируйте пользователей. Сгруппируйте все заинтересованные стороны в классы пользователей. Вы можете отсортировать их по следующим критериям:

• Уровень доступа (гость, обычный пользователь, платящий пользователь, провайдер, администратор)
• Задачи, которые они выполняют (найти, просмотреть, прочитать, выбрать, купить, поделиться, комментировать)
• Функции приложения, которые они используют (поиск, отображение, сортировка, сравнение, оплата и т. Д.)
• Частота посещений (ежедневно, ежемесячно)
• Используемые платформы (iOS или Android)
• Родной язык (или другие демографические данные, такие как местоположение, пол, образование и семейное положение).

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

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

После определения подходящих представителей пользователей получите их мнение по двум типам требований пользователей.

Запишите отзывы пользователей в документе с требованиями пользователя (URD) . Для этого можно использовать следующие приемы:

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

Истории пользователей. Составьте список действий, которые пользователи будут выполнять в вашем приложении для достижения своих целей. Затем расположите эти действия в естественной последовательности, чтобы определить типичный путь пользователя по вашему приложению. В зависимости от объема вашего проекта вы можете в первую очередь обрисовать эпики - сложные действия пользователя, которые вы можете разложить на более мелкие шаги, которые пользователи будут выполнять при использовании вашего приложения. Эпики - это пользовательские истории, которые обычно пишутся следующим образом: Как <тип пользователя>, я хочу <некоторая цель>, чтобы <какая-то причина>.

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

Системные Требования

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

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

Системные Требования
Функциональные требования	Перечислите функции, которые разработчики могут создать, чтобы пользователи могли выполнять задачи в соответствии с вашими бизнес-требованиями. Для этого используйте существующие интеллект-карты или пользовательские истории. После определения того, что будет делать ваше приложение, присвойте каждому функциональному требованию уникальное имя и номер, а также краткое описание, обоснование и статус.
Требования к подсистеме	Опишите требования к вашему мобильному приложению с точки зрения программных и аппаратных подсистем. Например, если вы собираетесь создать приложение для отслеживания фитнес-активности, вам нужно будет написать требования для носимых трекеров, которые будут синхронизироваться с приложением.
Бизнес правила	Поскольку каждый бизнес подчиняется законам, политикам и отраслевым стандартам, они будут очевидными источниками требований для SRS. Вот краткий список источников требований: Корпоративная политика Правительственные постановления Отраслевые стандарты Роли пользователей и рейтинги разрешений Если-то модели поведения пользователей Вычислительные алгоритмы, если есть
Требования к данным	При разработке мобильного приложения вам необходимо создавать, хранить, изменять, отображать, удалять, обрабатывать и использовать огромные объемы данных. Для управления потоками данных вам необходимо: обрисовать логическую модель взаимодействия сущностей данных определять сущности в словаре данных указать, как система должна обеспечивать анализ, хранение или удаление данных выбрать типы отчетов с данными (таблицы, диаграммы, информационные панели и т. д.)
Атрибуты качества	Написание четких критериев качества гарантирует, что разработчики оправдают ваши ожидания с конечным продуктом. Вам необходимо учитывать атрибуты качества, которые важны для: ваш бизнес и пользователи, такие как удобство использования, производительность и безопасность ( внешние атрибуты ) разработчики, такие как эффективность, модифицируемость и переносимость ( внутренние атрибуты ) Обсудите с другими заинтересованными сторонами, какие атрибуты важны для успеха вашего приложения, и расставьте приоритеты. Напишите конкретные ожидания для каждого атрибута, используя критерии соответствия - количественную оценку требования, которое описывает стандарт, которого должно соответствовать ваше приложение. Переведите атрибуты качества в технические спецификации и напишите приемочные испытания для вашей команды, чтобы они могли проверять результаты.
Внешние интерфейсы	Эта часть документа функциональных требований к мобильному приложению необходима для обеспечения правильного взаимодействия вашего приложения с пользователями и внешними аппаратными или программными системами. В SRS вам необходимо записать требования для: Пользовательские интерфейсы. Укажите дизайн экранов вашего мобильного приложения (стандарты шрифтов, значков, цветовых схем, изображений, размер экрана, макет, разрешение и т. Д.) Программные интерфейсы. Опишите взаимодействие между вашим приложением и другими программными компонентами, включая другие приложения, веб-сайты, библиотеки, базы данных и инструменты. Аппаратные интерфейсы. Опишите каждый из поддерживаемых типов устройств, взаимодействия данных и управления между программным и аппаратным обеспечением, а также протоколы связи, которые будут использоваться. Коммуникационные интерфейсы. В SRS для вашего мобильного приложения укажите требования для любых коммуникационных функций, которые ваше приложение будет использовать, включая сообщения внутри приложения, push-уведомления, электронные письма и сетевые протоколы.
Ограничения	Запишите ограничения, которые ограничивают дизайн, работу и реализацию вашего мобильного приложения. Прежде всего, проверьте, соответствует ли спецификация требований вашего мобильного приложения требованиям Apple App Store и Google Play Store. Кроме того, укажите другие системные ограничения, налагаемые, например, используемым языком программирования или правилами использования сторонних API или контента.
Требования к локализации	Если вы хотите, чтобы ваше приложение использовалось в странах, культурах и географических регионах, которые отличаются от тех, в которых оно было создано, вам следует установить требования для изменения: Валюта Форматы даты, номера, адреса и телефонного номера Язык (включая национальные правила правописания, местные диалекты, направления) Функциональность в соответствии с нормативными актами и законами Контент с учетом культурных и политических вопросов Часовые пояса Веса и меры Прочие переменные

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

Диаграмма «сущность-связь» (ERD) представляет, как сущности данных связаны друг с другом в системе, а также связи между элементами внутри этих сущностей. Ниже приведен пример диаграммы, которую мы использовали в документе со спецификацией требований для мобильного приложения для доставки еды:

Способы разработки требований и управления ими

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

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

Составление требований для вашего проекта мобильного приложения обычно состоит из четырех действий:

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

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

В Mind Studios мы определяем и согласовываем начальные требования к продукту на стадии открытия и проверки идеи, выполняя следующие шаги:

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

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

Характеристики хорошего документа с требованиями к разработке мобильных приложений

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

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

В идеальном мире требования к вашему мобильному приложению, указанные в PRD, должны быть:

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

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

Шаблон документа с требованиями к мобильному приложению

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

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

Краткое описание требований к продуктам для мобильных приложений, подготовленное Mind Studios

After you complete this brief, email it to us and one of our managers will respond promptly. This brief will provide a solid basis for creating a detailed mobile app product requirements document with the help of our team.

Have any questions about your mobile app project? Напишите нам.

Заключительное слово

Even for the smallest projects, it's critical to have a shared understanding of initial requirements. In some cases, ready-made product requirements document templates can help you out. But more often, they're only illustrative. Since no two apps are alike, there's no chance that someone else's PRD will suit your project.

To perfectly meet your specific tasks, you need to create an original mobile app requirements document , which can be a time-consuming and tedious process. The good news is that you can leave it to experts. Especially since they're just one call away.