Требования и их сбор
Виды требований, критерии качества, методики сбора, роль аналитика и жизненный цикл требования от бизнес-потребности до проверенной реализации.
22 вопросов
JuniorТеорияОчень частоКто такой системный аналитик и с кем он взаимодействует в команде?
Кто такой системный аналитик и с кем он взаимодействует в команде?
Системный аналитик — мост между бизнесом и разработкой: выявляет и анализирует требования, делает функциональную декомпозицию, проектирует интеграции и ставит задачи разработчикам. Взаимодействует с заказчиком, руководителем проекта, аналитиками, тестировщиками и разработчиками.
Типичные ошибки
- ✗Ограничивать контакты аналитика только заказчиком или только разработчиками
- ✗Путать системного аналитика с тестировщиком или чистым бизнес-аналитиком
- ✗Опускать проектирование интеграций и постановку задач из роли
Уточняющие вопросы
- →Чем системный аналитик отличается от бизнес-аналитика?
- →Как меняются задачи аналитика в Agile и Waterfall?
JuniorТеорияОчень частоКто такие стейкхолдеры, как их выявить и с какими группами работает аналитик?
Кто такие стейкхолдеры, как их выявить и с какими группами работает аналитик?
Стейкхолдеры — все, кого система затрагивает или кто может на неё влиять: заказчик, пользователи, спонсор, РП, разработчики, тестировщики. Выявляют по ролям, по источнику финансирования и по трассировке процессов. Аналитик работает с заказчиком, пользователями и командой.
Типичные ошибки
- ✗Ограничивать стейкхолдеров теми, кто платит или подписывает договор
- ✗Забывать внутренние роли — поддержку, тестировщиков, легал — как стейкхолдеров
- ✗Считать, что стейкхолдеров можно найти только после релиза
Уточняющие вопросы
- →Как быть со стейкхолдером, выявленным поздно на проекте?
- →Как отделить лицо, принимающее решение, от влияющего среди стейкхолдеров?
JuniorТеорияОчень частоКакие виды требований вы знаете и чем они различаются?
Какие виды требований вы знаете и чем они различаются?
Бизнес-требования (БТ) — верхнеуровневые цели и рамки, которые нужны заказчику и обосновывают проект. Функциональные требования (ФТ) описывают, что система должна делать — её функционал. Нефункциональные (НФТ) описывают, как она должна работать — её свойства (производительность, безопасность). Пользовательские требования описывают цели, которых пользователь должен достигать с продуктом.
Типичные ошибки
- ✗Путать функциональные (что система делает) с нефункциональными (насколько хорошо)
- ✗Считать бизнес-требования низкоуровневой деталью, а не рамками и целями
- ✗Игнорировать пользовательские требования как отдельный уровень намерения
Уточняющие вопросы
- →Приведите пример каждого типа требования для интернет-магазина.
- →Чем бизнес-требование отличается от функционального?
MiddleТеорияОчень частоКакие методики сбора требований вы знаете и как меняется подход для внутреннего и внешнего заказчика?
Какие методики сбора требований вы знаете и как меняется подход для внутреннего и внешнего заказчика?
Базовые методики выявления — интервьюирование стейкхолдеров, анкетирование/опросы и анализ входных документов; начинают с выявления стейкхолдеров и источников. С внешним заказчиком (проект или кастомизация продукта) общение формальное и привязано к договору; с внутренним — более прямое и итеративное. Набор методик выбирается по контексту, а не применяется вслепую.
Типичные ошибки
- ✗Называть только интервью, забывая анализ документов или анкетирование
- ✗Считать, что подход одинаков для внутреннего и внешнего заказчика
- ✗Пропускать выявление стейкхолдеров перед сбором требований
Уточняющие вопросы
- →Когда анкетирование лучше интервью?
- →Чем сбор требований для внутреннего заказчика отличается от проекта для внешнего?
JuniorТеорияЧастоКак вы готовитесь к интервью по сбору требований и что делаете с записями после?
Как вы готовитесь к интервью по сбору требований и что делаете с записями после?
До: изучите домен и существующие документы, узнайте, кого интервьюируете и его цели, и подготовьте план открытых вопросов от общего к частному. После оперативно структурируйте записи в черновые требования, отправьте письменное резюме на подтверждение интервьюируемому и зафиксируйте оставшиеся открытые вопросы.
Типичные ошибки
- ✗Приходить без плана и изучения домена
- ✗Оставлять записи сырыми и не подтверждать их у интервьюируемого
- ✗Откладывать обработку, пока детали не забудутся
Уточняющие вопросы
- →Зачем отправлять письменное резюме интервьюируемому после встречи?
- →Как построить план вопросов от общего к частному?
JuniorТеорияЧастоПревратите «система должна быть быстрой» в проверяемое нефункциональное требование — что добавите?
Превратите «система должна быть быстрой» в проверяемое нефункциональное требование — что добавите?
«Быстро» непроверяемо — добавляют метрику, целевое значение, условия нагрузки и перцентиль. Например: «95% поисков по каталогу отвечают быстрее 300 мс при 1000 одновременных пользователей». Указание метрики, порога и условий измерения делает требование проверяемым по критерию «прошло/не прошло».
Типичные ошибки
- ✗Переписывать «быстро» более сильными прилагательными вместо метрики
- ✗Давать порог, но без условий нагрузки или перцентиля
- ✗Считать скорость функциональным (функции) требованием, а не нефункциональным
Уточняющие вопросы
- →Почему перцентиль лучше среднего для цели по времени отклика?
- →Какие условия нагрузки должны сопровождать цель по производительности?
JuniorТеорияЧастоЧем верификация требования отличается от валидации и кто выполняет каждую?
Чем верификация требования отличается от валидации и кто выполняет каждую?
Верификация отвечает на «сделали ли правильно?» — проверку требования по критериям качества силами аналитика и команды на ревью. Валидация отвечает на «то ли сделали?» — проверку требования на соответствие реальной бизнес-потребности, которую на готовом результате подтверждают заказчик и пользователи.
Типичные ошибки
- ✗Менять их местами — считать верификацию проверкой бизнес-потребности
- ✗Считать, что обе делает только QA, без роли аналитика и заказчика
- ✗Думать, что сами требования нельзя верифицировать, только код
Уточняющие вопросы
- →Приведите пример требования, прошедшего верификацию, но провалившего валидацию.
- →Кто подписывает валидацию и против какого артефакта?
MiddleТеорияЧастоЧто такое бизнес-правила, почему их документируют отдельно от функциональных требований и где они живут?
Что такое бизнес-правила, почему их документируют отдельно от функциональных требований и где они живут?
Бизнес-правила — политики, которые бизнес соблюдает независимо от любой системы. Их документируют отдельно от функциональных требований, потому что одно правило управляет многими фичами и меняется по своему графику. Живут в каталоге правил, ссылаются по ID.
Типичные ошибки
- ✗Считать бизнес-правило тем же, что функциональное требование
- ✗Встраивать правило внутрь одной фичи вместо общего каталога
- ✗Считать, что правила принадлежат разработчикам, а не бизнесу
Уточняющие вопросы
- →Как ссылка на правило по ID помогает, когда правило меняется?
- →Когда бизнес-правила стоит вынести в отдельный движок правил?
MiddleТеорияЧастоКак вы управляете изменением требований, пришедшим после старта спринта?
Как вы управляете изменением требований, пришедшим после старта спринта?
Проводят через управление изменениями, а не тихой правкой — регистрируют запрос на изменение, делают анализ влияния на объём и сроки, затем несут владельцу продукта или совету по изменениям. Если принято — идёт в бэклог на будущий спринт; текущий спринт защищён. Каждый шаг фиксируется.
Типичные ошибки
- ✗Впихивать изменение в текущий спринт без анализа влияния
- ✗Пропускать запись, из-за чего изменение нельзя отследить
- ✗Позволять одному разработчику принять изменение без совета или владельца продукта
Уточняющие вопросы
- →Что оценивает анализ влияния до принятия изменения?
- →Чем защита спринта отличается от отказа от изменения?
MiddleТеорияЧастоКакой жизненный цикл проходит требование от бизнес-задачи до проверки реализации?
Какой жизненный цикл проходит требование от бизнес-задачи до проверки реализации?
Требование выявляется из бизнес-потребности, анализируется и декомпозируется, формализуется и проходит ревью, затем реализуется и проверяется. Сами требования тестируются послойно: аналитик сверяет их с критериями, команда — на понимание, QA — по сценариям.
Типичные ошибки
- ✗Пропускать анализ/декомпозицию между приёмом и реализацией
- ✗Считать, что требования нельзя тестировать — только код
- ✗Сводить проверку к QA, опуская ревью аналитиком и командой
Уточняющие вопросы
- →Как тестировщик проверяет само требование, а не код?
- →Где в цикле требование может «застрять» дольше всего и почему?
MiddleТеорияЧастоКакие нефункциональные требования вам приходилось выставлять?
Какие нефункциональные требования вам приходилось выставлять?
Нефункциональные требования описывают, как система ведёт себя, а не что делает: доступность и время отклика, надёжность, безопасность, производительность, масштабируемость. Сюда же входят требования к дизайну, легал и комплаенс. Каждое должно быть измеримым.
Типичные ошибки
- ✗Перечислять функции (функциональные) вместо свойств (нефункциональные)
- ✗Заявлять НФТ без измеримой цели, так что его нельзя проверить
- ✗Забывать про легал/комплаенс-ограничения как нефункциональные требования
Уточняющие вопросы
- →Как сделать требование к производительности измеримым?
- →Чем доступность отличается от надёжности?
MiddleТеорияЧастоПо каким критериям качества вы оцениваете требование?
По каким критериям качества вы оцениваете требование?
Хорошее требование корректно, недвусмысленно (читается единственным образом), полно и непротиворечиво с остальными. Оно упорядочено по важности и стабильности, проверяемо (можно протестировать), модифицируемо и трассируемо (связано с источником и с дизайном/тестами).
Типичные ошибки
- ✗Называть только полноту, забывая проверяемость или трассируемость
- ✗Путать недвусмысленность с просто детальностью или длиной
- ✗Считать приоритизацию и модифицируемость вне рамок качества требования
Уточняющие вопросы
- →Как сделать неоднозначное требование проверяемым?
- →Зачем требованию нужна трассируемость?
MiddleТеорияЧастоЧто такое трассируемость требований, что входит в матрицу трассируемости и что ломается без неё?
Что такое трассируемость требований, что входит в матрицу трассируемости и что ломается без неё?
Трассируемость — возможность проследить требование вперёд и назад — от бизнес-источника через дизайн и код к тестам. Матрица связывает ID каждого требования с источником, дизайном и тест-кейсами. Без неё нельзя оценить влияние изменения, доказать покрытие тестами и найти требования-сироты.
Типичные ошибки
- ✗Трассировать только вперёд к коду, не назад к источнику и не к тестам
- ✗Считать, что без матрицы ничего не ломается — теряя оценку влияния изменений
- ✗Путать трассируемость с учётом времени или задач
Уточняющие вопросы
- →Как матрица трассируемости ускоряет анализ влияния изменения?
- →Что такое требование-сирота и как матрица его выявляет?
MiddleТеорияЧастоЧто такое карта пользовательских историй и что она даёт сверх плоского бэклога?
Что такое карта пользовательских историй и что она даёт сверх плоского бэклога?
Карта пользовательских историй раскладывает истории в двух измерениях — горизонтальный костяк действий пользователя в порядке процесса, а под каждым истории по приоритету. Она показывает сквозной путь, который плоский бэклог скрывает, и позволяет нарезать MVP поперёк всех действий, а не как начало списка.
Типичные ошибки
- ✗Видеть в ней пересортированный плоский бэклог без второго измерения
- ✗Упускать горизонтальный костяк действий, показывающий путь пользователя
- ✗Считать, что MVP режут с начала списка, а не поперёк действий
Уточняющие вопросы
- →Как горизонтальный костяк соотносится с рабочим процессом пользователя?
- →Как вырезать релиз «скелет» из карты историй?
SeniorДизайнЧастоДва старших стейкхолдера дают вам прямо противоречащие требования к одному экрану: глава продаж хочет сохранять любой лид даже с пустыми обязательными полями, чтобы ничего не терять, а глава комплаенса хочет, чтобы форма жёстко блокировала отправку, пока все обязательные поля не проверены. Оба непреклонны, экран уходит в следующий спринт, и молчаливый выбор одного заставит другого почувствовать себя продавленным. Опишите по шагам, как вы разрешаете конфликт — как выносите его наружу, чьи цели и ограничения раскапываете, как приводите их к единому согласованному решению, какие варианты можете предложить и что фиксируете, чтобы разрешение и его обоснование остались трассируемыми.
Два старших стейкхолдера дают вам прямо противоречащие требования к одному экрану: глава продаж хочет сохранять любой лид даже с пустыми обязательными полями, чтобы ничего не терять, а глава комплаенса хочет, чтобы форма жёстко блокировала отправку, пока все обязательные поля не проверены. Оба непреклонны, экран уходит в следующий спринт, и молчаливый выбор одного заставит другого почувствовать себя продавленным. Опишите по шагам, как вы разрешаете конфликт — как выносите его наружу, чьи цели и ограничения раскапываете, как приводите их к единому согласованному решению, какие варианты можете предложить и что фиксируете, чтобы разрешение и его обоснование остались трассируемыми.
Делают конфликт явным — обе позиции как заявлено несовместимы. Находят реальную цель за каждой, сводят стейкхолдеров вместе владеть компромиссом и предлагают примиряющий вариант. Эскалируют, только если не договорятся, затем фиксируют решение и обоснование.
Типичные ошибки
- ✗Молча выбирать более старшего стейкхолдера, не вынося конфликт наружу
- ✗Пытаться построить оба противоречащих поведения вместо примирения
- ✗Разрешить конфликт, но не зафиксировать решение, обоснование и утверждение
Уточняющие вопросы
- →Как раскопать реальную цель за каждой заявленной позицией?
- →Когда стоит эскалировать, а не продолжать вести к консенсусу?
MiddleТеорияИногдаПо какой модели качества классифицируете нефункциональные требования — FURPS+ или ISO 25010 — и дайте измеримое НФТ на категорию?
По какой модели качества классифицируете нефункциональные требования — FURPS+ или ISO 25010 — и дайте измеримое НФТ на категорию?
Классифицирую по стандартной модели качества — FURPS+ (Functionality, Usability, Reliability, Performance, Supportability) или характеристикам ISO 25010. Каждой категории — одно измеримое НФТ: Performance — «95-й перцентиль до 300 мс», Reliability — «аптайм ≥ 99,9%».
Типичные ошибки
- ✗Называть модель, но давать неизмеримые цели из одних прилагательных
- ✗Путать категории модели качества с функциональными фичами
- ✗Не использовать классификацию, из-за чего целые категории НФТ забывают
Уточняющие вопросы
- →Что добавляет «+» в FURPS+ сверх пяти букв?
- →Чем ISO 25010 отличается от более старой модели FURPS?
MiddleТеорияИногдаЧто такое переходные требования и на каких проектах они появляются?
Что такое переходные требования и на каких проектах они появляются?
Переходные требования — временные возможности для перехода со старой системы на новую: миграция данных, параллельная работа, cutover с откатом. Они не входят в целевую систему и отпадают после переключения, появляясь на проектах миграции и замены legacy.
Типичные ошибки
- ✗Путать переходные (для перехода) требования с функциями целевой системы
- ✗Забывать миграцию данных, обучение и cutover как переходные требования
- ✗Считать, что они остаются после переключения, а не отпадают
Уточняющие вопросы
- →Почему параллельная работа старой и новой системы — переходное требование?
- →Как переходные требования влияют на план переключения и отката?
SeniorДизайнИногдаВам достаётся 40-страничное legacy ТЗ на систему, которая работает в проде годами. Исходные аналитики и стейкхолдеры ушли, документ мешает устаревшие и всё ещё действующие правила, и никто не помнит, почему многие пункты гласят то, что гласят. Запросы на изменение продолжают приходить, но безопасно менять что-либо нельзя, не зная реального текущего поведения. Доверять ТЗ на слово нельзя, и переписать его с нуля вслепую тоже нельзя. Опишите по шагам, как вы восстанавливаете текущую картину AS-IS и валидируете её — как раскапываете документ, работающую систему и данные; с кем говорите; как отделяете всё ещё истинное от устаревшего; и как подтверждаете, что восстановленная модель действительно соответствует реальности до предложения любых изменений.
Вам достаётся 40-страничное legacy ТЗ на систему, которая работает в проде годами. Исходные аналитики и стейкхолдеры ушли, документ мешает устаревшие и всё ещё действующие правила, и никто не помнит, почему многие пункты гласят то, что гласят. Запросы на изменение продолжают приходить, но безопасно менять что-либо нельзя, не зная реального текущего поведения. Доверять ТЗ на слово нельзя, и переписать его с нуля вслепую тоже нельзя. Опишите по шагам, как вы восстанавливаете текущую картину AS-IS и валидируете её — как раскапываете документ, работающую систему и данные; с кем говорите; как отделяете всё ещё истинное от устаревшего; и как подтверждаете, что восстановленная модель действительно соответствует реальности до предложения любых изменений.
Не доверяют ТЗ на слово. Восстанавливают AS-IS из источников — документ, работающая система, логи, данные и интервью с пользователями. При расхождении побеждает система. Каждый пункт помечают валидным, устаревшим или неизвестным и валидируют, проигрывая сценарии.
Типичные ошибки
- ✗Доверять legacy ТЗ на слово как всё ещё валидному
- ✗Переписывать с нуля, не изучив реальное поведение
- ✗Восстанавливать по памяти одного человека без перекрёстной сверки
Уточняющие вопросы
- →Почему при расхождении источников обычно побеждает работающая система?
- →Как валидировать, что восстановленное AS-IS соответствует реальности?
SeniorДизайнИногдаЗаказчик формулирует задачу одним предложением — «просто сделайте как у конкурента» — показывая на известный продукт и больше ничего. Ни списка функций, ни приоритетов, ни бюджета сверх «то же, но наше». У конкурента сотни функций, построенных за годы, большинство из которых этому заказчику не нужны и не по карману, а «как у них» скрывает совсем разные невысказанные ожидания. Скопировать всё приложение нельзя, и отбиться фразой «это не требование» тоже нельзя. Опишите по шагам, как вы превращаете эту размытую отсылку в структурированный приоритизированный набор требований — что делаете с конкурентом как образцом, какие вопросы задаёте, как отделяете реальную бизнес-цель от поверхностных функций и как приходите к чему-то реализуемому и согласованному.
Заказчик формулирует задачу одним предложением — «просто сделайте как у конкурента» — показывая на известный продукт и больше ничего. Ни списка функций, ни приоритетов, ни бюджета сверх «то же, но наше». У конкурента сотни функций, построенных за годы, большинство из которых этому заказчику не нужны и не по карману, а «как у них» скрывает совсем разные невысказанные ожидания. Скопировать всё приложение нельзя, и отбиться фразой «это не требование» тоже нельзя. Опишите по шагам, как вы превращаете эту размытую отсылку в структурированный приоритизированный набор требований — что делаете с конкурентом как образцом, какие вопросы задаёте, как отделяете реальную бизнес-цель от поверхностных функций и как приходите к чему-то реализуемому и согласованному.
Относятся к конкуренту как к образцу, а не спецификации. Сначала находят реальную бизнес-цель за «как у них». Делают разбор функций, затем вместе с заказчиком отделяют настоящие must-have от просто замеченного. Согласованное превращают в приоритизированные требования и MVP.
Типичные ошибки
- ✗Клонировать конкурента функция в функцию вместо поиска цели
- ✗Отказываться от размытой просьбы вместо добычи из неё реальной потребности
- ✗Пропускать приоритизацию и MVP, считая объём безграничным
Уточняющие вопросы
- →Как отделить must-have от функции, которую заказчик просто заметил?
- →Как разбор конкурента питает вашу приоритизацию?
SeniorТеорияИногдаКакие артефакты должна поддерживать система управления требованиями?
Какие артефакты должна поддерживать система управления требованиями?
Система управления требованиями ведёт: стабильный идентификатор требования; атрибуты (статус, приоритет, источник, версия); отчёты по набору; срезы по релизу или компоненту; матрицу трассировки, связывающую требования с источниками, дизайном и тестами; и шаблон единой структуры.
Типичные ошибки
- ✗Называть только хранилище документов, опуская идентификаторы или матрицу трассировки
- ✗Забывать атрибуты требования (статус, приоритет, версия)
- ✗Считать срезы/отчёты вне рамок управления требованиями
Уточняющие вопросы
- →Что именно связывает матрица трассировки и зачем?
- →Какие атрибуты требования вы бы сделали обязательными?
SeniorДизайнИногдаВ середине спринта ключевой стейкхолдер требует переделать фичу, которую команда уже доделала и влила в этом же спринте, чтобы она вела себя иначе. До конца три дня, фича покрыта тестами и показана внутри, а две другие истории в работе зависят от её текущего поведения. Стейкхолдер настаивает, что это срочно и «очевидно так и должно было быть с самого начала». Вы не можете молча впитать переделку, не рискуя целью спринта, и не можете просто отказать ключевому стейкхолдеру. Разберите по шагам, что вы делаете — как обрабатываете запрос, какой анализ проводите, кого вовлекаете, как решаете, войдёт ли это в текущий спринт или в следующий, и что фиксируете, чтобы решение и его влияние остались трассируемыми.
В середине спринта ключевой стейкхолдер требует переделать фичу, которую команда уже доделала и влила в этом же спринте, чтобы она вела себя иначе. До конца три дня, фича покрыта тестами и показана внутри, а две другие истории в работе зависят от её текущего поведения. Стейкхолдер настаивает, что это срочно и «очевидно так и должно было быть с самого начала». Вы не можете молча впитать переделку, не рискуя целью спринта, и не можете просто отказать ключевому стейкхолдеру. Разберите по шагам, что вы делаете — как обрабатываете запрос, какой анализ проводите, кого вовлекаете, как решаете, войдёт ли это в текущий спринт или в следующий, и что фиксируете, чтобы решение и его влияние остались трассируемыми.
Не впитывать молча и не отказывать наотрез. Регистрируют запрос на изменение, затем делают анализ влияния — переделка, две зависимые истории и цель спринта. Несут владельцу продукта и стейкхолдеру и решают по приоритету: обычно в следующий спринт. Фиксируют решение.
Типичные ошибки
- ✗Молча впитывать переделку и срывать цель спринта
- ✗Отказывать ключевому стейкхолдеру наотрез вместо управления изменениями
- ✗Решать без анализа влияния на две зависимые истории
Уточняющие вопросы
- →Как зависимость двух историй в работе меняет ваш анализ?
- →Когда правильнее пересогласовать текущий спринт, а не отложить?
SeniorДизайнРедкоЗаказчик говорит вам: «Мне нужна оцифрованная телефонная книга». Это всё, что есть на входе. Проведите весь процесс как системный аналитик: как вы соберёте требования на интервью (интервьюер играет заказчика), обработаете их, смоделируете процесс в BPMN, выделите сущности и построите ER-модель, и проведёте требования по жизненному циклу вплоть до проверки корректности реализации. Опишите шаги и какие точки взаимодействия вам понадобятся.
Заказчик говорит вам: «Мне нужна оцифрованная телефонная книга». Это всё, что есть на входе. Проведите весь процесс как системный аналитик: как вы соберёте требования на интервью (интервьюер играет заказчика), обработаете их, смоделируете процесс в BPMN, выделите сущности и построите ER-модель, и проведёте требования по жизненному циклу вплоть до проверки корректности реализации. Опишите шаги и какие точки взаимодействия вам понадобятся.
Проинтервьюируйте заказчика, уточняя поля, поиск, кто редактирует и масштаб. Обработайте ответы в структурированные требования с проверкой качества. Смоделируйте процесс to-be в BPMN и постройте ER-модель с ключами. Затем проведите требование до приёмочного тестирования с трассируемостью.
Типичные ошибки
- ✗Прыгать к моделированию или коду до сбора требований и уточнения рамок
- ✗Пропускать выделение сущностей/ER и хранить всё в одной плоской таблице
- ✗Заканчивать на разработке без тестирования требований и трассируемости
Уточняющие вопросы
- →Какие сущности и связи вы заложите в ER-модель телефонной книги?
- →Как вы проверите, что реализация соответствует исходному требованию?
