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

Выяснилось много интересного. В том числе и то, куда все же класть варианты использования в ТЗ по ГОСТ 34.602

Для того, чтобы это выяснить, смотрим ГОСТ 34.003-90 (Автоматизированные системы. Термины и определения).

Три определения:

1.1 автоматизированная система; AC: Система, состоящая из персонала и комплекса средств автоматизации его деятельности, реализующая информационную технологию выполнения установленных функций.

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

1.4 задача автоматизированной системы; задача АС: Функция или часть функции АС, представляющая собой формализованную совокупность автоматических действий, выполнение которых приводит к результату заданного вида

Говорят нам о том, что
1. Система в ГОСТ является организационно-технической (люди + техника)
2. Функция в ГОСТ - это действия, направленные к (ВНИМАНИЕ!) цели, то есть могут быть описаны, в частности вариантом использования.
3. Задача - это набор действий, совершаемых автоматически, то есть функция, выполняемая техникой.

Определение из RUP толкует функциональное требование так:

Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration

В результате получаем такое отображение ГОСТ -> RUP (и другие методологии)
функция -> вариант использование
задача -> функциональное требование

Молодец, тонкое замечание.

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

задача - часть функции системы, выполняема по большей части автоматически, в рамках исполнения функции или без оной? Например обновление БД в 00 часов каждого дня. Хотя тут может в качестве пользователя выступить таймер и взаимодействие тоже налицо - так что и ВИ прокатит

Может разберем примерчик?

Да и перевод
Functional requirements specify actions that a system must be able to perform, without taking physical constraints into consideration

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

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

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

Хотя вроде не так.
Общая функция подсистемы или скорее всей системы:
Загрузка данных (состоит):
  Загрузка блока данных (сценарий)
      требование 1, требование 2 и т.д. как элементарная операция или набор все-таки элементарных опреаций?
  Получить отчет о загрузке
  Отправить отчет о загрузке
  Принять блок данных

правда чем отличается REQ10 от ВИ C013

И все таки какова цель оператора? Судя по диаграмме, он может загрузить блок данных и тут же получить отчет, но может получить отчет совершенно независимо?

Для того, чтобы это выяснить, смотрим ГОСТ 34.003-90 (Автоматизированные системы. Термины и определения).
Три определения:
Говорят нам о том, что
1. Система в ГОСТ является организационно-технической (люди + техника)
2. Функция в ГОСТ - это действия, направленные к (ВНИМАНИЕ!) цели, то есть могут быть описаны, в частности вариантом использования.
3. Задача - это набор действий, совершаемых автоматически, то есть функция, выполняемая техникой.

UC это конкретная цель пользователя по отношению к системе. В ГОСТ нет явного указания что это за "определенная цель" (функция АС: Совокупность действий АС, направленная на достижение определенной цели), не понятно кем определенной и чьей именно цели.
Далее, коль скоро функция = "Совокупность действий АС направленная на достижение определенной цели", а  АС = "Система, состоящая из персонала и комплекса средств автоматизации ...", путем подстановки получаем, что функция АС есть "Совокупность действий Системы, состоящей из персонала и комплекса средств автоматизации, направленная на достижение определенной цели (прим. не понятно ЧЬЕЙ именно цели)"
Т.е. АС ВКЛЮЧАЕТ в себя в т.ч. и Экторов (!) и следовательно цели уже получаются не совсем Экторов по отношению к scope, а по сути "Экторов + средств автоматизации". В то же время мы знаем, что Эктор в том же RUP, это внешняя по отношению к scope сущность, цель которой рассматривается отдельно. Отсюда следует сомнение в эквивалентности и прямом мэппинге понятий "Функция = ВИ"

Не стоит забывать про ключевое слово СИСТЕМА. ГОСТ 34 относится больше к системной инженерии, чем к программной инженерии.

....
2. Могут ли быть действия без инициатора?
Ответив НЕТ
...

Для ф-ции инициатором м.б. сама система или другая ф-я, для ВИ же только актер.

ура, опять пошли разговоры за герменевтику )

Сергей,

А ты видел презентацию Юры, когда он описывал что куда из РУП можно всунуть в ГОСТ?

По идеи ГОСТ ф-я - это часть ВИ, т.е. один или несколько пунктов сценария ВИ.
Т.е. ВИ - это некая функциональность. И ВИ может служить для обобщения ГОСТ ф-ций, т.е. м.б. неким подразделом в ГОСТ ТЗ. Другое дело как этот подраздел описывать? В виде сценария или в виде требований/ф-ций? Если в виде сценария, то не понятно что делать с пред и пост условиями?! Да и вообще это больше походит уже на натягивание непонятно чего на непонятно что.
Возможно, будет правильнее сделать так:
1. ВИ
2. Сценарий ВИ
3. Ф-ции Системы, кот. трассируются к ВИ или п. в сценарии ВИ.
1 и 3 записываем в ТЗ, 2 оставляем для себя.

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

ТЗ это фактически единственный документ, который читает Заказчик. Вы хотите, чтобы он был сильно недоволен?
Написано : ТЗ делать по 34му ГОСТу. Как все люди- словами описывать. В ТП же развлечетесь вставками UC. Я так делала. ТП заказчик все равно читает сквозь пальцы, понимая, что это уже "технологии". А ТЗ - это святое, русскими буквами понятные предложения.

Написано : ТЗ делать по 34му ГОСТу. Как все люди- словами описывать. В ТП же развлечетесь вставками UC.  А ТЗ - это святое, русскими буквами понятные предложения.

Уважаемая Анна Васильевна, а скажите мне, пожалуйста, как пишутся варианты использования? Не словами? А также, для чего пишутся варианты использования и как? Не пишет ли господин Коберн, что вариант использование ПИШЕТСЯ словами понятными для заказчика с использованием терминологии предметной области и избегания технических терминов, при этом форма ВИ определяется назначением документа. Разве неформальное описание ВИ, не может служить описанием функции, выполняемой АС? И разве связное описание не будет понятным заказчику?

другой вопрос - можно ли писать ВИ в ТЗ в какой-либо форме.

Как я полагаю дискуссия развертывается вокруг этого + вокруг того, как анализ требований ориентированный на ВИ приспособить к написанию ТЗ

Сергей,

То ли ты не слышишь, то ли не хочешь слышать, что мы с Юрой пытаемся до тебя донести.
Любой ВИ может считаться ГОСТ ф-цией, но не любая ГОСТ ф-я может считаться ВИ.
Что бы полностью описать ФТ к Системе, то нужно еще как минимум БПр не забыть. Куда ты их будешь сувать? А еще порой не достаточно описать шаги ВИ, нужна еще и детализация некоторых шагов ВИ.
Просто, когда ты так говоришь, то большая вероятность, что ВИ в конечном счете превратятся просто в ФТ или простые операции Системы (ф-ции).

В 34 ГОСТе нет ясной направлености на пользователя. Однако при описании функции АС их можно распределять по подсистемам. естественно подсистемы определяются с заказчиком(например подсистема кадровго утчеа, подсистема расчета и начисления з/п, подсистема учета успеваемости студентов и т.п.). Каждая подсистема может содержать набор выполняемых ею функций - достаточно высокоуровневых: ведение личной карточки сотрудника, оформление и учет кадровых приказов и т.п.
Очевидно, что ведение личной карточки сотрудников может состоять из некоторого набора сценариев. Стоит ли написать просто: Система должна обеспечивать упраление кадровыми данными сотрудника.
Или можно описать это более подробно в виде неформального описания вариантов использования?

Как вариант, предлагаю само ТЗ сделать как все (без вкропления инородных слов "вариант использования"). Все ВИ и их нужную детализацию вынести в Приложения. Другой вопрос, что объем ТЗ будет весьма велик и его, как следствие, заказчик может не дочитать.
И другой вопрос: а что тогда вставлять в ТП? =)

Вопрос Sunshine и другим:
Является ли вариант использование требованием (или набором требований)
или
это описание реализации требования (проектное решение)?