Матрица трассирования требований. Как мы делали mit den Jungs в банке. Задача - небольшое бэкенд-приложение, с помощью которого можно проверять дебетовые платежи на соответствие каким-то правилам. HealthCheck, если угодно. Правила можно устанавливать (менять, удалять), эти правила можно читать, и на соответствие этим правилам можно проверять дебетовые транзакции. У приложения 40+ потребителей. Организовали воркшоп со стейкхолдерами, собрали изначальный список требований, назвали их БТ. Свели в таблицу, разбили на близкие по смыслу и ценности функциональные блоки, описали как единый кусок, назвали фичами. Теперь есть 2 уровня: бессвязные БТ и Фичи. Фичи попилил на Пользовательские Истории (да-да, там нет пользователей - за них взяли приложения-потребители). Вы скажете: «Пользовательские истории - чепуха для эджайлистов-легковесов». Я скажу: описывайте критерии приёмки в Gherkin (Given - When - Then), и будет у вас одновременно и лист функциональных требований, и, как минимум, заготовки под сценарии тестирования (а если до вас кто-то ввёл язык домена, то можно и сразу писать в формате, подходящем для запуска в среде разработки). Мы вели таблицу, да. Было норм. Просто придумайте несложную идентификацию (BR, US, AC, TC). Бюрократического запроса не было, но чуваки на проекте сразу сказали, что типовая проблема на других проектах - в непонимании: «Кто?», «Что?», «На кой хрен?», «Почему мы делаем это снова?», «Почему отвалился автотест?». Соответственно, мы решали вопросы смысловой нагрузки функциональных блоков, ну и банальное «откуда ноги растут?». Нужна ли для этого таблица? На горизонте - нет. Чтобы научить людей вести структуру в Jira так, чтобы потом не было мучительно больно за бесцельно прожитые годы, - да, рабочий инструмент. Делайте гигиену, учитесь вести Jira - и не будет у вас никакой проблемы с лишней бюрократией. Вы каждый день по этой доске и так ходите.