utility requirements

Требования полезности описывают, что именно должен делать продукт, чтобы быть полезным заказчику в конкретном контексте. В ITSM их часто используют для формализации ожиданий от ИТ-услуги или сервисного предложения через призму функциональности: какие операции доступны пользователю, какие данные обрабатываются, какие бизнес-правила должны соблюдаться, какие интеграции обязательны. Эти требования являются «уникальными для конкретного продукта», то есть отражают специфику именно данного продукта и сценариев использования, а не общие отраслевые ожидания. На практике требования полезности помогают согласовать объём работ, выстроить приоритизацию, подготовить критерии приёмки и валидации, а также обеспечить прослеживаемость от потребностей заказчика до решений в проектировании услуг и управления разработкой ПО. Важно понимать границы: требования полезности не описывают уровни услуги, доступность, непрерывность, производительность или ограничения по времени восстановления — это относится к требованиям гарантии и, как правило, фиксируется через соглашение об уровне услуг и сопутствующие целевые показатели.

Частая ошибка — смешивать требования полезности с требованиями гарантии. Формулировки вида «система должна отвечать за 2 секунды» или «услуга должна быть доступна 99,9%» относятся не к полезности, а к качественным характеристикам предоставления услуги (гарантии) и управляются через управление уровнем услуг, управление доступностью и управление непрерывностью услуг. Другая путаница возникает между требованиями полезности и техническими решениями: «использовать Oracle» или «развернуть в облачных вычислениях» — это ограничения реализации или архитектурные решения, а не функциональные требования. Также важно не подменять требования полезности описанием процесса поддержки: «обращения должны приниматься сервис-деск 24×7» — это требование к предоставлению услуги и организации поддержки, а не к функциональности продукта. Наконец, «уникальные для конкретного продукта» не означает «написанные в одиночку заказчиком»: обычно их уточняют совместно с поставщиком услуги, переводя ожидания в проверяемые формулировки, чтобы затем корректно проводить валидацию и тестирование и избегать расширения объёма работ без согласования.