|
•Предлогаю на данной стадии не описывать юзкейсы. - Hruks, 07.03.2010 17:01:15 |
|
|
Пока толком не описаны даже высокоуровневые требования, нет описания даже архитектуры толком, зато уже куча юзкейсов.
Юзкейсы хороши, когда не совсем понятно и неописано поведение всей системы, для того, чтобы прояснить какие-то отдельные детали и непонятное поведение в критических ситуациях. Они позволяют выявить вещи, неописанные или неоднозначно описанные в основных требованиях.
В ситуации же, когда высокоуровневые требования могут меняться, например частичными изменениями, либо дополнениями более детальной информацией, юзкейсы придётся постоянно менять. Это мартышкин труд.
Кроме того, в документе намешано куча всего, тут и параметры юнитов и их команды и описанине архитектуры всей системы и даже зачем-то опускаются до требований реализации, например указывается алгоритм шифрования 7zip. Такие должны быть описаны в требованиях только в одном случае - если это часть интерфеса разных модулей и эти модули могут быть реализованы разными командами. Но в таком случае нужно чётко формулировать полностью весь интерфейс, вместо того, чтобы указывать алгоритм шифрования. В подобном документе достаточно указать, что в целях экономии сетевого трафика большие объёмы данных должны сжиматься перед отправкой.
Всякую детализацию принято выносить в приложения. Те, кто читает документ и ему интересны детали (для изучения системы либо её реализации) пойдут по ссылкам и почитают детально, остальные долны получить общее представление, не вникая в детали, только так можно уместить в голове всю систему.
Ну и UI обычно описывается скринами. На эти скрины можно ссылаться в тексте требований. Сами же скрины описывают контролы, их условия доступности (например нет денег для апгрейда, кнопки будут недоступны, или пока пользователь не выбрал карту, на которой будет новая игры, кнопка Ok будет недоступна) а также реакцию системы на все контролы (наприер по кнопке Ok переход на скрин N, по кнопке апгрейда трата денег на увеличение выбранной характеристики на соед ступень)
Я бы разделил сразу этот документ на несколько.
1. Описание общей архитектуры. Что это многозвенная система, клиент и сервер расположены локально либо на разных машинах в сети. Выполняемые задачи и функции этих частей. Про мультиплатформенность и тому подобные вещи. В качестве приложения к этому документу должны идти описания взаимодействия частей, а также поведение системы, в случае взаимодействия и разных ошибок (о которых писать пока рано, но потом уже можно будет)
2. Описание серверной части подробно.
Интерфейсы у нас уже должны быть и на них только ссылаемся, по ходу интерфейсы будут уточняться, расширяться, переделываться. Тут же идёт идентификация и аутентификация клинта. Далее описываются состояния системы - создание новой игры, продолжение игры, переход хода, команды клиентов на запрос информации, управляющие команды от клиентов, реакция системы на доступные и недоступные команды. Ну и так далее, всё, что относится к серверной части, всё глубже погружаясь уже в игру - управление юнитами, конкретные команды, боевая система, строительство, в общем всё. Хотя эти вещи могут быть в дополнитлеьных документах, или главах большого документа.
3. Клинтская часть.
Вот тут уже идут описания разных скринов (главное меню, новая игры, выбор карты, параметров игры, открытых игр, экрана закупок, игрового экрана, перехода хода и т.д.). Далее взаимодействие с сервером, например узнать у сервера список игр данного игрока, послать данные аутентификации, получить данные о списке доступных команд выбранного юнита, получить доступные данные на данном ходу при подключении, получить дельту досупных данных после выполнения команды. Например игрок двинул скаута. Клиент послал серверу запрос на движение скаута из одной клетки в дуругую, проанализировал возможность этого, передвинул скаута, выслал клинту данные о новых клетках, которые теперь не подсвечены туманом войны, наличие юнитов противника в этих клетках, полезных ископаемых, если это был сурвеер и так далее. Задача клинта при получении этих данных визуализировать их для игрока. При этом клиент не должен знать больше, чем может знать игрок, а сервер не должен выдавать данные клиенту, которые не может унать игрок. Например если что-то скрыто туманом войны, то сервер этой информации не должен сообщать. Если данная клетка не разведана сурвеером, то сервер не должен высылать данных о геологии клетки. И даже если игрок построил там шахту, сервер насчитает добычу материалов на следующий ход и сообщит сколько добывает шахта, но в какой клетке железо, а в какой другие ископаемые сервер сообщать не должен.
По идее клиент может быть реализован на других платформах с применением других языков программирования и сред разработки и даже другими людьми. Достаточно лищь чётко описать интерфейсы взаимодействия клиента и сервера. Это не значит что всё нужно продумать заранее, потом можно и добавить и поменять, просто нужно понимать, что менять интерфейсы это дорогое удовольствие, в отличие от внутренностей клиента или сервера. |
|
| |