Хола, друзья! ✌️#hardGetAnalyst

Сегодня хотим рассказать вам про типы требований к программному обеспечению (ПО), с которыми на постоянной основе работают бизнес- и системные аналитики 🥷🦸‍♂️🦹


Существует множество классификаций требований (по Вигерсу и Битти, BABOK и другие), поэтому сегодня мы расскажем о каждом из типов, которые встречаются в работе аналитика.

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

Например:
Необходимо создать продукт, который позволит увеличить приток начинающих специалистов в сообщество 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 🖤💥