Функциональные требования: как писать, пример и шаблон

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

Функциональное требование — одна фраза о том, что система делает, записанная так, чтобы её поняли одинаково и проверили одним тестом. Ниже — формула такой фразы, та самая строка про статус заказа, проведённая через четыре правки, и шаблон набора требований, который можно скопировать себе.

Где функциональное требование отличается от бизнес-требования, подробно разобрано в статье чем бизнес-требования отличаются от функциональных. Здесь — о том, как сформулировать одно требование.

Формула одного требования

Когда [событие или условие], система должна [действие] [объект], [результат или ограничение].

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

В формуле четыре части, и у каждой своя работа. Условие говорит, когда требование действует, — без него непонятно, что проверять. «Система должна» фиксирует, кто действует: не пользователь, не сотрудник, а система. Действие и объект — это и есть поведение, которое увидят снаружи. Результат отвечает на вопрос, как понять, что всё сработало.

Похожий шаблон — EARS, Easy Approach to Requirements Syntax — придумали Алистер Мавин и его коллеги в Rolls-Royce, когда разбирали требования к системе управления реактивным двигателем. Впервые его опубликовали в 2009 году. Там та же идея: жёсткий порядок частей и несколько ключевых слов вместо свободного текста.

Условие бывает не у всех требований. «Система должна хранить историю изменений статуса заказа» действует всегда, и начинать её с «когда» не нужно. Но если условие есть, а в тексте его нет, — это первое, о чём спросит тестировщик.

Одна фраза — от плохой к хорошей

Возьмём строку из начала статьи и проведём её через правки. На каждом шаге убираем одну ошибку.

Исходная фраза: «Система должна быстро и удобно показывать клиенту статус заказа и не допускать ошибок».

Правка 1 — два требования в одной фразе. Здесь спрятаны как минимум два требования: показывать статус и не допускать ошибок. Их нельзя проверить одним тестом и нельзя по отдельности отложить или отменить. Разделяем:

• «Система должна быстро и удобно показывать клиенту статус заказа».
• «Система должна не допускать ошибок при показе статуса».

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

• «Когда клиент открывает страницу заказа, система должна показать текущий статус доставки и время его последнего обновления».

Правка 3 — отрицание. «Не допускать ошибок» говорит, чего не должно быть, но не говорит, что система делает вместо этого. Разработчик не знает, что строить, а тестировщик — что проверять. Спрашиваем: какая ошибка имеется в виду? Оказывается, служба доставки иногда не отвечает, и страница показывает пустое место. Переписываем в поведение:

• «Когда служба доставки не отвечает, система должна показать последний полученный статус и пометку, что он может быть устаревшим».

Правка 4 — устройство вместо поведения. На обсуждении разработчик предлагает уточнить первую фразу: «Система должна запрашивать статус у службы доставки каждые пять минут и сохранять его в базу». Это не требование, а способ его выполнить. Через месяц служба доставки начнёт сама присылать уведомления, опрос станет не нужен — и требование придётся переписывать, хотя клиенту ничего не поменялось. Оставляем то, что видно снаружи, а способ — в техническом решении.

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

1. «Когда клиент открывает страницу заказа, система должна показать текущий статус доставки и время его последнего обновления».
2. «Когда служба доставки не отвечает, система должна показать последний полученный статус и пометку, что он может быть устаревшим».

Эти четыре ошибки не придуманы для примера. Стандарт требований ISO/IEC/IEEE 29148 прямо перечисляет, чего избегать в формулировке: превосходных степеней, субъективных оценок, расплывчатых местоимений, сравнений, лазеек вроде «по возможности» и отрицаний. Правила списком есть везде, но на одной фразе видно, как каждое из них меняет смысл.

Шаблон набора требований

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

Выделите таблицу целиком и вставьте в Confluence, Excel или Google Таблицы: столбцы сохранятся.

Что делает каждый столбец:

• ID — короткий номер. На него ссылаются в задачах, тест-кейсах и спорах: «ФТ-02 не выполнено» понятнее, чем пересказ фразы.
• Формулировка — одна фраза по формуле выше.
• Источник — бизнес-требование, ради которого нужна функция. Если источник не находится, это повод спросить, зачем требование вообще в списке. На этом столбце держится трассировка — как её построить, разобрано в статье матрица трассировки требований: пример и шаблон.
• Критерий проверки — что сделает тестировщик и что увидит. Если критерий не получается написать, формулировку нужно править ещё раз.
• Приоритет — здесь MoSCoW: Must, Should, Could, Won’t. Подойдёт любая шкала, которую команда понимает одинаково.

Чего в шаблоне нет намеренно: разделов документа, титульного листа, глоссария. Это устройство документа, а не требования. Какой документ нужен под задачу, разобрано в статье BRD, FRD и SRS: какой документ когда нужен.

Где заканчивается функциональное требование

Если требование записано историей или сценарием, формула та же, меняется только обёртка: как выбрать между ними, разобрано в статье User Story и Use Case: чем отличаются и что писать.

То, что осталось после правки 2 — «быстро», — не функциональное требование. Оно говорит не что делает система, а насколько хорошо. Такие требования пишут отдельно и тоже измеримо: время ответа в секундах, доля доступности в процентах.

Как это звучит на собеседовании

В нашем банке вопросов с реальных собеседований функциональные требования — что это и чем они отличаются от бизнес-требований — встречаются в 15 вопросах, и 7 из них размечены как junior. Тему спрашивают с первого уровня.

Слабый ответ — определение и список свойств: «функциональные требования описывают, что делает система, они должны быть полными, однозначными и проверяемыми». Верно, но так отвечает любой, кто прочитал учебник.

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