Предположим, что я пишу техзадание на АИС. В процессе формирования ТЗ использую только MS Word и средство рисования uml-диаграмм (хотя, рисование, как я понимаю не обязательно, но желательно). При формировании ТЗ я разделяю данную систему на модули/подсистемы, отличающиеся своей функциональностью. Например: модуль цифровой подписи, модуль отчетности, модуль администрирования и т.п.
Таким образом, разбив концептуально целую систему на модули, я рисую ДВИ каждой подсистемы, описывая в спецификации то, как взаимодействуют с этой подсистемой пользователи + поведение самой подсистемы (алгоритмы работы - по сути те же UC, но ДЛ является сама подсистема).
Правильно ли я делаю?

А какие есть альтернативы такому подходу?
На мой взгляд такой подход выглядит вполне логично. Необходимость подготовки uml определяется кругом заинтересованных лиц, если все эти люди владеют uml, то, пожалуй, стоит потратить время на подготовку диаграмм, в противном случае подготовка uml-диаграмм может себя не оправдывать, как минимум ключевые заинтересованные лица должны владеть uml для работы с вашими диаграммами.

Павел,

В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.
Если что-то не ложится в ВИ, то это описывается просто доп функциональными требованиями.

В рамках ВИ одной подсистемы - остальные подсистемы будут ДЛ. По моему, ни чему не противоречит

В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.

Почему неправильно?

Павел,

В принципе правильно, но только использовать подсистемы в качестве ДЛ - это не правильно.

Смотрите, Александр, ведь ДЛ могут быть пользователи, внешние системы, часы (это по данным вашего доклада на ЛАФ). А почему бы не сделать ДЛ и другую подсистему, которая выполняет свой вариант использования в рамках границ рассматриваемой подсистемы (например, взаимодействует с ней для достижения какой-либо цели)? Тогда, по сути, другая подсистема является ДЛ по отношению к рассматриваемой подсистеме.

Павел,

Если что-то не ложится в ВИ, то это описывается просто доп функциональными требованиями.

То есть, помимо разделов ТЗ с описанием ВИ (пользовательские требования), необходимо создавать раздел с дополнительными ФТ для данной подсистемы? По сути, это "требования к функциям, выполняемым системой", исходя из ГОСТ 34?

Коллеги,

ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами (пользователями, др. системами, часами в конце концов), если же мы начинаем описывать в виде ВИ требования по взаимодействию между подсистемами НАШЕЙ СИСТЕМЫ, то теряем нужный/одинаковый уровень абстракции, т.к. будут ВИ по взаимодействию подсистемы с пользователем (один уровень абстракции) и будут ВИ по взаимодействию м\у подсистемами (другой уровень абстракции). Ни к чему хорошему это не приведет.
Исключения - это ВИ включения, необходимые для обобщения потока событий.

То есть, помимо разделов ТЗ с описанием ВИ (пользовательские требования), необходимо создавать раздел с дополнительными ФТ для данной подсистемы? По сути, это "требования к функциям, выполняемым системой", исходя из ГОСТ 34?

Именно так. А в чем сложность? Не надо все стараться засунуть в ВИ!!!

Коллеги,

ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами (пользователями, др. системами, часами в конце концов), если же мы начинаем описывать в виде ВИ требования по взаимодействию между подсистемами НАШЕЙ СИСТЕМЫ, то теряем нужный/одинаковый уровень абстракции, т.к. будут ВИ по взаимодействию подсистемы с пользователем (один уровень абстракции) и будут ВИ по взаимодействию м\у подсистемами (другой уровень абстракции). Ни к чему хорошему это не приведет.
Исключения - это ВИ включения, необходимые для обобщения потока событий.

1. кто сказал, что ... "ВИ - это взаимодействие НАШЕЙ СИСТЕМЫ с внешними объектами"? Это написано в спецификации?
2. все-таки нужно различать элементарные части системы и подсистемы
3. а зачем нам нужен одинаковый уровень абстракции? Может он нужен только будучи на определенном уровне? Если я на уровне всей системы, я имею один boundary. Но если я буду находится на уровне подсистемы, то эти другие подсистемы для меня такие же внешние сущности. Более того, эти внешние сущности-подсистемы помогают мне понять какие интерфейсы мне следует спроектировать.
4. возможно это не следует делать для простых системы, но Павел рассматривает АСУ, так что не вижу криминала, более того вполне законно и обосновано

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

2. все-таки нужно различать элементарные части системы и подсистемы

Эдуард Геннадьевич, вопрос в следующем: "А как я могу отличить элементарную часть системы и подсистему?"

4. возможно это не следует делать для простых системы, но Павел рассматривает АСУ, так что не вижу криминала, более того вполне законно и обосновано

Нет, я не рассматриваю АСУ (АСУ - это довольно сложная система, где логично производить деление на подсистемы). В первом посте указано о том, что, допустим, я пишу ТЗ на автоматизированную информационную систему, которой может являться, вполне возможно, небольшое веб-приложение.

Именно так. А в чем сложность? Не надо все стараться засунуть в ВИ!!!

Александр, а не будет ли дублирования информации в разделе ТЗ, описывающем ВИ подсистемы, и в разделе с описанием требований к функциям подсистемы?

дублирования информации в разделе ТЗ

По идее не будет , а если и будет то другими словами
ВИ -  это не функция.

И в целом, например, рассматривая подсистему - модуля отчетности, наверное ВИ и функции к данной подсистеме  это разные вещи?

Как мне видится, описывать ВИ подсистемы  как-то не очень правильно. У подсистемы есть функция формирования отчетности.
Но чтобы сформировать отчет пользователь использует скорее всю систему, а не только подсистему.

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

По идее не будет , а если и будет то другими словами
ВИ -  это не функция.

И в целом, например, рассматривая подсистему - модуля отчетности, наверное ВИ и функции к данной подсистеме  это разные вещи?

Как мне видится описывать ВИ подсистемы не как-то не очень. У подсистемы есть функция формирования отчетности.
Но чтобы сформировать отчет пользователь использует скорее всю систему, а не только подсистему.

Да, конечно ВИ и фунции - это разные вещи.
Смотрите, допустим, с помощью ВИ я описываю требования к п/системе формирования отчётности с точки зрения пользователя. Цель пользователя - сформировать отчёт. Исходя из этого пишется основной и альтернативные сценарии для данного ВИ.
Но а как быть с такими атомарными действиями, как СЧОУ (создание, чтение, обновление, удаление), ещё встречается термин CRUD. Они же, по сути, являются отдельными функциями данной подсистемы/модуля формирования отчётности? И, притом, в качестве ВИ действия СЧОУ не рекомендуется описывать, насколько я знаю.