Доброго времени суток, уважаемые знатоки.

У меня вопрос вот в чем, правильной ли дорогой проектирования я иду?

Мои этапы проектирования системы - это:
1) Архитектура системы (я понимаю что она очень далеко не полная):
    1.1) Общая структура системы - использую диаграмму классов.

2) Детальное проектирование:
    2.1) Проектирование свойств и методов диалоговых окон приложения:
           2.1.1) Структура диалоговых окон приложения:
                     - Использую диаграмму классов;
                     - На этом этапе я узнаю, сколько и каких диалоговых окон мне потребуется;
                     - К примеру окно Регистрации, Авторизации пользователя;

           2.1.2) Состояние диалоговых окон приложения:
                    - Использую диаграмму состояний;
                    - На этом этапе я узнаю, с какого в какое диалоговое окно может перейти пользователь приложения;
           
           2.1.3) Создание прототипов диалоговых окон приложения:
                    - Использую макетирование пользовательского интерфейса
                    - На это этапе я узнаю, какие графические компоненты мне понадобятся для взаимодействия с пользователем, и для отображения информационных данных
                    - К примеру, поле ввода информации, таблица, список, выпадающий список;

           2.1.4) Взаимодействия диалоговых окон приложения с пользователем
                    - Использую диаграмму взаимодействия;
                    - На этом этапе я узнаю, функциональные требования пользователя;
                    - К приложению, к примеру добавить, удалить, изменить запись в таблице;
   
           2.1.5) Анализ функциональных требований к приложению:
                    - Использую диаграмму деятельности;
                    - На этом этапе я узнаю, какой должен быть алгоритм работы функционального требования.

    2.2) Проектирование структуры базы данных;

    2.3) Проектирование логики приложения:
           2.3.1) Структура логики приложения:
                    - Использую диаграмму классов;
                    - На этом этапе я узнаю, какой класс(ы) должны быть реализованы, чтобы выполнить функциональные требования;

           2.3.2) Взаимодействия логики приложения:
                    - Использую диаграмму взаимодействия;
                    - На этом этапе я узнаю, какое кол-во классов затрагивает функциональное требование и какие "методы" мне нужно реализовать для того, чтобы выполнилось функциональное требование;

           2.3.3) Анализ методов класса:
                    - Использую диаграмму деятельности
                    - На этом этапе я узнаю, какой нужно будет реализовать алгоритм в методе класса.

P.S.: Буду рад, вашей критике.

Проектирование чего?
Нет единого, универсального, правильного для всех пути проектирования программных систем.
Я бы вообще начал с бизнес-требований.

Я согласен что нет волшебного шаблона для проектирования всех программных систем.
Но все же, какие то этапы проектирования, должны быть общие.

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

Интерфейс приложения подразделяется на:
1) Графический:
    - Компоненты взаимодействия с пользователем, их состояние.
    - верхние функции приложения, которые только видны пользователю, и их алгоритм поведения.
2) Консольный:
    - Текстовое объявление компонентов.
    - верхние функции приложения, которые только видны пользователю, и их алгоритм поведения
3) API - функции;
    - верхние функции приложения, которые только видны пользователю, и их алгоритм поведения .

Логика приложения: на этом этапе согласен, может и нет общих черт, но я не так много лет еще программирую.

А на счет базы данных, можно смело брать из структуры предметной области.

Constantine1911, интересный взгляд на разработку системы.
Я так понимаю, аспекты "бизнеса" здесь не рассматриваются. Предполагаю, предметная область вам близка и знакома и ее анализ для построения системы вы не выполняете. Или все необходимые материалы у вас уже имеются?

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

Могу предложить вынести на первый уровень определение вариантов использования.
Затем их описание в виде диаграммы взаимодействия пользователей с системой, затем алгоритмы выполнения задач самой системой. Вот только здесь появляются макеты GUI.
После погружения в эти работы уже можно сформировать предварительную модель данных.
И уже на наборе алгоритмов задач и модели данных можно определить архитектуру системы и углубляться в моделирование - классов, методов, модулей и их взаимодействия.

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

Очевидно, что процесс итеративный. У вас уже не так. Другой вопрос, а зачем изобретается велосипед, а не используются проверенные временем подходы, широко описанные в самой разной литературе?

https://yadi.sk/d/eTznHQAF3B7aKz
https://yadi.sk/d/ewTF17Od3PXutQ
https://yadi.sk/i/yPB2G4Sc3PXuuF
https://yadi.sk/i/K6D3jMOQ3PXuvE

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

Вы явно или неявно говорите о использование многослойной архитектуры - типичный выбор начинающих: например https://yadi.sk/i/rrbjoIZTgVVxP