Т.е. существующую ДВИ я оставляю как БВИ и начинаю делать другую - СВИ.

Не уверен, что у вас это ДБВИ, тут смесь точек зрений и перспектив.

Появилось пару вопросов.

1) Какая связь должна быть на диаграмме классов между классом сотрудник и классом менеджер - агрегация или наследование?
2) На диаграммах последовательности в конце должна быть достигнута цель(?), вот 2 варианта, какой из них 3х правильный(?):

Вариант 1:

1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. В случае ошибки сообщить пользователю (какая линия должна быть в этом случае, т.к. это может и не возникнуть, т.е. исключение)
6. Добавить сотрудника (если ошибок не было выявлено)

Вариант 2:

1. Открыть окно "Добавить сотрудника"
2. Ввести данные
3. Проверить данные ввода
4. Добавить сотрудника (если ошибок не было выявлено)

Вариант 3:

1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. Добавить сотрудника (если ошибок не было выявлено)

1) Какая связь должна быть на диаграмме классов между классом сотрудник и классом менеджер - агрегация или наследование?

Ассоциация, может быть и наследование, где Сотрудник обобщающий класс - менеджер уточняющий

2) На диаграммах последовательности в конце должна быть достигнута цель(?), вот 2 варианта, какой из них 3х правильный(?):

Гы предложение уже содержит ошибку

Вариант 1:

1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. В случае ошибки сообщить пользователю (какая линия должна быть в этом случае, т.к. это может и не возникнуть, т.е. исключение)
6. Добавить сотрудника (если ошибок не было выявлено)

Вариант 2:

1. Открыть окно "Добавить сотрудника"
2. Ввести данные
3. Проверить данные ввода
4. Добавить сотрудника (если ошибок не было выявлено)

Вариант 3:

1. На стартовом окне нажать кнопку "Добавить сотрудника"
2. Открыть окно "Добавить сотрудника"
3. Ввести данные
4. Проверить данные ввода
5. Добавить сотрудника (если ошибок не было выявлено)

А это варианты чего? Вообще диаграмма рисуется, а сценарий пишется. Однако в сценарии вообще-то отражаются взаимодействующие объекты, а где они?

Вот например

Вот например

1. Что вы хотите показать этой диаграммой? напомню, что ДП одна из диаграмм взаимодействия и служит для визуализации некоторого сценария (т.е. строгой последовательности действий), отображающего путь достижения или не достижения пользователем его цели. При этом мы используем некоторые объекты ( в начале объекты предметной области ) для отображения реализации сценария варианта использования.

2. Вы пытаетесь изобразить справа по сути черный ящик. Ларман называет такие диаграммы системными ДП и предлагает их использовать для отображения или идентификации системных событий, которые потом отображаются на системные операции. Т.е. ваш объект Добавить сотрудника по сути либо сама система, либо ее часть показанная без детализации. Возникает вопрос зачем нужно рисовать диаграмму, если ПРАВИЛЬНО составленный сценарий ВИ вполне решает туже задачу? Какую пользу вы лично (или кто-то другой) извлечете из этой диаграммы?

3. Кроме того концовка диаграммы реализована не верно. Шаги 5 и 6 взаимоисключающие, альтернативные. У вас же они изображаются как последовательные, а следовательно всегда выполняемые. Для отображения альтернативных путей и в UML1.5  и в UML 2 существуют адекватные средства

1. Что вы хотите показать этой диаграммой? напомню, что ДП одна из диаграмм взаимодействия и служит для визуализации некоторого сценария (т.е. строгой последовательности действий), отображающего путь достижения или не достижения пользователем его цели. При этом мы используем некоторые объекты ( в начале объекты предметной области ) для отображения реализации сценария варианта использования.

Здесь я описывал процесс как сотрудник КО добавляет нового сотрудника.
Т.е. сотрудник нажимает кнопку "Добавить сотрудника" на стартовом окне сотрудника (открывается после авторизации). В открывшемся окне он вводит данные для добавления сотрудника, нажимает "Добавить". Программа делает проверку на правильность ввода и на повтор. Если данные введены не верно или сотрудник существует, то программа сообщает сотруднику КО, что выявлена ошибка. Если ошибки нет, то программа добавляет сотрудника в БД.

Это 1 из ... диаграмм. Просто я выбрал первую попавшую и добавил сюда.

2. Вы пытаетесь изобразить справа по сути черный ящик. Ларман называет такие диаграммы системными ДП и предлагает их использовать для отображения или идентификации системных событий, которые потом отображаются на системные операции. Т.е. ваш объект Добавить сотрудника по сути либо сама система, либо ее часть показанная без детализации. Возникает вопрос зачем нужно рисовать диаграмму, если ПРАВИЛЬНО составленный сценарий ВИ вполне решает туже задачу? Какую пользу вы лично (или кто-то другой) извлечете из этой диаграммы?

Что значит без детализации?
А насчет "зачем?"...не знаю может спросите у моего преподавателя? Вот стоит требование кровь из носа заюзать 5-6 видов диаграмма, ну а что, буду говорить, да зачем мне делать? Вы же сами знаете что такое требования.

3. Кроме того концовка диаграммы реализована не верно. Шаги 5 и 6 взаимоисключающие, альтернативные. У вас же они изображаются как последовательные, а следовательно всегда выполняемые. Для отображения альтернативных путей и в UML1.5  и в UML 2 существуют адекватные средства

Вот как раз этот вопрос я и хотел узнать, я и так знал что это не правильно, но как отобразить это правильно я не знаю. Поэтому и обратился с вопросом.

Здесь я описывал процесс как сотрудник КО добавляет нового сотрудника.
Т.е. сотрудник нажимает кнопку "Добавить сотрудника" на стартовом окне сотрудника (открывается после авторизации). В открывшемся окне он вводит данные для добавления сотрудника, нажимает "Добавить". Программа делает проверку на правильность ввода и на повтор. Если данные введены не верно или сотрудник существует, то программа сообщает сотруднику КО, что выявлена ошибка. Если ошибки нет, то программа добавляет сотрудника в БД.

Это не уровень ЧТО нужно делать, не уровень описания требования. Это по сути описания некой реализации, причем с привлечением определенных программных компонентов. Почитайте внимательно FAQ по USE Cases

Вот как раз этот вопрос я и хотел узнать, я и так знал что это не правильно, но как отобразить это правильно я не знаю. Поэтому и обратился с вопросом.

Почитайте руководство пользователя UML от авторов или иные книги по UML.