Содержание:
1. Введение
2. Почему ТЗ не читают
3. Как писать требования, которые будут читать
4. Инструменты: как проверить качество требований
5. Практический пример: разбор реального кейса
Заключение

1. Введение

«А в ТЗ этого не было!» — знакомая ситуация?

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

• Разработчики интерпретируют требования по-своему — появляются непредусмотренные функциональные возможности.

• Тестировщики проверяют не то, что хотел бизнес, или по типовым тест-кейсам — дефекты всплывают на поздних этапах.

• Аналитик тратит время на разрешение конфликтов, возникающих из-за расхождений в интерпретации требований, вместо погружения в тонкости функционирования системы или работы над новыми задачами.

Пример из практики: «В ТЗ указано: “Права пользователей должны быть разграничены”. Но не сказано, в каких модулях, какие роли и как проверять доступ. В итоге пользователь без прав админа получил возможность назначить себе права админа без подтверждения — и это обнаружилось только на финальной приемке заказчиком».

Ключевой принцип:

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

Разберём реальные кейсы, советы и чек-лист, которые помогут избежать таких ситуаций.

2.  Почему ТЗ не читают

Разработчики игнорируют ТЗ, когда требования не соответствуют критериям качества. Такие требования реализовываются произвольно. Рассмотрим несколько критериев качества (метрик) на примере разработки ИИ-парсера вакансий.
(Критерии качества (метрики) требований подробнее можно изучить в Ссылках в конце статьи. Выбирайте источники метрик, исходя из бизнес-требований проекта.)

Нарушение метрики «Однозначность»

Требование должно иметь единственную интерпретацию.
Пример нарушения:
❌«Система должна работать быстро».
Как метрика страдает: требование допускает множественные трактовки.
Как исправить:
✅«Система (API сервис) должна обеспечивать время обработки и возврата ответа на запрос не более 500 мс».

Нарушение метрики «Атомарность»

Требование должно описывать одну конкретную функциональность или правило без объединения несвязанных условий.
Пример нарушения:
❌«Система должна проверять email на корректность, отправлять приветственное письмо и добавлять пользователя в группу "Новые"».
Как метрика страдает: объединены 3 независимых процесса (валидация, нотификация, управление группами).
Как исправить:
✅Разделить на атомарные требования:
RQ-101:
«При регистрации пользователя система должна проверять формат email по RFC 5322».
RQ-102:
«После успешной регистрации пользователя система должна отправлять письмо с темой "Добро пожаловать"».
RQ-103:
«Система должна добавлять новых пользователей в группу "Новые"».

Нарушение метрики «Проверяемость»

Требование должно содержать критерии для проверки.
Пример нарушения:
❌«Реализовать поиск».
Как метрика страдает: неясно, как проверить результат реализации требования.
Как исправить:
✅ RQ-101:
«Система должна предоставлять интерфейс поиска резюме по фамилии».
✅ RQ-102:
«Система должна поддерживать автодополнение в поле поиска по фамилии».
✅ RQ-103:
«Автодополнение должно срабатывать после ввода не менее 3 символов».
✅ RQ-104:
«Подсказки должны выводиться в виде списка (максимум 10 вариантов)».

Нарушение метрики «Актуальность»

Требования должны соответствовать последним утверждённым изменениям в продукте или бизнес-процессах и быть синхронизированы с реальной логикой работы системы.
Пример нарушения:
❌В ТЗ осталось: «Система должна отправлять СМС-уведомление при появлении нового резюме, подходящего под вакансию», хотя бизнес перешёл на email.
Как метрика страдает: заказчик получает систему, не соответствующую текущим нуждам.
Как исправить:
Внедрить процесс контроля версий (использовать теги актуально/ устарело).
✅RQ-205:
«При появлении нового резюме, подходящего под вакансию, система должна отправлять email с темой "В список добавлен новый кандидат" на email-адрес рекрутера».

Нарушение метрики «Полнота»

Требование содержит всю необходимую информацию для его однозначного понимания и реализации без необходимости в дополнительных уточнениях.
Пример нарушения:
❌«Система должна формировать отчёт».
Как метрика страдает: в требовании не описаны все аспекты его реализации, что затрудняет его выполнение.
Как исправить:
✅«Система должна формировать PDF-отчёт о работе рекрутера за текущий месяц, включающий список рассмотренных кандидатов, даты их появления на сайте и статусы рассмотрения рекрутером (отказ/приглашение на собеседование/сотрудник нанят)».

Нарушение метрики «Согласованность»

Требования должны использовать единую терминологию и не противоречить друг другу.
Пример нарушения:
❌В разных разделах ТЗ указаны противоречивые требования к интерфейсу:
В разделе «Форма авторизации»: «Кнопка "Войти" должна быть зелёной».
В разделе «UI-стандарты»: «Все кнопки должны быть синими».
Как метрика страдает: разработчики получают противоречивые указания, а тестировщики не могут однозначно определить правильный вариант.
Как исправить:
Определить единый верхнеуровневый источник требований.
✅RQ-001:
«Все кнопки должны иметь следующие характеристики:
Цвет: синий (#2E74B5);
Отступы: 12px сверху/снизу, 24px по бокам;
Шрифт: Roboto Medium 16px».

Иногда неточности в требованиях появляются не случайно, а из-за действий участников проекта.

Проблема: ошибки намеренно допускаются в проектах.
Пример:

• Со стороны бизнеса (заказчика): заказчик может потребовать скрыть логику реализации одной из функций от команды («это ноу-хау»).

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

• Со стороны разработчиков: намеренно добавляется размытая формулировка, чтобы оставить разработчику свободу реализации.

Решение:

• Со стороны бизнеса (заказчика):
  1. Закрепить в договоре NDA (соглашение о неразглашении);
  2. Выделить «закрытую» часть требований в отдельный документ с ограниченным доступом.

• Со стороны руководителей проекта:
  1. Внедрить матрицу трассируемости требований с пометками «реализовано» и «запланировано».
  2. Регулярно проводить демонстрации возможностей системы для заказчика.
  3. Явно документировать технический долг и планы по его устранению.

• Со стороны разработчиков:
  1. Обучить команду важности четких требований;
  2. Добавлять критерии приемки для каждого требования.

3. Как писать требования, которые будут читать

Совет 1: Разработайте перечень атрибутов требований

Каждое требование должно содержать обязательные метаданные. Пример структуры:

Как применять (пример):

Требование RQ-142:
Текст: «Парсер должен определять уровень зарплаты (junior/ middle/ senior) на основе текста резюме с точностью ≥90%».

Совет 2: Привязывайте требования к этапам тестирования

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

Как применять (пример):

• Для требования из RQ-142 тест-кейсы включают:
  Unit: Проверка accuracy модели на 1000 вакансий,
  UAT: Подтверждение точности рекрутерами.

Совет 3: Участвуйте в ручном тестировании и работе с заказчиком

Практические методы:
Ручной прогон ключевых сценариев перед передачей тестировщикам (QA):
Например, лично проверьте парсинг 50 сложных вакансий (с конфликтующими технологиями).
Сессии совместного тестирования с заказчиком:
Фиксируйте, как заказчик формулирует ожидания и что реализовано.
Работа в продакшн-среде 1-2 дня в месяц:
Анализ логов ошибок → доработка требований к обработке edge-кейсов.

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

Совет 4: Внедрите регламент обновления требований

Правила для команды:

1. Периодический аудит:
   1.1 Проверка актуальности требований при изменении API источников (например, HeadHunter обновил структуру JSON).
   1.2 Частоту аудитов необходимо подбирать исходя из требований и продолжительности проекта.

2. Система тегов в Jira/Confluence:
   #требование устарело — если найдено несоответствие.

3. Автоматические уведомления:
   Интеграция Git → Jira: комментарий к задаче при изменении связанного .md-файла с ТЗ.
   3.1 Через вебхуки Git + Jira Automation,
   3.2 Через GitHub Actions/Jenkins + Jira API.

4. Инструменты: как проверить качество требований

Чтобы систематизировать выявленные проблемы и предотвратить их в будущем, перейдем к инструментам контроля требований. Разберём инструменты, которые помогут:

• проверить выполнение метрик качества требований,

• снизить количество итераций на согласование,

• ускорить процесс разработки ТЗ.

4.1. Визуализация и валидация сложной логики

Диаграммы не только улучшают понимание, но и помогают найти противоречия. Инструменты:

1. Редакторы диаграмм с валидацией (Camunda, Visio, draw.io):

   • Проверяют недостижимые состояния в BPMN,

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

2. Swagger/OpenAPI для API:

   • Автоматическая проверка полноты описания полей,

   • Валидация примеров запросов/ответов.

Пример визуализации требования:

Если вакансия содержит разные данные о зарплате (например, в заголовке «от 200К», а в описании «150–300К»), система должна:
1. выбирать диапазон из описания, если он указан;
2. при отсутствии диапазона — использовать минимальное значение с пометкой «от»;
3. отправлять уведомление рекрутеру, если расхождение >30%.

4.2 Коллаборативные платформы для ревью

Снижают количество ошибок за счет коллективной проверки.

Инструменты:

1. Confluence + Jira:
   Комментарии с привязкой к конкретным строкам требований.
   Интеграция чек-листов для проверки (например, «Проверено: есть примеры для всех ошибок API»).

2. GitHub/GitLab для документов:
   Code Review-подход к правкам ТЗ: Diff-сравнение версий или Assign на ответственных за проверку.

5. Практический пример: разбор реального кейса

(Разбираем провалы в проекте ИИ-парсера вакансий)

Проект: SaaS-платформа для IT-рекрутеров с ИИ-парсером HeadHunter, LinkedIn и GitHub Jobs.
Последствия проблем: потеря ключевых клиентов и убытки компании.

5.1. Контекст: Что пошло не так?

После запуска парсера обнаружились проблемы:

1. дублирование вакансий из разных источников (например, одна и та же вакансия с HeadHunter и LinkedIn учитывалась дважды);

2. пропуск remote-позиций из-за некорректных фильтров;

3. отсутствие учета требований по интеграции с другими модулями (например, с CRM-системой клиентов).

Рассмотрим их подробнее.

Проблема №1: Дублирование вакансий из разных источников

Было в ТЗ:
«Система должна парсить вакансии с HeadHunter, LinkedIn и GitHub Jobs».

Проблемы:

• Не указаны правила дедубликации (как определить, что вакансия с HeadHunter и LinkedIn — одна и та же?);

• Нет приоритета источников (если данные конфликтуют, чему верить?);

• Не описана логика объединения данных (например, зарплата из HeadHunter + стек технологий из GitHub).

Последствия:

• В базе клиентов появлялись дубликаты вакансий;

• Рекрутеры тратили время на ручную чистку, что приводило к снижению эффективности.

Решение:

1. Четкие правила дедубликации

Обновленное ТЗ:
«Система должна определять дубликаты по:
1. Хешу контента (совпадение ≥85% текста),
2. ID компании + должности (например, «Java Developer в Yandex»),
3. Дате публикации (разница ≤3 дней).
4. Приоритет источников: LinkedIn > HeadHunter > GitHub Jobs.

2. Визуализация требования

3. Интеграция с Elasticsearch

• Настроили автоматическую дедубликацию через индекс vacancy_id,

• Добавили алерт для рекрутеров, если система не уверена в дубле.

Результат:

• Сокращение дубликатов,

• Увеличение скорости работы парсера за счёт оптимизации запросов.

Проблема №2: Пропуск remote-вакансий

Было в ТЗ:
«Система должна фильтровать вакансии по типу работы: удаленная работа, гибридный режим, работа в офисе».

Проблемы:

• Не определено, как идентифицировать remote (если в вакансии нет прямого указания),

• Нет списка ключевых слов (например, «удалёнка» ≠ «remote»),

• Не указано, что делать с гибридным режимом (2 дня в неделю в офисе - это гибридный режим или работа в офисе).

Последствия:

• часть remote-позиций не попадали в выборку,

• Клиенты теряли топовых кандидатов, готовых работать только удалённо.

Решение:

1 Детализация критериев

Обновленное ТЗ:

«Тип работы должен определяться по:

1. явным меткам: «remote», «удалёнка», «work from home»,

2. косвенным признакам: «график свободный», «офис в любом городе», отсутствие требований к локации.

3. гибридный режим: указание дней в офисе (≤3 дней = гибридный режим, >3 = работа в офисе).

4. правила для конфликтов: при противоречии данных (например, «удалёнка» в заголовке vs. «офис 2 дня» в описании) система должна отмечать резюме для ручной проверки рекрутером.»

2. Машинное обучение для классификации

• Дообучили модель BERT на датасете из 10 тысяч размеченных вакансий,

• Настроили кастомизацию под клиента: возможность добавлять свои ключевые слова (например, «digital nomad»).

3. Тест-кейсы для проверки

Результат:

• Выросло покрытие remote-вакансий,

• Клиенты получили настраиваемые фильтры.

Проблема №3: Интеграционные пробелы

Проблема: ТЗ парсера не учитывало требования по интеграции с другими модулями (например, с CRM-системой клиентов).

Что отсутствовало:

• форматы данных для обмена (JSON/XML),

• протоколы взаимодействия (REST/GraphQL),

• обработка ошибок (таймауты, retry-логика).

Решение:

1. Добавили в ТЗ раздел «Интеграционные требования»:

   • форматы API (REST с JSON Schema),

   • retry-логика: 3 попытки с интервалом 5 секунд.

2. Кросс-модульные согласования с архитектором и командами смежных модулей.

Практическое задание для читателей

Попробуйте улучшить эти требования:

•  «Система должна быть надёжной.»

• «Поиск должен выдавать релевантные результаты.»

• «Загрузка данных не должна занимать много времени.»

• «Интерфейс должен быть удобным.»

• «Обработка ошибок должна быть понятной.»

Подсказка

Используйте шаблон:
«[Система/модуль] должен [действие] [метрика] при [условия]».

Заключение

Чек-лист для проверки ТЗ

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

Пример проверки:
❌ «Парсить технологии» → Нарушение метрики «Проверяемость».
✅ «Извлекать технологии с точностью ≥90% на датасете из 1000 вакансий» → Соответствует.

Писать идеальные требования с первого раза невозможно, но каждый провал — это шаг к мастерству. Анализируйте ошибки, внедряйте метрики и не бойтесь пересматривать документы. Как показывает пример с ИИ-парсером, даже сложные проблемы решаются, если подходить к ним системно. Ваша цель — не просто документ, а продукт, который экономит время и деньги клиента.

Ссылки:

• BABOK Guide
  International Institute of Business Analysis (IIBA).
  A Guide to the Business Analysis Body of Knowledge (BABOK Guide), v3.

• Разработка требований к программному обеспечению
  Вигерс К., Битти Дж.
  М.: Русская редакция, 2020. — 576 с.
  ISBN 978-5-7502-0432-1

• ГОСТ Р ИСО/МЭК 59194-2021
  «Информационные технологии. Системная и программная инженерия. Процессы жизненного цикла систем».М.: Стандартинформ, 2021.

• ГОСТ 34.ххх-хх
  «Информационная технология. Комплекс стандартов на автоматизированные системы».
  М.: Стандартинформ, 20хх.

• РД 50-34.ххх-хх
  «Методические указания по разработке технических заданий на создание автоматизированных систем».
  М.: Госстандарт России, 20хх.