🔹 Бизнес-требования, которые отражают ожидания бизнеса к продукту. Такие требования располагаются на верхушке айсберга и преследуют улучшение показателей бизнеса – выручки, оборотов, притока клиентов и так далее.

Например:
Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.


🔸 Пользовательские требования, которые отражают интересы сторон, использующих продукт. Этот уровень требований уже более детально раскрывает бизнес-требования, но отражает интерес потребителей бизнеса – пользователей и клиентов.

Например:
Как пользователь приложения Get Analyst, я хочу видеть познавательный контент на тему анализа в IT, в одном месте, чтобы процесс обучения был ещё удобнее.


🔹 Функциональные требования, которые описывают возможности, которые должен содержать IT-продукт. Такие требования возникают после проработки бизнес- и пользовательских требований и именно этот тип требований необходимо передавать в разработку.

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


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

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


🔹 Требования переходного периода, которые содержат требования к процессу работы системы в период, пока планируемое изменение не станет доступным для пользователей. Иными словами, требования переходного периода – это как «подстелить соломку» перед выходом проектируемого изменения в общий доступ. Эти требования ближе к функциональным требованиям и чаще всего их не выделяют в отдельный тип, а формулируют, как требования к первой итерации* продукта.

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


🤪🤪 куда так много требований

Ну как, держитесь ещё? Завтра и послезавтра хотим подробнее рассказать вам про два самых популярных типа требований в работе аналитика: бизнес-требования и функциональные требования.

А в конце будет классный КВИЗ, где вы сможете закрепить свои знания (кажется, вы их любите. Мы тоже!💥).
Признавайтесь, ждёте? 😉

👋 Продолжаем тему требований к ПО и сегодня поговорим про бизнес-требования.

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

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


Рассмотрим на следующем примере:

🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.

В этом бизнес-требовании представлена информация об интересах бизнеса в решении. Иными словами, бизнес хочет, чтобы:

☝️ комьюинити аналитиков в сообществе расширялось;
✌️ узнаваемость бренда повышалась.


Для достижения этих целей можно придумать множество концепций решения.

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


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


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

Например:
🔸 повысить количество студентов на курсе на 13% засчёт увеличения узнаваемости бренда
🔸 увеличить количество положительных отзывов на 20% о бренде на популярных платформах
и так далее.

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

Куда расти и что еще стоит изучить по системному анализу? 🚀

Написала для вас статью, чтобы помочь найти новые точки роста в карьере или построить план для начинающих в системном анализе 😉

💥 СРОЧНЫЙ МЕМ на тему коммуникаций с заказчиком 💥

Всем отличного настроения! 🖤
Скоро продолжим разбираться с типами требований к ПО 😊

#GAhahaha

А вот и мыыыы👋

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

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

Вот так просто? Ну да 😊

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

Например:
🔹 Система должна получить информацию о clientId, clientFIO, clientNumber, clientLogin, clientPassword из POST-метода системы партнёра и сформировать личный кабинет клиенту с помощью метода CreateLK.

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

☝️Задача аналитика – обозначить конечную цель, ресурсы для её достижения, а также факторы, которые влияют на проектируемый процесс. А задача разработчика – определить лучший способ достижения этой цели и спроектировать обозначенную возможность в соотношении цена / качество.

Таков путь 🥷

А теперь разберём наш пример с приложением GetAnalyst.
В прошлый раз мы получили следующее требование от заказчика:

🔸 Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество GetAnalyst и повысит узнаваемость бренда.

В ответ мы, как аналитики, предложили множество вариантов для достижения этой бизнес-цели. И конечный выбор пал на приложение. А какие конкретно функции мы ожидаем в этом приложении? Идём к заказчику 🏃‍♀️🏃‍♂️

Один из самых популярных способов формулирования функциональных требований – это проектирование вопросов по CRUD-модели:

🔹 Create: Можно ли в приложении вести свой блог и создавать записи? Или создавать комментарии под записями? А есть ли у пользователя личный кабинет с персональной информацией? Закрыли функциональное требование на создание данных.

🔹 Read: Можно ли читать записи? Кстати, а откуда эти записи появляются? Закрываем требование по чтению данных и тут же по интеграции с другими платформами.

🔹 Update: Можно ли изменять созданные записи, комментарии или реакции? Как насчёт возможности менять свой ответ в викторинах? А редактирование данных в личном кабинете? Получили требования к изменению данных.

🔹 Delete: Можно ли удалять комментарии? А удалить свой личный кабинет? То есть узнали про возможность удаления данных.
И так далее.

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

Полученный ответ формулируется в виде утверждения со словами «должен», «должна» или «необходимо» + глагол + ожидаемый результат.

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

И ниже можно приложить список обязательных персональных данных, которые необходимо иметь в системе по каждому пользователю:
- Фамилия Имя Отчество
- Номер телефона (с указанием формата)
- Пароль (с указанием ограничений по длине и допустимым символам)
и так далее.

‼️ Функциональные требования напрямую связаны с другими типами требованиями. Ведь если спроектировать ПО, которое не представляет ценности для бизнеса (бизнес-требования) и пользователей (пользовательские требования), то ресурс на разработку был затрачен зря – такой продукт будет не нужен.

🤓 Всем привет!

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

Чтобы закрепить полученные знания, предлагаем вам пройти КВИЗ (ура, ура!🤪) на тему типов требований.

☝️Важное правило – не торопиться и рассуждать. Мы специально стараемся не давать очевидные ответы в КВИЗах, чтобы процесс решения задачи принёс вам больше профита (и удовольствия от правильного ответа 🙃). Начинаем через пару часов 🚀

Удачи ❤️ #quizGetAnalyst

🥳 Друзья, спасибо большое за участие в КВИЗе!

Очень надеемся, что тема требований стала чуть-чуть понятнее, но если есть вопросы – смело задавайте их в комментариях, будем разбираться вместе 💪

Как вы думаете, нужно ли подробнее разобрать, почему правильные ответы правильные?

Если пальцев вверх будет больше 10 👍, то следующим постом разберём подробнее каждый из вопросов КВИЗа (в том числе те, что были после теоретических частей про требования).

Наша задача разобраться в теме так, чтобы вы интуитивно решали кейсы, а не зубрили теорию 🤓😎

Всем отличных выходных!
Гордимся нашими крутыми участниками сообщества GetAnalyst 🖤💥

🙌 Всем привет и ОСТОРОЖНО, СПОЙЛЕР!🚨

Если вы не прошли последний КВИЗ по типам требований (листайте вверх ⬆️), то предлагаем сначала ответить на все вопросы, а потом уже читать этот пост. Потому что сейчас мы всей командой намерены рассказывать вам про ответы 🥷💥


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


1️⃣ Укажите ошибочное высказывание о бизнес-требованиях.

☝️ Условие сообщает, что из предложенных вариантов только один является ошибочным, его-то и необходимо определить.

Первый вариант. Мы с вами знаем, что бизнес-требования оттого и имеют приставку “бизнес-”, потому что отражают интересы компании в изменениях.

Второй вариант. Чаще всего этот тип требования поступает от заказчика в полном или неполном виде (кривое-косое, без метрик или сразу прекрасное, да ещё и с отработанной продуктовым аналитиком концепцией решения🌈)

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

Например:
Необходимо увеличить на 17% количество лидов от партнёра, завершивших последний этап регистрации на нашем сайте.

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

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

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

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

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

Получается, что ошибочным высказыванием будет третий вариант. Его и выбираем ☑️


🕺🏻 перерыв на победную ламбаду 💃🏻


2️⃣ Укажите верное высказывание о функциональных-требованиях

☝️ Исходя из условия мы знаем, что верное высказывание только одно, а остальные – ошибочные.

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

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

Как пользователь сайта, я хочу авторизоваться с помощью почты, чтобы быстрее попасть в личный кабинет.

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

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

Второй вариант. Функциональные требования сообщают разработчикам, какой результат должен получиться в результате проектировки. Какая бы экспертиза в архитектурном проектировании и системе не была у аналитика, написание кода – это не наша зона ответственности. Наша задача – предоставить чёткие атомарные (неделимые) требования к решению.

Третий вариант. Функциональные требования отражают интересы заказчика в лице бизнеса и/или пользователей. Если проектная команда будет создавать систему только исходя из интересов бизнеса, лояльность пользователей к продукту будет снижаться. А ноу юзерс, ноу ханей, ю ноу? 🍯🐝

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

Четвёртый вариант. CRUD-модель работы с данными (создание, чтение, изменение и удаление) действительно упрощает первичный сбор требований с заказчика. Тут действует принцип Парето (Vilfredo Federico Damaso Pareto), где 20% усилий в виде четырёх вопросов к функциональным возможностям внутри решения дают 80% результата. Пробуйте применить в работе – будете приятно удивлены 😊

Кстати, четвёртый вариант будет верным высказыванием. Пикачу, выбираем тебя ☑️


А сейчас перерыв на чашечку чая (или что там у вас в субботу?🙃) и через пару часов продолжаем.

Продолжаем с разбором КВИЗа 🚀

Переходим к серии вопросов по всей теме типов требований.


1️⃣ Верно ли, что бизнес-требования имеют средний уровень детализации ожидаемых возможностей к ПО?

Нет, неверно. Средний уровень детализации имеют пользовательские, но никак не бизнес-требования. «Они настолько верхнеуровневые, что даже Гулливер задирает голову» 😁


2️⃣ Верно ли, что требования переходного периода реализуются для того, чтобы переход между текущим состоянием системы и её будущим состоянием произошёл с меньшими осложнениями?

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

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

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

3️⃣ Верно ли, что пользовательские требования чаще всего формулируются по шаблону пользовательских историй?

Запрос пользователя безусловно можно сформулировать в формате, ближе к функциональным требованиям.

Например:
Пользователь должен иметь возможность указывать банковскую карту для оплаты.

Но если бы мы знали цель пользователя (чтобы что?): удобно и быстро проводить оплату без повторного ввода номера карты, то функциональное требование бы изменилось на:

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

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

Именно поэтому пользовательские требования лучше формулировать по шаблону User story.

4️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?

Нефункциональные требования влияют на результат функциональных требований, но не на сами алгоритмы выполнения функции. Процесс всё равно выполнится – успешно или неуспешно, но он будет завершён. Огромное вам спасибо за обсуждение в комментариях – там мы постарались разобрать формулировку вопроса и аргументировать разные точки зрения (это было супер!) 🖤