Как описываются технические и бизнесовые требования и в каком формате
Что проверяют
Различаете ли вы уровни требований и умеете ли подбирать формат под читателя: бизнесу, разработке и тестированию нужны разные документы. Следом обычно просят показать на своём проекте, как одно бизнес-требование превращалось в задачи для разработки.
Как отвечать
Опирайтесь на уровни требований и формат для каждого:
- бизнес-требования: зачем проект и как понять, что он удался. Цель, измеримый результат, границы. Формат: концепция или BRD на несколько страниц, без описания экранов;
- пользовательские: что человек делает с системой. User story с критериями приёмки, часто в виде Given/When/Then, или use case с основным и альтернативными сценариями, когда ветвлений много;
- функциональные: как ведёт себя система. Спецификация (SRS, а в госсекторе и крупных компаниях ТЗ по ГОСТ 34.602-2020), процессы в BPMN, диаграммы последовательности UML, контракт API в OpenAPI, модель данных;
- нефункциональные: производительность, доступность, безопасность, и обязательно с числами. Не «быстро», а «ответ за 300 мс для 95% запросов»;
- ограничения: стек, интеграции, регуляторика, например обработка персональных данных по 152-ФЗ.
Потом расскажите, как это жило у вас: где хранилось (Confluence, Jira или docs-as-code в Markdown рядом с кодом), кто согласовывал, как бизнес-требование трассировалось до задач и тест-кейсов.
Это вопрос про ваш опыт, так что нужен свой пример: какой проект, какой формат выбрали и почему, что пошло не так. Если вы работали только с user story, так и скажите, а затем покажите, что понимаете, когда их мало и нужна спецификация: сложные расчёты, интеграции, требования регулятора.
Где спотыкаются
Отвечают списком инструментов. Jira и Confluence не формат, интервьюер ждёт, как устроен сам документ и для кого он написан.
Пишут нефункциональные требования без чисел. «Система должна быть надёжной» проверить нельзя, значит, это не требование.
Считают user story полной спецификацией. История фиксирует потребность, а поля, валидации, ошибки и интеграции без отдельного описания останутся на усмотрение разработчика.