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

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

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

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

#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️⃣ Верно ли, что нефункциональные требования влияют на функциональные возможности проектируемой системы?

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

🏎💨 Ну и последние два вопроса КВИЗа (финишная прямая, ребята! )


5️⃣ Укажите бизнес-требование в представленном перечне

Для этого давайте тезисно вспомним, что содержит бизнес-требование:
🔸 описание цели изменения с точки зрения бизнеса (выгода);
🔸 идеально, если содержит метрику успешности (с единицами измерения).

Проанализируем варианты ответов.

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

Второй вариант. Бизнес хочет увеличить количество участников сообщества (это цель), приведена даже метрика успеха – 20% (это мера ожидаемого результата). И даже рассказали про верхнеуровневую концепцию решения в конце. Класс, берём! ☑️

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

6️⃣ Укажите функциональное требование в представленном перечне

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

☝️ Очень важно, что мы говорим именно про формулировку требований к ПО. Если же мы описываем AS IS-работу системы (бэкенд логика, интеграционное взаимодействие и тд), то детализация до системного уровня зачастую необходима для чистого понимания текущих процессов.

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

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



Фух, ну и потрудились мы с вами в субботу! Спасибо вам за участие в КВИЗе и за общение в комментариях! 🖤

Мы же здесь не только мемы смотрим, а вообще-то общаемся с единомышленниками и развиваем экспертизу в системном и бизнес-анализе – ЭТО ЛИ НЕ ЧУДО?😊🎉

Отличных выходных, друзья!

Встречаются как-то на планёрке в ZOOM бизнес-аналитик, системный аналитик и аналитик данных. Еще, конечно, владелец бизнеса и руководитель проекта 😄

Владелец бизнеса говорит:
- Надо создать новый онлайн-магазин с украшениями.

🌟 Бизнес аналитик пойдёт проводить исследование: изучит конкурентов, проанализирует целевую аудиторию, текущие тенденции в отрасли. ОБЯЗАТЕЛЬНО разберётся в законодательстве: посмотрит законы и правила, регулирующие онлайн-торговлю, чтобы убедиться, что новый онлайн-магазин будет соответствовать всем требованиям.

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

🌟 Теперь в игру вступает системный аналитик

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

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

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

Весь процесс очень интересный, насыщенный, кропотливый.

🌟 Теперь поприветствуем аналитика данных

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

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

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