Очень удобно смотреть group by фича, требование

Или "Применение алгоритмов шифрования должно ограничиваться корпоративными стандартами компании Х".

Поэтому придётся либо ОЧЕНЬ сложную систему трассировок строить между issue, либо вести требования отдельно от задач.

Первый вариант сложен тем, что придётся кастомить типы отношений задач в JIRA.

Плюс разбираться с отчётом на основании этой классификации по "Как мне посмотреть, какие программные компоненты задеты новым требованием".

Александр, запросом берём трудозатраты всех подзадач нфт, и показываем чего стоит реализация этого нфт. Если накоплена статистика по поддержке, то так же запросом выбираем трудощатраты

И дальше обосновываем трудоемкость на реализацию нфт - сравнивая сколько тратится в моменте

В моём кейсе не было про трудозатраты.

Требования это что то, что стоит каких то задач

требования - это иерархия табличек, грубо говоря. Если навесить UUID на них, то можно ссылаться по URI на любое требование
если запихнуть иерархию в Git (или нечто подобное, не обязательно на уровне файловой системы), то получаем версионирование и возможность ссылки на конкретную версию или семейство версий (если не включаем коммит или тэг, значит ссылка на последнюю версию)
трассировка требований ко всем артефактам - это отдельная задача. Важна природа артефакта. Для кода это может быть коммент + часть commit message-а, когда коммитим в репозиторий и так далее

Идея для стартапа.

это здравый смысл и некоторый опыт реализации в таком стиле :)

Если реализация требования бесплатна, то отдельное требование в фиче можно не заводить, но если для его реализации нужно что-то сделать - то в жире стоит и оценить подзадачи

Артём, здесь вопрос о том, что есть разные процессы разработки, и разные школы управления требованиями.

В одном случае мы считаем (сильно упрощаю сейчас), что нам достаточно трекера и бэклога, и мы можем так инкрементно фигачить.

В других случаях есть постулат, что требования не равны сумме эпиков (сильно срезаю углы).

И начинаем тогда городить отдельные views, делать PBS и прочие странные штуки. Вот для  этого случая поля Desc в задаче Jira обычно не хватает.

Ещё раз вопрос. На основании чего делаете оценку ?

Мнения эксперта, с последующим вычислением среднего отклонения по типу задач

Вот у вас есть новый продукт. Надо сделать первичную декомпозицию работ. На основнаии чего?

Второй вопрос. На основании чего делать оценку влияния внесения изменений в потребности на процесс разработки в подходе с задачам?

Я говорю, что так можно, но в случае JIRA - очень сложно.

Декомпозиции)) как фт так и нфт. Нфт арх декомпозирует дальше