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

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

Что спрашивают

• +Уровни: чем бизнес-требование отличается от функционального и почему уровень задаёт предмет высказывания, а не автор
• +НФТ против ограничений: что можно оптимизировать и торговать по цене, а что принимают как данность
• +Проверяемость: почему «система должна быть производительной» нельзя принять и как переписать это тремя частями
• +Сценарии: основной поток, альтернатива и исключение, и чем грозит постусловие, описанное только для успеха
• +Изменения: что такое baseline, как оценить влияние правки по связям и чем уточнение отличается от расползания объёма

Из чего состоит тема

Так тема разложена в тренажёре: движок ведёт прогресс по каждой подтеме отдельно и возвращает те, где вы ошибаетесь.

• Use case и сценарии13
• User story и критерии приёмки13
• Качество требований13
• Виды требований12
• Трассировка и изменения12

Разборы подтем

Конспект по каждой: что это, как отвечать вслух, на чём валятся, плюс вопросы для самопроверки.

• Виды требований12 вопросов
• Качество требований13 вопросов
• Use case и сценарии13 вопросов
• User story и критерии приёмки13 вопросов
• Трассировка и изменения12 вопросов

Примеры вопросов с разбором

1. #ana_req_quality1 / 9
   Что означает проверяемость требования?

   A)Требование согласовано всеми заинтересованными сторонами

   B)Требование прошло вычитку у технического писателя

   C)Требование записано в системе учёта, а не в переписке

   D)Есть однозначный способ установить, выполнено ли

   показать ответ и разбор

   +D)Есть однозначный способ установить, выполнено ли

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

2. #ana_req_trace2 / 9
   Что показывает матрица трассировки требований?

   A)Порядок реализации требований по срокам

   B)Связи требований с целями и тестами

   C)Оценку трудоёмкости каждого требования

   D)Историю правок текста требования

   показать ответ и разбор

   +B)Связи требований с целями и тестами

   // разбор: Матрица отвечает на два вопроса: откуда взялось требование (какая бизнес-цель или документ его породил) и во что оно превратилось (код, тесты, приёмка). Это позволяет быстро оценивать влияние изменений и доказывать полноту покрытия. Сроки, оценки и история правок живут в других инструментах.

3. #ana_req_types3 / 9
   Чем бизнес-требование отличается от функционального?

   A)Бизнес-требование пишет заказчик, функциональное — разработчик

   B)Разницы нет, это два названия одного уровня

   C)Бизнес-требование короче и не попадает в ТЗ

   D)Одно про цель компании, другое про поведение системы

   показать ответ и разбор

   +D)Одно про цель компании, другое про поведение системы

   // разбор: Уровни отличаются не автором и не длиной, а предметом. Бизнес-требование фиксирует цель организации («сократить время обработки заявки вдвое»), функциональное — конкретное поведение системы («система рассчитывает срок по тарифу и показывает его в карточке»). Одно бизнес-требование обычно раскрывается в несколько функциональных.

4. #ana_req_usecase4 / 9
   Кто такой актор в use case?

   A)Сотрудник заказчика, ведущий проект

   B)Модуль внутри проектируемой системы

   C)Конкретный пользователь с именем и учётной записью

   D)Роль или внешняя система со своей целью

   показать ответ и разбор

   +D)Роль или внешняя система со своей целью

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

5. #ana_req_userstory5 / 9
   Какая часть user story отвечает за ценность?

   A)«Как <роль>»

   B)«Я хочу <действие>»

   C)«Чтобы <результат>»

   D)Заголовок карточки

   показать ответ и разбор

   +C)«Чтобы <результат>»

   // разбор: Третья часть отвечает на вопрос «зачем» и часто оказывается единственной по-настоящему полезной. Она позволяет обсудить альтернативные решения: если цель — «быстрее находить заказ», то поиск может оказаться дешевле и лучше, чем выгрузка в файл, которую просил заказчик. Без неё история превращается в наряд на работу.

6. #ana_req_quality6 / 9
   Требование атомарно, если…

   A)оно занимает не больше одного предложения

   B)его реализует один разработчик

   C)оно содержит одно проверяемое утверждение

   D)оно относится к одному экрану интерфейса

   показать ответ и разбор

   +C)оно содержит одно проверяемое утверждение

   // разбор: Атомарность — про единственность утверждения, а не про объём текста или зону ответственности. Требование «система отправляет письмо и SMS» неатомарно: письмо может работать, а SMS нет, и статус выполнения становится неопределённым. Разделение на два требования даёт независимую приёмку и честную трассировку.

7. #ana_req_trace7 / 9
   Что такое базовая версия (baseline) набора требований?

   A)Первый черновик, написанный аналитиком

   B)Требования с наивысшим приоритетом

   C)Набор требований, реализованных в текущем релизе

   D)Согласованный срез, правки только по процедуре

   показать ответ и разбор

   +D)Согласованный срез, правки только по процедуре

   // разбор: Baseline — точка отсчёта: с этого момента набор считается согласованным, и любая правка проходит через управление изменениями с оценкой влияния. Без базовой версии невозможно отличить уточнение от расширения объёма, и спор «мы так не договаривались» становится неразрешимым.

8. #ana_req_types8 / 9
   Какое из требований — нефункциональное?

   A)Пользователь может отменить заказ до передачи в доставку

   B)Система отправляет клиенту письмо при смене статуса

   C)Страница каталога отвечает за 300 мс на 95-м перцентиле

   D)Менеджер видит список заявок за выбранный период

   показать ответ и разбор

   +C)Страница каталога отвечает за 300 мс на 95-м перцентиле

   // разбор: Функциональное требование отвечает на вопрос «что система делает», нефункциональное — «насколько хорошо она это делает»: скорость, доступность, безопасность, совместимость. Время отклика с указанием перцентиля — классическое НФТ производительности, потому что описывает качество работы уже существующей функции, а не новое поведение.

9. #ana_req_usecase9 / 9
   Что фиксирует предусловие use case?

   A)Что должно быть истинно до старта сценария

   B)Первый шаг, который делает актор

   C)Результат, ожидаемый после завершения

   D)Список ошибок, возможных в сценарии

   показать ответ и разбор

   +A)Что должно быть истинно до старта сценария

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

Частые вопросы

• Что чаще всего спрашивают про требования?

  Дают формулировку и просят найти в ней дефект. Это рабочий рефлекс, а не память: обычно там непроверяемость, слово-резинка вроде «современный» или конструкция «и/или», за которой прячется нерешённая развилка.

• Чем ограничение отличается от нефункционального требования?

  НФТ это измеримая характеристика, и способ её достижения остаётся за командой. Ограничение отнимает свободу выбора: только СУБД из реестра, только существующая шина. Его не оптимизируют, его оспаривают у того, кто наложил.