Алексей Е.Прочитал всё, так и не услышал не одного рабочего варианта.
В чём всё-таки удобнее описать существующую систему? Что-бы потом можно было куда-то двигаться. У меня похожий вопрос сейчас стоит.
Вот то же самое. Понял что готовых, проверенных жизнью вариантов нет. У всех своё видение. Это видение очень сильно различается, думаю, из-за того, что процессы разработки в разных организациях очень по разному выстроены.

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

Думаю у каждого: у заказчика, у специалиста по реинжинирингу бизнес-процессов, у проджект-менеджера, у специалиста по тестированию, у специалиста по развёртыванию, у специалиста по поддержке итп, будет своё видение. Многие из них не захотят видеть систему в единственном разрезе Бухгалтерский\Управленческий\Логистический учёт
И, думаю, каждый из этих специалистов считает, что их модели фундаментальны и всё остальное должны быть производными от них. Разработчик считает, что фундаментален код и модель должна синхронизироваться с кодом, специалист по БП, что фундаментальны БП и всё остально должно ссылаться на его схемы БП, специалист по инфраструктуре считает, что первичны приложения и сервисы и всё должно быть описано в их терминах итд итп

Если я сейчас скажу, что самое главное - это спецификации, я наверное буду выглядеть глупо .

LaoxПочему бы не пойти по очевидному пути? Т.е. использовать стандартную нотацию UML (case выбирайте по вкусу). Сначала описать бизнес UC, затем их реализацию в виде системных UC? В результате описание можно делизировать до описания конкретных сущностей (таблиц, классов) и процедур и функций?

Бизнес-анализ тяжело перевести на UML, возможно из-за определённых традиций в этой области, возможно из-за объективных причин. Придётся держать две модели одну в бизнес UC, а другую - традиционную.

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

Мне кажется не хватит ресусрсов на синхронизацию 3х описаний системы: бизнес-модели(скажем ARIS), спецификации, UML (в т.ч бизнес UC).

С моей точки зрения (аналитика), логичнее оставить UML разработчикам, и озаботится проблемой синхронизации бизнес-моделей и спецификаций ПО.

Алексей Е.Слова ARIS, UML, UC - я могу найти в интернете и познакомится с ними, а вот что такое спецификации не понятно, как они выглядят, может примерчик, если не трудно приведёте.
ключевые слова ieee 830-1998, software requirements specification
оно же ТЗ на создание информационной системы (не помню какой гост)
в RUP это Vision, Supplementary Specification, Use Case Specification, Business Rules

Это такие документы в Word'е одним словом.

Laox А тем есть такая штучка в UC diagramm - Realization называется. Попробуйте ее использовать.
Она мне сделает SRS из UC diagram?

Laox
Кроме того, каковы Ваши цели? Сделать бизнес-анализ или описать приложение?
мои цели

Ну вобщем я понял ваш подход - делать бизнес-модель на UML, а всё остальное (SRS итд) как-то синхронизировать с ней.
Вы в масштабе предприятия это практически применяли? Если да, то наверное мне есть о чём задуматься.

Ещё раз. С меня спрашивают SRS, а не модель. У меня есть сильное подозрение, что UML-модель c детальностью как у SRS (с описанием бизнес-целей, стэйкхолдеров, юзеров, их интересов, высокоуровневых фич, детальных функциональных требований, бизнес-правил итп) сделать очень тяжело. Возможно я ошибаюсь.

И ещё одно соображение по поводу UML. Я его знаю не слишком хорошо. Дальше документирования отдельных механизмов не ходил.

У меня есть сильное подозрение, что используя UML аналитик "впадёт" в дизайн вместо собственно анализа.

технолог Вот , почитайте о реальном использвании РеквизитаСтатья интересная, спасибо.
Только это про сбор требований к одному БольшомуПроекту. А у нас ситуация другая- много маленьких и средних проектов, которые надо координировать. Имхо, напрямую РеквизитПро это не поддерживает.

В принципе, можно подумать над таким вариантом: под РеквизитПро держим ГлавнуюSRS (полное описание системы), а конкретные проекты на доработку ведём как вели. Но после каждого проекта\проектика синхронизируем изменения с ГлавнойSRS.