Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - Pavel_T

Страницы: « 1 2 3 4 5
61
Павел,

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

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

62
Виталий Григораш
Цитата: Виталий Григораш
Мое мнение (коллеги могут не согласится ):...
Спасибо. Есть вопросы:

Цитата: Виталий Григораш
1. Опишите форматы всех входящих и исходящих сообщений, которыми обмениваются системы.
Если речь идет об одном сценарии, приведенном выше, то входящее сообщение будет только одно - это запрос. Так?

Цитата: Виталий Григораш
2. Опишите алгоритмы обработки входящих сообщений и алгоритмы формирования исходящих сообщений.
    Алгоритмы можно описать с помощью сценария (что вы и сделали) или с помощью диаграммы деятельности (если не знаете компоненты)
То есть "с помощью сценария" или "с помощью диаграммы"? Или сценарий лучше дополнить диаграммой?
Диаграмма деятельности, это collaboration?
А если без системных компонентов?


Было так:


...
Цитата: Виталий Григораш
4. Можно еще контекстную диаграмму нарисовать, на которой показать 2 системы (как черные ящики) и показать на связях все передаваемые между ними сообщения.
Судя по сценарию, там только запрос приходит от NT... и все.  ???


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

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

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

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

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

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

 :(

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


Цитировать
Вот что:Или их подсистемы.

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

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

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

66
Прежде всего, спасибо за ответы!

Цитировать
Посмотрите мою презентацию по новому походу в описании ПТ:
Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ.
Имеете ввиду вот это - "Пользовательские Сценарии как лучший способ описания Пользовательских Требований"?
Есть вопросы... не совсем понял... Дело в том, что пользовательских требований по сути нет в документе. Есть уже сразу фукции, со сценарием их реалицации.

Просто меня переклинивает, когда в разделе "Функциональные требования" присутствует "Сценарии работы с системой". Мне казалось - либо то, либо то :(

Цитировать
Мне кажется у вас подойдет простое описание алгоритма, нечто вроде DFD, диаграммы деятельности.
DFD - это что? Простите... а где можно посмотреть это? Это уже не будет ТЗ?


67
Цитировать
Здесь нет диалога, тут монолог.
Цитировать
Опять монолог, нет ДИАЛОГА, неясны действия внешних систем-акторов

В этом то и дело :( Пришел запрос от NT в нашу Систему и она там чего-то сама ворочает (регестрирует, сохраняет, изменяет).

Что посоветуете в таком случае?

Цитировать
...но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ
Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"?


68
Во первых - кто такие PPPt и NT?

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

Во-вторых, если у Вас ТЗ на интеграцию, то ее ни в коем случае не надо описывать в виде ВИ.

Хм. На интеграцию? Данная разработка направлена на внедрение разрабатываемой Системы в уже существующую систему (это телеком). То есть разрабатываемая Система использует другие части большой системы.

Подскажите, это интеграция?  ???


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

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

Альтернативные сценарии
Альтернатива 2.1

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

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



Я на правильном пути?  ???

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

Можете показать пример, как это выглядит?  ???
А то я нарисовал Актера (в виде сторонней системы NT и овал юзкейса, соединив стрелкой :( 


69
Добрый день!

Я начинающий аналитик.
Активно изучаю методики анализа требований, вникаю в эту область.
И одновременно работаю аналитиком на проекте.

Мне попал в руки документ, якобы ТЗ...
В нем присутствует таблица со сценариями.

Выглядит это таким образом:

Функция: Подключение услуги
Сценарий:

1. PPPt получает запрос от NT на регистрацию услуги KLH.
2. В случае если получен запрос на регистрацию услуги пользователю, ранее не зарегистрированному в PPPt, то производится регистрация профайла пользователя и выдается системное предупреждение об автоматической регистрации.
3. При получении запроса на регистрацию услуги пользователю, уже имеющему эту услугу формируется документированное предупреждение системы. Повторная регистрация не производится.
4. PPPt в профайле зарегистрированного пользователя регистрирует запись о подписке на услугу с указанием даты регистрации, после чего обработка прекращается.


Уважаемые эксперты. Поправьте меня пожалуйста...

1. Актером здесь выступает система, внешняя (далее во всем ТЗ именно так). Имеет ли смысл оформлять все в таком виде и дальше, с рисованием юзкейс диаграмм?
2. Очень хочется использовать для такого описания какой-то иной документ, возможно архитектурный или системный (подскажите какой?). Прав ли я? Или оставить все в ТЗ? Просто мне привычнее видеть ТЗ в виде функций, которые удовлетворяют требования пользователя, а здесь - сторонняя система удовлетворяет требования системы.
3. Этот документ (это ТЗ) используется разработчиками как первоисточник, актуальный и понятный по функциям. Может имело бы смысл оформлять не юзкейс диаграммы, а какие-либо другие типы диаграмм, для подобного описания (см. выше 4 пункта)?

Вобщем... большая путаница. :(
 


Страницы: « 1 2 3 4 5