Что такое требования и какие они бывают

Задачи редко приходят в виде требований. Они приходят фразами: «сделайте удобно», «нужна отмена заказа», «чтобы не тормозило». В одной такой фразе обычно спрятано сразу несколько разных вещей: зачем это нужно компании, чего хочет человек, что должна делать система, как хорошо она должна работать и в каких рамках. Пока их не разделили, разработчик делает одно, заказчик ждёт другое, а тестировщик не знает, что проверять. Разберём на одной задаче «Узелка», какие бывают виды требований и как отнести к виду любую фразу.

Кейс: «Пусть покупатели сами отменяют заказы»

Владелец «Узелка» пишет в рабочий чат: «Покупатели звонят, чтобы отменить заказ, и поддержка не успевает отвечать. Пусть отменяют сами, быстро и без путаницы с деньгами. Успеть надо до осенней распродажи». Для владельца это одна просьба. Для команды это пять разных вопросов.

Если разрезать фразу на куски, у каждого окажется своя роль. Одно объясняет, зачем нужна задача, другое называет действие покупателя, третье оценивает качество работы, четвёртое просит конкретных правил, пятое задаёт рамку, которую команда не выбирала. Эти роли и есть виды требований, а определение выведем из них.

Требование (requirement) - записанная потребность или условие, которое должно быть выполнено, чтобы задача считалась решённой, и которое можно проверить. Слово «проверить» здесь главное: «сделать удобную отмену» проверить нельзя, а «отмена доступна, пока заказ не передан в доставку» можно. Даже бизнес-цель получает проверку, когда к ней привязывают показатель: число звонков об отмене до релиза и после. Дальше разберём пять видов и то, как отличить один от другого.

Чем один вид отличается от другого

Виды выстроены от «зачем» к «как устроено». Бизнес-требование (business requirement) говорит, зачем задача нужна компании: разгрузить поддержку от звонков об отмене. Пользовательское требование (user requirement) говорит, что человек хочет сделать с помощью системы: покупатель отменяет заказ без звонка. Первое пишут на языке денег, времени и рисков компании, второе на языке действий человека.

Следующие два вида описывают саму систему, поэтому их вместе называют системными требованиями. Различаются они тем, о чём говорят: о поведении или о качестве.

Функциональные требования (functional requirements) описывают поведение: что система делает в ответ на действие. Например, у заказа, который ещё не передан в доставку, показывается кнопка «Отменить заказ», а при отмене оплаченного заказа создаётся возврат денег.

Нефункциональные требования (non-functional requirements) описывают, как хорошо система это делает: скорость, надёжность, безопасность. Например, отмена обрабатывается за 2 секунды в 95% случаев, а отменить заказ может только его владелец. Цифры здесь примеры: настоящие значения команда согласует с владельцем.

Последний вид стоит особняком. Ограничение (constraint) - условие, которое задано снаружи и не обсуждается: срок, бюджет, закон, чужая система. «Успеть до осенней распродажи» и «возвраты проводит платёжный сервис банка» ограничивают решение, но ничего в нём не описывают.

Вид	На какой вопрос отвечает	Кто чаще называет	Как обычно проверяют
Бизнес-требование	Зачем это компании?	Владелец, руководитель	Показатель изменился: звонков об отмене стало меньше
Пользовательское	Что хочет сделать человек?	Покупатели, поддержка	Человек справился сам, без помощи
Функциональное	Что делает система?	Команда вместе с заказчиком	Сценарий: действие, ожидаемый результат
Нефункциональное	Как хорошо она это делает?	Команда, безопасность, эксплуатация	Измерение: секунды, доля сбоев, права доступа
Ограничение	Что нельзя менять?	Владелец, закон, внешние сервисы	Соблюдено или нет

Названия видов в разных книгах и стандартах отличаются, но вопросы из таблицы помогают при любом делении. Остаётся вопрос, как отнести к виду реальную фразу, которая приходит без подписи.

Как отнести фразу к виду

Заказчик не говорит «вот нефункциональное требование», поэтому вид определяет тот, кто слушает. К каждому куску фразы задают четыре вопроса по порядку, и первое «да» называет вид. Если все ответы «нет», остаётся цель, и дальше вопрос, чья она: компании или человека.

Порядок вопросов не случаен. В фразе «отмена за 2 секунды» есть и действие, и качество: если спросить про действие первым, качество потеряется. Поэтому сначала проверяют условия и качество, а действие и цель оставляют напоследок. Одна фраза часто даёт сразу несколько требований, поэтому её режут на части, как сообщение владельца, и каждую часть проверяют отдельно. Разрез сразу показывает пробелы: «быстро» осталось пожеланием без числа, а «без путаницы с деньгами» не говорит, что делать с частичным возвратом или с оплатой, которая ещё не дошла. Эти вопросы уходят заказчику: как их задавать, разбирает статья 02-04, а как превратить «быстро» в число, статья 02-13.

Зачем делить, если можно записать одной фразой

Разные люди берут из требований разное. Разработчик ищет, что сделать: ему нужны функциональные требования и ограничения. Тестировщик ищет, что проверять: ему нужны проверяемые формулировки, в том числе нефункциональные. Владелец оценивает, зачем потрачены деньги: ему нужна связь с бизнес-требованием. Когда всё записано одной фразой, каждый вытаскивает из неё своё и остаётся при своём понимании.

Типичный сбой выглядит так. В задаче записаны только функциональные требования: кнопка есть, возврат создаётся. Отмена выходит в релиз и работает медленно, потому что про скорость никто не спросил, и это выясняется уже у покупателей.

Другой сбой: решение выдано за требование. «Сделать красную кнопку внизу страницы» описывает способ, а не потребность: из него не видно, что покупатель должен находить отмену без звонка в поддержку. Кнопку можно сделать точно по описанию, и она всё равно останется незаметной, а звонки не сократятся.

И третий: ограничение записано как пожелание. «Хорошо бы до распродажи» читается как пожелание, поэтому команда не сокращает объём, а на деле дата жёсткая. Если ограничение отделено от пожеланий, обсуждать можно объём работ, а не срок.

Где это встречается в работе

• Первая встреча с заказчиком. Фраза записывается дословно, потом режется на куски по вопросам из схемы.
• Разбор задачи с разработчиком. Функциональные требования и ограничения передаются списком, нефункциональные отдельным блоком с числами.
• Подготовка проверок. Тестировщик берёт функциональные требования для сценариев, а нефункциональные для проверки скорости и прав доступа.
• Спор о сроках. Жёсткий срок отделяют от пожелания, чтобы обсуждать объём, а не сдвиг даты.
• Объяснение результата владельцу. Релиз связывают с бизнес-требованием: звонков об отмене стало меньше или нет.

Итог

Требование - проверяемая запись потребности или условия. Виды отвечают на разные вопросы: зачем компании (бизнес), чего хочет человек (пользовательское), что делает система (функциональное), как хорошо (нефункциональное) и в каких рамках (ограничение). Поэтому одна фраза заказчика становится несколькими требованиями, и каждое попадает к тому, кому оно нужно: владельцу, разработчику или тестировщику.

Кто умеет задавать фразе вопросы по порядку, тот разрезает её на части и сразу видит, чего не хватает: числа у «быстро», правил про возврат, понятной цели.

Что дальше

Осталось неразобранным самое первое: как выяснить бизнес-цель и кто именно стоит за каждым видом. Это тема следующей статьи.

• 02-02. Бизнес-цель и заинтересованные стороны: как выяснить, зачем задача и кто решает
• 02-04. Уточняющие вопросы: как превратить расплывчатую фразу в список вопросов
• 02-08. User Story и INVEST: как записать пользовательское требование
• 02-13. Нефункциональные требования: как превратить «быстро» в измеримое требование
• 02-19. Как проверить качество требований: чек-лист критериев