Пока делаю такой предварительный вывод: допустим, разбиваем мы концептуально проектируемую систему (система может быть небольшой) на модули. Каждый модуль служит для выполнения какой-то отдельной функции. Соответственно, в ТЗ пишутся сценарии использования каждого из модулей, а также в дополнительных ФТ к данному модулю описываются атомарные функции вроде СЧОУ. Верно?

Павел,

Что-то мне подсказывает, что не совсем так (
В доп требования должно попасть либо детализация шага Системы из ВИ или те требования, кот. не описаны в ВИ.
А разбиение на подсистемы поможет разбить ВИ по разным Д, если биение не очень мелкое.
Давай лучше разберем на примере.

Павел,

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

Понятно. То есть, допустим, в подсистеме формирования отчётности пользователь может выполнять ВИ с названием "Формировать отчёт". Пишем сценарий на этот ВИ. Одним из шагов этого сценария будет действие по выбору отчета из шаблона. Описания сценария шага "Выбор отчёта из шаблона" и будет его детализацией, то есть дополнительным требованием?

Кстати, очень интересует метод описания требований к упомянутым выше атомарным действиям работы с данными (СЧОУ). Их тоже можно описывать в ВИ? Или в виде описания отдельных разделов в ТЗ?

Например, сначала описываем ВИ по формированию отчёта в одном разделе ТЗ. Затем в разделе дополнительных требований создаем раздел "Требования к функциям модуля отчётности" с подразделами:
- Требования к созданию отчёта.
- Требования к редактированию отчёта.
- Требования к удалению отчёта.

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

Зачем я задаю такие вопросы? Просто есть цель - сформировать для себя оптимальный и удобный шаблон документа требований. Знаю, что есть общие стандарты. Но также есть и корпоративные стандарты...

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

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

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

Ну веб-приложение и не является АИС. Хотя не вижу проблем и в этом случае. Вот со студентами делали COS: систему для кафетерия. Там подсистема работы с меню - вполне самостоятельная независимая часть. Подсистема заказа клиента, вот она уже зависит от подсистемы меню, и т.д.

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

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

Эд,

Теоретически можно говорить бесконечно, давай примеры.

Теоретически можно говорить бесконечно, давай примеры.

Саша, там не было никаких теоретических рассуждений, абстрактные - возможно. Абстракция вообще прекрасный инструмент аналитика.

Я не могу выложить тебе немедленно примеры, поскольку у нас в компании не используется UML в достаточной мере. А при обучении задачи слишком небольшие. Хотя на 5 курсе в ходе реализации проекта COS, о чем я много и, возможно, нудно писал, мы это делали. Некоторые наброски смотри в архиве.

Цели и задачи клиента - это первичные ВИ по клиенту (посетителю кафетерия)
Цели и задачи менеджера меню - это первичные ВИ по менеджеру меню (в качестве примера)

ДИ по подсистемам - это уже скорее некий архитектурный набросок, декомпозиция по подсистемам, показана как пакеты с зависимостями

ДИ Работа с заказами и подписками
ДИ Готовка блюд
ДИ Доставка
//в каждой из этих подсистем появляются дополнительные ВИ для сопряжения, естественно, что в них подсистемы выступают второстепенными ДЛ (сама по себе подсистема не обладает инициативой и потребностями, но она может действовать от имени)
Эти второстепенный ВИ являются дополнительными (учетными) источниками требований и при этом акцентируют внимание на наличие интерфейсов, что будет учитываться дальше в архитектурном анализе

Я, возможно, и ошибаюсь, но поскольку ВИ часть UML, то и следует это учитывать при работе с требованиями.

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

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

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

Мой вопрос в Use Cases Professionals: Could a subsystem be of an actor? Could one subsystem initiate (communicate) an use case of another one?

Ответы:
James Shields • 

Any user or system or subsystem that interacts with your system is an actor.
 And your system is an actor when it interacts with another system or subsystem.
 That other system or subsystem you interact with is often termed a secondary actor.
 Personally I don't like this secondary actor terminology as it leads to confusion.
 It's just a system or subsystem you interact with to use it's functionality via it's use cases.

Putcha Narasimham

If a subsystem SubX-SD becomes an Actor, the system boundary has to be redefined and the new SD NSD will be different. The SubX-SD must be truly independent of the NSD. As said earlier "initiation" use case is not crucial. It can be taken up and resolved later, that is after Naming the Use Case and its Goal.

 I wish to restate what you wrote: "in some cases SubX-SD can initiate some UC of the NSD ON BEHALF OF a previous Actor (PA) of the original SD. PA is NOT directly connected to the New SD and is NOT an Actor of NSD". I hope this is consistent with what you wrote & intended.

 If the SubX-SD is truly a subsystem with some independent processing power / storage etc (NOT A mere TRANSMITTER OF INFRORMATION with or without amplification) then the connection between SubX-SD and the PA (now Actor of SubX- SD) is irrelevant to the context of the new SD. SubX-SD must deal with the PA as its Current Actor CA separately in a suitable way. The SubX-SD must have its own GOAL (it may be related to what CA asks SubX-SD) with ref to the new SD. This is the principle of system boundary and specific context for each subsystem of any system.

 Within a SYSTEM BOOUNDARY of an SD, NO SubSystems of itself should be recognized and represented in the USE CASE DIAGRAM of SD. Accordingly it cannot be an actor of another External System ES which may be connected with SD . If a USE CASE DIAGRAM of the ES is drawn, then SD as a whole will be an Actor of ES which will now be THE SD.

 If an Actor A is a mere TRANSMITTER he or she or it is NOT an Actor. The entity on the other end is the true Actor of the System Under Development.

John Watson 

Hello Edward,
 I think that if Ivar Jacobson had English as his first language that Actors would have been called Interactors. An Actor (or Interactor)symbol on a Use Case diagram represents a role filled by anything outside the boundary of a system that interacts with that system.

 Consider an Automatic Check-in Kiosk at an airport. A traveller (Actor) interacts with the Check-in Kiosk (System) in order to obtain their boarding pass and bagggage tags. To complete the process, The Check-in Kiosk System requests the Reservation System (Actor from the viewpoint of the Check-in Kiosk) to validate the Traveller's reservation details. In this context, Get Boarding Pass is a Use Case of the Check-in Kiosk initiated by the Traveller Actor. From the viewpoint of the Traveller the Check-in Kiosk is a system and the Reservation System is "invisible". From the viewpoint of the Check-in Kiosk, the Reservation System is an Actor. From the viewpoint of the Reservation System the Check-in System is an Actor.

 If you would like a diagram and Use Case descriptions to illustrate the above, e-mail me.

 For scope control purposes we choose to treat the Check-in System and Reservation Systems as separate entities. From the viewpoint of each system (or sub-system?) the other system is an Actor

Мнения пока разделились

При формировании ТЗ я разделяю данную систему на модули/подсистемы, отличающиеся своей функциональностью. Например: модуль цифровой подписи, модуль отчетности, модуль администрирования и т.п.

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

Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?

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

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

Вот что такое «модуль цифровой подписи» на уровне концепции? Зачем он нужен?

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

А вообще Вигерс как-то начал описывать ВИ "по модному":
http://t.co/RAIHiTX

«По-модному» он описывает только вырожденные способы применения просмотра веб-страниц.

Я не говорю, что систему не надо разбивать на части.

Я говорю, что это надо делать ПОСЛЕ выделения и пакетирования способов применения, причём на уровне требований — только на бизнес-подсистемы, а не технические.

Технически в любой системе можно выделять подсистемы:
1. Подсистема отображения данных и организации взаимодействия с пользователем
2. Подсистема обработки данных
3. Подсистема хранения данных
4. Подсистема интеграции со смежными системами
От этого на уровне требований больше вреда, чем пользы.

По российскому ГОСТу в ТЗ входит разбиение системы на подсистемы, поэтому вопрос имеет прямое отношение к «как формировать ТЗ».

Разбивать систему на модули невнятной категории при разработке ТЗ — эта классическая, но опасная российская практика. «Отличающиеся функциональностью» с точки зрения кого? Пользователя, заказчика, архитектора?

Отличающиеся функциональностью - с точки зрения аналитика. Аналитик же пишет ТЗ и разбивает систему (любую, я не говорю именно о больших системах) на части/модули/сервисы.

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

Про то, что получаются некие модули невнятной категории, смесь бизнес- и технической архитектуры - согласен. От незнания того, как делать правильно, и "каша в голове".

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

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

Денис, имеется в виду бизнес-группировка способов применения (вариантов использования)?

Вот что такое «модуль цифровой подписи» на уровне концепции? Зачем он нужен?

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