--- title: Использование методологий questionDates: q-transfer-0332: '2026-10-01' q-transfer-0353: '2026-10-01' q-transfer-0354: '2026-10-01' seo: description: >- Тема «Использование методологий» для собеседования Systems Analyst. Приходилось ли вам писать Use cases? Как пишутся Use cases? Приходилось ли вам писать User story? title: Использование методологий — Systems Analyst --- [Все темы Systems Analyst](/prep/systems-analyst) ## Приходилось ли вам писать Use cases? Как пишутся Use cases? [#q-14bee738d69b81759319c5e766cc8d1b] О личном опыте расскажите на примере реального проекта. Use case обычно описывают так: 1. Определение актеров: Определите все актеры (пользователи или системы), которые будут взаимодействовать с системой. 1. Идентификация основных функциональных потребностей: Определите основные цели и задачи, которые должна выполнять система для каждого актера. 1. Написание основного потока событий: Опишите основной сценарий, который показывает последовательность действий между актерами и системой для достижения целей. 1. Описание альтернативных и расширенных потоков: Укажите возможные альтернативные сценарии и исключения, которые могут возникнуть в процессе выполнения основного потока событий. 1. Уточнение требований: Детализируйте каждый Use case, уточняя предусловия, постусловия и любые дополнительные условия, влияющие на его выполнение. 1. Проверка и утверждение: Проведите проверку Use cases с заинтересованными сторонами (стейкхолдерами) для утверждения и согласования. 1. Документация: Зафиксируйте Use cases в документации проекта для последующего использования разработчиками, тестировщиками и другими участниками проекта. :::note[Ссылки для изучения] 1. [Как описывать Use Case: структура сценария и пример перевода между счетами](https://habr.com/ru/articles/902884/) ::: --- ## Приходилось ли вам писать User story? [#q-14bee738d69b81858dd2c099ea86a532] Если у вас есть такой опыт, приведите реальную историю и её критерии приёмки. User story кратко описывает потребность с точки зрения пользователя; распространённый шаблон включает: 1. Заголовок (As a...): Определяет тип пользователя или роль, для которой пишется история. 1. Описание (I want to...): Описывает желаемую функциональность или задачу, которую пользователь хочет выполнить. 1. Цель или польза (So that...): объясняет, зачем пользователю эта возможность. Критерии приёмки записывают отдельно: они определяют проверяемые условия выполнения истории. User stories используются для коммуникации между участниками проекта (разработчики, заказчики, тестировщики) и позволяют лучше понять потребности пользователей, что способствует более эффективной итеративной разработке ПО. :::note[Ссылки для изучения] 1. [Как писать пользовательские истории: роль, потребность, польза и критерии приёмки — Atlassian](https://www.atlassian.com/ru/agile/project-management/user-stories) 2. [User Story и критерии приёмки. Artsiom Rusau QA Life, с 17:26](https://www.youtube.com/watch?v=Ct8mK-lFw1Q&t=1046s) ::: --- ## Как проверить готовность User Story к разработке? [#q-transfer-0332] User Story готова к разработке, если команда одинаково понимает её ценность, границы и ожидаемый результат. Проверяют, можно ли реализовать историю достаточно независимо, помещается ли она в итерацию, описаны ли критерии приёмки, негативные случаи и нужные макеты или контракты. Зависимости, данные, ограничения и открытые вопросы должны быть выявлены, а внешние решения получены либо явно вынесены из объёма. Финальный критерий практический: разработчик, тестировщик и владелец продукта могут оценить работу и объяснить, как подтвердят её готовность. :::note[Ссылки для изучения] 1. [Definition of Ready: критерии готовности истории и ограничения подхода — ScrumTrek](https://scrumtrek.ru/blog/product-management/15874/chto-takoe-definition-of-ready/) ::: --- ## Когда Given-When-Then ухудшает описание требования? [#q-transfer-0353] Given-When-Then ухудшает описание, когда простое правило приходится искусственно размножать на десятки почти одинаковых сценариев. Для большого числа комбинаций условий лучше таблица решений, для вычислений и преобразований данных подходят формула, примеры входа-выхода или отдельная спецификация. Нотация также неудобна для общих инвариантов, которые должны выполняться во всех сценариях. Технические шаги интерфейса делают текст хрупким и скрывают бизнес-поведение. Формат полезен, если есть конкретное исходное состояние, одно значимое событие и наблюдаемый результат. Выбор формы определяется сложностью правила, а не требованием писать всё одинаково. :::note[Ссылки для изучения] 1. [Когда таблица или диаграмма удобнее повторяющихся Given–When–Then: пример светофора](https://habr.com/ru/articles/344588/) ::: --- ## Как написать проверяемый сценарий Given-When-Then? [#q-transfer-0354] `Given` задаёт минимальное однозначное начальное состояние и значимые данные. `When` содержит одно бизнес-событие или действие, которое проверяется. `Then` описывает наблюдаемый результат: изменение состояния, ответ, событие или отсутствие эффекта. Сценарий связывают с конкретным правилом и не прячут в шагах детали кликов или реализации. Если нужно много комбинаций, используют `Scenario Outline` либо таблицу решений, но каждая строка всё равно должна давать понятный результат. Хороший сценарий независим, воспроизводим и позволяет без догадки определить, выполнено требование или нет. :::note[Ссылки для изучения] 1. [Given–When–Then: начальное состояние, событие и проверяемый результат на примере светофора](https://habr.com/ru/articles/344588/) :::