Выявление требований к ПО: интервью, анкеты, user stories и документ, который поймут разработчики

Новички часто считают, что требования у заказчика уже есть и их остаётся записать. На деле заказчик обычно называет готовое решение («нужна кнопка выгрузки в Excel»), а не задачу, ради которой оно понадобилось. Часть знаний люди не проговаривают вовсе, поэтому требования именно выявляют — сопоставляют слова, наблюдения и документы.

С кем говорить: карта стейкхолдеров

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

Методы: что каким способом удаётся узнать

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

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

Если неясно, есть ли проблема вообще и станут ли люди пользоваться решением, собирать требования рано: сначала проверяют спрос методами Customer Development, которым на сайте посвящена отдельная статья.

Учебный пример: возвраты в пункте выдачи

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

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

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

Как записать требования, чтобы их поняли разработчики

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

С государственными и крупными заказчиками требования оформляют в техническое задание по ГОСТ 34.602-2020; он действует в России с 1 января 2022 года и заменил ГОСТ 34.602-89. По п. 3.4 требования должны обладать шестью характеристиками — единичностью, непротиворечивостью, актуальностью, выполнимостью, проверяемостью и однозначностью — и по возможности быть максимально детализированы. Единичность значит, что в формулировке одно требование: во фразе «система принимает возвраты и уведомляет склад» их два, и проверять их придётся по отдельности.

Ещё два пункта полезны на практике. По п. 5.3 значения показателей указывают, как правило, с предельными отклонениями или как максимум и минимум, а если на этапе ТЗ цифру установить нельзя, в документ записывают порядок её установления и согласования. Это прямой ответ на «быстро загружается»: либо число с допуском, либо договорённость, кто и когда его определит. А примечание к п. 4.1 требует сохранять раздел ТЗ, даже если требований по нему нет, с записью об их отсутствии. Пустой раздел о надёжности становится согласованным решением, а не случайным пропуском. Функции системы стандарт собирает в подразделе 4.6.2, а надёжность, безопасность и эргономику — в общих технических требованиях подраздела 4.6.4.

Международный аналог — ISO/IEC/IEEE 29148:2018 о процессах работы с требованиями; в феврале 2026 года ISO отметила его к пересмотру, так что в ссылках указывайте год издания.

Трассировка: у каждой строки есть источник

Трассировка — связь требования с тем, откуда оно взялось и что из него получилось. Простая матрица — таблица со столбцами «номер требования», «источник» (запись интервью с отметкой времени, пункт регламента), «история», «тест-кейс», «статус». Когда заказчик через полгода спросит, зачем обязательное фото, ответ найдётся за минуту.

С чего начать и в каком порядке осваивать

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

1. Составьте карту стейкхолдеров для процесса, в котором участвуете сами: отпуск, заказ канцтоваров, запись к врачу.
2. Проведите два интервью по одному гайду и сравните ответы: там, где люди описывают процесс по-разному, прячутся требования.
3. Понаблюдайте, как коллега выполняет ту же операцию, и выпишите расхождения с его рассказом.
4. Нарисуйте прототип одного экрана и покажите его будущему пользователю.
5. Запишите несколько историй с критериями приёмки, включая негативные сценарии, и одно нефункциональное требование с допуском.
6. Сведите всё в таблицу трассировки.

Когда нужна проверка наставником, стоит посмотреть программы по бизнес-анализу. На онлайн-курсе «Бизнес-аналитик расширенный» Яндекс Практикума выявлению требований отведён отдельный блок — интервью, анкетирование, наблюдение и анализ документов, а функциональность затем описывают пользовательскими историями. Восемь месяцев спринтами по две-три недели, около 15 часов в неделю, 11 домашних заданий и три проекта с ручной проверкой; цена в обзоре — 158 500 ₽ (на 4 сентября 2026 года). Критерии приёмки и ТЗ в описании не названы, это стоит уточнить у школы.

Типичные ошибки и как проверить себя

Самая частая ошибка — записать решение как требование. «Кнопка выгрузки в Excel» — решение; требование — «бухгалтер раз в месяц сверяет возвраты с банковской выпиской», и, возможно, сверку сделает сама система. Вторая — наводящие вопросы: «Вам ведь удобнее выбирать из списка?» почти всегда получает «да». Третья — критерии приёмки только для успешного сценария, без случаев «у клиента нет чека» или «связь пропала при загрузке фото». Четвёртая — слова «быстро», «удобно», «при необходимости», которые нельзя проверить.

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

Тем, кому удобнее учиться в живой группе, подойдёт формат с вечерними вебинарами. На онлайн-курсе «Бизнес-аналитик в ИТ + автоматизация с ИИ» Компьютерной Академии TOP занятия идут дважды в неделю в группах до 12 человек, шесть месяцев: 192 академических часа с преподавателем и столько же самостоятельно. Второй модуль посвящён сбору и формализации требований и оценке эффективности проекта. На странице раскрыты только три первых модуля, поэтому про пользовательские истории, прототипы и ТЗ нужно спросить у школы. Платёж — 4 040 ₽ в месяц, за полгода не меньше 24 240 ₽.

Как навык влияет на доход

Отдельной надбавки за выявление требований в вакансиях обычно нет: навык входит в базовые обязанности бизнес- и системного аналитика. Влияние косвенное: тому, кто сам проводит интервью и сдаёт проверяемое ТЗ, поручают задачи целиком, а это шаг от младшего уровня к среднему.

Ориентир — калькулятор зарплат Хабр Карьеры: для бизнес-аналитика уровня Middle он показывает 166 666 ₽ по 486 анкетам (Россия без фильтра по городу, данные на октябрь 2026 года). Это зарплаты из анкет специалистов, а не предложения работодателей, и они отражают профессию, а не цену одного навыка. Смотрите цифры с фильтром по своему городу и учитывайте, что в анкетах указывают суммы и до вычета налога, и на руки.

Как выбрать обучение

Работающему менеджеру или разработчику полная профессиональная программа часто избыточна. Короткий вариант для перехода из смежной роли — повышение квалификации «Бизнес-аналитик. Подходы, инструменты, компетенции» Московской бизнес-школы: два дня с 10:00 до 17:30, очно в Москве или онлайн, первый день — стейкхолдеры, сбор и управление требованиями, бэклог, Agile и Waterfall. Стоимость — 45 900 ₽ (на 13 октября 2026 года); академические часы не указаны, инструменты даются на уровне знакомства.

Какую бы программу вы ни выбрали, попросите пример задания по требованиям. Хороший признак — учебное интервью, пользовательские истории с критериями приёмки и разбор от проверяющего, а не тест по терминам. Уточните и то, разбирают ли нефункциональные требования и ТЗ по ГОСТ.

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