Использование методологий

Все темы Systems Analyst

Приходилось ли вам писать Use cases? Как пишутся Use cases?

О личном опыте расскажите на примере реального проекта. Use case обычно описывают так:

1. Определение актеров: Определите все актеры (пользователи или системы), которые будут взаимодействовать с системой.

2. Идентификация основных функциональных потребностей: Определите основные цели и задачи, которые должна выполнять система для каждого актера.

3. Написание основного потока событий: Опишите основной сценарий, который показывает последовательность действий между актерами и системой для достижения целей.

4. Описание альтернативных и расширенных потоков: Укажите возможные альтернативные сценарии и исключения, которые могут возникнуть в процессе выполнения основного потока событий.

5. Уточнение требований: Детализируйте каждый Use case, уточняя предусловия, постусловия и любые дополнительные условия, влияющие на его выполнение.

6. Проверка и утверждение: Проведите проверку Use cases с заинтересованными сторонами (стейкхолдерами) для утверждения и согласования.

7. Документация: Зафиксируйте Use cases в документации проекта для последующего использования разработчиками, тестировщиками и другими участниками проекта.

Приходилось ли вам писать User story?

Если у вас есть такой опыт, приведите реальную историю и её критерии приёмки. User story кратко описывает потребность с точки зрения пользователя; распространённый шаблон включает:

1. Заголовок (As a…): Определяет тип пользователя или роль, для которой пишется история.

2. Описание (I want to…): Описывает желаемую функциональность или задачу, которую пользователь хочет выполнить.

3. Цель или польза (So that…): объясняет, зачем пользователю эта возможность. Критерии приёмки записывают отдельно: они определяют проверяемые условия выполнения истории.

User stories используются для коммуникации между участниками проекта (разработчики, заказчики, тестировщики) и позволяют лучше понять потребности пользователей, что способствует более эффективной итеративной разработке ПО.

Как проверить готовность User Story к разработке?

User Story готова к разработке, если команда одинаково понимает её ценность, границы и ожидаемый результат. Проверяют, можно ли реализовать историю достаточно независимо, помещается ли она в итерацию, описаны ли критерии приёмки, негативные случаи и нужные макеты или контракты. Зависимости, данные, ограничения и открытые вопросы должны быть выявлены, а внешние решения получены либо явно вынесены из объёма. Финальный критерий практический: разработчик, тестировщик и владелец продукта могут оценить работу и объяснить, как подтвердят её готовность.

Когда Given-When-Then ухудшает описание требования?

Given-When-Then ухудшает описание, когда простое правило приходится искусственно размножать на десятки почти одинаковых сценариев. Для большого числа комбинаций условий лучше таблица решений, для вычислений и преобразований данных подходят формула, примеры входа-выхода или отдельная спецификация. Нотация также неудобна для общих инвариантов, которые должны выполняться во всех сценариях. Технические шаги интерфейса делают текст хрупким и скрывают бизнес-поведение. Формат полезен, если есть конкретное исходное состояние, одно значимое событие и наблюдаемый результат. Выбор формы определяется сложностью правила, а не требованием писать всё одинаково.

Как написать проверяемый сценарий Given-When-Then?

Given задаёт минимальное однозначное начальное состояние и значимые данные. When содержит одно бизнес-событие или действие, которое проверяется. Then описывает наблюдаемый результат: изменение состояния, ответ, событие или отсутствие эффекта. Сценарий связывают с конкретным правилом и не прячут в шагах детали кликов или реализации. Если нужно много комбинаций, используют Scenario Outline либо таблицу решений, но каждая строка всё равно должна давать понятный результат. Хороший сценарий независим, воспроизводим и позволяет без догадки определить, выполнено требование или нет.