Финальная часть серии. Мы прошли интеграции, архитектуру, базы данных, SQL и диаграммы. Сегодня закрываем блоки, которые проверяют на каждом собеседовании без исключений: требования, методология разработки, тестирование, безопасность.
В конце — краткий итог всей серии. Сохрани этот пост вместе с предыдущими тремя — это полный чеклист подготовки от Junior до Senior.
────────────────────────────────────────
▶ Требования: ФТ и НФТ
Первый вопрос на любом уровне — чем отличаются функциональные требования от нефункциональных.
Функциональные требования (ФТ) описывают что система делает. Конкретные функции, действия, поведение. Пример: "Пользователь может зарегистрироваться через email и пароль."
Нефункциональные требования (НФТ) описывают как система работает. Производительность, безопасность, надёжность, масштабируемость. Пример: "Страница загружается не более 2 секунд при 1000 одновременных пользователях."
Частая ошибка кандидатов — путать НФТ с ограничениями или считать их второстепенными. На практике именно НФТ определяют архитектурные решения.
────────────────────────────────────────
▶ User Story vs Use Case
Два инструмента описания требований — их часто путают или не понимают разницу.
User Story — формат agile-команд:
Структура: "Как [роль] я хочу [действие], чтобы [ценность]."
Пример: "Как покупатель я хочу добавить товар в избранное, чтобы вернуться к нему позже."
К User Story обязательно пишутся Acceptance Criteria (критерии приёмки) — конкретные условия, при которых история считается выполненной.
Когда применять: в продуктовых командах, в Scrum, когда важна ценность для пользователя.
Use Case — более формальный инструмент:
Включает: актора (кто), предусловия (что должно быть выполнено до), основной поток (шаги успешного сценария), альтернативные потоки (что происходит при отклонениях).
Когда применять: в проектах с чёткими требованиями заказчика, при работе с государственными или корпоративными системами, когда нужна формальная документация.
Что нужно для задачи в разработку:
Хорошо написанная задача содержит: контекст и цель, описание поведения системы (happy path и альтернативы), критерии приёмки, макеты или схемы если нужны, ссылки на связанные требования и нефункциональные ограничения.
────────────────────────────────────────
▶ Scrum: события и артефакты
На собеседовании почти всегда спрашивают про методологию работы команды.
События Scrum:
• Sprint Planning: команда планирует что делать в спринте, выбирает задачи из бэклога
• Daily Standup: ежедневная встреча 15 минут — что сделал, что делаю, есть ли блокеры
• Sprint Review: демонстрация того что сделано стейкхолдерам
• Sprint Retrospective: команда обсуждает что шло хорошо и что улучшить в процессе
• Refinement: уточнение и оценка задач до того как они попадут в спринт
Артефакты Scrum:
• Product Backlog: все задачи и идеи для продукта, упорядоченные по приоритету
• Sprint Backlog: задачи выбранные на текущий спринт
• Increment: рабочий результат спринта, потенциально готовый к выпуску
────────────────────────────────────────
▶ QA и тестирование
QC vs QA — вопрос на котором часто спотыкаются:
QC (Quality Control) — контроль качества: найти дефекты в уже существующем продукте. Тестировщик проверяет то что уже написано.
QA (Quality Assurance) — обеспечение качества: выстроить процессы чтобы дефекты не появлялись. QA работает с процессом разработки, а не только с продуктом. На практике многие компании называют тестировщика "QA-инженером" — но это не одно и то же. Настоящий QA участвует в ревью требований и планировании ещё до того как написана первая строчка кода. Аналитик должен понимать эту разницу, потому что именно он передаёт требования на эту стадию.
Виды тестирования — уровень Senior:
• Unit тестирование: проверка отдельного модуля или функции в изоляции
• Integration тестирование: проверка взаимодействия между компонентами
• E2E (End-to-End) тестирование: проверка полного пользовательского сценария от начала до конца
• Нагрузочное тестирование: проверка поведения системы под высокой нагрузкой
• Регрессионное тестирование: проверка что новые изменения не сломали существующий функционал
────────────────────────────────────────
▶ Аутентификация vs Авторизация
Это пара понятий которую путают даже опытные кандидаты.
Аутентификация — это процесс подтверждения личности: "Кто ты?" Логин и пароль, токен, биометрия — всё это аутентификация. Система проверяет что ты тот, за кого себя выдаёшь.
Авторизация — это процесс проверки прав: "Что тебе можно делать?" После того как система знает кто ты — она проверяет есть ли у тебя доступ к конкретному ресурсу или действию.
Простой пример: войти в систему — аутентификация. Попытаться удалить чужой файл и получить отказ — авторизация.
────────────────────────────────────────
▶ Дефект vs Инцидент
Дефект: поведение системы не соответствует требованиям. Есть чёткое ожидание из документации — и система его не выполняет. Это баг.
Инцидент: что-то пошло не так, но непонятно баг это или не баг. Нестандартная ситуация, которая требует расследования. Может оказаться дефектом, может оказаться некорректно написанным требованием, может быть пользовательской ошибкой.
────────────────────────────────────────
▶ ИТОГ СЕРИИ
Четыре поста — полный чеклист подготовки к собеседованию на системного аналитика.
Пост 1. Интеграции: REST API, методы, идемпотентность, статус-коды, SOAP vs REST, синхронное и асинхронное взаимодействие, брокеры сообщений, версионирование.
Пост 2. Архитектура и базы данных: монолит и микросервисы, C4 нотация, HTTP vs HTTPS, Docker, CI/CD, нормализация, ACID, типы связей, SQL vs NoSQL, партиционирование, шардинг, репликация.
Пост 3. SQL и диаграммы: типы JOIN, GROUP BY и HAVING, пагинация, транзакции в SQL, UML Sequence diagram, BPMN нотация — события, шлюзы, пулы, дорожки.
Пост 4. Требования, Scrum, QA: ФТ vs НФТ, User Story vs Use Case, Scrum события и артефакты, QC vs QA, виды тестирования, аутентификация vs авторизация, дефект vs инцидент.
Сохрани серию и проработай каждый блок. Это не теория ради теории — каждый пункт встречался на реальных собеседованиях. Удачи на интервью.
#системныйаналитик #собеседование #ITкарьера #аналитик #подготовка