Добрый день!

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

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

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

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

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

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

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

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

Павел,

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

теперь по вопросам:
1. См. выше
2. Не вижу проблем написать ТЗ на интеграцию
3. см. выше.

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

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

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

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

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

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

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

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

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


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

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

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

1. Интеграция - это взаимодействие ИС (или их частей) между собой
2. Можно и так описывать внутренность ф-ций, только не называйте их ВИ
замечания по потокам:
из п. 2 не понятно что Система находит Пользователя. Т.е. надо так и писать - Система находит зарегистрированного Пользователя по параметрам Запроса. А в 2.1. писать: "Система обнаружила, что Пользователь не зарегистрирован (отсутствует профайл абонента)."
в. п.3. можно написать исключение прямо в этом п., например, "Система проверяет наличие у Пользователя Услуги. Если Услуга не найдена, то сценарий продолжается. Если услуга найдена, то Системе формирует сообщение о наличии услуги у пользователя и сценарий завершается."

3. Пример см. ниже. Вместо Данных можно писать название ф-ий.

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

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

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


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

Use case должен начинаться с действий основного действующего лица, инициирующего процесс. Т.е. с действий NT

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

Здесь нет диалога, тут монолог. Действует разрабатываемая система, действий внешних систем нет.

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

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

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

Эд,

Если ты прочитал внимательно наш разговор с Павлом, то я сказал, что можно описывать ф-ции Системы в виде сценария, но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ.

Здесь нет диалога, тут монолог.

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

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

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

...но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ

Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"?

Эд,

Если ты прочитал внимательно наш разговор с Павлом, то я сказал, что можно описывать ф-ции Системы в виде сценария, но нельзя называть из ВИ НИ В КОЕМ СЛУЧАЕ.

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

Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"

К "сценарию" я притензий не имею Посмотрите мою презентацию по новому походу в описании ПТ:
Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ.
Можно в похожем ключе описывать и ФТ.

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

Что посоветуете в таком случае?
Можно не называть ВИ или юзкейз. Тогда правомерно ли писать "сценарий", "прецедент"?

Мне кажется ненужно относиться слишком серьезно к форме. Главное содержание и то, что Вы пытаетесь донести до разработчика(архитектора, проектировщика). Если у вас в компании развита культура UML, то значит есть старшие товарищи, которые помогут. Если нет, то скорее всего вам просто и легко никого не удивить и не убедить. Потому можно пойти по принципу: правильно применяем концепцию, а там сами поймете подходит или нет все это в к вам.

Мне кажется у вас подойдет простое описание алгоритма, нечто вроде DFD, диаграммы деятельности. В общем как САША уже сказал
Но и ВИ вполне можно родить...

Но и ВИ вполне можно родить...

Еще раз повторюсь, что для интеграционных задач ВИ лучше не рожать

It depends on..

Даю справку: рожать, родить- от слова род (правило проверки, поставить гласную под ударение)

Двоечник     

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

Посмотрите мою презентацию по новому походу в описании ПТ:
Пользовательские Сценарии или как уйти от ВИ и перейти к иерархии ПТ.

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

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

Мне кажется у вас подойдет простое описание алгоритма, нечто вроде DFD, диаграммы деятельности.

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

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

http://unesco.kemsu.ru/study_work/method/po/dfd_idef3.pdf

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