Системный аналитик — это тот, кто ищет детали

У системного аналитика много задач, и одна из самых важных — работа с требованиями. И вот что мы хотим сказать всем начинающим: не верьте исходному требованию в лоб. Любое требование можно (и нужно!) раскручивать.

Например, заказчик говорит:
Сделайте возможность регистрации пользователей на сайте.

Вы передали это разработчикам, а они возвращаются к вам с уточняющими вопросами:
😱 Какой минимум данных нужен для регистрации?
😱 Нужно ли подтверждение email или телефона?
😱 Какие поля должны быть обязательными?
😱 Нужно ли поддерживать регистрацию через соцсети?
😱 Как будет реализована безопасность?
и еще 20 вопросов

Заказчик сказал немного, но за этим стоит огромный пласт работы.
Ваша задача как системного аналитика — найти детали, которые упустил заказчик, и превратить общую идею в конкретное, понятное требование.

💡 Это и есть системное мышление. Развивайте его, и работа с требованиями станет вашим сильным преимуществом!

#requirements

Тренируем системное мышление! 🧠✨

К вам пришел заказчик с требованием:
Хочу добавить фильтры для поиска товаров в интернет-магазине.

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

✅ Какие параметры фильтрации важны для товаров? (цена, категория, бренд, цвет, размер и т.д.)
✅ Сколько фильтров пользователь может применить одновременно?
✅ Как будет отображаться результат после применения фильтров?
✅ Должен ли фильтр запоминать предыдущий выбор пользователя?
✅ Какие виды товаров вообще подлежат фильтрации?
✅ Как обработать ситуацию, если под выбранные фильтры нет товаров?
✅ Фильтры должны обновляться автоматически или по кнопке?

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

👉 Вопрос на подумать: Что ещё нужно уточнить у заказчика про фильтры? Можете написать свои варианты в комментариях.

#requirements

💡 Как одно требование превращается в множество?

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

Мы задали уточняющие вопросы:
* Где будет размещаться форма для отзыва?
* Какие поля должны быть в форме?
* Нужно ли подтверждение личности пользователя?
* Можно ли добавлять фото или видео?
* Как будут модераться отзывы?
* Должны ли отображаться только положительные отзывы?

После уточнений требование превратилось в:
1️⃣ Форма отзыва с полями: текст, оценка, фото/видео.
2️⃣ Проверка пользователя через подтверждение email.
3️⃣ Автоматическая и ручная модерация.
4️⃣ Сортировка отзывов по дате или оценке.
5️⃣ Возможность лайкать и жаловаться на отзывы.

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

#requirements

Продолжаем тренировать системное мышление 🧠

Изначальное требование от заказчика:
Сделайте поиск товаров на сайте.

Здесь кажется, что всё просто, но системный аналитик то знает... Это только верхушка айсберга. Что скрывается за этой формулировкой?
1️⃣ Добавить строку поиска на главную страницу.
2️⃣ Настроить поиск по названию товара.
3️⃣ Настроить поиск по категориям и фильтрам.
4️⃣ Реализовать автодополнение и подсказки при вводе.
5️⃣ Обрабатывать некорректные запросы (например, опечатки).

Дальше детализируем один из пунктов:
4️⃣ Реализовать автодополнение и подсказки при вводе.

4.1. Источник данных для автодополнения (на основе популярных запросов или полного каталога товаров).
4.2. Ограничение на количество подсказок (например, до 10 вариантов).
4.3. Визуальное оформление подсказок (добавлять иконки категорий, фото товара и т.д.).
4.4. Реализация подсказок для часто задаваемых вопросов (например, «доставка», «возврат»).
4.5. Логика обработки, если пользователь не завершил ввод и быстро удалил текст.

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

Системный аналитик — это тот, кто видит детали за каждым общим требованием.

#requirements

Вы молодцы! 🎉 Спасибо, что участвовали в задании!

Все ответы были правильными, кроме:
❌ Автодобавление товаров в корзину при выборе категории — поиск и фильтрация товаров должны оставаться на уровне отображения товаров, а не вмешиваться в процессы добавления в корзину.
❌ Запретить пользователю менять категории после выбора — это ограничение, да и вредное. Мы не можем «привязать» пользователя к одной категории, так как это ограничивает возможности поиска.

Продолжим тренировку! 🧠

К нам пришли с требованием:
Реализовать корзину покупателя на сайте.

Это требование можно разложить:
1️⃣ Добавление товаров в корзину.
2️⃣ Удаление товаров из корзины.
3️⃣ Просмотр содержимого корзины.
4️⃣ Изменение количества товаров.
5️⃣ Подсчет общей стоимости товаров.
6️⃣ Проверка наличия товаров на складе.
7️⃣ Возможность сохранения корзины между сессиями.
8️⃣ Очистка всей корзины одним кликом.

#requirements

Разбираем ошибки

Судя по предыдущему заданию есть вопросы к некоторым вариантам ответа. Все варианты верные, кроме:
❌ Запретить пользователю изменять товары в корзине после добавления — это «вредное» ограничение. В нашем примере мы собирали требования к обычному интернет-магазину, где можно менять количество.
❌ Добавление товаров в Избранное — это отдельная функция, которая имеет свой сценарий использования.
❌ Оформление заказа с возможностью выбора способов доставки — это следующая стадия после наполнения корзины.

#requirements

Пишем через «Если, то, иначе» 🚦

Эту конструкцию часто используют разработчики в коде:
💡 Если пользователь нажал кнопку,
💡 то открыть окно регистрации,
💡 иначе показать подсказку.

Как это помогает нам, системным аналитикам?
Вопросы «А что будет, если...?», «Что делать, если иначе?» помогают сделать требования более качественными и детализированными.

Например:
✏️ Если товар есть в наличии, то добавляем его в корзину, иначе показываем сообщение, что товар закончился.

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

Каждое «если» — это возможность предусмотреть нюансы, улучшить требования и избежать будущих доработок. Чем больше вы задаёте такие вопросы, тем качественнее становятся ваши требования.

#requirements

Если, то, иначе: учимся предусматривать всё 🧠

Давайте проработаем требование: Возврат товара в интернет-магазине.

💡 Сценарий 1:
Если товар куплен онлайн, то возврат делается через форму на сайте, иначе через чек в магазине.

💡 Сценарий 2:
Если прошло менее 14 дней с момента покупки, то возврат возможен, иначе требуется подтверждение от службы поддержки.

💡 Сценарий 3:
Если товар повреждён, то при возврате требуется фото с описанием дефекта, иначе достаточно указать причину возврата.

Каждое из этих «если» помогает нам учесть важные аспекты работы системы.

#requirements

Алгебра логики для системного аналитика
Это про умение работать с условиями: И, ИЛИ, НЕ. Вспоминаем уроки информатики в школе!

❗Почему это важно?

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

Представим, что мы разрабатываем hh.ru.
Задача — добавить баннер с рекламой Премиума. Компания заинтересована продвигать платный тариф.
❌ Формулировка «Реализовать баннер с рекламой премиума» недостаточно.
Разработчику нужны четкие условия. В ТЗ это может выглядеть так:

- Если статус соискателя «Активно ищу работу» И у него тариф НЕ «Премиум», то отображать баннер с рекламой премиума.
- Иначе отображать баннер с предложением «проверить резюме hr-специалистами».

Давайте протестируем это условие. Какие вообще могут быть варианты?

💡 КЕЙС_1
статус соискателя = «Активно ищу работу», тариф «Премиум»
Что отобразится по описанной выше логике?
Ответ: баннер с предложением «проверить резюме hr-специалистами»

💡 КЕЙС_2
статус соискателя = «Не ищу работу», тариф «Премиум»
Что отобразится по описанной выше логике?
Ответ: снова баннер с предложением «проверить резюме hr-специалистами»

💡 КЕЙС_N .... принцип вы поняли)

Итого баннер с предложением «проверить резюме hr-специалистами» отобразится в случаях:
- статус соискателя = «Активно ищу работу», тариф «Премиум»
- статус соискателя = «Не ищу работу», тариф «Премиум»
- статус соискателя = «Не ищу работу», тариф НЕ «Премиум»
- статус соискателя = «Рассматриваю предложения», тариф «Премиум»
- статус соискателя = «Рассматриваю предложения», тариф НЕ «Премиум»

❗Почему так?
В нашем условии указан оператор «И».

Оператор И требует выполнения всех условий. Поэтому в нашем примере для показа баннера с рекламой премиума должны одновременно выполняться два условия:
1️⃣ Статус соискателя = «Активно ищу работу»,
2️⃣ Тариф НЕ = «Премиум».
Если хотя бы одно из них не выполняется, логика переходит к «Иначе».

#requirements

Оператор И: основы алгебры логики

Оператор И — означает, что для выполнения условия должны быть верны все его части.

Пример из жизни:
💡 Если сегодня выходной И погода хорошая, то мы идем на пикник.
Если хотя бы одно из условий не выполняется (не выходной или плохая погода), на пикник мы не идем.

Пример в разработке:
💡 Если пользователь активен И его подписка истекает через 7 дней, то отправить напоминание о продлении.
И = все условия должны быть выполнены.
👆 Если пользователь не активен или подписка истекает позже, напоминание не отправится.

#requirements

Упражнение на оператор «И»

Условие:
* Если пользователь подтвердил email И заполнил профиль, то показать поздравительное сообщение. 🎉
* Иначе показать напоминание о завершении регистрации.

❓Вопрос: В каких случаях покажется напоминание о завершении регистрации?

Спасибо, что участвуете!
❗Правильный ответ на прошлое задание.
Напоминание о завершении регистрации отобразится во всех кейсах, кроме
3️⃣ Пользователь подтвердил email И заполнил профиль.

__________

Давайте еще потренируемся 👇

Жизненно:
* Если в холодильнике есть молоко И хлеб, то можно приготовить завтрак.
* Иначе придется отправиться в магазин за продуктами.

❓Вопрос: В каких случаях нужно будет идти в магазин?

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

💪💪💪💪💪

Выполняйте задания, и вы быстрее придёте к своей цели — стать хорошим системным аналитиком.

Сегодня вы учитесь, завтра — используете новые знания, а послезавтра — получаете повышение грейда и зп.
Начните сегодня, и в будущем скажете себе спасибо! 🌟

Оператор ИЛИ: основы алгебры логики

Оператор ИЛИ — означает, что условие выполнится, если верно хотя бы одно из его частей.

Пример из жизни:
💡 Если я захочу пиццу ИЛИ суши, я закажу еду на ужин.
Если хотя бы одно из условий выполняется (я хочу пиццу, или я хочу суши), то заказ будет оформлен. Пицца или суши приедут ко мне на ужин.

Пример в разработке:
💡 Если пользователь выбрал способ оплаты наличкой ИЛИ СБП, то предоставить скидку.
ИЛИ = достаточно выполнения хотя бы одного из условий.
👆 Если пользователь выбрал оплату другим способом (не наличкой, не СБП), например, банковской картой, то скидка не применится.

#requirements

Упражнение на оператор «ИЛИ»

Условие:
* Если пользователь выбрал оплату через СБП ИЛИ наличкой, то применить скидку 5% к сумме заказа.
* Иначе отобразить сообщение о скидке при оплате наличными или СБП.

❓ Вопрос: В каких случаях не будет применена скидка?

Спасибо вам за участие! ❤️
❗Правильный ответ.
Скидка не будет применена, если:
3️⃣ Пользователь выбрал оплату банковской картой
4️⃣ Пользователь выбрал оплату через криптовалюту

__________

Теперь посложнее. Скомбинируем операторы И и ИЛИ 👇

Условие:
* Если пользователь выбрал оплату через СБП ИЛИ наличными, то применить скидку 5%.
* Если пользователь выбрал оплату через банковскую карту И у него статус «новый клиент», то предложить дополнительную скидку 3%.
* Иначе — не применяются скидки.

❓ Вопрос: В каких случаях не будет применена ни одна скидка?