Инженерия требований составляет фундамент любого успешного программного проекта. Среди различных доступных методов описание случая использования остается одним из наиболее эффективных способов сбора функциональных требований с точки зрения пользователя. Хорошо написанный случай использования устраняет разрыв между бизнес-потребностями и технической реализацией, обеспечивая единое понимание поведения системы всеми заинтересованными сторонами.
Однако неоднозначность в этих описаниях часто приводит к ошибкам при разработке, расширению сферы проекта и сбоям при тестировании. Это руководство предлагает структурированный подход к созданию точных, выполнимых описаний случаев использования с использованием стандартов унифицированного языка моделирования (UML). Следуя установленным шаблонам, команды могут создавать документацию, которая служит одновременно чертежом проекта и чек-листом для проверки.
🔍 Понимание основных компонентов
Прежде чем приступать к написанию повествовательного текста, необходимо определить структурные элементы, составляющие полный случай использования. Эти компоненты обеспечивают ограниченность и измеримость сценария.
1. Актор 🧍
Актор представляет собой роль, которую выполняет сущность, взаимодействующая с системой. Акторы находятся за пределами границы системы. Они могут быть:
- Человеческие акторы:Реальные люди, такие как клиент, администратор или техник.
- Внешние системы:Другие программные или аппаратные интерфейсы, которые запускают или получают данные.
- Акторы, основанные на времени:События, запускаемые часами или таймером, например, запланированный процесс резервного копирования.
При определении актора назначьте конкретную роль, а не конкретное должностное название. Например, используйте «Зарегистрированный пользователь» вместо «Джон Доу». Это обеспечивает сохранность требования даже при смене персонала.
2. Граница системы ⬜
Граница системы определяет, что находится внутри программного обеспечения, а что — снаружи. Она уточняет ответственность. Все, что находится внутри рамки, — это система; все, что снаружи, — это окружающая среда. Это различие критически важно для определения ответственности за конкретную ошибку или действие.
3. Цель 🎯
Каждый случай использования представляет собой одну цель, которую актор хочет достичь. Если описание содержит несколько нерелевантных целей, его следует разделить на отдельные случаи использования. Одна цель обеспечивает возможность тестирования и управляемости случая использования.
📋 Анатомия описания случая использования
Полное описание выходит за рамки простой диаграммы. Оно требует текстового описания, детально раскрывающего последовательность взаимодействий. Ниже приведена стандартная структура, используемая в профессиональной документации по требованиям.
Метаданные и идентификация
- Идентификатор случая использования:Уникальный идентификатор (например, UC-001) для отслеживания.
- Название случая использования:Фраза из глагола и существительного, описывающая действие (например, «Подать заказ»).
- Основной актор:Основной пользователь, инициирующий действие.
- Второстепенные акторы:Любые поддерживающие системы или пользователи.
- Приоритет: Критически важный, высокий, средний или низкий.
Предусловия
Предусловия определяют состояние системы до начала использования. Если эти условия не выполняются, использование не может начаться. Это помогает тестировщикам понять необходимую настройку.
- Пользователь должен быть авторизован в системе.
- В корзине покупок должно быть хотя бы одно изделие.
- Платежный шлюз должен быть в сети.
Постусловия
Постусловия описывают состояние системы после успешного завершения использования. Они служат критериями приемки функции.
- В базе данных создается новая запись заказа.
- Пользователю отправляется подтверждение по электронной почте.
- Уровни запасов обновляются.
Последовательность событий
Это суть описания. Оно описывает последовательность шагов, выполняемых актером и системой. Обычно она делится на основной сценарий успеха и дополнения.
🚀 Основной сценарий успеха (путь успеха)
Основной сценарий успеха описывает идеальный путь, когда всё идет хорошо. Нет ошибок, прерываний или альтернативных решений. Каждый шаг должен быть атомарным, то есть представлять собой единую операцию, которую нельзя разделить дальше без потери смысла.
При написании этих шагов соблюдайте следующие рекомендации:
- Нумеруйте шаги: Используйте 1, 2, 3… для обозначения последовательности.
- Определите источник: Четко укажите, кто инициирует шаг (Актер или Система).
- Используйте действительные глаголы: Начинайте с глаголов действия, таких как «Выбрать», «Ввести», «Отобразить» или «Проверить».
- Избегайте технической терминологии: Описывайте то, что видит пользователь, а не запрос к базе данных за кадром.
🛑 Альтернативные и исключительные потоки
На практике использование редко следует идеальному пути. Дополнения обрабатывают отклонения от основного потока. Они критически важны для надежного сбора требований.
Альтернативные потоки
Они возникают, когда актер делает выбор, отличный от основного пути. Они все равно приводят к той же цели, но по другому маршруту.
- Пример: Пользователь выбирает применить код скидки при оформлении заказа.
Потоки исключений
Они возникают, когда что-то пойдет не так. Система должна корректно обрабатывать ошибки. Цель использования может не выполниться, но может быть восстановлена.
- Пример: Шлюз оплаты возвращает сообщение об ошибке.
- Пример: У пользователя недостаточно средств.
Расширения должны ссылаться на конкретный номер шага в основной сценарии успеха, где происходит отклонение.
📝 Практический пример: «Обработка оплаты»
Чтобы проиллюстрировать эти концепции, рассмотрим общий сценарий обработки платежа. Этот пример показывает, как переводить абстрактные идеи в конкретные шаги.
| Шаг | Актор/Система | Действие | Ответ |
|---|---|---|---|
| 1 | Актор | Выбирает кнопку «Оплатить сейчас». | – |
| 2 | Система | Отображает форму оплаты. | Форма появляется с полями карты. |
| 3 | Актор | Вводит данные карты. | – |
| 4 | Система | Проверяет данные карты. | Проверяет формат и срок действия. |
| 5 | Система | Отправляет транзакцию шлюзу. | – |
| 6 | Шлюз | Возвращает авторизацию. | Код успеха или ошибки. |
| 7 | Система | Подтверждает оплату. | Показывает экран успеха. |
Альтернативный поток A (недействительная карта):
- На шаге 4, если проверка не пройдена, отобразить сообщение об ошибке.
- Позволить пользователю повторно ввести данные.
Альтернативный поток B (тайм-аут):
- На шаге 5, если шлюз не отвечает в течение 10 секунд, отобразить сообщение о тайм-ауте.
- Позволить пользователю повторить попытку или отменить.
🛠 Лучшие практики для ясности и точности
Формулирование требований — это навык, который улучшается с практикой. Соблюдение конкретных стандартов снижает вероятность неверного толкования между бизнес-аналитиками, разработчиками и тестировщиками.
1. Поддерживайте детализацию
Не объединяйте несколько действий в одну стадию. Если шаг требует от пользователя нажать кнопку, а затем ввести текст, разделите его на две стадии. Детализация обеспечивает возможность написания тестовых случаев для каждого конкретного взаимодействия.
2. Избегайте предположений
Никогда не предполагайте, что пользователь знает технические термины. Избегайте слов, таких как «парсить», «коммитить» или «кэшировать», если интерфейс явно не отображает их. Описывайте результат, а не механизм.
3. Согласованность терминологии
Используйте контролируемую лексику. Если вы называете это «Продуктом» в одной части, не называйте его «Товаром» в другой. Несогласованность сбивает с толку разработчиков и приводит к ошибкам сопоставления с базой данных.
4. Фокусируйтесь на поведении, а не на реализации
Описывайте, что делает система, а не как она это делает. Например, напишите «Система проверяет наличие на складе», а не «Система запрашивает таблицу инвентаря SQL». Первый вариант позволяет команде разработки выбрать лучшую технологию.
⚠️ Распространённые ошибки, которые следует избегать
Даже опытные авторы допускают ошибки. Признание этих паттернов на ранних этапах предотвращает повторную работу на более поздних этапах жизненного цикла разработки.
Ошибка 1: «Божественный сценарий использования»
Это происходит, когда один сценарий использования пытается сделать слишком много. Если сценарий использования имеет 50 шагов, он, скорее всего, охватывает несколько целей. Разбейте его на более мелкие, сфокусированные сценарии использования.
Опасность 2: Отсутствующие предварительные условия
Пропуск предварительных условий заставляет тестировщиков гадать о начальном состоянии. Это часто приводит к нестабильным тестам, которые случайным образом завершаются неудачно, потому что среда не была настроена правильно.
Опасность 3: Неопределённые глаголы
Избегайте слов, таких как «управлять», «обращаться» или «обрабатывать». Они слишком общие. Вместо этого используйте «Обновить», «Удалить», «Вычислить» или «Отправить». Точность устраняет неоднозначность.
Опасность 4: Смешение уровней детализации
Не смешивайте высокие бизнес-цели с низкоуровневыми действиями интерфейса. Держите основной сценарий успеха на логическом уровне. Детали интерфейса можно документировать отдельно в макетах или спецификациях интерфейса.
🔗 Интеграция с другими спецификациями
Сценарии использования не существуют изолированно. Они связаны с другими элементами в документации требований.
- Следуемость: Каждый сценарий использования должен соответствовать конкретным пользовательским историям или бизнес-целям. Это гарантирует, что каждая функция выполняет свою цель.
- Тест-кейсы: Шаги в основном сценарии успеха напрямую трансформируются в положительные тест-кейсы. Расширения трансформируются в отрицательные тест-кейсы.
- Проектирование интерфейса: Акторы и шаги определяют структуру навигации и макеты экранов.
- Проектирование базы данных: Данные, упомянутые в шагах (например, «Введите номер кредитной карты»), определяют требования к модели данных.
📊 Сравнение: Эффективные и неэффективные описания
Разница между хорошим и плохим требованием часто заключается в уровне детализации и ясности. В таблице ниже выделены эти различия.
| Функция | ❌ Неэффективное описание | ✅ Эффективное описание |
|---|---|---|
| Актор | «Пользователь» | «Зарегистрированный администратор» |
| Шаг | «Обработать вход в систему» | «Введите имя пользователя и пароль» |
| Результат | «Система проверяет доступ» | «Система проверяет учетные данные в базе данных» |
| Исключение | «Если это не удается» | «Если учетные данные неверны, покажите сообщение об ошибке и сбросьте поле» |
| Область | «Управлять всем» | «Просмотр и редактирование профиля пользователя» |
Обратите внимание, как эффективное описание предоставляет конкретные действия и четкие границы. Это снижает когнитивную нагрузку на разработчика, реализующего функцию.
🧩 Обработка сложных сценариев
Не все требования подходят для простой линейной последовательности. Некоторые сценарии включают параллельные процессы или условную логику.
Отношения включения и расширения
В UML случаи использования могут быть связаны между собой. В включениеотношение возникает, когда один случай использования всегда требует другого для функционирования. Например, «Сделать заказ» всегда включает «Проверка оплаты». Это уменьшает избыточность в описаниях.
В расширенииотношение позволяет одному случаю использования добавлять поведение другому при определенных условиях. Например, «Применить скидку» расширяет «Сделать заказ», только если у пользователя есть промокод.
Параллельные процессы
Для сложных систем одна последовательность может быть недостаточной. Используйте подпотоки или отдельные диаграммы для представления параллельных действий. Убедитесь, что точки взаимодействия между этими потоками четко определены.
🔍 Обзор и проверка
Как только описание написано, его необходимо проверить. Документ не считается завершенным, пока его не проверили заинтересованные стороны.
- Обход: Проведите обход с владельцем бизнеса. Попросите его прочитать шаги и подтвердить, что они соответствуют его внутренней модели.
- Проверка осуществимости: Проконсультируйтесь с ведущим разработчиком. Убедитесь, что шаги технически выполнимы в рамках ограничений проекта.
- Полнота: Проверьте наличие пропущенных путей ошибок. Что произойдет, если интернет отключится? Что будет, если база данных заполнена?
- Согласованность: Убедитесь, что термины совпадают во всем документе требований.
🛠 Инструменты и форматы
Формат описания варианта использования может варьироваться в зависимости от потребностей проекта. Распространенные форматы включают:
- Структурированный текст:Формат нумерованного списка, подходящий для Word или Google Docs.
- Формат таблицы:Табличное оформление для быстрого сканирования, часто используемое в электронных таблицах.
- Записи в базе данных:Хранятся в инструментах управления требованиями для обеспечения отслеживаемости.
- Страницы вики:Совместно создаваемые страницы, позволяющие вести историю версий и устанавливать ссылки.
Независимо от носителя, структура содержания остается неизменной. Цель — доступность и ясность, а не конкретный тип файла.
🔗 От требований к тестированию
Конечная ценность описания варианта использования заключается в его полезности на этапе тестирования. Тестировщики используют основной сценарий успеха для определения тестов «счастливого пути». Они используют расширения для определения тестов «негативного пути».
Если описание варианта использования неясно, тестовые случаи будут неполными. Это приводит к пробелам в покрытии и ошибкам, достигающим продакшена. Четкие описания выступают в качестве контракта между бизнесом и инженерной командой.
📈 Оценка качества
Как вы узнаете, что ваши варианты использования имеют высокое качество? Обратите внимание на эти показатели:
- Тестируемость:Может ли тестировщик составить тестовый случай, основываясь только на этом тексте?
- Однозначность:Существует ли только одно возможное толкование?
- Отслеживаемость:Можно ли связать это с бизнес-целью?
- Полнота:Охвачены ли все основные пути и исключения?
🏁 Основные выводы
Создание эффективных описаний вариантов использования требует дисциплины и внимания к деталям. Речь идет не просто о документировании того, что делает система, а о определении границ ее поведения. Сосредоточившись на атомарных шагах, четких предусловиях и надежной обработке исключений, команды могут снизить неоднозначность и улучшить качество доставки.
Ключевые элементы, которые следует помнить:
- Четко определите участников и границы системы.
- Используйте структурированный формат с ID, названием и потоком.
- Разделяйте основной сценарий успеха от альтернативных и исключительных потоков.
- Используйте действительные глаголы и конкретную терминологию.
- Проверьте описания с заинтересованными сторонами до начала разработки.
Вложение времени в написание четких требований окупается на протяжении всего жизненного цикла проекта. Это снижает повторную работу, уточняет ожидания и обеспечивает соответствие конечного продукта реальным потребностям пользователей.
