Эд,

А как твои утверждения коррелируют с определение ГОСТ:
функция автоматизированной системы; функция АС: Совокупность действий АС, направленная на достижение определенной цели

Эд,

А как твои утверждения коррелируют с определение ГОСТ:
функция автоматизированной системы; функция АС: Совокупность действий АС, направленная на достижение определенной цели

А я и не пытаюсь искать корреляции, я просто рассуждаю в слух, словомудрствую так скать.

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

Сейчас в бизнесе мы видим некое торжество процессного подхода.

Недостатки фунционального подхода известны, они проявляются и в функциональной оргструктуре. Основной - конфликт интересов-целей.

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

Вот мне и кажется (крещусь часто), что Use case - это процесс, т.е. некий поток событий продвигающий субъекта к цели (или не продвигающий - это уж как предусмотрим). Причем ясно что движение к цели может быть разнопутевым, но все равно эти пути много имеют общего.

Функция же она не подчинена синтетической задачи достижения цели, она просто исполняет свою функцию.

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

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

В какой-то мере я с тобой согласен. ВИ естественно облегчает процесс формирования требований:
1. Направлен на достижение цели конечного ПОЛЬЗОВАТЕЛЯ
2. Представляет Тр в виде сценария, что облегчает его понимание и воспринимается как нечто целое, а не обрывок.

Строго говоря, если брать определение функции по ГОСТ -- то оно по сути гласит, что ф-я это совокупность действий  людей, железа и ПО направленная на достижение определенной цели. И ничего в данном определении не говорится про то, ЧЬЯ это цель! Это отдается на откуп конкретного ТЗ. А с юзкейсом все понятно -- это цель Actor-а. Определение по ГОСТ не дает возможности говорить об эквивалентности функции АС и юзкейса. Но зато вполне позволяет использовать в документах ГОСТ юзкейсы :-) -- т.к. на основании определений можно утверждать, что юзкейсы а) направлены на достижение определенных целей -- более того, мы явно идентифицируем эти цели, б) описывают ту самую "совокупность действий". Это становится некой доказательной базой в случае, если на стороне заказчика сидит человек, утверждающий что он знает ГОСТы ... а у нас есть желание писать юзкейсы. Но это не скорее всего не будет работать, если у ГОСТовцев есть собственные традиции в описании требований по ГОСТ.