Заказчик требует использовать конкретную СУБД. Как аналитик должен трактовать это требование при моделировании?
Требование использовать конкретную СУБД следует трактовать как техническое ограничение, а не как функциональность системы. Его нужно зафиксировать отдельно от пользовательского поведения, указать область действия и обоснование, а затем проверить влияние на архитектуру, эксплуатацию, стоимость и риски проекта.
Если выбор СУБД порождает обязательные свойства системы, например ограничение объёма данных или требование к способу хранения, эти свойства следует описать отдельными требованиями. Само ограничение не заменяет требований к функциям и качественным характеристикам.
Разделение требований на функциональные, нефункциональные и ограничения появилось как практический способ не смешивать желаемое поведение системы с условиями её реализации. Без такого разделения архитектурные решения часто ошибочно выдаются за пользовательские потребности.
Это различие помогает связать каждый тип требования с подходящими способами проверки: функции проверяются сценариями, качественные характеристики — измерениями, а ограничения — подтверждением соблюдения заданного условия и анализом его последствий.
Фраза «система должна использовать СУБД X» сама по себе не описывает, что пользователь сможет сделать. Она задаёт допустимый способ реализации или обязательную технологическую среду.
Если записать её как функциональное требование, команда может начать оценивать её через пользовательские сценарии, хотя проверять нужно другое: действительно ли используется указанная СУБД, совместима ли она с нагрузкой, поддерживает ли нужные операции и не создаёт ли неприемлемых рисков.
Неверная классификация приводит к нескольким последствиям: скрытые архитектурные ограничения обнаруживаются поздно, критерии приёмки становятся неясными, а обсуждение бизнес-ценности подменяется спором о конкретном инструменте.
Аналитик должен сначала выяснить источник и причину требования. Возможные причины различаются по смыслу: корпоративный стандарт, наличие лицензий, требования безопасности, совместимость с существующей инфраструктурой, компетенции команды или ошибочное предпочтение конкретной технологии.
Затем требование фиксируется как ограничение с явными параметрами:
После этого проводится анализ влияния. Нужно проверить совместимость СУБД с объёмом и структурой данных, транзакционными требованиями, ожидаемой нагрузкой, резервным копированием, отказоустойчивостью, безопасностью, стоимостью эксплуатации и доступностью специалистов.
Функциональные требования моделируются независимо: например, поиск, оформление заказа или формирование отчёта. Ограничение на СУБД не должно автоматически считаться доказательством того, что эти функции реализуемы или будут работать с нужным качеством.
Важен компромисс между конкретностью и преждевременной фиксацией решения. Жёсткое ограничение может снизить варианты архитектуры, но иногда оно оправдано регуляторными или инфраструктурными причинами. Если причина не подтверждена, аналитик должен вынести ограничение на отдельное решение заинтересованных лиц, а не молча превращать предпочтение заказчика в обязательное условие.
Для новой системы заказчик потребовал использовать СУБД, уже принятую в компании. Были рассмотрены три варианта: безусловно принять требование, разрешить любую СУБД или зафиксировать корпоративную СУБД как ограничение с процедурой исключений.
Первый вариант быстро запускает проект, но может скрыть проблему несовместимости с высокой нагрузкой. Второй даёт архитекторам свободу, однако нарушает корпоративный стандарт и усложняет сопровождение. Третий требует дополнительного анализа, зато сохраняет управляемость: стандартная СУБД используется по умолчанию, а отклонение допускается только после обоснования.
Выбрали третий вариант. Аналитик отдельно описал пользовательские функции, ограничение инфраструктуры и измеримые требования к производительности. На нагрузочном анализе выяснилось, что для одного вида отчётов требуется специализированный механизм хранения; это стало предметом отдельного архитектурного решения, а не неявным изменением пользовательских требований.
1. Может ли ограничение стать функциональным требованием?
Да, но не из-за самого факта выбора технологии. Если требование формулирует наблюдаемое поведение системы, например обязательную синхронизацию с существующей базой или поддержку определённого протокола доступа, это поведение описывается как функциональное требование. Указание конкретной СУБД при этом остаётся отдельным ограничением, если оно действительно обязательно.
2. Нужно ли включать ограничение на СУБД в критерии приёмки пользовательской истории?
Только если соблюдение ограничения входит в объём конкретной истории или релиза. Обычно критерии приёмки подтверждают результат истории для пользователя, а проверка используемой СУБД относится к технической приёмке, архитектурному контролю или Definition of Done. Смешивание этих проверок делает пользовательскую историю зависимой от деталей реализации без необходимости.
3. Что делать, если заказчик не может объяснить причину выбора СУБД?
Нельзя автоматически считать требование необоснованным, но его следует пометить как требующее решения и выяснить скрытые ограничения: корпоративные стандарты, лицензирование, безопасность, интеграции и эксплуатацию. До подтверждения причины аналитик должен показать последствия фиксации выбора и предложить сравнение допустимых вариантов. Решение о снятии или сохранении ограничения принимает уполномоченный владелец, а не аналитик единолично.