Кажется ты немного не понял кейс с безопасностью:

я как начальник отдела безопасности банка  в соответствии с документами такими-то хочу, чтобы при получении доступа к своим данным пользователи проходили аутентификацию логином и паролем. Это надо для того, чтобы бла-бла-бла...

Короче пользователь не единственный тут. Это ошибка определения стейкхолдера/интересанта

Аналитик живет в мире людей, играющих роли и их интересов.
Если value непонятно, как раз тут важно узнать, а кому это надо? А может не надо? А можно по-другому? А в каком виде?

А так ты просто пропустил отдел ИБ и это средняя по тяжести ошибка аналитика.

Потом они прибегут с воплями и придется переделывать.

Видишь? Не просто так все это придумали, просто надо уметь это готовить.

У Левенчука в курсе на курсере и книге это подробно описано

+ я как клиент хочу, чтобы мои данные не утекли, использованы и тд
И вот это порождает кучу сторей интересов других людей, которые реализуют самую простую сторю для пользователя.
Для него она проста и как-бы работает по-умолчанию.

Я же исхожу вопрос кейса выше, там явно перекладывают на клиента (классический neo продукт менеджер), так как в их парадигме некто из безопасности не может выступать. Продукт у них для конечно клиента, т.е. для потребителя их банковской услуги.

Это мы еще не зашли на метрики, в такой схеме считают что некто продукт обеспечивает поток например кредитов, в денежном выражении. И это и есть единная метрика его продукта. Которую он сам установит на фазе предпроекта (или discovery)

Я как клиент даже думать не хочу. Т.е. выше то согласен, там парадигма. А тут это не мои проблемы должны быть. Для этого я государству налоги плачу. Что бы не заявлять, что я как клиент не хочу что бы мои данные...

У тебя простая сторя клиента про безопасность  порождает это все. Value со стороны клиента понятно.

Но есть интересы компании и отдельных ролей внутри. Без них тоже никак.

Для тебя иб - тоже интересант и заказчик, а также клиент и пользователь будущей системы.

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

Обычно их списывают в constraints, в классике вообще отдельная глава про безопасность (которую все игнонируют) и закидывают в функциональные требования.

Сторя это просто фрейм над требованиями и его можно подстраивать под себя, компанию И так далее

Классика существует только в вакууме. Тут еще можно аджайл вспомнить как пример.

Так я понимаю, сложность что рынок, русскоязычный не "дозрел" что ли, я вот пообщался с фин тех и пром наймом например, вот все примерно то, что я говорю. И они в это верят, и транслируют.

Там вообще все может быть проще. Двухэтапная аутентификация может быть бизнес-правилом, налагаемым регулятором. И дальше это превращается в нефункциональное требования по безопасности - аутентификация при помощи логина и смс.

А ты хоть один пример такого требования регулятора можешь показать?

Профили защиты фстэк, требования фсб, стандарт банка россии по ИБ

Не источник, а пример)

Конкретно по атуентификации или вообще? По аутентифкации долго искать

Угу именно про двухэтапную аутентификацию

А, ну в принципе как я и думал у Банка России есть. Положение Банка России от 4 июня 2020 г. № 719-П . 2.9. Технологические меры, указанные в пункте 2.8 настоящего Положения, должны обеспечивать реализацию: механизмов двухфакторной аутентификации клиента оператора по переводу денежных средств при совершении им действий в целях осуществления переводов денежных средств;