С какими документами приходилось работать
Что проверяют
Различаете ли вы жанры аналитической документации и понимаете ли, кто читатель каждого документа. Аналитик, для которого всё это просто «документация», обычно пишет одно длинное описание, которое не читают ни разработка, ни заказчик.
Как отвечать
Пройдите по уровням, от бизнеса к разработке:
- уровень бизнеса: бизнес-требования, описание процесса «как есть» и «как будет», обоснование целесообразности;
- требования: спецификация, пользовательские истории с критериями приёмки, сценарии использования, нефункциональные требования;
- модели: BPMN для процесса, UML для последовательности и состояний, модель данных, схема интеграций;
- контракты: описание интерфейсов в OpenAPI, форматы сообщений, справочники кодов ошибок;
- сопровождение: матрица трассировки требований, реестр открытых вопросов, глоссарий, протоколы решений;
- для пользователя: инструкции, описание изменений в релизе, обучающие материалы.
Дальше про свою роль: что писали сами, что только согласовывали, где документ живёт и как поддерживается в актуальном состоянии. Назовите читателя: разработчику нужна однозначность, тестировщику критерии приёмки, заказчику соответствие его задаче. Один пример противоречия в требованиях и того, как вы его сняли, весит больше длинного перечня.
Где спотыкаются
Смешивают требование и решение. В спецификацию попадают выбор библиотеки и структура таблиц, а сама задача теряется, и потом любая правка реализации тянет за собой правку требований.
Не различают жанры. История без критериев приёмки уходит в разработку, и приёмка превращается в спор о том, что имелось в виду.
Рассказывают о документах без жизненного цикла. Документ, который никто не согласовывал и который устарел через спринт, это имитация опыта. Про версии, согласование и актуализацию стоит сказать самому.