Обычно большую часть времени аналитик отводит на формирование функциональных требований к системе.
Многие начинающие (и не только) аналитики боятся приступить к нефункциональным требованиям (НФТ), избегают их или и вовсе забывают про их существование.
Возникают вопросы: как узнать целевые значения? Про что я должен подумать в первую очередь, выбирая метрики?
Хотя, во многом, большую роль в формировании НФТ играет архитектор, аналитику полезно иметь общее представление о том, что они из себя представляют и как их можно измерить.
Предлагаю далее рассмотреть перевод статьи на эту тему.
Ссылка на оригинал — https://www.altexsoft.com/blog/non-functional-requ.
Немного о сущности НФТ
Нефункциональное требование — это спецификация, описывающая возможности работы системы, а также ограничения, улучшающие ее функциональность
Представьте, что вы покупаете мотоцикл. Какие функции вы ожидаете увидеть?
Ожидаете ли вы, что он будет двигаться со скоростью 170 миль в час и не развалится?
Бизнес-анализ мобильных приложений #2 — Кто такой бизнес-аналитик?
Сможете ли вы прикрепить к нему коляску или расширить багажное отделение, добавив прицеп? И не забываем о системах безопасности.
Хотя эти требования не описывают напрямую функции транспортного средства: перемещение человека из точки А в точку Б, они по-прежнему важны для удовлетворения ваших потребностей, как водителя.
Подобно мотоциклам или любому другому оборудованию, программное обеспечение имеет свои нефункциональные требования.
Будь то веб-сайт, мобильное или десктопное приложение, оно должно соответствовать ряду качественных атрибутов для удовлетворения потребностей конечных пользователей.
Что такое нефункциональные требования, они же НФТ?
Проще говоря, нефункциональное требование — это спецификация, описывающая возможности работы системы, а также ограничения, улучшающие ее функциональность.
Это могут быть требования к скорости, безопасности, надежности и т. д.
Что говорят стандарты?
Структура стандартов ISO / IEC 25000 определяет нефункциональные требования, как требования к качеству системы и качеству программного обеспечения.
BABOK, один из основных источников знаний для бизнес-аналитиков, предлагает термин нефункциональные требования (NFR), который в настоящее время является наиболее распространенным определением.
Тем не менее, эти обозначения относятся к одному и тому же типу вопросов — требованиям, которые описывают рабочие качества, а не поведение продукта.
При этом их список варьируется в зависимости от типа приложения. Например, если вы собираетесь хранить пользовательские данные и ваш веб-сайт работает в ЕС , вы должны соответствовать регламенту о защите данных GDPR.
В некоторых случаях НФТ могут не иметь отношения к потребностям бизнеса. Например, в случае дополнительных требований соответствия при обработке платежей.
В этой статье будут рассмотрены только самые распространенные типы НФТ, которые должны попасть в ваш чек-лист. Однако их может быть сотни.
Нефункциональные требования. Как не упустить качество продукта
Требования будут распределены на несколько групп, поскольку подходы к документированию этих требований совпадают, а также по причине их взаимного влияния друг на друга.
Рассмотрим следующие группы
1. Производительность и масштабируемость
— Как быстро система возвращает ответ на запрос?
— Насколько изменится эта производительность при более высоких нагрузках?
2. Переносимость и совместимость
— На каком оборудовании, операционных системах, браузерах и их версиях работает программное обеспечение?
— Конфликтует ли разрабатываемое ПО с другими приложениями и процессами в этих средах?
3. Надёжность, доступность, ремонтопригодность
— Как часто в системе случаются критические сбои?
— Cколько времени у пользователей есть на время простоя?
4. Безопасность
— Как система и её данные защищены от атак?
5. Локализация
— Соответствует ли система местной специфике?
6. Удобство использования (юзабилити)
— Насколько легко клиенту пользоваться системой?
1. Производительность и масштабируемость
Производительность определяет, насколько быстро работает приложение: как быстро каждый её модуль реагирует на действия определённых пользователей при определённой рабочей нагрузке.
В большинстве случаев эта метрика объясняет, сколько пользователь должен ждать, прежде чем произойдёт целевая операция (отобразится страница, обработается транзакция и т. д.), учитывая общее количество пользователей в данный момент.
Но так бывает не всегда. Требования к производительности могут описывать и фоновые процессы, невидимые для пользователей. Например, резервное копирование. Но давайте сосредоточимся на производительности, ориентированной на пользователя.
Масштабируемость оценивает максимальные рабочие нагрузки, при которых система по-прежнему будет соответствовать требованиям к производительности.
Как определить?
1. Начните с рекомендаций Google для обычных веб-страниц
Google очень требователен к скорости загрузки страниц на компьютерах и мобильных устройствах. Поэтому если вы ищете рекомендации по производительности для обычных веб-страниц, к которым имеют доступ все пользователи сети Интернет, проверьте статистику скорости загрузки страниц Google.
Поисковая система рассматривает несколько сценариев, включая тип подключения, мобильную или настольную версию устройства, а также тип отображаемого контента.
Основываясь на сумме факторов, Google предлагает разные оценки производительности, которые вы можете использовать в качестве НФТ и для своего веб-сайта.
- 1 секунда — предел, после которого реакция системы уже не кажется пользователю мгновенной;
- 1 секунда — это время, когда пользователь заметит задержку, но без прерывания мыслей;
- 10 секунд — время, когда внимание пользователя полностью потеряно.
3. Конкретизируйте сценарий измерения
Включает ли ваша метрика чтение страницы браузером или только время, необходимое для получения ответа на запрос?
Если разные типы контента загружаются с разной скоростью, у вас могут быть разные временные ограничения для текста, изображений и видео.
4. Укажите рабочую нагрузку
Так как у вас может быть, скажем, 5 тыс. пользователей днём и 1 тыс. ночью, определите, для каких сценариев рабочей нагрузки вы хотите задокументировать НФТ.
Возможно, вы захотите добавить в качестве требований и то, и другое. А, возможно, вы захотите установить наивысший порог.
5. Исключайте из НФТ время, необходимое для получения результатов обработки запросов сторонними приложениями
Если работа вашего приложения зависит от вызовов, возвращающих данные стороннего API, ваша команда разработчиков не сможет взять на себя ответственность за это.
6. Не забывайте про архитектурные ограничения
Если разработчики имеют дело с корпоративным решением или устаревшей системой, может быть затруднительно улучшить производительность без перепроектирования всей архитектуры.
7. Учитывайте масштабируемость
В этот раздел также включены требования к масштабируемости, поскольку этот признак учитывает максимальную нагрузку, которую система не обязательно должна обрабатывать сейчас, но должна суметь обработать в ближайшем будущем.
Например, вы ожидаете, что количество сеансов в приложении удвоится после маркетинговой кампании, и при этом вы по-прежнему хотите сохранить существующую производительность.
Хотя заранее делать прогнозы сложно, стоит установить хотя бы некоторые значения ожидаемых нагрузок.
Пример требования к производительности
Целевая страница, поддерживающая 5 тыс. пользователей в час, должна обеспечивать время отклика в браузере Chrome для настольных ПК не более 6 секунд, включая рендеринг текста и изображений, через соединение LTE.
2. Переносимость и совместимость
Переносимость определяет, как система или ее компонент могут быть запущены в той или иной среде.
Обычно переносимость включает в себя оборудование, программное обеспечение или другую конфигурацию платформы использования.
Проще говоря, этот признак устанавливает, насколько хорошо действия, выполняемые в условиях одной платформы/конфигурации, выполнятся в других условиях.
У переносимости также есть дополнительный аспект, называемый совместимостью.
Совместимость определяет, как система может сосуществовать с другой системой в той же среде.
Например, программное обеспечение, установленное на операционной системе, должно быть совместимо с ее брандмауэром или антивирусной защитой.
Переносимость и совместимость определяются с учётом операционных систем, аппаратных устройств, браузеров, программных систем и их версий.
На данный момент кроссплатформенное, кросс-браузерное и мобильное решение является общепринятым стандартом для веб-приложений.
Нефункциональные требования к переносимости обычно основываются на предварительных исследованиях рынка, полевых исследованиях или аналитических отчётах о типах программного обеспечения и устройств, которыми пользуется целевая аудитория.
Если вы работаете в корпоративной среде и доступ к программному обеспечению будет осуществляться через задокументированный список устройств и операционных систем, определить совместимость и переносимость довольно просто.
Как определить?
1. Если можете, сделайте вывод о требованиях к переносимости из аналитических отчётов
2. Если у вас есть доступ к данным о посетителях через Google Analytics или другие аналитические платформы, вы можете оценить, какие типы устройств, браузеры и их версии используются клиентами наиболее часто
Рассмотрим максимально полный список требований к переносимости.
Обычно данные требования фиксируется не только для разработчиков, но также и для тестировщиков в рамках описания сценариев тестирования.
- Операционные системы и их версии;
- Специфику сети;
- Браузеры и их версии;
- Требования к устройствам и другому оборудованию.
Если система должна сосуществовать со сторонним программным обеспечением или другими приложениями в программной экосистеме, не забываете учитывать и их.
Пример требования к совместимости
Приложение iOS должно поддерживать устройства iPhone, работающие на версиях ОС: 3.6, 3.3, 3.4, 4.3, 2.3.
3. Надёжность, доступность, ремонтопригодность
Хотя эти три типа требований обычно документируются отдельно, в рамках этой статьи они объединены в один раздел, поскольку рассматривают одну и ту же проблему с разных сторон.
Ещё одна вещь, о которой следует помнить в рамках этих требованиях, заключается в том, что их чрезвычайно трудно выразить в расчётных терминах.
И, честно говоря, многие поставщики систем вообще не документируют их.
Надежность
Этот атрибут качества указывает, насколько вероятно, что система или её элемент будут работать без сбоев в течение заданного периода времени при заранее определенных условиях.
Традиционно выражается в процентах вероятности. Например, если система имеет 85-процентную надежность в течение месяца, это означает, что в течение этого месяца при нормальных условиях использования c вероятностью 85% мы можем утверждать, что система не выйдет из строя.
Как вы уже догадались, довольно сложно определить критический сбой, время и нормальные условия использования.
Другой, несколько более простой подход к этой метрике — подсчитать количество критических ошибок, обнаруженных в производственной среде за некоторый период времени, или вычислить среднее время работы до отказа.
- Вероятность в процентах, время;
- Количество критических отказов, время;
- Среднее время работы до отказа.
Ремонтопригодность определяет время, необходимое для исправления ошибок в приложении или его компоненте, а также время, необходимое для изменений при повышении производительности или других качеств или адаптации к изменяющейся среде.
Как и надежность, она может быть выражена в виде вероятности ремонта в течение некоторого времени.
Например, если у вас показатель ремонтопригодности равен 75% в течение 24 часов, это означает, что с вероятностью 75% ошибку в компоненте можно будет исправить за 24 часа.
Доступность
И, наконец, доступность описывает, насколько вероятно, что система будет доступна для пользователя в данный момент времени.
Хотя его можно выразить в виде процента вероятности, вы также можете определить этот показатель как процент времени, в течение которого система доступна для работы в течение некоторого промежутка времени.
Например, система может быть доступна 98% времени в течение месяца.
Доступность, возможно, является наиболее важным требованием для бизнеса, но для его определения вы также должны иметь оценки надёжности и ремонтопригодности.
Как вы видите, эти три показателя тесно связаны. И, что еще более важно, вы должны подойти к ним одновременно, если решите добавить их в список НФТ вашей системы.
Источник: schoolforanalyst.ru
Как написать бизнес-требования? Бизнес-специалисту – как разговаривать на одном языке с ИТ
Эта книга поможет Вам создать уютный оазис определенности в жестокой пустыне проектной деятельности. Палящие лучи неопределенности, выжигающие все живое вокруг, остановятся, когда на их пути возникнут нормальные, понятные, продуманные бизнес-требования к проекту.
Вы внесете в проект атмосферу взаимопонимания и управляемости, если будете руководствоваться изложенными в книге подходами и шаблонами. Ваши контрагенты будут приятно удивлены и станут стремиться только к Вам, потому как Вы станете тем редким «заказчиком, который точно знает, что он хочет».
Книга поможет вам задать правильные вопросы и найти ответы на старте проекта, заранее, до того, как все сроки прошли, а работа сделана. И не важно, кто вы – бизнес-специалист или аналитик, в любом случае требования, вышедшие из под Вашего пера после прочтения этой книги будут вызывать диалог по существу, а не ужас в глазах ваших потенциальных исполнителей. Это дорогого стоит! Добро пожаловать в мир правильных бизнес-требований!
Источник: play.google.com
Каким должен быть функционал мобильного приложения
7974 
23-04-18 
Время чтения: 8 мин
Мобильное приложение разрабатывается под определенные бизнес-задачи. В зависимости от этого строится функционал приложения – набор возможностей, доступных пользователю. Рассмотрим несколько примеров функционала приложения:
- В интернет-магазине пользователь может выбрать, сравнить характеристики и купить товар, отследить статус заказа, просмотреть историю покупок, оставить отзыв, оплатить онлайн. Автоматизация этих процессов минимизирует ручной труд менеджеров. Поток заказов обрабатывается автоматически в приложении, компании остается только следить за актуальностью ассортимента, цен и характеристик. Клиент может в несколько касаний найти нужную позицию среди тысяч вариантов – в таких условиях шансы успешной покупки значительно возрастают. Механизм интернет-продаж упрощается и становится более эффективным – это дает преимущества обеим сторонам: покупатель получает более качественный сервис, а магазин – больше довольных покупателей.
- Приложение службы такси дает возможность построить маршрут, выбрать цену, заказать машину. Не нужно звонить оператору, дожидаться ответа на перегруженной линии, получать смс и уточнять адрес подачи машины. Приложение все делает автоматически: определяет геолокацию пассажира, предлагает несколько авто на выбор, предоставляет возможность выбора цены и класса такси, показывает перемещение машины в режиме онлайн. Пользуясь таким функционалом, пассажир получает более качественную услугу, соответствующую его ожиданиям. Повышается стабильность работы службы такси, растет поток клиентов, компания имеет возможность развиваться и масштабироваться – и все это благодаря правильному функционалу мобильного приложения.
- В спортивном приложении можно фиксировать активность и вес, вести дневник питания, смотреть видеотренировки. Информационная и практическая база собрана на одной платформе, пользователю предоставляются разнообразные инструменты для отслеживания, контроля, планирования личных показателей. В приложение встраиваются календари, калькуляторы, таблицы, диаграммы и многие другие специфические опции. При необходимости расширенный функционал можно сделать платным как способ монетизации приложения.
- Обучающие приложения предлагают получить доступ к урокам, тестам, базе знаний. Пользователи смотрят видео, проходят тестирование, делают заметки, работают с интерактивными инструментами, общаются онлайн с преподавателями. Приложение собирает статистические данные об успехах учеников, они могут отслеживать собственный прогресс. Концентрация обучающих материалов и всевозможных полезных инструментов на одной платформе экономит время пользователей и повышает эффективность усвоения знаний. Компания получает возможность монетизации приложения за счет платной подписки на отдельные функции, разделы, уровни обучения.
Все это обобщенные примеры, которые наглядно показывают, насколько разным может быть функционал мобильного приложения.
Требования к функционалу мобильного приложения
Функционал любого мобильного приложения должен соответствовать трем базовым требованиям:
1. Удобство для пользователя. Все функции должны быть интуитивно понятны для каждого пользователя. Важно, чтобы человек мгновенно находил нужные кнопки, легко ориентировался в функционале и сразу видел все доступные возможности. Для этого внедряются принципы UX/UI дизайна – создания красивых и удобных пользовательских интерфейсов.
Внешний вид прорабатывается в плотной связке с механизмом работы интерфейса. Чтобы создать комфортную и привычную среду для пользователя, интерфейс разрабатывается по гайдлайнам, которые описывают общие принципы взаимодействия пользователей с приложениями в iOS и Android.
2. Повышение конверсии. Функционал приложения разрабатывается не только для удобства пользователя, но и для выгоды компании. В идеале, нажатие кнопки должно по цепочке вести пользователя к целевому действию – к покупке, заказу, бронированию и т. д. Для анализа действий пользователей и отслеживания ключевых метрик приложения используются специальные инструменты (AppCenter, Firebase и т.д).
3. Оптимизированный набор функций. Функционал определяется исходя из конкретной бизнес-задачи. Приложение должно содержать ровно столько функций, сколько необходимо клиенту на пути к целевому действию (покупке, заказу, бронированию и пр.). Приложение с недостаточным функционалом не решит задачи аудитории, а значит – окажется невостребованным. Лишние опции также нежелательны – избыток ненужных кнопок только запутает пользователей.
Этапы разработки функционала приложения
Этап 1. Определение функционала при составлении ТЗ
Точный перечень требований бизнес-модели клиента и функциональной части для разработчиков формируется на этапе создания ТЗ на разработку приложения до начала программирования. Для этого проводится комплексный анализ по нескольким направлениям:
1.1 Ниша, продукт
В каждой сфере бизнеса действуют свои законы, приемы, тренды. Например, эффективные решения для интернет-продаж могут совершенно не работать в обучающих приложениях. Здесь важен глубокий индивидуальный подход, который возможен только при наличии у разработчиков большого профессионального опыта.
1.2 Задачи и цели приложения
После общего анализа ниши и продукта необходимо внести конкретику: какие задачи должно решать приложение, какую пользу приносить компании, каким способом должна проходить его монетизация (прямые продажи, продвижение бренда, заработок на рекламе, продажа платных пакетов и прочее).
1.3 Особенности ЦА
Функционал разрабатывается для удовлетворения потребностей целевой аудитории, поэтому своих пользователей нужно знать «в лицо»: для чего им нужно приложение, какие опции могут быть полезны, что может зацепить внимание. Необходимо знать, на какой платформе сконцентрирована аудитория – в Android, iOS либо в обеих системах. Только понимая особенности ЦА, можно создать полезное и востребованное приложение с ценным набором функций. Компания KITAPP специализируется на разработке кросс-платформенных приложений на React Native, что позволит вам охватить всю потенциальную аудиторию пользователей.
1.4 Конкурирующие приложения
Чтобы понять предпочтения целевой аудитории, достаточно проанализировать самые популярные приложения конкурентов. Дальнейшая задача состоит не в копировании чужого, а в создании собственной уникальной концепции на основе проверенных решений. Важно взять от конкурентов лучшее, устранить их ошибки и по-своему усовершенствовать функционал.
1.5 Возможность последующих обновлений
Мобильное приложение должно быть гибким и перспективным продуктом. Хорошее приложение растет и совершенствуется параллельно с развитием технологий, расширением аудитории, масштабированием бизнеса. При разработке основного функционала необходимо предусмотреть возможность для таких обновлений.
Этап 2. Создание пользовательского интерфейса
Даже самый «навороченный» функционал окажется бесполезным, если не будет качественно продуман пользовательский интерфейс. UI/UX специалист создает дизайн приложения, прорабатывает расположение функциональных элементов, кнопок, форм, меню. UI дизайн делает интерфейс красивым и приятным для восприятия, а UX – удобным и полезным для решения пользовательских задач. Важно максимально проработать каждую деталь интерфейса на этапе прототипирования. Это важнейший этап, который определяет удобство приложения, а значит – оказывает прямое влияние на его конверсию.
Этап 3. Программирование и тестирование
В соответствии с техническим заданием команда разработчиков создает функционал приложения. Для создания конечного продукта производится разработка front-end (клиентская сторона) и back-end (логика, API, админ-панель), после чего приложение направляется на тестирование. После устранения ошибок, выявленных группой тестировщиков, приложение публикуется на AppStore / PlayMarket. Успешно опубликованное приложение становится доступным для пользователей – и с этого момента оно начинает решать поставленные задачи, приносить пользу компании, способствовать развитию бизнеса.
Самые востребованные функции мобильных приложений
Основное меню
Это неотъемлемый элемент практически каждого приложения. В меню указаны основные разделы, категории, опции, которые посетитель может использовать для навигации.
Регистрация
- Форма регистрации с ручным вводом данных или через аккаунты в социальных сетях.
- Авторизация с одно- или многофакторной аутентификацией через сервис смс или по одноразовому OTP коду.
- Создание личного кабинета пользователя.
Продажи
- Акции. Повышение лояльности за счет бонусных программ.
- Каталог товаров. Внутри каталога могут быть добавлены различные функции: поиск, фильтрация, сравнение, сортировка товаров и прочее.
- Корзина. Это центральный функциональный элемент интернет-магазина. Пользователь добавляет в корзину товары с разными параметрами и в нужном количестве, выбирает способ оплаты и доставки, оформляет заказ.
- Онлайн-платежи. Обеспечивается возможность оплаты непосредственно в приложении. Производится подключение к одной или нескольким платежным системам, настраиваются соответствующие параметры безопасности данных.
- Заказ. Эта функция необходима, если приложение продает услуги или реализует товары под заказ.
- Бронирование. Опция актуальна для приложений аренды недвижимости, продажи билетов, бронирования туров и т. д.
- История покупок. В личном кабинете хранятся данные о купленных товарах, можно отследить статус заказа, просмотреть этапы доставки.
Коммуникация
- Форма обратной связи. Через форму пользователь может отправить контактные данные, заказать обратный звонок либо задать интересующий вопрос.
- Чат-бот. Эта функция позволяет общаться онлайн с ботом – задавать популярные вопросы, получать автоматические ответы.
- Онлайн-чат. При необходимости чат может быть настроен на общение с менеджером.
- Push-уведомления. Приложение направляет на телефон пользователя уведомления различного содержания – новости, акции, спецпредложения, новинки, обновления и другую полезную информацию.
- Прямой звонок. Пользователь может позвонить сотруднику компании напрямую непосредственно из приложения.
Дополнительный функционал
- Оценки и отзывы. Пользователи могут оставить оценку или написать свое мнение о товаре/услуге.
- Сканирование QR-кодов.
- Использование данных геолокации. Полезная опция для построения маршрутов, формирования карты ближайших филиалов компании.
- Видео и фото контент. В функционал приложения может быть встроена возможность размещения галереи изображений, видеоматериалов.
- Календарь.
- Игровые элементы.
- Привязка к картам Google или Yandex.
- Привязка к внутренним программам трекинга состояния здоровья и пр. — например, HealthKit, Google Fit.
Программа лояльности
- Скидочные купоны.
- Бонусная карта (альтернатива пластиковой).
- Уведомления об акциях.
Безопасность
- Безопасные платежи. Система защиты платежных данных при подключении функционала онлайн оплаты, использование стандартных методов оплаты ApplePay, GooglePay и различных банковских систем.
- Безопасная авторизация. Помимо ввода пароля могут быть использованы другие способы – подтверждение по смс, считывание отпечатка пальца либо лица пользователя, графический или цифровой ключ.
Расширение функционала мобильного приложения
Иногда необходимость внедрения каких-либо функций возникает уже после запуска приложения. На определенном этапе растущему бизнесу становится «тесно» в существующем приложении, аудитория требует новых опций. Современные технологии мобильной разработки позволяют масштабировать функционал, адаптировать приложение под новые потребности пользователей. Исключение составляют сильно устаревшие приложения, доработка которых обойдется дороже, чем создание нового продукта.
Во многих случаях компании начинают с минимального набора опций: запускают приложение, анализируют поведенческие факторы и отзывы, при каждом следующем обновлении наращивают функционал в соответствии с потребностями ЦА. Это так называемый Minimal Viable Product (дословно – минимально жизнеспособный продукт). Что такое MVP в мобильной разработке? Это версия приложения с минимальным, но достаточным набором функций, которые могут удовлетворить главные потребности пользователя. Такой подход позволяет:
- сэкономить на старте;
- растянуть вложения во времени;
- планомерно развивать функционал;
- давать пользователям именно то, в чем они нуждаются.
Команда студии KitApp реализует комплексный подход к разработке функционала приложения для бизнеса:
- выделяет ключевые функции, адаптирует их под индивидуальные задачи;
- создает пользовательский интерфейс для удобного доступа к функционалу;
- выполняет программирование приложения «под ключ».
Каким должен быть функционал вашего приложения? Обращайтесь в нашу компанию – мы с удовольствием проконсультируем вас по этому вопросу и поможем выбрать оптимальный набор функций в рамках бюджета.
Источник: kitapp.pro
