я плохо объясняю требования.
Не ты одна
вот план моего курсового..нам выдала преподаватель. может так станет понятнее.
Вообще, если смотреть этот план работы, то совершенно не понятно почему вам нужно указать бизнес-уровень, а потом представить проектные решения для новой системы.
Разберем по пунктам
1. Постановка задачи (
Описание предметной области.
Прекрасно - это очень все понятно. Что же включает описание предметной области скорее всего это находит отражение в так называемой модели бизнеса (бизнеспроцессов и бизнес объектов) вместе они описывают бизнес-требования, на основании которых далее формулируются требования к системе: пользовательские требования (поведенческие), функциональные - не вошедшие в поведенческие, нефункциональные (например ограничения и бизнес-правила)
Описание требований к проектной системе)
Думаю не к проектной а проектируемой, т.е. системные требования
2. Модель бизнес-процессов.
Варианты использования business use case.
Спецификация.
Описание потока событий
диаграмма вариантов использования
Никак не описывает поведение системы, она описывает кто яляется потребителями, партнерами бизнеса, формирует границы бизнес-системы, границы бизнес-процессов, позволяет понять, что требуется изменить (или если хотите какие процессы или их части будут автоматизированы)
3. Модель бизнес-анализа (исполнитель, сущность)
Проектирование классов, диаграмма классов, модели бизнес-анализа
все в кучу и проектирования и моделирование и анализ требований
проектируются классы системы, а не классы предметной области. Классы предметной области есть результат анализа предметной области.Они помогают понять как реализуется бизнес-процесс, а также чтоже нам нужно хранить и учитывать при проектировании приложения. Часто классы предметной области, становятся сущностными классами приложения, т.е. классами которые хранят информацию о предметной области (в твоем случае: книги, автора, название, номер, количество, цена, когда поступила, от кого, сколько, когда продана, сколько, возможно кому)
Проектирование же классов начинается уже на стадии проектирования и подразумевает проектирование классов приложения - формы, интерфейсы, управляющие классы, классы хранения(базы данных...например)
Диаграмма последовательности для основного сценария(пример структуры бизнес-
модели
Причем тут стурктура бизнес модели и диаграмма последовательности.
ДП моделирует взаимодействие объектов и события возникающие в потоке этого взаимодействия. ДП чаще всего используется на стадии именно проектирования, чтобы определить операции классов и объектов, спроектировать поведение этих классов и объектов. На бизнес уровне, тоже можно конечно показать - однако гораздо удобнее проще и понятнее использовать для этого сценарии вариантов использования, в крайнем случае диаграммы деятельностей и состояний, но никак не ДП.
4. Проектирование баз данных (
модель данных,
связи между сущностями,
характеристики таблиц)
Вообще проектирование не включает моделирование, моделиование предшедствует проектированию. Моделирование тем и хорошо, что вы абстрагируетесь от реализации и инструментов, однако это у вас делается уже на стадии моделирование классов предметной области, зачем же еще делать модель данных?
??
А вот характеристики таблиц - это уже вы подбиратесь к реализации, что фактически и будет проектом их реализации, когда ваши таблицы описаны верно - или описаны на языке DDL или представлены в какой-то дургой форме.
На мой взгляд задание сформулировано не профессионально и сумбурно. Тот кто составлял задание несовсем понимает или совсем не понимает суть вопроса.