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

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

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

В предыдущей статье мы добывали сырой материал: слова стейкхолдеров, наблюдения, документы. Здесь — то, что с этим материалом делают дальше: раскладывают по уровням, чистят и делают проверяемым. Формы записи (user story, use case, спецификация) разбираются в следующей статье — тут важнее содержание, а не формат.

Карта уровней

Ключевая мысль схемы: уровень задаёт не формулировка, а адресат. Фраза «выгрузка должна работать быстро» может оказаться бизнес-требованием (продавцы уходят к конкуренту из-за медленного кабинета), нефункциональным (p95 ≤ 3 с при 50 одновременных выгрузках) или вообще ограничением (лимит шлюза — 30 секунд на HTTP-запрос). Пока не спросили «а кто это подтвердит и как мы узнаем, что сделали» — ярлык поставить нельзя.

Практическая проверка: для каждой строки в вашем документе попробуйте назвать имя человека, который её подписывает, и способ, которым вы её проверите после релиза. Строки, где не нашлось ни того, ни другого, — мусор. Обычно их 20–40%.

Бизнес-требования: единственный уровень, отвечающий на «зачем»

Бизнес-требование описывает изменение в мире, а не в системе. Формула, которая почти всегда работает:

Чтобы <измеримый результат для организации>, нам нужно, чтобы <кто> смог <что делать>, потому что сейчас <что мешает и чего это стоит>.

Плохо:

Нужен личный кабинет продавца с экспортом заказов.

Хорошо:

BR-3. Сократить долю обращений в поддержку по вопросу «где мои заказы за месяц»
с 18% до 6% от всех тикетов за два квартала после релиза.
Сейчас продавцы просят выгрузку письмом, поддержка делает её руками:
~340 тикетов в месяц, среднее время обработки 11 минут, это 1,1 FTE.

Разница не в длине. Во втором варианте есть три вещи, которых нет в первом:

1. Метрика и базовое значение. Без «сейчас 18%» цель «сократить» непроверяема.
2. Стоимость текущей боли. Она задаёт потолок бюджета: решение за 6 человеко-месяцев при экономии 1,1 FTE окупится, за 30 — нет.
3. Отсутствие решения. «Личный кабинет с экспортом» — это уже проект. Может быть, дешевле поправить письмо-уведомление или дать ссылку на готовый отчёт.

Приёмы приоритизации бизнес-целей и работы с метриками подробно разобраны в треке продакт-менеджмента: метрики и приоритизация. Аналитику важно другое: если бизнес-требования нет вообще, дальше идти нельзя. Не потому что «так в BABOK», а потому что без него любой спор о scope превращается в спор о вкусах, и выигрывает тот, кто громче.

Антиметрика: страховка от «выполнили цель и сломали бизнес»

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

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

Пользовательские требования: задача человека, а не экран

Пользовательский уровень отвечает на вопрос: какую работу человек пытается сделать и в каком контексте. Здесь живут user story, use case, job story и сценарии.

Классическая ошибка — записать на этом уровне интерфейсное решение:

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

Лучше:  Как продавец с 200+ заказами в месяц, я хочу получить заказы
        за произвольный период в виде таблицы, чтобы свести их
        со своей 1С и понять, за что мне не доплатили.

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

Полезная эвристика: если из формулировки нельзя выбросить упоминание конкретного UI-элемента без потери смысла — это не требование, а дизайн. Дизайн тоже бывает нужен и зафиксирован, но он живёт в макетах и решениях, а не в реестре требований (см. прототипирование).

Формат записи, INVEST-критерии и структура use case — в статье о документировании; там же про то, когда история должна быть разбита, а когда достаточно одной строки.

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

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

EARS: шаблоны, которые убирают половину двусмысленности

EARS (Easy Approach to Requirements Syntax) — набор из пяти шаблонов, придуманных в Rolls-Royce для авиационных спецификаций и отлично работающих в обычном продукте (https://alistairmavin.com/ears/). Смысл: у каждого требования есть явный триггер, и он вынесен в начало предложения.

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

Состояния как генератор требований

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

Вопросы, которые эта диаграмма задаёт автоматически и которые почти никогда не звучат на встрече:

• Можно ли отменить задачу в статусе Running — и что происходит с уже записанной частью файла?
• Expired удаляет файл физически или только скрывает ссылку? Кто отвечает на запрос «верните файл, я не успел»?
• Сколько задач одновременно может держать один продавец, и что видит второй, если лимит исчерпан?

Подробнее про диаграммы состояний и другие UML-нотации — в статье об UML.

Таблица решений вместо трёх абзацев текста

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

Шесть строк — шесть тест-кейсов, и вопрос «а что видит сотрудник магазина на длинном периоде» получил ответ на этапе анализа, а не на демо.

Нефункциональные требования: насколько хорошо

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

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

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

Каталог категорий качества стоит брать не из головы, а из ISO/IEC 25010 (https://iso25000.com/index.php/en/iso-25000-standards/iso-25010): функциональная пригодность, производительность, совместимость, удобство использования, надёжность, безопасность, сопровождаемость, переносимость. Пройти по восьми пунктам на старте проекта — 40 минут, а находит обычно два-три требования, о которых никто не думал.

Глубже — нефункциональные требования этого трека; как их реально измеряют инженеры — в нагрузочном тестировании и измерении производительности. Про SLO/SLI и бюджеты ошибок отлично написано в Google SRE Workbook (https://sre.google/workbook/implementing-slos/).

Виды, которые забывают чаще всего

Четырёх уровней из заголовка не хватает. Ниже — типы, отсутствие которых регулярно ломает сроки.

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

Бизнес-правила. Живут дольше любой системы и часто применяются в нескольких продуктах сразу: «комиссия для категории „Электроника“ — 8%, для остальных — 12%», «возврат принимается в течение 14 дней с момента доставки». Правило — не функция, это факт о бизнесе; система лишь реализует его. Практический смысл разделения: у правила есть владелец в бизнесе и своя частота изменений, поэтому его выносят в отдельный реестр (а часто и в конфигурацию), а не зашивают в текст истории.

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

Из такой схемы сразу видны требования, которых нет в тексте: заказ номинирован в валюте (значит, нужен курс и дата курса), время хранится в UTC (значит, нужно требование о часовом поясе в файле), total_amount — с НДС (значит, ставка НДС где-то должна быть). Подробно — в моделировании данных и в реляционной модели.

Бизнес-правило, доведённое до данных, часто становится ограничением в схеме — и это лучший способ сделать его непреодолимым:

-- Правило BR-11: срок жизни ссылки на файл — ровно 72 часа от момента запроса.
-- Не «должно быть 72 часа», а «иначе строка не запишется».
alter table export_file
  add constraint export_file_ttl_chk
  check (expires_at = requested_at + interval '72 hours');

-- Правило BR-12: у продавца не более одной активной выгрузки одновременно.
create unique index export_job_one_active_per_seller
  on export_job (seller_id)
  where status in ('Queued', 'Running');

Требования переходного периода (transition requirements). Существуют только на время внедрения и потом умирают: миграция 12 лет истории заказов, параллельная работа старого и нового кабинета два месяца, обучение 40 сотрудников поддержки, скрипт сверки остатков. Их регулярно забывают, потому что они «не про продукт» — и получают сдвиг релиза на месяц. В BABOK это отдельный класс требований именно поэтому (https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/).

Требования соответствия (compliance). 152-ФЗ и GDPR для персональных данных, PCI DSS для карт, отраслевые стандарты. Их особенность в том, что они недоговорные: нельзя «снизить приоритет» требования об аудите доступа. Смежное — приватность и комплаенс.

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

Уровни полезны не сами по себе, а связями между ними. Трассировка отвечает на два вопроса: «зачем мы это делаем?» (снизу вверх) и «всё ли мы сделали для этой цели?» (сверху вниз).

Обратите внимание на пунктирную стрелку: ограничение CON-2 (таймаут шлюза) не порождает функциональность, но вынуждает архитектуру быть асинхронной. Если бы этого ограничения не записали, требование «выгрузка синхронно» дожило бы до первой большой выборки в проде.

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

• Урезание scope. «Мы выкидываем FR-24» → сразу видно, какая история ломается и какая цель перестаёт достигаться. Спор идёт про цель, а не про «мне кажется, это важно».
• Регресс и импакт-анализ. Изменилось бизнес-правило по комиссии → по связям находятся все требования и тесты, где оно фигурирует.

Похожие рассуждения про связь требований и оценок — в оценке и планировании.

Что ломается чаще всего

1. Неявные требования

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

Три вопроса-зонда, которые вытаскивают неявное быстрее любого чек-листа:

1. «А если этого очень много?» — 2 млн строк, 500 одновременных пользователей, товар с 300 вариантами.
2. «А если этого нет?» — заказ без адреса, продавец без ИНН, справочник недоступен, курс валюты за выходной день.
3. «А кому это видно?» — сотрудник магазина, служба поддержки, партнёр по API, аудитор, сам покупатель.

Дополнительно работает вопрос «что происходит между?»: между нажатием и результатом, между двумя системами, между рабочими днями. Именно там прячутся таймауты, повторы и двойные списания.

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

2. Противоречия между стейкхолдерами

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

Что делает аналитик (а не «пусть договорятся»):

1. Формулирует конфликт как выбор, а не как ссору. «Требования A и B несовместимы; вариантов три: A, B, компромисс C (повторная аутентификация только для выгрузок с персональными данными). Цена каждого — вот такая».
2. Поднимает конфликт на уровень выше. Два функциональных требования спорят — смотрим, каким бизнес-целям они служат. Часто оказывается, что одна из целей в этом квартале не приоритетна, и спор исчезает сам.
3. Фиксирует решение письменно с автором. «Решение: вариант C. Принял: директор по безопасности, 14.03. Основание: BR-3 важнее, риск принят». Без имени и даты решение развалится при первом же инциденте.
4. Записывает проигравшее требование в реестр отложенных, а не выбрасывает. Иначе оно вернётся через два месяца как «а мы же договаривались».

Механики согласования и работы с властью стейкхолдеров — отдельная тема, см. работу со стейкхолдерами.

3. «Хотелки» без задачи

Признак: требование сформулировано как решение, и на вопрос «что сломается, если не сделать» ответа нет. Рабочая процедура — три вопроса подряд:

• Какую задачу это решает? («Хотим фильтр по 15 полям» → «Ищем заказы, по которым не пришли деньги».)
• Как вы решаете её сейчас? (Часто выясняется, что уже есть отчёт, который делает то же самое, но о нём никто не знает.)
• Что произойдёт, если мы не сделаем это в этом квартале? (Если ответ «ну, будет неудобно» — это не требование, а пожелание, и оно живёт в бэклоге идей.)

Хороший приём — просить пример из прошлого, а не прогноз: «расскажите, когда в последний раз вам это понадобилось и что вы сделали». Прогнозы о собственном поведении врут, а истории о прошлом — редко.

4. Требования, которые невозможно проверить

Тест на проверяемость формулируется грубо, но безотказно:

Опишите ситуацию, в которой это требование нарушено. Не можете — требование бессмысленно.

«Система должна быть масштабируемой» — ни один результат прогона не может её опровергнуть, значит, требования нет. «При росте RPS с 200 до 600 добавление двух инстансов возвращает p95 в бюджет 400 мс без изменения кода» — опровергается прогоном, значит, требование есть.

Слова-маркеры, при которых надо остановиться и задать вопрос:

Такую проверку легко автоматизировать — линтер на 30 строк ловит большую часть мусора до ревью:

"""Мини-линтер требований: ищет размытые формулировки и неизмеримые НФТ."""
import re
from dataclasses import dataclass

WEASEL = [
    "быстро", "оперативно", "удобн", "интуитивн", "гибк", "надёжн", "надежн",
    "стабильн", "и т.д", "и т. д", "и другие", "при необходимости",
    "оптимальн", "корректно", "по возможности", "минимальн", "максимальн",
]
# Требование обязано содержать субъект действия и модальный глагол долженствования.
MODAL = re.compile(r"\b(обязан[аоы]?|должн[аоы]?|shall)\b", re.IGNORECASE)
NUMBER = re.compile(r"\d")


@dataclass
class Issue:
    line: int
    kind: str
    detail: str


def lint(text: str, nfr_marker: str = "NFR") -> list[Issue]:
    issues: list[Issue] = []
    for i, raw in enumerate(text.splitlines(), start=1):
        line = raw.strip()
        if not line or line.startswith("#"):
            continue
        low = line.lower()

        for w in WEASEL:                       # размытые слова
            if w in low:
                issues.append(Issue(i, "weasel", f"размытое слово: «{w}»"))

        if not MODAL.search(line):             # нет модальности — это не требование
            issues.append(Issue(i, "no-modal", "нет «обязана/должна»: описание, не требование"))

        if nfr_marker in line and not NUMBER.search(line):
            issues.append(Issue(i, "nfr-no-number", "НФТ без числа: нечего проверять"))

        if len(re.findall(r"\bи\b", low)) >= 2 and len(line) > 160:
            issues.append(Issue(i, "not-atomic", "похоже на несколько требований в одном"))
    return issues

Сложность — O(n·m) по времени, где n — число строк, m — размер словаря маркеров, и O(k) по памяти на найденные замечания; на документе в тысячи строк это доли секунды. Линтер не понимает смысла и не должен: его задача — вернуть текст автору до того, как на него потратят время трое рецензентов. Тот же приём в тестировании называется «проверка тест-кейса на падаемость», см. тест-дизайн.

5. Требование, притворяющееся решением

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

Простой приём — лестница «зачем» (не больше трёх ступеней, дальше начинается философия):

«Нужна кнопка экспорта»            → зачем?
«Чтобы забрать заказы в таблицу»   → зачем?
«Чтобы свести с 1С и найти расхождения по выплатам» ← вот настоящее требование

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

6. Дубли и разъехавшиеся копии

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

Формальный документ или схема на доске

Уровень формализации — экономическое решение, а не вопрос вкуса. Документ стоит денег дважды: при написании и при каждом изменении. Значит, платить за него имеет смысл, когда знание живёт долго и/или ошибка дорога.

Практические критерии «нужен документ»:

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

И критерии «хватит доски и разговора»:

• решение проверяется в тот же день (прототип, эксперимент, фича-флаг);
• цена ошибки — час работы разработчика;
• участников трое, все в одной комнате и в одном контексте;
• знание всё равно устареет через две недели.

Есть, однако, минимум, который фиксируют всегда, даже в самой быстрой команде:

1. Решение и его автор с датой — одна строка в задаче.
2. Критерии приёмки — иначе приёмка превращается в спор о вкусах (см. приёмку).
3. Изменившееся бизнес-правило — в реестр правил, а не в комментарий к тикету.
4. Числовые НФТ — потому что «мы вроде договаривались про 3 секунды» не работает.

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

Если проект живёт в жёстком SDLC-контуре, набор обязательных документов задан процессом; про это — требования в SDLC и учебные материалы по требованиям в треке архитектуры (требования).

Сквозной разбор: «нужен экспорт заказов в Excel»

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

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

Мини-итог

• Уровень требования определяется не формулировкой, а адресатом и способом проверки. Нет ответа на «кто утверждает» и «чем проверяется» — строку можно удалять.
• Бизнес-требование обязано содержать метрику, базовое значение и цену текущей боли; к нему полезно приписать антиметрику.
• Пользовательское требование описывает задачу человека, а не элемент интерфейса. Если убрать упоминание кнопки нельзя — это дизайн, а не требование.
• Функциональное требование удобно писать по шаблонам EARS, а искать пропуски — по диаграмме состояний и таблице решений.
• НФТ без числа и условий измерения не существует; «удобно» тоже измеримо — через задачу, время и порог успеха.
• Не забывайте ограничения, бизнес-правила, требования к данным, переходные и compliance-требования: срывы сроков живут именно там.
• Трассировка нужна ради двух операций: осмысленно урезать scope и оценивать влияние изменений.
• Формальность документа покупается за деньги: платите там, где знание живёт долго или ошибка дорога. В остальных случаях — доска, фото и одна строка с решением, автором и датой.

Источники

• Karl Wiegers, Joy Beatty. Software Requirements, 3rd ed. — базовая книга по уровням требований и их качеству: https://www.karlwiegers.com/books.html
• ISO/IEC/IEEE 29148:2018 — стандарт по процессам и характеристикам требований: https://www.iso.org/standard/72089.html
• ISO/IEC 25010 — каталог характеристик качества (основа для НФТ): https://iso25000.com/index.php/en/iso-25000-standards/iso-25010
• BABOK Guide v3, IIBA — классификация требований, включая переходные: https://www.iiba.org/career-resources/a-business-analysis-professionals-foundation-for-success/babok/
• Alistair Mavin. EARS — Easy Approach to Requirements Syntax: https://alistairmavin.com/ears/
• Volere Requirements Specification Template — подробный шаблон с чек-листами типов требований: https://www.volere.org/templates/volere-requirements-specification-template/
• Bill Wake. INVEST in Good Stories: https://xp123.com/invest-in-good-stories-and-smart-tasks/
• Gojko Adzic. Specification by Example — про требования как исполняемые примеры: https://gojko.net/books/specification-by-example/
• Google SRE Workbook, Implementing SLOs — как формулируют измеримые цели надёжности: https://sre.google/workbook/implementing-slos/

Что дальше

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

Документирование: user story, use case, спецификация, критерии приёмки