Привет! С вами снова я, Юлия Чугунова. В первой части мы учились слушать заказчика и вытаскивать из «у меня что-то не так» конкретные проблемы. Во второй – собирали разрозненные мнения команды в систему и ставили SMART-цели.
Теперь настало время документирования. Потому что даже самые гениальные идеи превращаются в хаос, если их не зафиксировать. В этой части разберём:
- BRD, SRS и Backlog – чем они отличаются и когда что использовать.
- Функциональные и нефункциональные требования. Почему «письмо должно отправляться за 5 секунд» не менее важно, чем «письмо должно отправляться».
- Практическое задание: попробуем превратить расплывчатое «хочу что-то про лояльность» в чёткие требования.
Готовы перевести слова в документы? Тогда вперёд.
Артефакты аналитика: BRD, SRS и Backlog
«Хороший документ – это не описание мира. Это договор между теми, кто его строит.»
Карл Вигерс, Software Requirements, Microsoft Press
Когда желания стали целями, а наблюдения – формулировками, наступает следующий шаг: зафиксировать все это так, чтобы с этим могли работать другие.
Документация – не бюрократия, а способ сохранить смысл и передать его дальше: разработчикам, дизайнерам, тестировщикам, новым участникам команды.
У аналитика в арсенале есть три ключевых артефакта. Каждый из них выполняет свою задачу – в зависимости от того, кто будет его читать и на каком этапе находится проект.
BRD (Business Requirements Document)
Документ бизнес-требований, в котором описываются, бизнес-требования к проекту или продукту. Он определяет цели, ожидания заказчика и то, как программное обеспечение (ПО) или система должны помочь их достичь. BRD служит мостом между бизнесом и техническими специалистами, объясняя, почему компания нуждается в создании нового продукта или решения.
Для чего? Объяснить, зачем вообще запускается проект.
Кто читает? Бизнес, руководители, маркетинг, инвесторы.
Включает в себя:
- Контекст – в чем проблема, почему возник запрос;
- Цели и задачи проекта;
- Границы – что входит, а что нет;
- Риски, ограничения, метрики успеха.
BRD помогает всем сторонам прийти к единому пониманию, особенно если в проект вовлечены не только IT–специалисты.
SRS (Software Requirements Specification)
Спецификация требований к ПО. Описывает полный набор требований к ПО, включая его функциональность, производительность, конструктивные ограничения и внешние интерфейсы. Это всеобъемлющее описание того, что разрабатываемое ПО должно делать и как оно должно работать.
Для чего? Описать, как система должна работать.
Кто читает? Разработчики, тестировщики, тимлиды.
Включает в себя:
- Архитектуру и сценарии (Use Case);
- Функциональные и нефункциональные требования;
- Интеграции и форматы API;
- Диаграммы, схемы, условия переходов.
SRS особенно нужен там, где есть сложная логика, внешние зависимости, высокие требования к качеству или интеграции.
Различия функциональных и нефункциональных требований
Важно понимать различие этих двух типов требований.
Функциональные описывают, что делает система.
Например,
- «При нажатии на кнопку “Купить” пользователь переходит к оплате»
- «Система отправляет письмо после оплаты»
Нефункциональные – как система это делает.
Например,
- «Ответ за ≤2 секунд при 1000 пользователях»
- «Данные шифруются по AES–256»
Если не указать нефункциональные требования, система может быть технически рабочей, но неудобной, уязвимой или нестабильной. А если все перепутать – получится каша вместо спецификации.
Одно дело – "система должна отправлять письмо".
Другое – "письмо должно уходить за 5 секунд, даже при пиковой нагрузке".
Первая фраза – функциональное требование. Вторая – нефункциональное. Без нее система формально работает, но пользователь раздражен задержками – а значит, цель не достигнута.
Нефункциональные требования – это все, что влияет не на действие, а на качество, скорость, удобство, надежность, безопасность и поддержку системы.
Категории, о которых важно помнить:
🟣 Производительность: время отклика, максимальная нагрузка
🟣 Безопасность: шифрование, контроль доступа, аудит
🟣 Юзабилити: адаптивность, доступность, понятность
🟣 Надежность: резервное копирование, откат
🟣 Масштабируемость: рост нагрузки без деградации
🟣 Совместимость: работа на разных устройствах, браузерах
🟣 Поддерживаемость: логирование, читаемый код, документация
🟣 Локализация: мультиязычность, форматы дат и валют
Полезная шпаргалка:
Функциональные – что система делает.
Нефункциональные – насколько хорошо она это делает.
Это как рецепт: ингредиенты и шаги – это функция. А вкус, подача и атмосфера – нефункциональные детали. Если их упустить, блюдо формально приготовлено, но есть его не хочется.
Backlog (User Stories)
Для чего? Вести работу в Agile, фиксируя потребности пользователей.
Кто читает? Вся команда – аналитики, разработчики, дизайнеры, тестировщики, проджекты.
Формат User Story: Как [роль], я хочу [действие], чтобы [ценность]
Например, Как покупатель, я хочу ввести адрес один раз, чтобы не повторять его на этапе оплаты.
Backlog – это живой документ. Он развивается, уточняется, приоритизируется и реализуется поэтапно. В нем видно, чего хотят пользователи, что уже сделано и что делать дальше.
Какой артефакт выбрать?
🔹 Если нужен фокус на бизнесе – BRD
🔹 Если важна техническая точность – SRS
🔹 Если проект гибкий и живой – Backlog
На практике часто используется комбинация. Например, в проекте с органическими джемами мы начали с легкого Backlog – чтобы быстро двигаться. Завели и краткий BRD, чтобы помнить, к какой цели идем. А когда появились более сложные сценарии и требования к качеству – пригодился и SRS.
Совет героя
При сборе и описании требований сразу разделяй:
- Что должно происходить – это функциональные требования;
- При каких условиях – это нефункциональные.
Тогда в документах будет порядок, а у команды – ясность.
Документы – это не отчеты, а точки опоры. Они помогают не забыть, не перепутать и не потерять главное на пути.
Выбирай формат под задачу – но всегда помни:
ты фиксируешь не текст, а смысл, чтобы команда могла двигаться вперед – даже если тебя рядом не будет.
Практическое задание
«От варенья к системе: путь аналитика от слов к артефактам»
Цель: применить на практике такие навыки, как:
➡️ выявления требований,
➡️ фасилитации,
➡️ формулирования целей по SMART,
➡️ работы с аналитическими артефактами (BRD, SRS, Backlog).
Сценарий: вы – аналитик в проекте по разработке мобильного приложения для линейки органических джемов. Заказчик говорит:
«Мы хотим, чтобы люди у нас заказывали больше. И вообще, чтобы приложение работало удобно.
Ну и чтобы была какая–то лояльность: рецепты, может, какие–то штуки с историей джемов, как в Инстаграме, но не совсем. Мы не знаем пока точно. Главное – чтоб нравилось и не затягивалось».
Задачи:
1) Разобрать запрос на части
Выпишите все фразы, которые вызывают вопросы или требуют уточнений.
Подготовьте не менее 7 уточняющих вопросов для заказчика.
2) Смоделировать фасилитацию
Опишите, как бы вы провели встречу с заказчиком и командой.
Укажите:
- кого пригласите;
- какие техники фасилитации примените (например: доска Х–сценариев, карта стейкхолдеров, Crazy 8);
- как структурируете выводы по итогам встречи.
3) Сформулировать SMART–цель
Перепишите фразу «чтобы заказывали больше» в 1 – 2 SMART–цели.
Обоснуйте, почему они важны для команды и проекта.
4) Выбрать нужные артефакты
Укажите, какие документы вы заведете (например: BRD, SRS, Backlog).
Для каждого кратко поясните:
— кто его читает,
— зачем он нужен,
— что получится на выходе.
5) Сформулировать требования
Придумайте:
- 3 функциональных требования (например: «Пользователь может сохранить рецепт в избранное»),
- 2 нефункциональных требования (например: «Время загрузки экрана не более 2 секунд»).
Можно кратко, главное – чтобы было видно, что вы умеете структурировать и формулировать требования.
В результате вы:
➕ Преобразуете размытое «хочу» в конкретную цель.
➕ Смоделируете фасилитацию с реальной пользой для команды.
➕ Покажете понимание: артефакты – это инструмент ясности, а не «бумажка ради бумажки».
➕ Сформируете основу продукта, который будет ближе к людям, а не просто к ТЗ.
Вывод
Теперь наш герой знает, как превратить:
- «Мне нужно, чтобы работало» → в BRD для бизнеса.
- «Как это должно работать?» → в SRS для разработчиков.
- «А можно вот ещё…» → в Backlog для Agile-команды.
Но это ещё не конец пути. В следующий раз коротко разберем это задание и вы сможете сравнить его со своим решением. Задание вроде простое: разобрал фразы, расписал цели, сформулировал пару требований. Но именно с таких шагов и начинается путь. Там, где раньше было “ну, чтобы заказывали больше”, теперь – конкретика, ясность и вектор движения. И наш герой не родился аналитиком. Он просто начал внимать, задавать, уточнять. Так что если сейчас вам стало хоть чуть понятнее, как работать с “хочу” – поздравляю. Вы сделали важный шаг.
А дальше по плану начнем тему «Бизнес–процессы и сценарии». Поговорим о BPMN 2.0, разберем процесс «Оформление и ввод данных» (AS IS и TO BE), а затем перейдем к Use Case и элементам UML – чтобы описывать не только путь пользователя, но и поведение системы.
А пока попробуйте выполнить практическое задание из этой статьи. Проверьте, сможете ли вы уловить суть между строк и превратить её в структуру. До встречи!
P.S. Если вдруг пропустили предыдущие части – вот первая и вторая. Без них будет как без карты в лесу: вроде идёшь, но неясно куда.
