Диагностика «смысловой кашицы» или как отличить требование от иллюзии требования

Содержание статьи

Привет, Хабр!

Меня зовут Андрей Бирюков. Я — независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу статьи и книги.

В системной аналитике есть страшная тайна, о которой не принято говорить на конференциях: примерно 60–70% требований в типовом SRS — это не требования. Это просто набор слов, которые создают у всех участников процесса иллюзию понимания, но при первом же прикосновении к реальности рассыпаются.

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

Звучит серьёзно и все кивают.

А потом разработчик спрашивает: «А что значит „корректную“? Обработку чего именно? Возврат денег на карту или на баланс? А если клиент передумал через 10 секунд? А если через 10 дней? А если оплата была бонусами?»

И вы понимаете: у вас не требование, а смысловая кашица.

Диагностика этой кашицы — ключевая компетенция, которая отделяет профессионального аналитика от «переводчика с русского на русский».

В этой статье мы разберём не то, как делать правильно, а то, как понять, что вы делаете неправильно. Причём понять — быстро, дешёво и без привлечения внешних экспертов.

Быстрые тесты на пригодность требований

Диагностика, как и в медицине, начинается с осмотра. Вы берёте требование (любое) и проводите три экспресс‑теста.

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

Тест № 1. Единственный возможный ответ

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

Для этого вы берёте формулировку: «Система должна уведомлять клиента об изменении статуса заказа».

• Разработчик А говорит: «Отправлю письмо на почту».

• Разработчик Б говорит: «Отправлю push‑уведомление в приложении».

• Разработчик В говорит: «А почему не через SMS? У нас же есть интеграция».

Три человека — три разных реализации.

Это потому, что требование не содержит ответа на ключевые вопросы: каким каналом? с какой частотой? с каким содержанием? что делать, если не доставлено?

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

Вот пример эталонного требования.

«При переходе заказа из статуса „Подтверждён“ в статус „Отгружен“ система отправляет клиенту на электронную почту, указанную в профиле, письмо с темой „Ваш заказ отправлен“ и текстом, содержащим номер заказа, ссылку на трекинг и ожидаемую дату доставки. Если письмо не доставлено в течение 5 минут, система делает повторную попытку. После трёх неудачных попыток — логирует ошибку в журнал и не предпринимает дальнейших действий».

Видите разницу? Здесь нет вопроса «как это делать?». Есть инструкция и любой разработчик реализует это одинаково.

Тест № 2. Пустота глагола

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

Для этого выпишите все глаголы из требований, распределив их на две колонки:

1. Конкретные глаголы (хорошо): Сохранить, отправить, рассчитать, проверить, сравнить, присвоить, удалить, создать

2. Абстрактные глаголы (плохо): Обеспечить, реализовать, организовать, настроить, поддержать, учесть, предусмотреть

Теперь посчитайте процент плохих глаголов. Если больше 30% — у вас системная проблема.

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

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

Пример провала: «Система должна организовать процесс согласования заявки».

Вопрос: что значит «организовать»? Создать задачу в workflow? Отправить ссылку на утверждение? Собрать голоса? Вызвать секретаря с печатью?

Никто не знает. Но все кивают.

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

Тест № 3. За 30 секунд найти exception

Любое хорошее требование описывает не только основной сценарий, но и исключения. Тест заключается в том, чтобы найти хотя бы одно исключение (What If‑сценарий) в описанном требовании за 30 секунд.

Если не нашли — требование неполное.

Например, берём требование: «Пользователь нажимает кнопку „Оплатить“, система перенаправляет его на платёжный шлюз».

Далее начинаете задавать вопросы «А что, если…»:

• А что, если шлюз не отвечает?

• А что, если у пользователя упало соединение после нажатия?

• А что, если платёж прошёл, но ответ не вернулся?

• А что, если пользователь закрыл вкладку?

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

Здесь инструментом ускоренной диагностики является быстрый чек‑лист из трёх вопросов:

1. Что происходит, если операция не удалась?

2. Что происходит, если операция удалась, но подтверждение потерялось?

3. Что происходит, если пользователь передумал на полпути?

Если после прочтения требования вы не можете ответить на эти три вопроса за 30 секунд — перед вами не требование, а мечта.

Работа с контекстом и неявными предположениями

Если первичный осмотр показывает симптомы, то глубокая диагностика вскрывает причины. Здесь мы идём не по тексту, а по тому, чего в тексте нет.

Диагностический приём № 1. Метод «Пяти „почему“» в обратную сторону

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

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

Для выполнения приема берём требование и спрашиваем: «Зачем это нужно?» Получаем ответ. Спрашиваем ещё раз. И так 5 раз.

Пример:

Требование: «Система должна отправлять уведомление о начислении бонусов».

• Почему 1: «Чтобы клиент знал, что получил бонусы».

• Почему 2: «Чтобы он вернулся и потратил их».

• Почему 3: «Чтобы увеличить повторные покупки».

• Почему 4: «Чтобы повысить LTV (пожизненную ценность) клиента».

• Почему 5: «Чтобы бизнес зарабатывал больше на удержании, чем на привлечении».

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

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

Более того, если бонусы маленькие — может, уведомление и не нужно вовсе, потому что оно создаст негатив («всего 20 бонусов, зачем писали?»).

Здесь аналитик перепутал средство (отправка уведомления) с результатом (повторная покупка). Он не диагностировал реальную потребность. Он записал первое, что пришло в голову.

Если после 5 «почему» вы выяснили, что требование не соответствует конечной цели — вы нашли корень зла. И теперь вы можете переформулировать требование так, чтобы оно решало задачу, а не просто «было».

Диагностический приём № 2. Тест на «Невидимые акторы»

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

Просто возьмите любое требование и спросите: «А кто ещё участвует в этом действии, кроме основного пользователя?»

А затем: «А где это зафиксировано в требовании?»

Например, вот простое требование:

«Сотрудник создаёт заявку на командировку, система сохраняет её».

Здесь присутствуют невидимые акторы:

• Бухгалтерия — она должна утвердить бюджет

• Руководитель — он должен подписать заявку

• HR — он должен проверить нормы суточных

• Security — если командировка за границу

В требовании ничего этого нет. Но в реальной жизни заявка проходит 4 согласования.

Аналитик описал только «создание», а не «жизненный цикл».

Разработчик сделает форму и кнопку «Сохранить».

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

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

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

Диагностический приём № 3. Тест на «Исчезающий контекст»

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

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

И посмотрите, есть ли это в требовании.

Пример:

Требование: «Система рассчитывает стоимость доставки как 10% от суммы заказа».

Тест на исчезающий контекст:

• А что, если завтра логистический партнёр поднимет цены на 20%?

• А что, если заказ на 1 рубль — 10% это 10 копеек, а доставка реально стоит 500 рублей?

• А что, если клиент из другого региона, где цена доставки фиксированная?

Если в требовании нет ни слова о том, как обновляется коэффициент 10%, какая минимальная стоимость доставки, какая привязка к региону, — требование живёт в вакууме. Оно работает только в момент написания. Как только мир меняется — оно ломается.

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

Визуальная диагностика

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

Диагностический приём № 4. Тест на «Закрытый цикл»

Возьмите диаграмму процесса (BPMN, поток данных, любую). Проведите пальцем по всем стрелкам от начала до конца. Если есть хотя бы одна развилка, из которой нет явного «выхода» — у вас дыра в требованиях.

Пример:

Вы рисуете процесс возврата. Есть узел: «Проверить, был ли товар в употреблении».

• Ветка «Да» — «Отказать в возврате».

• Ветка «Нет» — «Одобрить возврат».

А что происходит с клиентом, который не согласен с отказом? Он пишет в поддержку. А в диаграмме поддержки нет.

И если вы не поставили там стрелку «Перевести в ручной режим» или «Открыть обращение в службу качества» — процесс обрывается.

На практике это означает: клиент звонит, оператор не знает, что делать, процесс встаёт, клиент уходит к конкуренту.

Здесь диаграмма не замкнута. В ней есть висячие узлы, которые в реальности никуда не ведут. А значит, требование не описывает полный цикл.

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

Диагностический приём № 5. Тест на «Мёртвый объект»

Этот приём — для моделей данных (ERD, класс‑диаграммы). Найдите любой объект/сущность и спросите себя: «Какие операции над ним возможны?»

1. Если вы можете создать объект, но не можете его удалить, — это подозрительно.

2. Если вы можете его изменить, но не знаете, кто и когда это делает, — это подозрительно.

3. Если объект есть, но нигде не используется, — это «мёртвый объект».

Пример:

В модели данных есть сущность «Промокод». У неё есть поля: код, скидка, дата начала, дата окончания. Атрибуты: активен/неактивен.

Вопросы:

• Кто создаёт промокод? (нет требования).

• Кто деактивирует? (нет требования).

• Что происходит с применёнными промокодами после окончания срока? (нет требования).

• Как часто промокод можно использовать одним клиентом? (нет требования).

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

Получается, что вы описали структуру, но не описали поведение, и по сути ваши требования неполные. Вы диагностировали «что» (поля таблицы), но не диагностировали «как живёт этот объект в системе».

Эпилог. Ваш ежедневный чек‑лист диагностики

Вот короткий чек‑лист, который вы можете распечатать и повесить над рабочим столом. Перед тем как отдать требование разработчику, задайте себе 7 вопросов:

1. Единственный ответ: Если я дам это трём разработчикам — они сделают одинаково?

2. Пустой глагол: У меня есть глагол «обеспечить» или «организовать»? Если да — переписываю.

3. Исключения: Я знаю, что делать, если операция не удалась, если подтверждение потерялось, если пользователь передумал?

4. Пять почему: Я знаю настоящую бизнес‑цель, или я просто описал средство?

5. Невидимые акторы: Я учёл всех, кто участвует в процессе, или только основного пользователя?

6. Контекст: Моё требование сломается, если завтра изменится цена, закон или партнёр?

7. Приемочный тест: Я могу за одну минуту написать тест‑кейс, который проверит это требование?

Если хотя бы на один вопрос ответ «нет» — требование НЕ ГОТОВО. Диагностика не пройдена. И вы не имеете права передавать его дальше.

Диагностика — это не про «найти ошибки». Это про честность перед собой. Это про признание: «Я пока не понял эту задачу до конца. »

Дайте мне время разобраться«. Это единственный путь, чтобы разработчики не переделывали вашу работу через месяц, а заказчики не говорили: „Мы имели в виду совсем не это“.»

Плохой аналитик пишет требования. Хороший аналитик диагностирует их на прочность. Великий аналитик знает, что 80% хорошего требования — это не то, что написано, а то, что продумано до написания.

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

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

• 17 сентября, 20:00. «Событийные подпроцессы в BPMN 2.0: как моделировать процессы, реагирующие на события». Записаться

• 23 сентября, 20:00. «Как системному аналитику проводить архитектурное ревью и находить риски до начала разработки». Записаться

А полный список бесплатных уроков сентября собрали в дайджесте.