Здравствуйте, slava.4e, Вы писали:

S4>Здравствуйте, bkat, Вы писали:

B>>Здравствуйте, slava.4e, Вы писали:

S4>>>В общем, буду рад если кто нибудь поделится опытом, как это сделать наиболее красиво, эффективно и при этом не разбивая на тысячу разных документов.

B>>Общий подход — использование так называемых alternate/exception flow, как часть описания варианта использования.
B>>Т.е. вasic flow лучше не перегружать особенностями исключительных, специальных ситуаций.

S4>Т.е. лучше в начале представить базовый сценарий, с его описанием, а потом нарисовать alternative flow, с указанием альтернативных веток и их описанием?

Именно так.

S4>Но подобные диаграммы слишком абстрактны, для подобного рода задач, на мой взгляд. Я только что попытался на бумаге нарисовать, и ничего толкового не вышло. Дело в том что мне нужно расписать почти каждое сообщение, с его специфическими параметрами, без которых услуга работать не будет. А сообщений там порядка 30, конечно если исключить все подтверждения, не несущие в себе важных, с точки зрения создания и конфигурации конференции, параметров, получится около 20 сообщений, которые никак нельзя упускать, как и некоторые их особенности.

Что значить абстрактны?
Use Case штука очень конкретна и показывает поведение системы с точки зрения пользователя.
О каких параметрах и сообщениях ты говоришь?
Не пытаешься ли ты смешать варианты использования с деталями реализации?

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

Короче для начала я бы попытался ответить на вопрос кому вообще нужна эта документация
и для каких целей. Предположим что варианты использования
вам нужны чтобы специфицировать систему для девелоперов и тестеров.
У нас в этих случаях варианты использования используются только как иллюстрация формальных спецификакий.
В стандартном случае рисуется GUI Mockup.
По нему создаются описания вариантов использования (обычный текст).
Ну и далее следует набор формальных спецификаций (тоже обычный текст).
В большинстве случаев такого набора достаточно, чтобы понять что должна делать система.
В тривиальных или специальных случаях Mockup'ы или варианты использования опускаются.

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