Что делать после написания документа с требованиями пользователя?

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

Чтобы работать последовательно, вы должны завершить всю аналитическую документацию, прежде чем делать дизайн, и до касания кода. Исходные базы данных могут быть сгенерированы из классов Java (beans), так что когда это произойдет.

В соответствии с выбранной вами методологией ссылка wiki, которую вы указали, перечисляет то, что, как ожидается, будет сделано в порядке. Для части дизайна высокого уровня, к которой у вас возникли проблемы, вам понадобятся соответствующие диаграммы UML, используйте компоненты для архитектуры модулей/программного обеспечения.

Потому что это высокий уровень дизайн держать его на высоком уровне, не разбирайтесь в деталях. например, для видеоигры: Graphics, Audio, Network и т.д., и как они будут взаимодействовать (интерфейсы), не определяют ничего меньшего, не могут быть классов, методов, основных пакетов/библиотек. Для аппаратной архитектуры вы можете использовать диаграмму развертывания, я полагаю, каждый куб представляет аппаратное обеспечение ящиков, которые будут запускать ваш код, вы не готовы к развертыванию, но можете внести изменения в свое первоначальное предложение следующей итерацией, если вам нужно.

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