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

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

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

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

Классическое определение из стандарта ISO/IEC/IEEE 29148:2018 звучит так: функциональное требование описывает функцию, которую продукт или компонент системы должен быть способен выполнить.

На практике функциональное требование выглядит примерно так:

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

Это конкретно, проверяемо и не допускает двойного толкования.

Место ФТ в иерархии требований

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

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

Чем функциональные требования отличаются от нефункциональных

Функциональные требования описывают поведение системы — что она делает. Нефункциональные описывают качество этого поведения — насколько хорошо она это делает.

Рассмотрим на примере мобильного приложения банка:

• ФТ: «Пользователь должен иметь возможность перевести деньги другому клиенту по номеру телефона».
• НФТ: «Перевод должен обрабатываться не дольше 5 секунд в 99% случаев».

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

Чем ФТ отличаются от ТЗ, SRS и бизнес-требований

Техническое задание (ТЗ) по ГОСТ 34.602-2020 — это полный документ, который включает функциональные требования, нефункциональные требования, требования к документации, условия эксплуатации и многое другое. ФТ — это лишь один из разделов ТЗ.

SRS* (Software Requirements Specification) по стандарту IEEE 830 / ISO/IEC/IEEE 29148 — международный аналог ТЗ. Структура похожа: ФТ входят в SRS как отдельный раздел.

Бизнес-требования — это уровень выше. Они формулируются в бизнес-документах (BRD, концепция проекта) и отвечают на вопрос «зачем», тогда как ФТ отвечают на вопрос «что».

Простая схема соотношения:

Бизнес-требования

       ↓

  ТЗ / SRS (документ)

       ├── Функциональные требования   ← наша тема

       ├── Нефункциональные требования

       ├── Требования к интерфейсу

       └── Требования к документации

Понимание этой иерархии позволяет не спорить о терминах с заказчиком, а сразу говорить на одном языке.

Зачем нужны функциональные требования к программному обеспечению

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

Только 31% IT-проектов завершается в срок, в рамках бюджета и с нужным результатом. Среди главных причин провала — неполные или постоянно меняющиеся требования.

Отсутствие формализованных ФТ запускает цепочку проблем:

• Разработчик реализует функцию «как понял» — заказчик получает «не то»
• Правки вносятся постфактум, когда изменение кода стоит в 10–100 раз дороже, чем на этапе требований
• Команда тратит время на споры о том, что «подразумевалось», вместо того чтобы разрабатывать
• Тестировщик не знает, по каким критериям принимать работу
• Проект расползается в объеме (scope creep*) — каждая новая «очевидная» функция добавляется без оценки и согласования

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

Для кого пишутся функциональные требования

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

Важно! Разработчик и тестировщик — не единственные читатели. Если ФТ написаны настолько технически, что заказчик их не понимает, согласование превращается в формальность. А формальное согласование — это несогласование.

Когда начинать разработку функциональных требований

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

В Waterfall-проектах ФТ пишутся до начала разработки — полным пакетом. Это обязательное условие, особенно в государственных проектах и системах с жесткими регуляторными требованиями (например, медицинские информационные системы или интеграции с ФНС). Документ фиксируется, согласовывается и «замораживается».

В Agile (Scrum, Kanban) функциональные требования к программному продукту существуют в виде user story и критериев приемки в бэклоге. Они детализируются итерационно — непосредственно перед спринтом, в котором задача берется в работу. Полного документа ФТ может не быть совсем.

В гибридном подходе — наиболее распространенном в крупных российских компаниях есть и общий документ с верхнеуровневыми ФТ, и декомпозиция в user story для конкретных спринтов.

Совет: начинайте писать ФТ сразу после того, как зафиксированы бизнес-требования и определены ключевые стейкхолдеры. Чем позже — тем дороже.

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

В российских командах ответственность за ФТ чаще всего лежит на одной из трех ролей — в зависимости от размера и структуры команды.

Бизнес-аналитик (BA) — классическая роль. Собирает требования от стейкхолдеров, формализует их, согласовывает с заказчиком и передает команде разработки. Стандарт работы BA описан в BABOK* Guide (Business Analysis Body of Knowledge) от IIBA. Подбробнее о бизнес требованиях рассказали в этом гайде.

Системный аналитик (SA) — более технически ориентированная роль. Берет верхнеуровневые ФТ от BA и детализирует их до уровня, пригодного для проектирования архитектуры и API.

Product Owner (PO) — в Agile-командах PO отвечает за бэклог, в котором ФТ «живут» в форме user story. Формально написание ФТ — его ответственность, но на практике PO часто делегирует детализацию аналитику.

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

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

Универсальной классификации не существует — разные методологии предлагают разные подходы. На практике в российских командах чаще всего используют деление по функциональным блокам системы в сочетании с приоритизацией по MoSCoW. Рассмотрим оба среза.

Требования к бизнес-процессам и ролям пользователей

Это самый верхний и самый важный тип ФТ. Он описывает, что система делает для конкретного актера — пользователя с определенной ролью.

Прежде чем писать требования, нужно зафиксировать роли. Например, для маркетплейса это будут: покупатель, продавец (селлер), менеджер поддержки, администратор системы. У каждой роли — свой набор разрешенных действий и свои сценарии.

Пример формулировки:

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

Это требование привязано к конкретной роли (продавец), описывает конкретное действие и содержит поведение системы при ошибке.

Требования к данным и интеграциям

Этот тип описывает, как система работает с данными: хранит, обрабатывает, передает. Сюда же входят интеграции с внешними сервисами.

Для российских продуктов типичные интеграции — это:

• СБП и платежные системы
• Сервисы доставки
• Системы учета
• Государственные сервисыCRM и маркетинговые платформы

Пример требования к интеграции:

«Система должна передавать данные о подтвержденном заказе в 1С:Управление торговлей в течение 60 секунд после смены статуса заказа на “Оплачен”. Формат передачи — JSON через REST API. При недоступности 1С система должна поставить событие в очередь и повторить передачу через 5 минут, но не более 3 раз».

Обратите внимание: здесь описано и штатное поведение, и поведение при сбое. Это признак правильно написанного требования.

Требования к безопасности и управлению доступом

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

Типичная структура требований к управлению доступом:

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

Требования к интерфейсу и пользовательскому взаимодействию

Здесь важно провести четкую границу: ФТ описывают функциональное поведение интерфейса, а не его визуальное оформление. Цвета кнопок, шрифты и отступы — это дизайн-система и UI-спецификация. ФТ — это то, что происходит, когда пользователь взаимодействует с интерфейсом.

Примеры корректных ФТ к интерфейсу:

• «При вводе некорректного email в форму регистрации система должна отображать сообщение об ошибке рядом с полем, не очищая остальные поля формы».
• «Поиск товаров должен начинаться после ввода минимум 3 символов и выдавать результаты в реальном времени с задержкой не более 300 мс».
• «Кнопка “Оформить заказ” должна быть неактивной, пока не заполнены все обязательные поля адреса доставки».

Все, что касается размера кнопки или цветовой палитры, — убирайте из ФТ в отдельный документ или макет в Figma.

Классификация по приоритету: метод MoSCoW

Помимо типологии по содержанию, каждое требование нужно приоритизировать. Самый распространенный метод в российских командах — MoSCoW, разработанный Дай Клеггом в рамках методологии DSDM.

Важно! «Won’t» — это не «никогда». Это «не в текущем релизе». Фиксация таких требований помогает управлять ожиданиями заказчика и не терять идеи для будущих итераций.

Совет: если в вашем документе больше 40% требований помечены как Must — вы либо неправильно приоритизируете, либо пишете все сразу. Must-требований в здоровом документе обычно не более 20–30% от общего числа.

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

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

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

Общая часть документа

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

Обязательные элементы общей части:

• Титульный лист — название системы, версия документа, дата, авторы, статус (черновик / на согласовании / утвержден)
• История изменений — таблица с версиями: что изменено, кем, когда. Без этого через месяц никто не поймет, почему требование выглядит именно так
• Цель документа — одним абзацем: для чего создается система и что этот документ описывает
• Область применения (Scope) — что входит в систему, а что явно выходит за ее рамки
• Список терминов и аббревиатур — глоссарий, согласованный с заказчиком. Если аналитик понимает под «заказом» одно, а заказчик другое — документ бесполезен

Описание системы и контекста

Этот раздел отвечает на вопрос: «Что это за система и в каком окружении она работает?» Без него разработчик, пришедший в проект позже, вынужден восстанавливать контекст по кусочкам из чатов.

Что включить:

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

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

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

Границы системы. Явно зафиксируйте, что система не делает. Это защита от scope creep. Например: «Система не обрабатывает возвраты — эта функция остается в 1С.»

Функциональные блоки и разделы

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

Каждое требование должно иметь уникальный идентификатор. Стандартный формат: FR-[номер модуля]-[порядковый номер]. Например, FR-02-014 — четырнадцатое требование второго модуля.

Минимальный набор атрибутов каждого требования:

Чем крупнее проект, тем важнее дисциплина в заполнении атрибутов. В небольших командах можно упростить до ID + описание + приоритет + критерий приемки. Но ID — всегда обязателен.

Критерии приемки (Acceptance Criteria)

Это один из самых недооцененных элементов документа. Без критериев приемки требование технически выполнено, когда разработчик так решил. С критериями — когда тест пройден.

Стандартный формат — Given / When / Then (Дано / Когда / Тогда):

Given (контекст): Пользователь находится на странице авторизации и не авторизован
When (действие): Вводит корректный email и пароль и нажимает «Войти»
Then (результат): Система перенаправляет его на главную страницу личного кабинета и отображает имя пользователя в шапке

Для каждого требования рекомендуется писать минимум два сценария: штатный (happy path) и негативный (что происходит при ошибке).

Негативный сценарий для того же требования:

Given: Пользователь на странице авторизации
When: Вводит неверный пароль три раза подряд
Then: Система блокирует попытки входа на 15 минут и отображает соответствующее сообщение

Матрица трассируемости

Матрица трассируемости — инструмент, который связывает каждое функциональное требование с бизнес-целью, тест-кейсом и задачей в трекере. Это позволяет ответить на три вопроса: «Зачем это требование существует?», «Как проверяется?» и «Где реализуется?»

Пример фрагмента матрицы:

В небольших проектах матрицу ведут в Google Sheets. В крупных командах — в специализированных ALM-системах*: Jama Connect, IBM DOORS или российском аналоге — Яндекс Трекер с кастомными полями.

Матрица особенно ценна при изменениях. Если заказчик хочет скорректировать бизнес-цель, аналитик сразу видит, какие ФТ это затрагивает — и что нужно пересогласовать.

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

Шаг 1 — Определить стейкхолдеров и провести интервью

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

Типичная карта стейкхолдеров для внутреннего корпоративного продукта:

Методы сбора требований — не один, а целый арсенал. Выбор зависит от доступности стейкхолдеров и зрелости продукта:

• Интервью — глубокий разговор 1:1, лучший способ вытащить неявные потребности. Готовьте вопросы заранее, но не зачитывайте их по списку
• Воркшоп (совместная сессия) — когда нужно согласовать требования между несколькими стейкхолдерами сразу.
• Анализ документов — изучение существующих регламентов, инструкций, отчетов. Часто выявляет требования, о которых стейкхолдеры просто забыли упомянуть
• Наблюдение (shadowing) — аналитик смотрит, как пользователь работает «вживую». Выявляет неосознанные паттерны поведения
• Прототипирование — показать кликабельный макет в Figma и собрать реакции. Люди лучше формулируют требования, когда видят что-то конкретное

Главное правило интервью: записывайте не решения, а проблемы. Если заказчик говорит «нам нужна кнопка экспорта в Excel» — спросите «зачем?». За этим чаще всего стоит потребность «мы хотим анализировать данные в привычном инструменте» — и это уже требование, а не конкретное техническое решение.

Шаг 2 — Описать бизнес-контекст и пользовательские сценарии

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

Два главных формата для этого — Use Case* и User Story*. Они не конкуренты, а инструменты для разных ситуаций.

Шаблон User Story:

«Как [роль], я хочу [действие], чтобы [бизнес-ценность].»

Пример для сервиса доставки:

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

Шаблон Use Case (упрощенный):

Название: Оформление заказа
Пользователь: Покупатель
Предусловие: Пользователь авторизован, в корзине есть товары
Основной поток:

1. Пользователь нажимает «Оформить заказ»
2. Система отображает форму доставки с предзаполненным адресом
3. Пользователь выбирает способ доставки и оплаты
4. Система рассчитывает итоговую стоимость
5. Пользователь подтверждает заказ
6. Система создает заказ и отправляет подтверждение на email

Альтернативный поток (A1): Если выбранный способ оплаты недоступен → система предлагает альтернативные варианты
Исключение (E1): Если товар закончился в процессе оформления → система уведомляет пользователя и предлагает удалить позицию из корзины

Шаг 3 — Декомпозировать сценарии на атомарные требования

Use Case и User Story — это еще не ФТ. Это сценарии, из которых нужно вычленить отдельные, атомарные требования.

Атомарность означает: одно требование = одна проверяемая функция системы. Если требование можно разбить на два независимых теста — его нужно разбить на два требования.

Сравните:

❌ Плохо (неатомарно):

«Система должна позволять пользователю регистрироваться, авторизоваться и восстанавливать пароль».

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

✅ Хорошо (атомарно):

FR-01-001: «Система должна позволять незарегистрированному пользователю создать учетную запись, указав email и пароль».
FR-01-002: «Система должна позволять зарегистрированному пользователю войти в систему по email и паролю».
FR-01-003: «Система должна позволять пользователю инициировать сброс пароля через ссылку, отправленную на зарегистрированный email».

Шаг 4 — Приоритизировать требования по MoSCoW

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

Проводите приоритизацию совместно с Product Owner’ом и ключевыми стейкхолдерами. Не делайте это в одиночку — иначе получите конфликт на этапе сдачи.

Пример приоритизированного фрагмента для интернет-магазина:

Совет: Must-требований не должно быть больше 20–30% от общего числа.

Шаг 5 — Написать требование по шаблону

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

Базовый шаблон формулировки ФТ:

Система должна [глагол действия] [объект] при [условие/контекст], чтобы [бизнес-ценность/результат]

Не каждое требование нуждается во всех четырех элементах, но чем их больше — тем точнее формулировка.

Примеры по шаблону:

✅ «Система должна отправлять push-уведомление пользователю при изменении статуса его заказа, чтобы он мог своевременно отслеживать доставку».

✅ «Система должна блокировать попытку входа после пяти неверных вводов пароля подряд, отображая сообщение о блокировке на 30 минут».

✅ «Система должна предоставлять администратору возможность экспортировать список клиентов в формате CSV при наличии соответствующей роли, чтобы передавать данные в сторонние аналитические инструменты».

Запрещенные слова в формулировках ФТ — те, которые невозможно проверить тестом:

Шаг 6 — Верифицировать и согласовать

Написанные требования — еще не финал. Перед согласованием с заказчиком проведите внутреннюю верификацию. Это экономит время на переделки после формального согласования.

Чек-лист качества каждого требования:

✅ Атомарность — требование описывает одну функцию, тестируемую одним тестом

✅ Однозначность — нет слов, допускающих двойное толкование

✅ Полнота — описаны и штатный сценарий, и поведение при ошибках

✅ Непротиворечивость — требование не конфликтует с другими в документе

✅ Тестируемость — можно написать конкретный тест-кейс

✅ Осуществимость — технически реализуемо в рамках проекта

✅ Трассируемость — привязано к бизнес-цели или user story

✅ Идентификатор — у требования есть уникальный ID

После внутренней проверки документ уходит на согласование к стейкхолдерам. Фиксируйте согласование письменно — в Яндекс Трекере, по email или через подпись на документе. Устная договоренность в мессенджере — не согласование.

Описание функциональных требований — правила хорошего стиля

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

Глаголы-маркеры: «должна», «обязана», «может»

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

Стандарт ISO/IEC/IEEE 29148:2018 и RFC 2119 определяют следующую градацию:

Главное правило: в одном документе используйте глаголы последовательно. Если «должна» означает обязательность, то нигде в документе это слово не должно стоять там, где имеется в виду опция. Смешение градаций — источник разночтений между аналитиком, разработчиком и тестировщиком.

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

Типичные формулировки-антипаттерны

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

Разберем самые распространенные.

Антипаттерн 1: Требование-прилагательное

❌ «Интерфейс должен быть интуитивно понятным и удобным для пользователя».

Что не так: «Интуитивно понятный» — это субъективная оценка, которую невозможно проверить тестом. Два человека не договорятся, выполнено ли это требование.

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

Антипаттерн 2: Требование без субъекта

❌ «Должна быть возможность фильтрации товаров по цене».

Что не так: Непонятно, кто фильтрует. Любой пользователь? Только авторизованный? Администратор?

✅ Как исправить: «Незарегистрированный пользователь должен иметь возможность фильтровать товары в каталоге по диапазону цены с шагом 100 рублей».

Антипаттерн 3: Требование-решение

❌ «Система должна использовать Redis для кэширования сессий».

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

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

Антипаттерн 4: Составное требование

❌ «Система должна позволять пользователю просматривать историю заказов, фильтровать их по статусу и дате, а также скачивать детализацию в PDF».

Что не так: Это три требования в одном предложении. Каждое из них может иметь разный приоритет и разный тест-кейс.

✅ Как исправить: Разбить на FR-05-001, FR-05-002 и FR-05-003 с отдельными описаниями и критериями приемки.

Антипаттерн 5: Требование с «как правило»

❌ «Система, как правило, должна отправлять уведомление в течение минуты после события».

Что не так: Фраза «как правило» создает неопределенное исключение. Разработчик не знает, как должна вести себя система в нештатном случае. Тестировщик не знает, засчитывать ли задержку в две минуты как ошибку.

✅ Как исправить: «Система должна отправлять email-уведомление пользователю в течение 60 секунд после подтверждения заказа. Если отправка не удалась, система должна повторить попытку через 5 минут, но не более трех раз, после чего зафиксировать ошибку в журнале событий».

Уровень детализации: когда хватит общего описания, а когда нужна таблица полей

Ориентир по уровням детализации:

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

Пример таблицы полей для формы регистрации:

Такая таблица стоит дороже абзаца текста: разработчик сразу видит все параметры, тестировщик — все граничные случаи, а заказчик — что именно будет на экране.

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

Теория без примеров — это инструкция без иллюстраций. В этом разделе три полных кейса: e-commerce, мобильное приложение и корпоративная CRM. Каждый показывает, как описание функциональных требований выглядит на практике — с разным уровнем детализации и в разных форматах.

Кейс 1 — Мобильное приложение для доставки еды

Для мобильного приложения используем формат Use Case — он лучше передает последовательность взаимодействия пользователя с системой на маленьком экране.

Use Case 01 — Поиск ресторана

Пользователь: Покупатель
Предусловие: Приложение установлено, геолокация разрешена
Триггер: Пользователь открывает главный экран

Основной поток:

1. Система определяет геолокацию пользователя и отображает рестораны, доставляющие по его адресу
2. Пользователь вводит запрос в строку поиска или выбирает категорию (пицца, суши, бургеры)
3. Система отображает список ресторанов с рейтингом, временем доставки и минимальной суммой заказа
4. Пользователь нажимает на карточку ресторана и переходит в меню

Альтернативный поток А1 — Геолокация не разрешена:

На шаге 1: система запрашивает разрешение на геолокацию. Если отклонено — предлагает ввести адрес вручную. Если адрес не введен — отображает рестораны по умолчанию (город из профиля).

Альтернативный поток А2 — Нет ресторанов в зоне доставки:

На шаге 1: система отображает экран «В вашем районе пока нет ресторанов» с предложением подписаться на уведомление о запуске.

Use Case 02 — Оформление заказа

Пользователь: Авторизованный покупатель
Предусловие: В корзине есть товары, выбран ресторан

Основной поток:

1. Пользователь переходит в корзину и нажимает «Оформить заказ»
2. Система отображает адрес доставки из профиля (редактируемый) и время доставки
3. Пользователь выбирает способ оплаты: картой онлайн, СБП или наличными курьеру
4. Система отображает итоговую сумму с учетом доставки и примененного промокода
5. Пользователь подтверждает заказ
6. Система создает заказ, списывает оплату и переводит пользователя на экран отслеживания

Исключение E1 — Оплата не прошла:

На шаге 6: система отображает сообщение «Оплата не прошла. Попробуйте другой способ оплаты.» Заказ не создается, корзина сохраняется.

Исключение E2 — Ресторан перестал принимать заказы:

На шаге 5: система отображает уведомление «Ресторан временно не принимает заказы» и предлагает выбрать другой ресторан.

Требования к трекингу курьера:

Кейс 2 — Корпоративная CRM-система (Enterprise)

Enterprise-проект — это другой масштаб требований. Здесь особенно важны ролевая модель, интеграции и обработка граничных случаев. За основу возьмем CRM для отдела продаж с интеграцией в 1С и IP-телефонию.

Ролевая матрица доступа:

Модуль «Управление сделками»:

Интеграция с 1С:Управление торговлей:

Типичные ошибки при разработке функциональных требований

Большинство ошибок в ФТ не выглядят как ошибки в момент написания. Они проявляются позже — на code review, при тестировании или, в худшем случае, на сдаче продукта заказчику. Разбираем пять самых дорогостоящих.

Ошибка 1 — Смешение «что» и «как»

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

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

Реальные примеры из практики:

❌ «Система должна хранить сессии пользователей в Redis с TTL 1800 секунд».
❌ «Фронтенд должен использовать React и отправлять запросы через GraphQL».
❌ «База данных должна содержать таблицу orders с полями order_id, user_id, created_at».

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

✅ Правильно:

«Система должна сохранять авторизованную сессию пользователя в течение 30 минут после его последнего действия без необходимости повторного входа».

Как избежать: перед каждым требованием задавайте себе вопрос «Это описывает поведение системы или способ реализации?». Если второе — перефразируйте или перенесите в технический дизайн-документ.

Ошибка 2 — Неполнота и неявные предположения

«Это же очевидно» — самая дорогая фраза в разработке ПО. То, что кажется очевидным аналитику или заказчику, совершенно не очевидно разработчику, который видит задачу без контекста.

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

Типичные зоны неявных предположений:

• Поведение при ошибках. Что происходит, если сервис недоступен? Если пользователь ввел невалидные данные? Если закончился лимит?
• Граничные случаи. Что если в корзине 0 товаров? Что если пользователь одновременно открыл две вкладки?
• Права доступа. Кто именно может выполнять это действие? Что происходит, если роль не соответствует?
• Состояния объектов. Какие статусы может принимать сущность? Какие переходы между ними допустимы?

Пример неполного требования:

❌ «Система должна позволять менеджеру редактировать карточку клиента».

Вопросы, которые возникнут у разработчика: все поля редактируемы или только часть? Что происходит с историей изменений? Может ли менеджер редактировать клиентов других менеджеров? Что если карточка заблокирована другим пользователем?

✅ Правильно:

«Авторизованный менеджер должен иметь возможность редактировать поля карточки клиента: имя, телефон, email, адрес, комментарий. Поля “Дата создания” и “Ответственный менеджер” недоступны для редактирования. Система должна фиксировать каждое изменение в журнале истории с указанием автора, даты и измененного значения. Менеджер не должен иметь доступа к карточкам клиентов, назначенных другим менеджерам».

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

Ошибка 3 — Дублирование и противоречия

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

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

Противоречие выглядит, например, так:

FR-02-003: «Система должна сохранять корзину авторизованного пользователя в течение 30 дней».
FR-07-011: «Корзина пользователя очищается автоматически через 7 дней неактивности».

Оба требования написаны корректно по форме. Но вместе они создают неопределенность: 7 дней или 30? Разработчик реализует одно из двух — и оба будут правы, что требование выполнено.

Как избежать:

• Ведите реестр требований — единую таблицу всех ФТ с уникальными ID. Перед добавлением нового требования проверяйте, нет ли аналогичного
• Используйте полнотекстовый поиск по документу перед финальной верификацией
• Проводите кросс-ревью — второй аналитик читает документ свежим взглядом
• В базе знаний используйте теги и метки для группировки связанных требований

Ошибка 4 — Нетестируемые формулировки

Если требование нельзя проверить тестом — это не требование, а пожелание. Тестировщик не может написать тест-кейс к пожеланию. Разработчик не знает, когда он «достаточно хорошо» его выполнил.

Нетестируемость чаще всего возникает из трех источников:

Субъективные прилагательные — «удобный», «привлекательный», «современный». Не имеют объективного критерия проверки.

Отсутствие измеримых параметров — «система должна работать быстро». Что значит быстро? 100 мс? 3 секунды? 10 секунд?

Неопределенные условия — «система должна корректно обрабатывать большие объемы данных». Что такое «большие объемы»? Каков ожидаемый результат?

Чек-лист тестируемости требования — три вопроса:

✅ Можно ли написать конкретный тест-кейс с входными данными и ожидаемым результатом?

✅ Результат проверки однозначен: «прошел» или «не прошел» — без зоны субъективной оценки?

✅ Тест можно повторить и получить тот же результат?

Если хотя бы на один вопрос ответ «нет» — требование нужно переформулировать.

Пример трансформации нетестируемого требования:

❌ «Система должна быстро загружать страницу каталога.»

✅ «Страница каталога должна полностью загружаться за не более 2 секунд при скорости соединения от 10 Мбит/с и количестве отображаемых товаров до 60 позиций».

Второе требование тестируется автоматически с помощью Lighthouse или Яндекс.Танк.

Ошибка 5 — Игнорирование нефункциональных требований

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

Вот реальная ситуация: аналитик описал все функциональные требования к программному обеспечению для системы онлайн-записи к врачу. Функционал реализован корректно. Но в день запуска система легла под нагрузкой 500 одновременных пользователей — потому что требования к производительности никто не написал.

НФТ, которые чаще всего забывают зафиксировать рядом с ФТ:

Совет: после написания каждого функционального блока задавайте вопрос «Есть ли к этому блоку требования по производительности, безопасности или доступности?». Если есть — фиксируйте их в отдельном разделе НФТ, но с явной ссылкой на соответствующие ФТ.

Сводная таблица ошибок и способов их избежать

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

Выбор инструмента зависит от масштаба проекта, методологии и зрелости команды. Писать ФТ в Word, а потом хранить их на файловом сервере — технически возможно, но на проекте с 300+ требованиями это превращается в управляемый хаос. Разбираем инструменты от простых к сложным.

Яндекс Tracker + Яндекс Wiki 

Для команд, которые ищут полностью отечественное решение или работают в контуре Яндекс 360, это рабочая связка.

Яндекс Wiki выполняет роль Confluence: страницы с документацией, таблицы, история изменений. Поддерживает Markdown, есть возможность встраивать таблицы требований.

Яндекс Tracker — система управления задачами с настраиваемыми полями, досками и очередями. Поддерживает кастомные типы задач — можно создать тип «Требование» с нужными атрибутами: ID, приоритет (MoSCoW), статус, ссылка на ФТ в Wiki.

Что хорошо работает в Яндекс Tracker для управления требованиями:

• Кастомные поля на задачах — можно добавить поля «Источник требования», «Бизнес-цель», «Критерий приемки»
• Связи между задачами — «реализует требование», «тестирует требование»
• Фильтры и дашборды — быстрый срез по статусу требований перед спринтом
• Автоматизации — уведомление аналитика при изменении статуса требования разработчиком

Стоимость Яндекс 360 для бизнеса — от 249 рублей за пользователя в месяц (тариф «Оптимальный», 2025). Для небольших команд это существенно дешевле Atlassian Cloud.

Специализированные ALM-инструменты: Jama, DOORS, Visure

Когда проект требует строгой трассируемости, управления базлайнами и соответствия стандартам (ГОСТ, ISO, IEC), wiki-систем уже недостаточно. Здесь нужны специализированные ALM-инструменты (Application Lifecycle Management).

IBM Engineering Requirements Management DOORS — отраслевой стандарт для aerospace, automotive и государственных проектов. Используется в проектах, где требуется сертификация по DO-178C, IEC 61508 или аналогичным стандартам. В российском контексте — применяется в оборонных и промышленных системах.

Возможности DOORS:

• Полная двунаправленная трассируемость: от бизнес-требования до тест-кейса
• Управление базлайнами — можно «заморозить» версию требований на момент согласования
• Анализ влияния изменений: при изменении одного требования система показывает, что затронуто
• Интеграция с IBM Engineering Test Management

Jama Connect — более современный и дружелюбный интерфейс, чем DOORS. Популярен в медтехе и промышленных IoT-проектах. В России используется реже из-за санкционных ограничений.

Visure Requirements — специализированный инструмент с поддержкой ГОСТ и российских стандартов. Есть русскоязычный интерфейс и локальная техподдержка.

Для большинства коммерческих продуктовых команд в России эти инструменты избыточны. Они оправданы, когда:

• Проект проходит государственную экспертизу или сертификацию
• Требований более 500 и над ними работают несколько аналитиков параллельно
• Есть аудиторские требования к истории изменений

Диаграммы: draw.io, PlantUML

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

draw.io (diagrams.net) — бесплатный инструмент для создания UML-диаграмм, BPMN-схем и диаграмм контекста. Интегрируется с Confluence как плагин. Файлы хранятся локально или в Google Drive — что важно для команд с требованиями к безопасности данных.

Что рисовать в draw.io для документа ФТ:

• Диаграмма контекста системы (Context Diagram)
• Use Case диаграмма
• Диаграмма состояний объектов (State Diagram) — для сущностей с несколькими статусами
• BPMN-диаграмма бизнес-процесса

PlantUML — текстовый генератор диаграмм. Пишете код — получаете диаграмму. Идеален для команд, которые хранят документацию в Git: диаграммы версионируются вместе с кодом.

Шаблоны в Google Docs для небольших команд

Для стартапов и небольших команд (до 10 человек) тяжелые инструменты не нужны. Google Docs закрывает 90% потребностей при правильной организации.

Google Docs подходит для написания самого документа ФТ. Совместное редактирование, комментарии, история версий — все есть из коробки. Главный минус: нет структурированного реестра требований и трассируемости.

Решение — дополнить Google Docs таблицей в Google Sheets как реестром требований. Минимальная структура реестра:

Главное правило выбора инструмента: лучший инструмент — тот, который команда реально использует. Google Doocs с живым реестром требований лучше DOORS, в котором никто не работает.

Сравнительная таблица инструментов

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

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

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

Waterfall: монолитный документ и заморозка требований

В классической каскадной модели функциональные требования к программному продукту пишутся полным пакетом до начала разработки. Документ согласовывается, подписывается и «замораживается» — изменения после этого момента проходят через формальную процедуру управления изменениями (Change Request).

Когда Waterfall оправдан:

Государственные IT-проекты в России работают преимущественно по Waterfall — этого требует 44-ФЗ и 223-ФЗ, регулирующие закупки. Заказчик (госорган) принимает работу по заранее согласованному ТЗ, и отклонение от него — юридический риск для исполнителя.

Аналогичная логика работает в:

• Встроенных системах и промышленной автоматизации
• Медицинских информационных системах с сертификацией Росздравнадзора
• Банковских системах с требованиями ЦБ РФ (например, интеграции с АС БЭСП или СПФС)
• Проектах с фиксированной ценой контракта, где scope нельзя менять

Структура артефактов в Waterfall:

Концепция проекта (Vision & Scope)

        ↓

Техническое задание (по ГОСТ 34.602-2020)

        ├── Функциональные требования (полный документ)

        ├── Нефункциональные требования

        ├── Требования к интерфейсам

        └── Требования к документации

        ↓

Технический проект (архитектура, детальное проектирование)

        ↓

Разработка

        ↓

Тестирование (по программе и методике испытаний)

        ↓

Сдача-приемка

Особенности написания ФТ в Waterfall:

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

Объем документа ФТ для типового корпоративного проекта в Waterfall — от 50 до 300 страниц. Это не бюрократия ради бюрократии: это страховка от споров при сдаче.

Главный риск Waterfall: требования устаревают. За 6–12 месяцев разработки бизнес-контекст меняется, появляются новые вводные, конкуренты выпускают новые продукты. Система сдается в срок и в рамках бюджета — но уже не вполне соответствует текущим потребностям бизнеса.

Agile: User Story, критерии приемки и бэклог как живой документ

В Agile функциональные требования к программному обеспечению не существуют как монолитный документ. Они живут в product backlog* в виде user story, эпиков и задач — и детализируются итерационно, непосредственно перед спринтом.

Как устроена иерархия требований в Scrum:

Бизнес-цель (Goal)

        ↓

Эпик (Epic) — крупный функциональный блок

        ↓

User Story — требование с точки зрения пользователя

        ↓

Подзадачи (Tasks) — техническая декомпозиция для разработчика

        +

Критерии приемки (Acceptance Criteria) — как проверить Story

Definition of Ready (DoR) — список критериев, которым должна соответствовать user story, прежде чем команда берет ее в спринт. Это Agile-аналог верификации требований.

Типовой DoR для user story:

• [ ] Написана по шаблону «Как [роль], я хочу [действие], чтобы [ценность]»
• [ ] Есть минимум три критерия приемки в формате Given/When/Then
• [ ] Оценена командой в story points
• [ ] Нет неразрешенных зависимостей от других story
• [ ] Макет или прототип согласован (если требуется)
• [ ] Нефункциональные требования зафиксированы

Definition of Done (DoD) — список критериев, при которых story считается выполненной. Аналог критериев приемки на уровне команды.

Типовой DoD:

• [ ] Код написан и прошел code review
• [ ] Unit-тесты написаны и проходят
• [ ] Функциональное тестирование по критериям приемки пройдено
• [ ] Документация обновлена
• [ ] Демо показано Product Owner’у и принято

Детализация требований в Agile — принцип «Just In Time»:

Ключевое отличие от Waterfall: требования детализируются не все сразу, а непосредственно перед тем, как команда берет их в работу. Это называется backlog refinement (груминг бэклога).

На горизонте 2–3 спринтов требования проработаны детально. На горизонте 6+ спринтов — существуют как эпики с грубыми описаниями. Это нормально и намеренно: детализировать требования за полгода до реализации — значит тратить время на то, что изменится.

Пример эволюции требования в Scrum:

Гибридный подход: когда и тот, и другой

Чистый Waterfall и чистый Agile — крайности. Большинство реальных проектов в крупных российских компаниях работают по гибридной модели, которая сочетает:

• Верхнеуровневый документ ФТ (для фиксации scope и согласования с бизнесом)
• Итерационную детализацию в бэклоге (для гибкости в разработке)

Это особенно характерно для проектов, где есть корпоративный заказчик, которому нужно «подписать документ», и Agile-команда разработки, которой нужна гибкость.

Как это работает на практике в крупных российских компаниях:

Фаза 1 — Discovery (4–8 недель)

├── Сбор и анализ требований

├── Написание верхнеуровневого документа ФТ (20–40 страниц)

├── Согласование scope с бизнесом

└── Подписание документа (фиксация границ)

        ↓

Фаза 2 — Delivery (итерации по 2 недели)

├── Backlog refinement перед каждым спринтом

├── Детализация ФТ в user story по мере приближения к реализации

├── Обновление документа ФТ при изменениях (Change Request)

└── Демо заказчику в конце каждого спринта

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

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

Решение: назначить владельца документа (обычно ведущий аналитик), который отвечает за актуальность ФТ и обновляет его после каждого согласованного изменения.

Сравнительная таблица подходов

FAQ — Часто задаваемые вопросы

Чем функциональные требования отличаются от технического задания?

Функциональные требования — это раздел внутри более широкого документа. Техническое задание (ТЗ) по ГОСТ 34.602-2020 включает ФТ как один из блоков, но помимо него содержит нефункциональные требования, требования к документации, условия эксплуатации, порядок сдачи-приемки и многое другое. Если ТЗ — это паспорт системы, то ФТ — раздел «что умеет делать».

Кто отвечает за написание функциональных требований в команде?

Формальная ответственность — у бизнес-аналитика или системного аналитика. В Agile-командах без выделенного аналитика эту роль берет Product Owner. В небольших стартапах — нередко сам разработчик или основатель. Ключевое условие не в должности, а в том, чтобы один человек был назначен владельцем документа и отвечал за его актуальность.

Нужны ли функциональные требования в Agile-проектах?

Нужны — просто в другой форме. В Agile написание функциональных требований происходит итерационно в виде user story с критериями приемки. Полного монолитного документа может не быть, но каждая user story — это и есть функциональное требование, только упакованное в карточку бэклога. Команды, которые отказываются от любой формализации требований в Agile, как правило, накапливают технический долг и неожиданно обнаруживают, что реализовали «не то».

Что делать, если заказчик не может четко сформулировать требования?

Это нормальная ситуация — и задача аналитика именно в том, чтобы помочь заказчику сформулировать то, что он чувствует, но не может выразить словами. Рабочие техники: показать кликабельный прототип в Figma и собрать реакции, провести совместный воркшоп в Miro с картой пользовательского пути, изучить существующие бизнес-процессы через наблюдение (shadowing). Заказчик всегда лучше реагирует на конкретное — «вот так будет выглядеть экран» — чем на абстрактный вопрос «что вы хотите».

Сколько страниц должен занимать документ с ФТ?

Зависит от масштаба проекта и методологии. Ориентиры из практики: небольшой веб-сервис (Agile) — 10–20 страниц или 30–50 user story. Корпоративная система среднего масштаба (гибрид) — 40–80 страниц. Крупный государственный проект (Waterfall) — 100–300 страниц. Объем — не самоцель. Если документ на 15 страниц покрывает все сценарии, проверяем и тестируем — это хороший документ. Если на 200 страниц, но половина — вода и дублирование — это плохой документ.

Что такое нефункциональные требования и где их описывать?

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

Мнение эксперта

— Александр Апраксин, совладелец и генеральный директор digital-агентства MWI (входит в ТОП-10 Рейтинга Рунета). Автор книги «50 способов увеличения продаж интернет-магазина». Ведущий подкаста «Маркетологи», автор Telegram-канала Апраксин Pro Бизнес. Практик с 15+ годами опыта в digital и eCommerce. Сайт компании: mwi.me.

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

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

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

Заключение

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

Используйте шаблон и чек-лист из этой статьи на следующем проекте — и сравните, насколько меньше вопросов возникнет у команды в процессе разработки.

Термины и сноски

* ALM (Application Lifecycle Management) — класс инструментов для управления жизненным циклом приложения: от требований до тестирования и релиза. Примеры: IBM DOORS, Jama Connect, Visure Requirements.

* Backlog (бэклог) — приоритизированный список всех требований, задач и улучшений продукта. В Scrum различают product backlog (все требования) и sprint backlog (задачи текущего спринта).

* BABOK (Business Analysis Body of Knowledge) — международный стандарт бизнес-анализа от IIBA. Описывает области знаний, задачи и техники работы бизнес-аналитика, включая сбор и управление требованиями.

* BPMN (Business Process Model and Notation) — стандартная нотация для визуального моделирования бизнес-процессов. Используется для описания сложных сценариев с ветвлением и несколькими участниками.

* Scope creep — неконтролируемое расширение границ проекта за счет добавления новых требований без пересмотра сроков и бюджета. Одна из главных причин срыва IT-проектов.

* SRS (Software Requirements Specification) — спецификация требований к программному обеспечению. Международный аналог российского ТЗ, структура определяется стандартом IEEE 830 / ISO/IEC/IEEE 29148.

* Use Case (прецедент) — структурированное описание взаимодействия актера с системой для достижения конкретной цели. Включает основной поток, альтернативные потоки и исключения.

* User Story — короткое неформальное описание функциональности с точки зрения пользователя по шаблону: «Как [роль], я хочу [действие], чтобы [бизнес-ценность]».

Категория вопроса

Что мы можем предложить?