# Бесплатная экспертная база знаний по управлению ИТ

Никакого пересказа ITIL, COBIT, ISO 20000, PRINCE2, TOGAF и прочего. Только сведения от консультантов и тренеров Cleverics. Включает ответы на **несколько тысяч вопросов** из **сотен источников**, а также детальный глоссарий с примерами, объяснениями и нюансами

# Требования полезности

Функциональные требования, которые были определены [заказчиком](https://cleverics.ru/digital/kb-glossary/customer/) и являются уникальными для конкретного [продукта](https://cleverics.ru/digital/kb-glossary/product/).

## Оригинальный английский термин

utility requirements

## Подробности

[Требования полезности](https://cleverics.ru/digital/kb-glossary/utility-requirements/) описывают, что именно должен делать продукт, чтобы быть полезным заказчику в конкретном контексте. В [ITSM](https://cleverics.ru/digital/kb-glossary/it-service-management/) их часто используют для формализации ожиданий от [ИТ-услуги](https://cleverics.ru/digital/kb-glossary/it-service/) или [сервисного предложения](https://cleverics.ru/digital/kb-glossary/service-offering/) через призму функциональности: какие [операции](https://cleverics.ru/digital/kb-glossary/operation/) доступны [пользователю](https://cleverics.ru/digital/kb-glossary/user/), какие данные обрабатываются, какие бизнес-правила должны соблюдаться, какие интеграции обязательны. Эти требования являются «уникальными для конкретного продукта», то есть отражают специфику именно данного продукта и [сценариев использования](https://cleverics.ru/digital/kb-glossary/use-case/), а не общие отраслевые ожидания. На [практике](https://cleverics.ru/digital/kb-glossary/practice/) требования [полезности](https://cleverics.ru/digital/kb-glossary/utility/) помогают согласовать объём работ, выстроить приоритизацию, подготовить критерии [приёмки](https://cleverics.ru/digital/kb-glossary/acceptance/) и [валидации](https://cleverics.ru/digital/kb-glossary/validation/), а также обеспечить прослеживаемость от потребностей заказчика до решений в [проектировании](https://cleverics.ru/digital/kb-glossary/design/)[услуг](https://cleverics.ru/digital/kb-glossary/service/) и управления [разработкой](https://cleverics.ru/digital/kb-glossary/development/) ПО. Важно понимать границы: требования полезности не описывают [уровни услуги](https://cleverics.ru/digital/kb-glossary/service-level/), [доступность](https://cleverics.ru/digital/kb-glossary/availability/), непрерывность, [производительность](https://cleverics.ru/digital/kb-glossary/performance/) или ограничения по времени [восстановления](https://cleverics.ru/digital/kb-glossary/recovery/) — это относится к [требованиям гарантии](https://cleverics.ru/digital/kb-glossary/warranty-requirements/) и, как правило, фиксируется через [соглашение об уровне услуг](https://cleverics.ru/digital/kb-glossary/service-level-agreement/) и сопутствующие целевые показатели.## Нюансы

Частая [ошибка](https://cleverics.ru/digital/kb-glossary/error/) — смешивать требования полезности с требованиями [гарантии](https://cleverics.ru/digital/kb-glossary/warranty/). Формулировки вида «[система](https://cleverics.ru/digital/kb-glossary/system/) должна отвечать за 2 секунды» или «услуга должна быть доступна 99,9%» относятся не к полезности, а к качественным характеристикам [предоставления услуги](https://cleverics.ru/digital/kb-glossary/service-provision/) (гарантии) и управляются через управление уровнем услуг, [управление доступностью](https://cleverics.ru/digital/kb-glossary/availability-management-practice/) и [управление непрерывностью](https://cleverics.ru/digital/kb-glossary/service-continuity-management-practice/) услуг. Другая путаница возникает между требованиями полезности и техническими решениями: «использовать Oracle» или «развернуть в [облачных вычислениях](https://cleverics.ru/digital/kb-glossary/cloud-computing/)» — это ограничения реализации или архитектурные решения, а не функциональные требования. Также важно не подменять требования полезности описанием [процесса](https://cleverics.ru/digital/kb-glossary/process/) поддержки: «[обращения](https://cleverics.ru/digital/kb-glossary/call/) должны приниматься [сервис-деск](https://cleverics.ru/digital/kb-glossary/service-desk/) 24×7» — это требование к предоставлению услуги и [организации](https://cleverics.ru/digital/kb-glossary/organization/) поддержки, а не к функциональности продукта. Наконец, «уникальные для конкретного продукта» не означает «написанные в одиночку заказчиком»: обычно их уточняют совместно с [поставщиком услуги](https://cleverics.ru/digital/kb-glossary/service-provider/), переводя ожидания в проверяемые формулировки, чтобы затем корректно проводить валидацию и тестирование и избегать расширения объёма работ без согласования.## Примеры

- Пользователь должен иметь возможность создавать и утверждать заявки на закупку с маршрутизацией по подразделениям
- Система должна автоматически рассчитывать НДС и формировать печатные формы счетов в соответствии с заданными бизнес-правилами
- Продукт должен поддерживать интеграцию с корпоративным каталогом пользователей для назначения ролей и прав доступа
- Должна быть функция поиска договоров по контрагенту, номеру и диапазону дат с сохранением фильтров
- Пользователь должен получать уведомления о смене статуса заказа в личном кабинете и по электронной почте

## Рекомендуемые продукты по этой теме

- [ITSM. Основы управления ИТ-услугами](https://edu.cleverics.ru/itsm-foundation?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=ITFO4) — Учебный курс: интенсив с тренером. Самый популярный тренинг по управлению ИТ
- [Apollo 13 — ITSM на практике](https://edu.cleverics.ru/apollo?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=APOLLO) — Деловая игра. Service Desk, управление инцидентами, проблемами, изменениями
- [Altevics](https://cleverics.ru/solutions/altevics?utm_source=knowledgebase&utm_medium=article&utm_content=banner&utm_term=altevics) — Современная ITSM/ESM-система