Оставьте ваш отзыв
Продолжая использовать сайт, вы даете согласие на обработку файлов cookies. Если вы не хотите, чтобы ваши данные обрабатывались, покиньте сайт
Функциональные требования: как описать, чтобы разработчики не задавали лишних вопросов
Функциональные требования — одна из основ работы системного аналитика. Именно из них команда должна понять, что система должна делать, как вести себя в определенных условиях и какой результат должен получить пользователь. Если FR сформулированы неоднозначно, разработчику приходится уточнять детали, у тестировщика появляется простор для вольной интерпретации ожидаемого поведения, а часть вопросов обнаруживается уже после реализации.
Цена такой неопределенности — дополнительные обсуждения, переделки, повторное тестирование и сдвиг сроков. Поэтому задача аналитика не просто зафиксировать пожелание заказчика, а превратить его в понятное и проверяемое требование.
Разберем, чем функциональные требования отличаются от NFR, в каких случаях удобнее использовать user story, use case или табличную форму, как составить эффективный FR и какие ошибки чаще всего приводят к лишним вопросам со стороны команды.
Цена такой неопределенности — дополнительные обсуждения, переделки, повторное тестирование и сдвиг сроков. Поэтому задача аналитика не просто зафиксировать пожелание заказчика, а превратить его в понятное и проверяемое требование.
Разберем, чем функциональные требования отличаются от NFR, в каких случаях удобнее использовать user story, use case или табличную форму, как составить эффективный FR и какие ошибки чаще всего приводят к лишним вопросам со стороны команды.
Отличие нефункциональных и функциональных требований
Функциональные требования, или FR (Functional Requirements), описывают поведение и функции системы: что именно система должна делать.
Например:
FR: Система дает возможность зарегистрированному пользователю добавлять товары в корзину покупок.
Здесь определено конкретное поведение системы — возможность добавить товар.
Нефункциональные требования, или NFR (Non-Functional Requirements), определяют характеристики системы и ограничения, которым она должна соответствовать: производительность, доступность, безопасность, масштабируемость и другие параметры.
Например:
NFR: Страница корзины должна открываться не более чем за 2 секунды при заданной проектом нагрузке.
Первое требование отвечает на вопрос «что делает система?», второе — «каким характеристикам должно соответствовать ее выполнение?».
На практике FR и NFR тесно связаны. Возможность выполнить операцию еще не означает, что функция реализована приемлемо для бизнеса. Интернет-магазин может технически поддерживать поиск товара, но если результаты появляются через 20 секунд, пользователь вряд ли сочтет такую функцию нормально работающей.
Уместна схема: «FR — что делает система / NFR — какими характеристиками обладает система»
Например:
FR: Система дает возможность зарегистрированному пользователю добавлять товары в корзину покупок.
Здесь определено конкретное поведение системы — возможность добавить товар.
Нефункциональные требования, или NFR (Non-Functional Requirements), определяют характеристики системы и ограничения, которым она должна соответствовать: производительность, доступность, безопасность, масштабируемость и другие параметры.
Например:
NFR: Страница корзины должна открываться не более чем за 2 секунды при заданной проектом нагрузке.
Первое требование отвечает на вопрос «что делает система?», второе — «каким характеристикам должно соответствовать ее выполнение?».
На практике FR и NFR тесно связаны. Возможность выполнить операцию еще не означает, что функция реализована приемлемо для бизнеса. Интернет-магазин может технически поддерживать поиск товара, но если результаты появляются через 20 секунд, пользователь вряд ли сочтет такую функцию нормально работающей.
Уместна схема: «FR — что делает система / NFR — какими характеристиками обладает система»
Форматы описания функциональных требований
Единственного обязательного формата для всех проектов не существует. Способ фиксации зависит от сложности функции, принятой в команде документации и того, кому предстоит работать с требованием.
Чаще всего используются use case, user story и структурированная табличная форма.
- 13 шаблонов системного аналитика с пояснениями и примерами. Готовый набор шаблонов
Чаще всего используются use case, user story и структурированная табличная форма.
Use case: когда важна последовательность взаимодействия
Use case (сценарий использования) описывает взаимодействие актора — пользователя или внешней системы — с системой для достижения определенной цели.
Такой формат особенно полезен, когда необходимо показать последовательность действий, предусловия, основной сценарий и альтернативные варианты.
Например, для оформления заказа:
Use case: Оформление заказа
Актор: зарегистрированный пользователь.
Предусловие: в корзине пользователя есть хотя бы один доступный для заказа товар.
Основной сценарий:
Альтернативный сценарий: если один из товаров стал недоступен, система сообщает об этом пользователю и не позволяет подтвердить заказ, пока состав корзины не будет актуализирован.
Use case удобен там, где простого предложения недостаточно. Он показывает не отдельную функцию, а логику взаимодействия с системой.
Такой формат особенно полезен, когда необходимо показать последовательность действий, предусловия, основной сценарий и альтернативные варианты.
Например, для оформления заказа:
Use case: Оформление заказа
Актор: зарегистрированный пользователь.
Предусловие: в корзине пользователя есть хотя бы один доступный для заказа товар.
Основной сценарий:
- Пользователь открывает корзину.
- Система отображает товары, количество и итоговую стоимость.
- Пользователь переходит к оформлению заказа.
- Пользователь указывает предпочитаемый способ доставки.
- Пользователь выбирает доступный способ оплаты.
- Система отображает итоговые данные заказа.
- Пользователь подтверждает оформление.
- Система создает заказ и присваивает ему идентификатор.
- Система показывает пользователю подтверждение создания заказа.
Альтернативный сценарий: если один из товаров стал недоступен, система сообщает об этом пользователю и не позволяет подтвердить заказ, пока состав корзины не будет актуализирован.
Use case удобен там, где простого предложения недостаточно. Он показывает не отдельную функцию, а логику взаимодействия с системой.
User story: когда важна ценность для пользователя
User story (пользовательская история) — компактный способ сформулировать потребность через роль, цель и ожидаемую ценность.
Распространенная конструкция:
Как [роль], я хочу [действие/возможность], чтобы [ценность/цель].
Например:
Как зарегистрированный покупатель, я хочу сохранять товары в избранное, чтобы вернуться к ним позже.
Преимущество user story — простота. Из формулировки сразу понятно, кому нужна функция и зачем.
Но одной user story часто недостаточно для разработки. Фраза «хочу сохранять товары в избранное» не отвечает на вопросы: может ли пользователь удалить товар из избранного, что произойдет с недоступным товаром, требуется ли авторизация, где отображается список.
Поэтому user story обычно дополняют критериями приемки и, при необходимости, более подробными требованиями.
Распространенная конструкция:
Как [роль], я хочу [действие/возможность], чтобы [ценность/цель].
Например:
Как зарегистрированный покупатель, я хочу сохранять товары в избранное, чтобы вернуться к ним позже.
Преимущество user story — простота. Из формулировки сразу понятно, кому нужна функция и зачем.
Но одной user story часто недостаточно для разработки. Фраза «хочу сохранять товары в избранное» не отвечает на вопросы: может ли пользователь удалить товар из избранного, что произойдет с недоступным товаром, требуется ли авторизация, где отображается список.
Поэтому user story обычно дополняют критериями приемки и, при необходимости, более подробными требованиями.
Табличная форма: когда нужна структурированная спецификация
Для систем с большим количеством требований удобно фиксировать FR в таблице или в соответствующем разделе SRS (Software Requirements Specification).
Например:
Например:
Идентификаторы упрощают обсуждение, трассировку требований и работу с изменениями: вместо «некоего требования про корзину» команда может ссылаться на конкретный FR-02.
Как выбрать формат
Эти способы не обязательно конкурируют друг с другом. В одном проекте user story может описывать пользовательскую потребность, use case — раскрывать сложный сценарий, а отдельные FR — фиксировать конкретное поведение системы.
Как правильно сформулировать функциональное требование: пошаговая инструкция
Хорошее функциональное требование должно позволять команде одинаково понять ожидаемое поведение системы и проверить его после реализации.
Шаг 1. Определить пользователя и его цель
Сначала необходимо понять, кто инициирует действие и зачем ему эта возможность.
Формулировка «нужно сделать выгрузку заказов» оставляет слишком много вопросов.
Кто выполняет выгрузку? Покупатель, менеджер магазина или администратор? Какие заказы? За какой период? Для какой задачи?
Более точная постановка начинается с контекста:
Менеджеру интернет-магазина необходимо выгружать список заказов за выбранный период для дальнейшей обработки данных.
Теперь понятны роль и задача.
Формулировка «нужно сделать выгрузку заказов» оставляет слишком много вопросов.
Кто выполняет выгрузку? Покупатель, менеджер магазина или администратор? Какие заказы? За какой период? Для какой задачи?
Более точная постановка начинается с контекста:
Менеджеру интернет-магазина необходимо выгружать список заказов за выбранный период для дальнейшей обработки данных.
Теперь понятны роль и задача.
Шаг 2. Описать действие системы
Следующий уровень — определить, что именно должна сделать система.
Например:
Система должна позволять пользователю с ролью «Менеджер» выгружать список заказов за выбранный период.
Глаголы вроде «поддерживать», «обеспечивать удобную работу» или «предоставлять качественную возможность» желательно заменять конкретным наблюдаемым поведением.
Чем точнее действие, тем меньше пространства для разных трактовок.
Например:
Система должна позволять пользователю с ролью «Менеджер» выгружать список заказов за выбранный период.
Глаголы вроде «поддерживать», «обеспечивать удобную работу» или «предоставлять качественную возможность» желательно заменять конкретным наблюдаемым поведением.
Чем точнее действие, тем меньше пространства для разных трактовок.
Шаг 3. Указать ожидаемый результат
Необходимо определить состояние системы или ожидаемый результат.
Продолжим пример:
После запуска выгрузки система должна сформировать файл со списком заказов, соответствующих выбранному периоду.
Если для реализации существенны формат файла, набор полей, сортировка или правила отбора данных, их необходимо зафиксировать отдельно.
Продолжим пример:
После запуска выгрузки система должна сформировать файл со списком заказов, соответствующих выбранному периоду.
Если для реализации существенны формат файла, набор полей, сортировка или правила отбора данных, их необходимо зафиксировать отдельно.
Шаг 4. Добавить критерии приемки
Критерии приемки описывают условия, при которых конкретную функцию или user story можно считать соответствующей ожиданиям.
Например, для функции добавления товара в корзину критериями могут быть:
Важно не смешивать критерии приемки с Definition of Done. Acceptance criteria относятся к конкретной функции или пользовательской истории. Definition of Done обычно представляет собой более общий набор условий, по которым команда определяет завершенность работы: например, код реализован, проверки пройдены, документация обновлена.
Например, для функции добавления товара в корзину критериями могут быть:
- доступный товар добавляется в корзину;
- после добавления отображается актуальное количество товаров;
- итоговая стоимость корзины пересчитывается;
- недоступный для заказа товар добавить нельзя;
- после попытки добавить недоступный товар пользователь получает соответствующее сообщение.
Важно не смешивать критерии приемки с Definition of Done. Acceptance criteria относятся к конкретной функции или пользовательской истории. Definition of Done обычно представляет собой более общий набор условий, по которым команда определяет завершенность работы: например, код реализован, проверки пройдены, документация обновлена.
Хорошее и плохое функциональное требование
Плохо:
Система должна удобно работать с корзиной.
Непонятно, что означает «работать», что именно считается «удобно» и какое поведение необходимо реализовать.
Лучше:
Лучше:
Система должна позволять пользователю изменить количество каждого товара в корзине в пределах доступного для заказа количества. После изменения система должна пересчитать стоимость позиции и итоговую стоимость заказа.
Такое требование существенно легче реализовать и проверить.
Ошибки при написании FR
Даже технически грамотный документ может создавать проблемы, если требования допускают разные трактовки.
Слишком общие формулировки
Плохо:
«Система должна обеспечивать удобный поиск товаров».
Что такое «удобный» поиск? По названию? Артикулу? Категории? Частичному совпадению?
Лучше:
«Система должна позволять пользователю выполнять поиск товаров по названию. В результаты должны попадать товары, в названии которых содержится введенная пользователем строка».
При необходимости отдельно фиксируются регистр, минимальное количество символов, сортировка результатов и другие правила.
Несколько требований внутри одного предложения
Плохо:
«Система должна позволять создать заказ, оплатить его, изменить адрес доставки и отправить пользователю уведомление».
Здесь фактически объединены разные функции. Если одна из них реализована, а другая нет, становится непонятно, выполнено требование или нет.
Лучше разделить его на отдельные FR:
FR-01: Система должна позволять пользователю создать заказ из товаров в корзине.
FR-02: Система должна позволять выбрать доступный способ оплаты заказа.
FR-03: Система должна позволять изменить адрес доставки до установленного проектом момента обработки заказа.
FR-04: После успешного создания заказа система должна отправить пользователю предусмотренное проектом уведомление.
Лучше разделить его на отдельные FR:
FR-01: Система должна позволять пользователю создать заказ из товаров в корзине.
FR-02: Система должна позволять выбрать доступный способ оплаты заказа.
FR-03: Система должна позволять изменить адрес доставки до установленного проектом момента обработки заказа.
FR-04: После успешного создания заказа система должна отправить пользователю предусмотренное проектом уведомление.
Отсутствие критериев проверки
Плохо:
«Пользователь может восстановить пароль».
Фраза передает общую идею, но не определяет поведение системы. Необходимо уточнить предусмотренный проектом сценарий: как пользователь инициирует восстановление, какие данные вводит, что делает система, в каком случае операция считается успешной и как обрабатываются ошибки.
Неопределенные слова
Особенно осторожно стоит относиться к формулировкам «быстро», «корректно», «при необходимости», «удобно», «оптимально», «обычно», «в случае ошибки». Такие слова создают видимость конкретики, но сами по себе почти ничего не определяют. Например, требование «система должна быстро открывать каталог» нельзя объективно проверить. Если скорость важна, для нее нужен измеримый показатель, который уже относится к области NFR.
Практический пример: FR для интернет-магазина
Рассмотрим одну предметную область и опишем несколько функций разными способами.
Пример 1. User story: избранное
User story:
Как авторизованный покупатель, я хочу добавлять товары в избранное, чтобы сохранить интересующие позиции и вернуться к ним позже.
Критерии приемки:
User story показывает потребность, а критерии превращают ее в проверяемый набор условий.
Как авторизованный покупатель, я хочу добавлять товары в избранное, чтобы сохранить интересующие позиции и вернуться к ним позже.
Критерии приемки:
- авторизованный пользователь может добавить товар в избранное из карточки товара;
- добавленный товар отображается в списке избранного;
- пользователь может удалить товар из избранного;
- повторное добавление не создает дубликат одной и той же позиции.
User story показывает потребность, а критерии превращают ее в проверяемый набор условий.
Пример 2. Use case: удаление товара из корзины
Use case: Удаление товара из корзины.
Актор: покупатель.
Предусловие: в корзине находится хотя бы один товар.
Основной сценарий:
Такой формат полезен, когда важно зафиксировать последовательность взаимодействия.
Актор: покупатель.
Предусловие: в корзине находится хотя бы один товар.
Основной сценарий:
- Пользователь открывает корзину.
- Система отображает текущий состав корзины.
- Пользователь инициирует удаление выбранной позиции.
- Система удаляет товар из корзины.
- Система пересчитывает итоговую стоимость.
- Система отображает обновленный состав корзины.
Такой формат полезен, когда важно зафиксировать последовательность взаимодействия.
Пример 3. Таблица FR: изменение количества товара
В реальном проекте состав полей зависит от принятой структуры документации. Могут дополнительно использоваться источник требования, приоритет, связанные требования, ограничения, бизнес-правила, ссылка на макет и другие атрибуты.
Шаблон функциональных требований: как ускорить подготовку документации
Значительная часть времени аналитика уходит не только на анализ, но и на оформление результата: вспомнить структуру документа, создать таблицы, определить поля, привести требования к единому виду.
Особенно заметна эта проблема, когда требования приходится оформлять регулярно. Даже опытный аналитик может каждый раз тратить время на механическую подготовку документа, хотя его основная ценность — в анализе содержания.
Готовый шаблон функциональных требований не заменяет работу аналитика и не формулирует FR автоматически. Его задача другая: заранее задать структуру, в которую останется внести содержание конкретного проекта.
Хорошая структура помогает:
При этом шаблон не должен превращаться в формальность. Если поле не помогает понять, реализовать, проверить или сопровождать требование, необходимость его заполнения стоит оценивать с учетом конкретного проекта.
В наборе AnalystBox шаблон FR собран вместе с другими шаблонами системного аналитика и содержит пояснения по заполнению. Такой подход позволяет не создавать структуру документа каждый раз с нуля и больше времени оставлять непосредственно на анализ требований.
Получить набор шаблонов
Особенно заметна эта проблема, когда требования приходится оформлять регулярно. Даже опытный аналитик может каждый раз тратить время на механическую подготовку документа, хотя его основная ценность — в анализе содержания.
Готовый шаблон функциональных требований не заменяет работу аналитика и не формулирует FR автоматически. Его задача другая: заранее задать структуру, в которую останется внести содержание конкретного проекта.
Хорошая структура помогает:
- не забыть обязательные для команды поля;
- отделить само требование от условий и результата;
- поддерживать единый формат FR;
- быстрее подключать к документации новых участников;
- упростить чтение, согласование и дальнейшее обновление требований.
При этом шаблон не должен превращаться в формальность. Если поле не помогает понять, реализовать, проверить или сопровождать требование, необходимость его заполнения стоит оценивать с учетом конкретного проекта.
В наборе AnalystBox шаблон FR собран вместе с другими шаблонами системного аналитика и содержит пояснения по заполнению. Такой подход позволяет не создавать структуру документа каждый раз с нуля и больше времени оставлять непосредственно на анализ требований.
Получить набор шаблонов
Главное о функциональных требованиях
Эффективные функциональные требования — это не максимально длинное описание системы. Их задача — снизить неопределенность.
Разработчик должен понимать, какое поведение требуется реализовать. Тестировщик — каким способом его проверить. Аналитик и заказчик — иметь возможность однозначно определить, соответствует ли результат согласованному требованию.
Для простой потребности может быть достаточно user story с критериями приемки. Для разветвленного взаимодействия удобнее use case. Для большого количества требований — структурированный список или таблица FR. В сложных проектах эти форматы можно использовать совместно.
Главный критерий качества остается тем же: требование должно быть конкретным, однозначно понимаемым и проверяемым.
Разработчик должен понимать, какое поведение требуется реализовать. Тестировщик — каким способом его проверить. Аналитик и заказчик — иметь возможность однозначно определить, соответствует ли результат согласованному требованию.
Для простой потребности может быть достаточно user story с критериями приемки. Для разветвленного взаимодействия удобнее use case. Для большого количества требований — структурированный список или таблица FR. В сложных проектах эти форматы можно использовать совместно.
Главный критерий качества остается тем же: требование должно быть конкретным, однозначно понимаемым и проверяемым.
Не тратьте время на создание документов с нуля
Чтобы не тратить время на создание документов с нуля, скачайте готовый набор из 13 шаблонов системного аналитика с пояснениями и примерами.
Готовый набор
Готовый набор
Как работать с шаблонами
1 шаг Оплатите набор на сайте
2 шаг Скачайте архив с шаблонами
3 шаг Посмотрите структуру, пояснения и примеры
4 шаг Адаптируйте шаблон под задачи своего проекта
Выгодная стоимость шаблонов
Получите готовый набор документов со скидкой 40%
Вопросы перед покупкой
Что важно знать о шаблонах
Да, в каждом шаблоне есть пояснения, что и куда вписывать. Вы сможете быстро разобраться, даже если только начинаете работать системным аналитиком
Все основные шаблоны поставляются в формате Word (docx). Это позволяет импортировать их в Confluence в 2 клика и делиться с коллегами без потери структуры и оформления
Да, все 13 шаблонов оформлены в одном стиле: одинаковые шрифты, заголовки, отступы и логика построения. Это значит, что документация в вашей команде будет выглядеть согласованно и профессионально
После оплаты вы перейдете на страницу с ссылкой на Google Диск, где лежат все файлы. Доступ мгновенный
Бесплатные материалы обычно разрозненные, устаревшие и без пояснений. Здесь вы получаете актуальные структуры с комментариями, единым стилем и гарантией, что они применимы в реальных проектах
На биржах вы потратите больше денег и времени на подбор, а файлы не будут связаны между собой стилистически и логически. В наборе уже всё собрано и согласовано
Да, после покупки вы получаете право использовать шаблоны в любых своих проектах. Запрещено только перепродавать или распространять сами шаблоны
Чаще всего шаблоны из курсов даны «для галочки» и предназначены только для обучения. Наши шаблоны созданы практикующим аналитиком и используются в живых интеграционных проектах
Напишите на почту help-analystbox@mail.ru — помогу с решением проблемы
Пока набор финальный, но при появлении новых шаблонов или улучшений вы получите уведомление на почту