Без хорошо проработанного и грамотно оформленного требования невозможно создать качественный IT-продукт. На что стоит обратить внимание бизнес-аналитику при подготовке требований? В этой статье в блоге ЛАНИТ я попробую подсветить эти моменты. При этом вопросы сбора и приоритизации я решил не рассматривать: будем считать, что все требования собраны.

Разделим аспекты, которые нужно учитывать при подготовке требований к разработке ПО (без этапа сбора и приоритизации) на соответствующие смысловые блоки:

• функционал;

• административный блок;

• качество требований;

• оформление и стилистика;

• другое.

Далее сосредоточимся на каждом из блоков.

Функционал

Начнем с общих моментов. 

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

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

• Необходимо описание поведения системы во всех особых случаях (при ошибках разной природы) и альтернативных сценариях. Это важно, так как помимо описания того, что система должна делать, бывает полезно сразу описать и то, как это будет происходить (например, посредством Use Cases, хорошее объяснение которого можно прочитать здесь). Разработчики могут сделать так, чтобы система выполняла то, что требуется, но последовательность действий для достижения целей окажется настолько неудобной для пользователей, что реализацию нужно будет пересмотреть. 

• Необходимо обеспечить соответствие UI и поведения системы принятой дизайн-системе. Если дизайн-системы нет, то ее нужно хотя бы на каком-то минимальном уровне разработать и стараться ей следовать. Если этого не сделать, то очень скоро можно получить по-разному работающие типовые элементы.

• Важно помнить про разрешения (пермишены) при работе разных ролей в системе.

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

  • типа задачи (тип 1, выбрано по умолчанию, доступны обе периодичности) и тип 2 (доступна только периодичность «ежедневно»);

  • значения периодичности («разово», выбрано по умолчанию) и («ежедневно»);

  • времени запуска (по умолчанию задано 18:00).

Как себя должна повести система, если мы поменяли время запуска на 19:00 и после этого переключили тип задачи на тип 2? Периодичность автоматически поменяется на «ежедневно»? Время запуска останется 19:00 или сбросится на 18:00? А если вернем показатель тип 1, останется ли периодичность «ежедневно»? Эти нюансы тоже необходимо прописывать. Решение по ним зависит от конкретной задачи.

• Нужно провести сценарно-имитационное моделирование работы системы и определить:

  • когда и что может пойти не так;

  • к каким последствиям это может привести;

  • как это обойти, учесть или разрулить. 

Например, есть пул устройств, и по информации от них мы рассчитываем некоторые показатели. Предположим, что несколько устройств из этого пула стали недоступны. Как при этом должен производиться расчет показателей? Если его не произвести, то в процессе эксплуатации могут возникнуть неожиданные и неприятные сюрпризы.

• Желательно наличие макетов (прототипов) страниц системы (если прототипированием занимается сам бизнес-аналитик). В некоторых случаях требуется еще дополнительно согласовать с заказчиком и цветовую палитру приложения, чтобы системой могли пользоваться люди с особенностями восприятия цвета.

• Желательно наличие схемы роутинга по страницам системы (для web-приложений). Это нужно, чтобы быстро понимать, куда попадает пользователь, без необходимости искать эту информацию по требованию. Кроме того, схема дает верхнеуровневое представление о навигации. 

• Желательно зафиксировать, какие бизнес-потребности закрывает конкретное требование.

На практике я однажды столкнулся с требованием к расчету технической доступности банкомата (состоит из нескольких узлов: картридер, диспенсер  и вес влияния узла = 100%). Формула, предоставленная клиентом, выглядела так:

где:

• T – итоговая техническая доступность (в долях единицы);

• D_j – доступность узла;

• m – количество критических узлов для каждого типа УС.

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

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

где:

• D_n – доступность узла (в долях единицы);

• R_n – количество рабочих часов узла (количество часов в отчетном периоде, когда узел находился в состоянии «нет ошибок»);

• P  – плановое время работы УС за отчетный период (часов).

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

А теперь попробуем понять, что же за доступность банкомата дает такая формула.

1. Допустим, в банкомате есть пять узлов.

2. Рассмотрим период рабочего времени банкомата с 08:00 до 20:00 включительно (12 часов работы).

3. Берем предельный случай, когда все пять узлов не работали одновременно с 8:00 до 10:00 (например, банкомат сломался, быстро приехал мастер и оперативно починил его). Итого: имеем 2 часа простоя и 10 часов работы.

  — доступность любого из устройств банкомата

В нашем примере получается, что по формуле доступность — 40,19%, а если включить здравый смысл, то банкомат был доступен 83,33% времени (с 10 до 20 при графике работы с 8:00 до 20:00). Разница — более чем в 2 раза, а это значит, что, скорее всего, что-то не так с методологией. 

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

Административный блок

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

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

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

• Ревью требования другим аналитиком и/или разработчиками перед отправкой на согласование с заказчиком.

• Ведение версионности требования.

• Учет движения требования по процессу.

• Декомпозиция задач на реализацию требования.

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

Качество требований

В этой части мы будем учитывать соответствие требования «Критериям качества требований». К ним относят следующие критерии:

• полнота (завершенность);

• непротиворечивость (согласованность);

• недвусмысленность (однозначность);

• выполнимость (осуществимость);

• проверяемость (тестируемость);

• приоритизированность (упорядоченность);

• атомарность (единичность);

• необходимость (обязательность);

• прослеживаемость (трассируемость);

• модифицируемость;

• понятность.

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

Оформление и стилистика

Сюда можно отнести все то, что касается визуальной составляющей и легкости восприятия. 

• Соответствие оформления принятому стандарту (это может быть ГОСТ или любой другой стандарт, утвержденный в организации).

• Применение общепринятой терминологии и определений (желательно избегать введения новых терминов, когда без них можно обойтись). Желательно все термины и определения фиксировать в соответствующем разделе. 

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

• Лаконичность, минимальное количество длинных и сложных предложений.

• Отсутствие орфографических и пунктуационных ошибок.

• Рисунки и схемы:

  • читабельность;

  • спокойная цветовая палитра (без кислотных цветов);

  • соблюдение пропорций (отсутствие сжатия изображения по одному из направлений);

• сообразный размер рисунка (два маленьких элемента не должны занимать всю страницу).

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

• Корректная нумерация пунктов. 

Другое

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

Заключение

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

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

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

*Статья написана в рамках ХабраЧелленджа 4.0, который прошел в ЛАНИТ весной  2025 года. О том, что такое ХабраЧеллендж, читайте здесь.