Функциональные требования

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

Даня

Артём, а такое функциональное требование — ок?

«На главной странице веб-приложения Chatty понадобится яркая кнопка, которая позволит пользователю сразу перейти в словарь, где в центре страницы будет строка для поиска слова»

Артём

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

Почему важны функциональные требования

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

Функциональные требования позволяют разработчикам перейти к созданию описанной функциональности — они понимают, что именно нужно сделать и как это должно выглядеть в системе. Тестировщики же, опираясь на функциональные требования, могут понять, что именно нужно протестировать и как система должна вести себя в ответ на то или иное действие. Если её поведение не соответствует функциональным требованиям, значит система не работает как надо.

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

Как правильно формулировать функциональные требования

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

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

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

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

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

Чтобы функциональные требования учитывали все требования к ПО и возможные бизнес-правила компании, были понятны как разработчикам, так и заинтересованным лицам, в них нужно описать:

Возможные действия пользователя и реакцию системы на них.
Обязательные и необязательные поля, которые пользователю нужно (или не нужно) заполнять, чтобы система совершила определённое действие.
Условия, для выполнения необходимых действий системы — например, в последний день каждого месяца система должна формировать отчёт о проданных за 30 дней товарах, условием здесь будет «в последний день каждого месяца».
Требования к действиям системы или пользователя, если что-то пойдет не по основному сценарию.

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

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

При вызове такси у пользователя должна быть возможность указать место подачи машины и пункт назначения.

Это требование сформулировано корректно. Разработчикам понятно, что необходимо реализовать, а в требовании не указаны лишние детали.

Вызывая такси, после заполнения обязательных полей пользователь должен нажать на кнопку «Заказать», расположенную внизу экрана.

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

Пользователь должен видеть время ожидания машины.

Требование некорректно, поскольку оно нечётко сформулировано. Лучше бы сформулировать данное требование так: «После заказа такси у пользователя должна быть возможность видеть время ожидание машины».

Источники функциональных требований

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

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

Система должна предоставлять авторизованному пользователю возможность просмотра избранных товаров.
В системе должна быть возможность отметить или добавить в избранное понравившиеся товары.

Источником функциональных требований могут быть не только пользовательские требования. Бизнес-правила и нефункциональные требования также влияют на них, а ещё функциональные требования могут зависеть друг от друга. Подробнее об этих взаимосвязях и новых пунктах схемы, в том числе атрибутах качества и приёмочных тестах, вы узнаете в следующих уроках.

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

На сайте кондитерской должна быть форма заказа торта по критериям клиента.

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

На странице контактов должна отображаться карта с адресом кондитерской.

Это функциональное требование, но оно не относится к нашему пользовательскому требованию.

В форме для заказа должно быть обязательное поле с датой, к которой должны изготовить торт, и поле с описанием необходимого изделия.

Это функциональное требование подходит под наше пользовательское требование, с помощью которого мы понимаем какой торт хочет получить клиент и какого числа.

Клиент должен иметь возможность нажать на кнопку «Заказать» и перейти на форму заказа торта.

Это функциональное требование подходит под наше пользовательское требование, с помощью которого клиент сайта может перейти на форму заказа торта.

Как кондитер, я хочу иметь доступ к административной части сайта для настройки товаров в наличии на определенный день

Это пользовательское требование, а не функциональное.

Подведём итоги

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

Основные принципы:

Формулировать функциональные требования можно как с позиции работы системы, так и с позиции пользователя, который будет с ней работать.
Записывать функциональные требования можно в форме утверждений со словами «должен» или «должна».
Функциональные требования включают возможные действия системы или пользователя, а также реакцию системы на них и возможные условия для выполнения этих действий.
При составлении функциональных требований важно сделать их понятными — не углубляйтесь в мелкие детали и описывайте именно функции будущей системы.

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

Функциональные требования

Почему важны функциональные требования

Как правильно формулировать функциональные требования

Источники функциональных требований

Рекомендации по написанию функциональных требований

Подведём итоги