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

Спасибо.
Простите, а что в моем случае (сценарий приведен выше) будет в качестве "прямоугольничков" в такой диаграмме?

Простите, а что в моем случае (сценарий приведен выше) будет в качестве "прямоугольничков" в такой диаграмме?

Вот что:

PPPt - разрабатываемая Система, на которую пишется ТЗ.
NT - сторонняя Система.

Или их подсистемы.

Диаграммы юзкейсов вам тут не помогут

Скажите, почему?
Просто, компетентные товарищи (на работе) к существующим сценариям рекомендовали нарисовать юзкейс-диаграммы. Даже если это будет "NT--->Овал с вписанной функцией".
Можете аргументировать несостоятельность такого визуального отображения? Точнее, я сам понимаю, что "диаграмма мало о чем говорит"... но ... хочется выслушать экспертов. 

Вот что:Или их подсистемы.

Оно и понятно, но не совсем понятно, как между NT и PPPt нарисовать все то, что описано в сценарии? Получается, стрелочка с запросом от NT к PPPt... а дальше система ворочается сама в себе

Павел, правильно ли я понимаю, что внешняя система NT выступает в роли черного ящика, и Вы имеет в наличии только форматы передаваемых сообщений (описание интерфейса)?
В данном случае внешняя система может выступать как инициатор определенных действия, которые вы описали в виде сценария.
Моем мнение (коллеги могут не согласится :
1. Опишите форматы всех входящих и исходящих сообщений, которыми обмениваются системы.
2. Опишите алгоритмы обработки входящих сообщений и алгоритмы формирования исходящих сообщений.
    Алгоритмы можно описать с помощью сценария (что вы и сделали) или с помощью диаграммы деятельности (если не знаете компоненты) или диаграммы последовательности/коммуникации (если известны компоненты - как показал выше Александр.). Называть это вариантом использования не совсем правильно, а вот алгоритмом или функцией наверное можно.
3. Рекомендую также подготовить список данных, которые "живут" в системе - Сущности и их параметры
4. Можно еще контекстную диаграмму нарисовать, на которой показать 2 системы (как черные ящики) и показать на связях все передаваемые между ними сообщения.

Таким образом у вас будет общая картина взаимодействия двух систем, алгоритмы обработки (функции) и участвующие данные.

В общем пока писал, Виталий высказал мою мысль длиннее

Хочу только добавить про ВИ:
Аргументация лежит в книге Коберна "Современные методы описания функциональных требований к системам".
Можно еще почитать ФАК по ВИ.
А вообще главная аргументация в том, что ВИ - это ЦЕЛЬ Пользователя по отношению к Системе. ВИ отражают ПОЛЬЗОВАТЕЛЬСКИЕ требования, а при взаимодействии м\у ИС - какие ПТ?
Но в нынешней эконом. ситуации лучше не спорить с "компетентные товарищи (на работе)"

Господа, прощу прощения!

Речь о передаче данных пока не идет. Представлен простейший сценарий:

Функция: Подключение услуги
 
Основной сценарий
1. Система получает запрос от NT на регистрацию услуги. Формат запроса приведен в Приложении 2.
2. Система проверяет регистрацию пользователя (наличие профайла пользователя в Системе).
3. Система проверяет наличие у пользователя услуги.
4. Система в профайле пользователя регистрирует услугу с указанием даты регистрации.
5. Сценарий завершен.

Альтернативные сценарии
Альтернатива 2.1
1. Система обнаружила, что пользователь не зарегистрирован (отсутствует профайл абонента).
2. В Системе формируется сообщение об автоматической регистрации пользователя.
3. Производится регистрация пользователя.
4. Возврат в п.3 основного сценария.

Альтернатива 2.2
1. Система обнаружила, что пользователь уже подписан на услугу.
2. В Системе формируется формируется сообщение о наличии услуги у пользователя.
3. Сценарий завершен.

"Система" - это наша разрабатываемая система.
"NT" - сторонняя система, которая инициирует запрос (то есть наша Система его принимает и начинает шуршать внутри себя).

 

Павел,

ИМХО Вам уже все расписали как делать, это мы так уже упражняемся.

DFD - это что? Простите... а где можно посмотреть это? Это уже не будет ТЗ?

Эд, человек ведь новичок. Чего так удивляешься? Я, например, тоже никогда еще в жизни не использовал DFD в практике

Виталий Григораш

Мое мнение (коллеги могут не согласится ):...

Спасибо. Есть вопросы:

1. Опишите форматы всех входящих и исходящих сообщений, которыми обмениваются системы.

Если речь идет об одном сценарии, приведенном выше, то входящее сообщение будет только одно - это запрос. Так?

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

То есть "с помощью сценария" или "с помощью диаграммы"? Или сценарий лучше дополнить диаграммой?
Диаграмма деятельности, это collaboration?
А если без системных компонентов?


Было так:


...

4. Можно еще контекстную диаграмму нарисовать, на которой показать 2 системы (как черные ящики) и показать на связях все передаваемые между ними сообщения.

Судя по сценарию, там только запрос приходит от NT... и все. 

Павел,

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

Павел,

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

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

А как на этой же диаграмме отобразить шаги сценария?

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

Если речь идет об одном сценарии, приведенном выше, то входящее сообщение будет только одно - это запрос. Так?

Да именно так. Исходящих судя по всему 2: из каждого альтернативного сценария + нужно ли в NT какое-то подтверждение слать или нет?

То есть "с помощью сценария" или "с помощью диаграммы"? Или сценарий лучше дополнить диаграммой?
Диаграмма деятельности, это collaboration?
А если без системных компонентов?

Диаграмма деятельности это activity (на ней обычно компоненты не показываются) - блок-схема
Диаграмма взамодействия - sequence
Диаграмма коммуникации - collaboration
Примеры в каждой диаграммы в атаче

Эд, человек ведь новичок. Чего так удивляешься? Я, например, тоже никогда еще в жизни не использовал DFD в практике

Странно, публиковал ответ, а его не вижу. Я удивляюсь не незнанию человека, а нашему образованию. Это же классика!

Очень совету посмотреть сюда: http://yourdon.com/strucanalysis/wiki/index.php?title=Chapter_19