HLR: как сформулировать высокоуровневые требования к проекту
Что описывают HLR
Высокоуровневые требования переводят цели и потребности заинтересованных сторон на язык обязательств будущей системы. Например, цель бизнеса «сократить время запуска рассылок» ещё не считается требованием. Формулировка «маркетинговая платформа должна поддерживать самостоятельный запуск кампаний авторизованным маркетологом» уже задаёт ожидаемую возможность.
HLR описывают систему как единое целое и отвечают на основные вопросы:
- Какие задачи пользователей должна закрывать система?
- Какие бизнес-процессы войдут в проект?
- С какими внешними системами потребуется обмен данными?
- Какие ограничения по безопасности, производительности и размещению критичны?
- По каким результатам заинтересованные стороны признают проект успешным?
HLR не обязательно оформляют отдельным документом. Они могут находиться в концепции проекта, бизнес-требованиях, спецификации, таблице требований или системе управления задачами.
Место HLR в структуре требований
Верхний уровень определяет ожидаемый результат, а нижние уровни раскрывают условия его реализации и проверки. Типовая логика выглядит так:
- Бизнес-цель — какой результат нужен организации.
- Потребность заинтересованной стороны — что требуется пользователю, заказчику или владельцу процесса.
- HLR — какую возможность или характеристику должна обеспечить система.
- Детальные требования — какие функции, данные, правила и интерфейсы нужны для выполнения HLR.
- Критерии приёмки и тесты — как команда подтвердит выполнение требований.
Важно сохранять связь между уровнями требований в обе стороны: от HLR можно проследить исходную потребность или бизнес-цель, а от детальных требований и тестов — соответствующее HLR. Если высокоуровневое требование уже достаточно точно для непосредственной проверки, дополнительная декомпозиция может не потребоваться.
HLR связывают потребности бизнеса с детальными требованиями и критериями проверки
Что включают высокоуровневые требования
Набор HLR зависит от проекта, но обычно охватывает несколько категорий:
- Функциональные возможности. Что система должна делать: объединять данные, формировать сегменты, запускать коммуникации, принимать заказы или строить отчёты.
- Пользователи и роли. Кто работает с системой и какие операции выполняет.
- Данные. Какие сведения система получает, хранит, обрабатывает и передаёт.
- Интеграции. С какими приложениями, базами данных и внешними сервисами требуется взаимодействие.
- Качественные характеристики. Требования к производительности, доступности, масштабированию, безопасности и удобству сопровождения.
- Ограничения решения. Обязательная инфраструктура, нормативные условия, требования к размещению данных, совместимости или использованию утверждённых технологий.
Как составить качественное HLR
Удобная базовая конструкция:
[Система или пользователь] должна [обеспечить возможность или результат] [в заданных условиях или пределах].
Например:
Маркетинговая платформа должна обновлять профиль клиента не позднее чем через пять минут после получения события о покупке из CRM.
Требование называет систему, ожидаемое действие, источник данных и измеримое ограничение. При этом оно не определяет протокол обмена и внутреннюю архитектуру.
При подготовке HLR следует соблюдать несколько правил:
- Одна формулировка — одно требование. Объединение нескольких функций затрудняет согласование и проверку.
- Точные термины. Слова «быстро», «удобно», «современно» и «при необходимости» допускают разные трактовки.
- Проверяемость. Команда должна заранее понимать, каким способом подтвердит выполнение требования.
- Независимость от реализации. HLR фиксирует ожидаемый результат. Конкретный продукт, технология или архитектура указываются только при наличии обоснованного ограничения.
- Необходимость. У требования должна быть бизнес-причина, источник или родительская потребность.
- Уникальный идентификатор. Коды HLR-01, HLR-02 и другие упрощают согласование, управление изменениями и связь с дочерними требованиями.
Кроме текста требования, полезно хранить его атрибуты:
- идентификатор;
- источник и владелец;
- обоснование;
- приоритет;
- статус согласования;
- зависимости;
- способ проверки;
- связанные детальные требования.
Такой реестр показывает не только список пожеланий, но и логику проектных решений.
Чем HLR отличаются от связанных документов
| Артефакт | Что описывает | Насколько подробно |
|---|---|---|
| Бизнес-требования | Цели, проблемы и ожидаемые результаты организации | Самый общий уровень, без описания возможностей системы |
| HLR | Основные возможности, характеристики и ограничения системы | Без деталей реализации |
| Функциональные требования | Конкретное поведение, операции и правила | Подробно, до отдельных функций и условий |
| Нефункциональные требования | Производительность, безопасность, доступность и другие характеристики | От общих ограничений до измеримых параметров |
| User stories | Потребности пользователя в контексте продукта или итерации | Зависит от декомпозиции |
| Техническая спецификация | Интерфейсы, форматы данных, компоненты и технические правила | Технические детали реализации |
| Критерии приёмки | Проверяемые условия завершения функции или задачи | Конкретные условия проверки |
HLR и техническое задание — не взаимоисключающие документы. Высокоуровневые требования могут стать разделом ТЗ или исходными данными для его подготовки.
Пример HLR для маркетинговой платформы
- HLR-01. Система должна формировать единый профиль клиента на основе данных сайта, мобильного приложения и CRM.
- HLR-02. Авторизованный маркетолог должен создавать аудитории по данным профиля, поведению и истории покупок.
- HLR-03. Система должна запускать коммуникацию после получения заданного клиентского события.
- HLR-04. Система должна предоставлять отчёты о доставке сообщений, реакции аудитории и переданных в платформу целевых действиях.
- HLR-05. Обмен согласованными наборами данных с корпоративными системами должен выполняться без ручного экспорта и импорта файлов.
- HLR-06. Доступ пользователей к данным и операциям должен зависеть от назначенной роли.
На следующем этапе каждое HLR при необходимости декомпозируют. Для единого профиля потребуется определить идентификаторы клиента, источники, поля, правила сопоставления и обновления. Для событийной коммуникации — перечень событий, задержку запуска, исключения и поведение при ошибках.
Как использовать HLR в проекте
После согласования HLR становятся контрольной рамкой проекта. На их основе команда:
- определяет границы работ и исключает функции, которые не относятся к целям проекта;
- сравнивает программные продукты и предложения подрядчиков;
- проектирует архитектуру и интеграции;
- формирует функциональные и нефункциональные требования;
- оценивает объём работ и риски;
- связывает разработку и тестирование с исходными потребностями бизнеса;
- анализирует влияние изменений.
HLR не следует считать неизменным обещанием, составленным один раз в начале проекта. Требования уточняются по мере анализа. Однако каждое изменение нужно согласовывать и отслеживать в зависимых спецификациях и тестах. Иначе верхний уровень будет описывать одну систему, а команда фактически создаст другую.
Заключение
HLR описывают основные возможности, характеристики и ограничения будущей системы без преждевременного перехода к деталям реализации. Они связывают бизнес-потребности с функциональными и нефункциональными требованиями, архитектурой и критериями приёмки.
Качественное высокоуровневое требование однозначно, необходимо, выполнимо и проверяемо. Для каждого HLR стоит зафиксировать источник, обоснование, приоритет и связи с зависимыми требованиями и материалами по проверке. Тогда список требований становится рабочей основой для выбора системы, оценки проекта и контроля результата.
Читайте по теме
