Функциональные требования и сценарии использования
Ключевые тезисы
- Функциональные требования описывают поведение системы — как она должна работать для выполнения задач пользователя.
- Они являются частью области решения, в отличие от пользовательских требований, которые описывают, что система должна делать.
- Ключевым инструментом для выявления функциональных требований являются сценарии вариантов использования, которые служат мостом между пользовательскими и функциональными требованиями.
- Качество функциональных требований критически важно для корректного понимания и реализации системы.
Основное содержание
Что такое функциональные требования?
Функциональные требования — это требования, описывающие поведение системы, то, как она должна работать для реализации пользовательских потребностей. Они детализируют, как система будет выполнять конкретные действия (например, «при нажатии кнопки X должно произойти Y»).
Сценарий варианта использования как промежуточный слой
Между пользовательским требованием (часто в виде варианта использования — «глагол + объект») и функциональными требованиями находится сценарий варианта использования. Он описывает последовательность шагов, как должно быть выполнено действие, но ещё не содержит конкретных параметров системы.
Структура сценария (по шаблону Вигерса):
- Идентификатор: Уникальный код (например,
UC-1) для удобства ссылок. - Название: Отражает суть действия.
- Описание: Краткий синопсис.
- Основное действующее лицо: Тот, кто инициирует и выполняет основные действия (человек или система).
- Предусловия: Условия, которые должны быть выполнены до старта сценария (например, «пользователь авторизован»).
- Пост-условия: Результат, который должен быть достигнут после выполнения сценария (физический результат или запуск следующего процесса).
- Цель: Пользовательская ценность, ради которой выполняется сценарий.
- Триггер: Событие, запускающее сценарий.
- Основной сценарий: Последовательность нумерованных шагов успешного выполнения.
- Альтернативные сценарии: Развитие событий при выполнении определённых условий (например, отправка уведомления не SMS, а email).
- Исключительные сценарии: Обработка ошибок и ситуаций, когда что-то пошло не так.
Алгоритм выделения функциональных требований
- Выбрать шаг сценария, который относится к ответственности системы.
- Задать вопросы к шагу:
- Что система должна сделать, чтобы этот шаг был выполнен?
- Что система делать не должна?
- Какие параметры, данные, ограничения нужны?
- Сформулировать и оформить требования в документацию.
Пример на основе шага «Система проверяет корректность введённых данных»:
- Система должна проверить, что поле логина не пустое.
- Система должна проверить, что логин соответствует формату email.
- Система должна проверить длину логина (например, не более 120 символов).
- Система должна проверить допустимые символы в логине (латиница, цифры, определённые спецсимволы).
- В случае ошибки система должна сообщить о ней пользователю.
Критерии качества функциональных требований
Обязательные критерии (касаются содержания):
- Корректность: Требование отражает реальную потребность и необходимо для работы системы.
- Однозначность: Требование может быть истолковано только одним способом всеми участниками проекта.
- Непротиворечивость: Требование не конфликтует с другими требованиями.
- Проверяемость (Тестируемость): Существует чёткий критерий, по которому можно определить, выполнено требование или нет.
Структурные критерии (касаются формы):
- Атомарность: Одно требование описывает только одну функцию, которую нельзя разбить на более мелкие.
- Полнота: Требование содержит всю необходимую информацию для его реализации без отсылок к неизвестным источникам.
- Трассируемость: Каждое функциональное требование связано с родительским пользовательским требованием (и далее с бизнес-требованием).
Критерии здравого смысла:
- Реализуемость: Требование технически выполнимо в рамках существующих технологий.
- Отсутствие избыточности: Одна и та же функциональность не должна дублироваться в разных требованиях (принцип DRY — Don't Repeat Yourself).
Примеры/кейсы
Разбор авторизации:
На примере упрощённого сценария авторизации показано, как из шагов («пользователь вводит данные», «система проверяет корректность», «система ищет пользователя в БД») выводятся функциональные требования к валидации формата, проверке длины, взаимодействию с базой данных и обработке ошибок.
Практический разбор:
На занятии совместно разрабатывался сценарий варианта использования «Принять заявку от работодателя» для системы кадрового агентства. Были определены шаги основного потока (уведомление рекрутёра, проверка, регистрация заявки), альтернативные (заявка некорректна) и исключительные (ошибка при сохранении) сценарии. На основе первого шага («Система отправляет уведомление») были сформулированы первые функциональные требования (система должна уметь отправлять push-уведомления определённого содержания при наступлении триггера).
Выводы
- Функциональные требования — это детальная спецификация поведения системы, извлекаемая из сценариев использования.
- Сценарий варианта использования — ключевой инструмент для перехода от описания «что делать» к описанию «как делать».
- Качество требований обеспечивается соблюдением набора критериев (корректность, однозначность, атомарность и др.).
- Процесс выделения требований итеративен: сначала набрасываются идеи, затем они проверяются на логику и корректность, после чего приводятся в соответствие с критериями качества и оформляются.