[Бизнес-анализ] Виды требований

1) Бизнес-требования
2) Пользовательские требования
3) Функциональные требования
4) Нефункциональные требования
4.1) Бизнес-правило
4.2) Атрибуты качества
4.3) Ограничения
4.4) Внешние интерфейсы

1) Бизнес-требования - это высокоуровневые бизнес-цели организации или владельца бизнеса.

Цели по SMART: Specific - конкретный Measurable - измеримый Achievable - дост достижимый Relevant - уместный Time-bounded - ограниченный по времени

Сравнение целей:

Не по SMART - пробежать марафон
По SMART - пробежать Бостноский марафон в 2021 году быстрее чем за 4:30 часа.

Не по SMART - Все должны покупать наш продукт
По SMART - Увеличить количество клиентов в возрасте от 20 до 30 лет на 30% в течении 6 месяцев с момента запуска приложения

Где документировать бизнес-требования?

• Vision and Scope document
• Business case

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

2) Пользовательские требования - задачи, которые определенные типы пользователей должны иметь возможность выполнять в рамках системы. Т.е. хотелки заинтересованных лиц. Например : заказ товара, регистрация на рейс.

Пользовательские требования описывают ЧТО пользователь хочет делать с системой, а не КАК он хочет это сделать.

Пользовательские требования описываются с помощью Вариантов использования (Use Case) или Пользовательских историй (User Stories)

Определяют эти требования конечные пользователи, а не заказчики. Хранятся в спецификации ПО или Бэклоге продукта.

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

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

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

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

Классификации пользователей:

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

Приоритезируем пользовательские требования в зависимости от ценности бизнеса по RICE и ICE.

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

Reach — это охват
Impact — влияние
Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
Effort — трудозатраты

Reach (Охват)

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

Важно акцентировать внимание на реальных метриках, а не использовании непонятных чисел.

Например: Фичей будет пользоваться 800 пользователей в месяц.1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.

Impact (Влияние)

Влияние показывает какой вклад приносит эта фича продукту.

Ценность понимается по-разному в каждом продукте. Например, в Hygger (B2B SaaS) для текущего квартала фичи получают высокое значение, если они:

1. Улучшают trial-to-paid конверсию (metric movers)

Исходя из ваших текущих целей у вас будут свои метрики.

2. Помогают привлечь новых пользователей

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

Например, в SaaS отличным индикатором удержания в первый день является показатель 15%. Это означает, что 85% людей просто уходят на второй день. Поэтому здесь вы должны подумать о фичах, которые большинство новых пользователей смогут увидеть в первой сессии.

3. Помогают сохранить текущих пользователей

Клиенты купили подписку и теперь просят сделать некоторые фичи. Мы не «спешим» слепо делать все подряд. Мы накапливаем статистику по каждой фиче — сколько клиентов просили об этом. И тогда мы реализуем самые популярные фичи.

4. Добавляют ценности продукту и отстраивают нас от конкурентов

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

К слову, влияние трудно измерить точно. Так, мы выбираем из шкалы с множеством вариантов: 3 для «массового влияния», 2 для «высокого», 1 для «среднего», 0,5 для «низкого» и, наконец, 0,25 для «минимального». Эти цифры умножаются на итоговый результат, чтобы масштабировать его ниже или выше.

Confidence (Уверенность в оценке)

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

Например Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности. Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.

Effort (Трудозатраты)

Трудозатраты оцениваются как количество «человеко-месяцев», недель или часов, в зависимости от потребностей.

Например: Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.

Метод оценки ICE

Метод определения приоритетов ICE был придуман Шоном Эллисом, который известен авторством термина Growth Hacker.

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

ICE Scoring: Как это работает?

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

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

В качестве примера, применим это к фиче «Виджеты для Dashboard»: Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам? Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу? Уверенность: как я могу быть уверен, что эта фича приведет к такому улучшению, которое я описал в Impact и займет столько-то времени?

3) Функциональные требования - это возможности системы, которыми она должна обладать. Т.е. функц. требования отвечают на вопрос ЧТО должна делать система.

Например:
• Система должна формировать чек на оплату при оформлении договора.
• Система должна позволять пользователю загружать фотографии в телефон.

Как описывать функциональные требования?

• Варианты использования (Use Case)
• Пользовательские истории (User Stories)
• Текстовые списки утверждений о системе

Где документировать функциональные требования?

• Спецификация ПО - классический метод с большим кол-вом документации
• Бэклог Продукта - гибкие методологии без большого количества документации

Шаблоны для подготовки функциональных требований:

• Базовый - система должна совершать какое-то действие
• Базовый + Объект - система должна предоставлять пользователю возможность совершать какое-то действие
• Комплексный - если {определенное условие}, то система должна совершать какое-то действие/предоставлять пользователю возможность совершать какое-то действие

Критерии хороших требований:

• Полнота
• Осуществимость
• Необходимость
• Конкретность
• Приоритезированность
• Однозначность
• Проверяемость

Примеры функциональных требований:

Плохой - пользователь должен иметь возможность просматривать свои личные данные и выгружать их на электронный адрес. (В рамках 1 требования 2 функции)

Хороший - пользователь должен иметь возможность просматривать свои личные данные.
Пользователь должен иметь возможность выгружать свои личные данные на электронный адрес.

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

Типы нефункциональных требований:

4.1) Бизнес-правило - это высокоуровневое обстоятельство накладывающее ограничение на деятельность бизнеса.

Где выявлять бизнес-правила?

• Знания организации
• Предыдущие системы и их документации
• Существующие документы
• Нормативно-правовые акты организации или отрасли
• Политики

4.2) Атрибуты качества - это характеристики, которыми должна обладать система.
Например: требования к производительности, доступности или переносимости.

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

• Доступность • Удобство установки • Целостность • Совместимость • Производительность • Надежность • Устойчивость • Защита • Безопасность • Удобство использования

Внутренние атрибуты качества - это свойства, наблюдаемые разработчиками при взаимодействии с системой, например:

• Эффективность • Возможность модификации • Переносимость • Возможность повторного использования • Масштабируемость • Проверяемость

Как документировать атрибуты качества?

Список в разделе Спецификации ПО:
• Нефункциональное требование 1
• Нефункциональное требование 2
• Нефункциональное требование 3

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

4.3) Ограничения - это рамки, накладываемые на доступный разработчику выбор дизайна или реализации.

Ограничения могут служить:
• Языки программирования
• Стандарты разработки кода
• Протоколы связи с другими системами
• Разрешения экрана
• Форматы обмена данными (XML, JSON)

Примеры ограничений:
• Интернет-платежи могут выполняться только через PayPal.
• Все используемые в приложении текстовые данные должны храниться в виде JSON-файлов

Документируем органичения в Документе о концепциях и границах продукта в начале разработки продукта.

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

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