Виды требований
Первый блок почти любого собеса аналитика. Проверяют не заучённую классификацию, а умение разложить кашу из пожеланий заказчика по уровням: где цель бизнеса, где поведение системы, а где рамка, которую ты не вправе двигать.
Стержень: уровень определяется предметом высказывания, а не автором и не длиной формулировки. Одно бизнес-требование раскрывается в несколько функциональных, а рядом с ними живут требования к качеству и ограничения - и у каждой группы своя судьба на проекте.
// Формулировки: «какие виды требований знаешь?», «куда отнесёшь вот это?», «чем нефункциональное требование отличается от ограничения?»
Три уровня на одной цепочке
Уровни проще всего почувствовать на одной сквозной цепочке. Бизнес говорит: «сократить срок обработки заявки вдвое» - это бизнес-требование, оно про цель компании и почти никогда не содержит слова «система».
Спускаемся: «клиент оформляет возврат сам, не звоня в поддержку» - пользовательское требование, задача человека в его словах. Ещё ниже: «система рассчитывает срок возврата по тарифу и показывает его в карточке заказа» - функциональное, конкретное поведение системы.
Уровень задаёт предмет, а не автор. Если директор скажет «система должна показывать срок в карточке», это останется функциональным требованием, просто озвученным директором. И наоборот - фраза аналитика «нам нужно снизить нагрузку на поддержку» остаётся бизнес-требованием.
// Две быстрые проверки. Если из формулировки нельзя составить тест, ты ещё не на функциональном уровне. Если в ней есть слова «система должна» - ты уже на нижнем и подниматься некуда.
Требования к качеству: не что, а насколько хорошо
Функциональное требование отвечает на вопрос «что делает», нефункциональное - «насколько хорошо делает». Сюда попадают скорость, доступность, безопасность, совместимость и наблюдаемость.
Проверяемое требование к качеству всегда состоит из трёх частей: показатель, условия замера и порог. «Отклик каталога не выше 300 миллисекунд на 95-м перцентиле при 200 запросах в секунду в промышленной среде» - работает, по такому можно принять работу. «Система должна быть быстрой» - не работает, потому что принимать нечего и спорить будут о вкусах.
Перцентиль тут не украшение. Среднее время ответа прячет хвост: при среднем в 100 миллисекунд каждый двадцатый запрос может ждать три секунды, и уходят пользователи именно из-за него. Поэтому пишут «на 95-м перцентиле» - то есть девяносто пять запросов из ста укладываются в порог.
// Чаще всего забывают наблюдаемость: логи, метрики, сквозной идентификатор запроса. Вспоминают о ней на первом же инциденте, когда причину сбоя просто не видно, и добавлять её приходится задним числом по всей системе.
- перцентиль
- граница, ниже которой лежит заданная доля замеров. 95-й перцентиль - значение, которое не превышают 95 процентов запросов
Ограничение - это рамка, а не качество
Ограничение отнимает свободу выбора: только СУБД (система управления базами данных) из реестра отечественного программного обеспечения, интеграция строго через существующую шину, срок хранения журналов три года. Оно приходит извне - от регулятора, от архитектурного комитета, из подписанного договора.
Разница с требованием к качеству чисто практическая. Качество можно оптимизировать и торговать по цене реализации, и цена там нелинейная. Доступность 99,9 процента означает почти девять часов простоя в год, 99,99 процента - меньше часа; второе стоит кратно дороже первого, и это предмет разговора с бизнесом о деньгах.
Ограничение оптимизировать нельзя вообще. Его можно только оспорить у того, кто его наложил, и это совсем другой разговор, с другими людьми и другими аргументами.
// Поэтому классификация здесь не бюрократия, а навигация: она определяет, что подлежит обсуждению на проекте и с кем именно это обсуждение вести. Спорить с архитектором о цене того, что предписал регулятор, - потерянное время.
Как отвечать: «Заказчик требует хранить журналы три года. Что это за требование?»
Здесь на самом деле три разных требования, и я бы их развёл. Сам факт записи журнала операций - функциональное требование: система пишет события в журнал, у него есть проверяемое поведение. Срок хранения в три года - ограничение, оно приходит от регулятора или из отраслевого регламента, и двигать его я не вправе, могу только оспорить у источника. И одновременно этот срок задаёт требования к качеству хранилища: какой объём накопится за три года, за какое время нужно достать запись двухлетней давности, можно ли держать старое в холодном архиве. Развожу их потому, что судьба у каждого разная: функцию мы проектируем, ограничение принимаем как данность, а качество считаем в деньгах и обсуждаем с архитектором.
Ответ показывает, что кандидат видит за одной фразой заказчика три разных требования и, главное, понимает, что с каждым из них делать дальше и с кем разговаривать.
На чём валятся
- −− Определяют уровень по автору: «раз сказал заказчик, значит бизнес-требование». Уровень задаёт предмет высказывания, а не источник.
- −− Пишут требования к качеству без чисел: «производительная», «удобная», «надёжная». Принять такое нельзя, и на приёмке начинается спор о вкусах.
- −− Смешивают ограничение с качеством и месяцами оптимизируют то, что вообще не подлежит выбору.
- −− Забывают целые группы качества: наблюдаемость, сопровождаемость, совместимость. Вспоминают, когда чинить уже дорого.
- −− Тянут в требования конкретную библиотеку без причины, отбирая у команды более дешёвое решение.
Проверьте себя
Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.
- Что описывает пользовательское требование?A)Задачу, которую пользователь решает в системеB)Экран и расположение элементов на нёмC)Ограничение по технологиям, выбранным в компанииD)Формат сообщения, которым обмениваются два сервиса
показать ответ и разбор
+A)Задачу, которую пользователь решает в системе// разбор: Пользовательский уровень — прослойка между целью бизнеса и поведением системы: он фиксирует задачу пользователя в его словах («оформить возврат, не звоня в поддержку»). Верстка — это дизайн, стек — ограничение, формат сообщения — уже техническая спецификация интеграции.
- Заказчик требует хранить журналы операций три года. К чему это отнести?A)К функциональному требованию: система пишет журналB)К бизнес-правилу, которое не попадает в ТЗC)К ограничению регулятора и НФТ храненияD)К пользовательскому требованию администратора
показать ответ и разбор
+C)К ограничению регулятора и НФТ хранения// разбор: Срок хранения диктуется извне — законом или отраслевым регламентом, поэтому это ограничение, которое аналитик не вправе изменить. Одновременно оно задаёт НФТ к хранилищу: объём, глубину архива, скорость выемки. Сам факт записи журнала — отдельное функциональное требование, и его стоит держать отдельной строкой.
- Чем ограничение (constraint) отличается от нефункционального требования?A)Ограничение сужает выбор, НФТ задаёт метрикуB)Ограничение касается только железа, НФТ — только софтаC)Ограничение можно обсуждать, НФТ обсуждению не подлежитD)Это синонимы, разделение придумано в ГОСТе
показать ответ и разбор
+A)Ограничение сужает выбор, НФТ задаёт метрику// разбор: НФТ — измеримая характеристика («доступность 99,9% в месяц»), и способ её достижения остаётся за командой. Ограничение отнимает свободу выбора: «только отечественная СУБД из реестра», «интеграция через существующую шину». Путаница вредна: ограничение нельзя оптимизировать, его можно только оспорить у того, кто его наложил.
- Бизнес-правило «скидка 10% при сумме от 5000 ₽» меняется несколько раз в год. Где его держать?A)Захардкодить в коде оформления заказа, менять релизомB)Продублировать в каждом требовании, где упоминается скидкаC)Вынести в реестр правил, требования ссылаютсяD)Держать в описании маркетинговой акции
показать ответ и разбор
+C)Вынести в реестр правил, требования ссылаются// разбор: Бизнес-правило живёт дольше и меняется чаще, чем функции, которые его применяют. Отдельный реестр с идентификатором правила даёт одну точку правки: меняется значение — требования и код остаются целыми. Дублирование по тексту гарантирует рассинхрон, а хардкод превращает правку тарифа в релиз.
- Почему НФТ «система должна быть производительной» бесполезно?A)Оно написано не по ГОСТу и не пройдёт согласованиеB)Его нельзя проверить: нет метрики, нагрузки и порогаC)Производительность вообще не относится к требованиямD)Оно дублирует требование по доступности
показать ответ и разбор
+B)Его нельзя проверить: нет метрики, нагрузки и порога// разбор: У проверяемого НФТ есть три части: метрика, условия замера и порог — «p95 отклика каталога ≤ 300 мс при 200 rps на проде». Без них приёмка превращается в спор о вкусах, нагрузочное тестирование невозможно спроектировать, а команда не понимает, когда работа закончена. Формулировка без чисел — это пожелание, а не требование.
дальше
Теорию прочитали. Навык ставится повторением
В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.