ВИ - это пользовательские требования, как написано, например, у Вигерса.

ВИ - это пользовательские требования, как написано, например, у Вигерса.

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

Ты точно указываешь что ВИ - не проектное решение, так что по-моему ему места в техпроекте нет, в техпроекте должна присутствовать реализация ВИ

Вот еще для затравки ....ВИ -- это функциональные требования в контексте их использования

Юра, ты думаешь все это выпускают из виду?

Для построения функциональной иерархии мы берем иерархию вариантов использования
 и выкидываем все ручные шаги (действия людей), тогда остаются или декомпозируемые функции или атомарные шаги-задачи.
Проблема только в том, что один ВИ может включаться в несколько других, тогда или поднимаем его на уровень выше или произвольно включаем в одну из ветвей функциональной иерархии. Так как важен, в основном, только список задач (функциональных требований) с их подробным описанием.

это очень близко моему опыту:
функциональные требования к разрабатываемой системе уровня пользователей (использование системы)
- однозначно в ВИ,

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

собираю все строки сценариев, начинающиеся "Система(в ответ на пред-й шаг пользователя)...чего-то делает"

НО! Строю по ним ДРУГУЮ, логичную с т.зр. зависимостей функций, без учёта логики работы отдельных пользователей.

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

к примеру, один и тот же диалог просмотра данных по Клиету может использовать как Оператор контакт-центра,
так и Менеджер, изменяющий статус Клиента. Каждый -  в своих, совершенно разных, ВИ.

за выходные или на след неделе выложу соответствующее продолжение в тему об управлении требованиями.

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

к примеру, один и тот же диалог просмотра данных по Клиету может использовать как Оператор контакт-центра,
так и Менеджер, изменяющий статус Клиента. Каждый -  в своих, совершенно разных, ВИ.

А не легче тут выделить ВИ включения или расширения? И сосредоточится на детализации каких-то шагов ВИ? Зачем по 10 раз все переписывать?

А не легче тут выделить ВИ включения или расширения? И сосредоточится на детализации каких-то шагов ВИ? Зачем по 10 раз все переписывать?

не легче
Гуры настоятельно советуют НЕ прегружать ВИ глубокой детализацией.
кроме того - функциональная детализация мне видится принципиально отличной от концепции ВИ, а соответственно, и место ей в другом документе, с другой структурой.
мне очень понравился термин "ортогональность" понятий ВИ и функции в одной из тем на форуме.

не легче
Гуры настоятельно советуют НЕ прегружать ВИ глубокой детализацией.
кроме того - функциональная детализация мне видится принципиально отличной от концепции ВИ, а соответственно, и место ей в другом документе, с другой структурой.
мне очень понравился термин "ортогональность" понятий ВИ и функции в одной из тем на форуме.

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