Постановка требований

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

0. Общие положения
1. Функциональные требования
2. Нефункциональны требования
3. Требования безопасности
4. Требования к качеству продукта

Общие цели и формулировка задачи

В конечном виде, продукт должен представлять собой готовый для встраивания в проект модуль, реализующий в себе функционал, помогающий в удобном для пользователя виде хранить, и обрабатывать игровые данные. Под данными имеется ввиду любой набор данных, которые содержатся в игре – начиная от локализации и заканчивая настройками игровых объектов. Предполагается, что данный модуль должен состоять из двух подсистем:

0. Клиентская подсистема, позволяющая, не углубляясь непосредственно в исходный код проекта, обрабатывать игровые данные
1. Встраиваемая непосредственно в игру подсистема, которая будет отвечать за получение, хранение и обработку данных

Допускается изменение/доработка/правка требований к проекту на протяжении разработки проекта только в следующих случаях:

0. На этапе расписания требований, некоторых не хватало – можно добавить
1. Не точна или не ясна формулировка того или иного требования – можно править
2. Требования не относятся к своей группе – можно переместить на свое место
3. По факту разработки какое-то, не критичное для конечного результата, требование определяется как невыполнимым или сложно выполнимым (200 или более часов на реализацию требования) – можно отметить как не выполнимое и игнорировать при реализации

Цель продукта считается достигнутой, если:

0. Все требования из последующих списков удовлетворены
1. По меньшей мере, 70% исходного кода встраиваемого модуля покрыто Unit-тестами
2. Работоспособность программного продукта протестирована, по меньшей мере, на 3х любых платформах, поддерживаемых Unity3D
3. На 20% кода, который выполняет 80% функционала описана документация
4. С использованием данной системы написано демонстрационное приложение

Функциональные требования

В этом разделе опишем требования к функциональности модуля.

0. Функциональные требования к клиентской подсистеме
1. Подсистема должна поддерживать следующие функции вода данных в систему: 0. Поддерживать функции табличного процессора 0. Ввод данных от оператора ввода данных 0. Копирование данных из прочих документов табличных процессоров 0. Поддерживаемые типы данных (ограничительные характеристики форматов берутся аналогичные как для платформы Mono): 0. Строковые форматы 0. Целочисленные и числа с плавающими точками 0. Перечислители данных (к примеру, для обьекта «Камень» характеристика «Влажность» будет поддерживать одно из «Мокрый» «Сухой») 0. Дата-время (DateTime) 0. Промежуток времени (TimeSpan) 0. Во время ввода данных, подсистема должна поддерживать следующие функции проверки и генерации данных: 0. Проверки на формат вводимых данных 0. Поддерживать сигнализацию о не верно введенных данных 0. При передаче данных от клиентской части во встраиваемый модуль должна происходить верификация данных на предмет их целостности 0. При редактировании данных иметь наличие автоматической генерации новых данных на основе старых (к примеру, id записи на основе прочих его уникальной характеристики + постфикса)
2. Подсистема должна обладать выводом данных для просмотра и редактирования на уровне работы оператора набора данных с табличным процессором
3. Клиентская подсистема должна поддерживать функцию выдачи данных во встраиваемую подсистему
4. Возможности контроля версий должны включать следующие функции: 0. Иметь возможность в любой момент сделать резервную копию всех данных 0. Иметь возможность конфигурировать данные разных версий под конкретные нужды (к примеру, отдельно иметь релизную версию, отдельно для тестировщиков, отдельно для разработчиков и т. п.)
5. Функциональные требования ко встраиваемому модулю:
6. Общие требования: 0. Модуль должен представлять из себя библиотеку или набор библиотек, способные входить в состав приложений, написанных с использованием движка Unity3D 0. Иметь возможность быть используемым в приложениях с использованием движка Unity3D в терминах разработки на этом движке 0. Иметь вид базового набора компонент, на основе которых можно развернуть слой архитектуры паттерна Model, включающий функции хранения, обработки и предоставление в использование данных для проекта 0. Помимо библиотек, включать в себя графическую утилиту, позволяющую взаимодействовать с версиями загружаемых данных (загружать, удалять и т. п.) 0. Включать в себя графическую утилиту, позволяющую управлять текущей ревизией непосредственно в скомпилированном, запущенном на машине пользователя конечном приложении
7. Интерфейс работы с встраиваемым модулем должен иметь следующие функции ввода данных: 0. Данные в подсистему могут вводиться только: 0. При заборе данных от клиентской подсистемы 0. При обновлениях данных со стороны пользовательского кода, который базируется на основе этой подсистемы 0. Поддерживаемые типы данных данных (ограничительные характеристики форматов берутся аналогичные как для платформы Mono): 0. Строковые форматы 0. Целочисленные и числа с плавающими точками 0. Перечислители данных (к примеру, для обьекта «Камень» характеристика «Влажность» будет поддерживать одно из «Мокрый» «Сухой») 0. Дата-время (DateTime) 0. Промежуток времени (TimeSpan)
8. Вывод данных из подсистемы подразумевается только в следующих функциях: 0. Забор данных исходным кодом, написанным на базе данной подсистемы 0. Вывод данных о хранимых на текущий момент ревизиях
9. Взаимодействие с клиентской частью включает в себя функции: 0. Подключение к клиентской части и забор с нее данных 0. Иметь возможность сохранять слепок данных, полученных от клиентской части (далее – ревизия) и выдавать приложению доступ на чтение/обработку этих данных 0. Каждая ревизия должна хранить в себе набор данных, описывающих ее назначение, версию и прочие идентифицирующие характеристики 0. По умолчанию сохранять все загруженные ревизии и иметь возможность в любой момент перейти к использованию той или иной их версии
10. Дополнительный функционал включает в себя 0. Возможность кэширования данных: 0. Возможность кэширования всех или некоторых ответов модели данных в контексте оптимизации (отключаемая опция) 0. Выставление максимального размера кэша или длительности жизни записей в кэше 0. Заготовка быстрых запросов-паттернов (кэширование запроса и выдача результата по заранее заготовленному запросу) 0. Создание хранилищ данных как для межсессионного, так и для сессионного назначения 0. Сессионные хранилища данных размещаются в оперативной памяти и автоматически удаляются по окончании сессии пользователя 0. Межсессионные данные хранятся в постоянном хранилище данных целевого устройства и могут восстанавливать свое состояние во время последующих сессий 0. Инициализация хранилищ данных может быть произведена как из режима проигрывания, так и из режима редактирования в редакторе 0. Межсессионные хранилища должны обладать следующими системами политики сохранения данных: 0. Мгновенное сохранение данных 0. Отложенное сохранение (раз в кадр) 0. Автоматическое сохранение (период автоматического сохранения задается отдельно) 0. Генерация на стороне проекта исходные коды классов, описывающие сущности, обозначенные на клиентской стороне модуля 0. Части модуля должны поддерживать события обновления данных и прочие, сигнализирующие о каких-то изменениях в данных
11. Генерация исходного кода для текущей ревизии 0. Для текущей ревизии (только в редакторе) иметь возможность автоматически генерировать исходный код классов, описывающих сущности текущей ревизии (сущность конкретного обьекта коллекции, сущность конкретной коллекции). В случае смены ревизии данных - автоматически заменять старые исходные коды новыми 0. Иметь возможность указывать путь к директории в проекте, в которую нужно сохранять исходные коды автоматически генерируемых данных

Нефункциональные требования

В этом разделе будут описаны все ограничительные и нефункциональные требования, диктующие дополнительные условия, в которых должна будет работать конечная система. 0. Требования к клиентской подсистеме: 0. Должна быть рассчитана на работу в облаке и быть доступной для редактирования или чтения в любое время 0. Протоколы общения подсистем 0. Подсистемы должны поддерживать передачу данных между собой по протоколу HTTP 0. Во время передачи данных от клиентской подсистемы ко встраиваемой необходимо иметь возможность оценивать прогресс передачи с обновлением информации не реже, чем раз в 10 секунд 0. Время передачи данных от клиентской подсистемы не должно превышать 15 минут, если сама передача будет блокировать работу со средой разработки. Превышение этого лимита допускается только в случае не блокировки работы программной системы и регулярного информирования пользователя о прогрессе передачи данных 0. Ограничительные требования 0. За эталонный образец работоспособного объёма системы включает в себя следующие ограничительные требования: 0. Для клиентского модуля: 0. Не менее 30 таблиц на 5+ атрибутов каждая по 1500 записей для реляционной схемы данных, либо аналогичные объёмы для других схем 0. Возможность поддерживать одновременно не менее 5 работоспособных версий (для тестирования можно взять названия Dev, Release, Test, ABTest1, ABTest2) 0. Для встраиваемой подсистемы: 0. Обработка полной загруженной системы (объём описан выше) со скоростью обработки данных: 0. Чтения – не менее 15 запросов в секунду 0. Записи – не менее 5 запросов в секунду

Требования к безопасности

0. Безопасность клиентской подсистемы заключается в настройках уровней доступа:
1. У пользователя должна быть возможность ограничивать доступ к людям, не входящим круг доверенных лиц
2. Пользователь должен иметь возможность запретить доступ только к части данных, остальное оставить в свободном доступе
3. Межмодульное общение (передача данных от клиентской подсистемы на встраиваемую) подразумевает:
4. Режим передачи данных между подсистемами должен поддерживать режим шифрования любым общедоступным алгоритмом шифрования защищенным электронным ключом безопасности
5. Требования к безопасности встроенного модуля:
6. Наличие системы шифрования контента, защищающую раскрытие хранилища с данными внутри приложения на конечной машине

Требования к качеству продукта

0. Требования к качеству продукта подразумевают:
1. Человеко-машинный интерфейс этой части должен иметь следующие свойства: 0. Обладать интерфейсом, который позволяет без особых сложностей управлять большим количеством данных (к примеру, интерфейс табличного процессора) 0. Предоставлять пользователю возможность выставлять необходимые ему взаимосвязи между данными 0. Интерфейс работы с данными должен быть прост в использовании и иметь низкий порог вхождения
2. Требования к качеству встраиваемого модуля:
3. Требования к архитектуре исходного кода включают в себя: 0. Архитектура модуля должна поддерживать функцию «горячей замены» данных как при использовании из редактора, так и при использовании из уже собранной в конечном виде игры 0. Архитектура должна быть построена с использованием набора правил SOLID 0. Архитектура должна соблюдать принциы IoC 0. Архитектура должна исключать использование статических полей и/или методов за исключением Helper-классов, классов реализующих статические паттерны (фабрики и т. п.) и константных значений 0. Интерфейс работы с исходным кодом модуля должен подразумевать низкий порог вхождения и, на сколько это возможно, препятствовать возникновению ошибок у пользователя при написании последующего кода на основе модуля
4. Части модуля должны поддерживать события обновления данных и прочие, сигнализирующие о каких-то изменениях в данных
5. Гарантия качества модуля кода подразумевает: 0. Наличие верификаторов данных, загружаемых с клиентской части модуля 0. Наличие системы логирования состояния работы модуля и выставления ограничений на выводимые ошибки 0. Заранее определенный и согласованный по всему модулю режим обработки исключительных ситуаций аналогичной системе исключительных ситуаций .NET 0. Внедрение системы сбора данных о используемом количестве оперативной памяти загруженными данными и подача этой информации пользователю 0. Во время разработки модуля, покрытие, как минимум, 70% функциональности модуля Unit-тестами 0. Наличие демонстрационных данных для простого вхождения в проект 0. Демонстрация реализации системы локализации на основе данного модуля 0. Совместимость с разными типами данных, заданными в локальных стандартах (в частности, чтение словарей, поддержка DateTime, поддержка чисел с плавающей точкой как с точкой, так и с запятой в качестве разделителя и т. п.)