ТЕХНИЧЕСКОЕ ЗАДАНИЕ
ПРОЕКТ
версия 0.1 от 01.01.2001
«Разработка системы распределенной многопользовательской ролевой игры в реальной жизни»
Москва 2016 г.
1. ОБЩИЕ СВЕДЕНИЯ
1.1. Наименование работы: «Разработка системы распределенной многопользовательской ролевой игры в реальной жизни (РМР РЖ)».
1.2. Шифр работы – «Лемминг».
1.3. Полное наименование изделия: Распределенная многопользовательская ролевая игра в реальной жизни
1.4. Сокращенное наименование изделия: РМР РЖ.
1.5. Заказчик работ – ФГУП «Строгая утилитарность».
1.6. Исполнитель работы – АО «Сбыча мечт».
1.7. Основание для выполнения работы: Рабочие программы по дисциплинам «Программная инженерия», «Распределенные информационные системы» и «Проектирование информационных систем» АНО ВО «Российский новый университет»
1.8. Сроки исполнения: 15.10.2016 г. – ___ 20__ г.
1.9. Работа выполняется в рамках учебного процесса и дополнительного финансирования не требует.
1.10. Результаты работы предоставляются заказчику в виде материалов по выполнению курсовых и практических работ.
2. НАЗНАЧЕНИЕ И ЦЕЛИ СОЗДАНИЯ СИСТЕМЫ
2.1. Назначение системы
Система предназначена для вовлечения молодежи, подростков и других активных частей населения в социальную и культурную жизнь района, города и страны. Достичь этой цели предполагается внесением игрового элемента в реальную жизнь людей, реализуемое на основе внедрения современных технологий в игровой форме, интуитивно понятно целевой группе населения.
2.1. Цели создания системы
Разработка программного обеспечения для РМР РЖ.
3. ХАРАКТЕРИСТИКИ ОБЪЕКТА АВТОМАТИЗАЦИИ (ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ)
3.1. Определения и термины
Термин | Значение |
Статическая характеристика персонажа | Такая характеристика, которая медленно изменяется с течением времени и недоступна системе непосредственно и/или постоянно. Пример: интеллект, сила. |
Динамическая характеристика персонажа | Такая характеристика, которая изменяется с течением времени в зависимости от действий персонажа и/или игрока и доступна системе непосредственно. Пример: количество денег на счету. |
Социальный статус персонажа | Статус, возникающий и изменяющийся в зависимости от действий персонажа и/или игрока при его взаимодействии с другими персонажами и/или игроками. Пример: уважение, любовь. |
Состояние (сленг.: баф, дебаф) | Назначается системой. Одновременно может быть несколько. Состояние персонажа, вызванное его или чужими действиями, носящее временный характер и оказывающее заметное воздействие на характеристики и поведение персонажа (игрока). Могут быть: – положительными (сленг.: баф): студент (меньше платит за проезд); – отрицательными (сленг.: дебаф): опьянение (нарушена координация и др.); – нейтральными: беременность (сложное системное состояние). |
Статус | Назначается самим игроком. Выбирается из предопределенного списка. Включает статусы «онлайн» и «оффлайн». |
Титул, достижение (сленг.: ачивка) | Назначается системой. Игрок может выбрать один из них для текущего отображения в профиле. Получение титула может трактоваться как завершение квеста. Отражает социальные и другие достижения игрока. Предположительно, меняет отношение к игроку. Пример.: волонтер 10 часов, 3 прыжка с парашютом. |
Роль | TBD |
Характеристика | TBD |
Задание (сленг.: квест) | TBD |
4. ТРЕБОВАНИЯ К СИСТЕМЕ
4.1. Требования к системе в целом
4.1.1. Требования к структуре и функционированию системы
4.1.1.1. Имеются два типа пользователей РМР РЖ:
– игроки;
– администраторы.
4.1.1.2 РМР РЖ содержит приложение, выполняющееся на устройстве игрока и обеспечивающее его взаимодействие с системой.
4.1.2. Требования к численности и квалификации персонала системы и режиму его работы
4.1.2.1. CRQ-SCAL-2 Максимальное число игроков (и их персонажей) одновременно подключенных к системе должно быть не меньше 100000.
4.1.2.2. CRQ-GEN-3 Игровой персонаж для каждого пользователя (игрока) только один.
4.1.2.3. CRQ-SCAL-3 Максимальное количество неигровых персонажей (NPC) одновременно доступных в системе должно быть не меньше 10000.
4.1.2.4. Максимальное число администраторов одновременно подключенных к системе должно быть не меньше 1000.
4.1.2.5. Игроки для участия в игре должны иметь уровень подготовки «среднего пользователя», то есть иметь базовые умения работы с графическими пользовательскими интерфейсами.
4.1.2.6. Администраторы для выполнения своих обязанностей должны пройти специальную подготовку. На этапе проектирования системы должны быть определены:
– Состав и объем знаний и умений требующихся от администраторов;
– Порядок прохождения ими подготовки;
– Порядок, периодичность и способ контроля знаний и навыков.
4.1.2.7. Игроки должны иметь возможность доступа к функциональности системы в режиме 7/24.
4.1.2.8. Администраторы должны иметь возможность посменной работы для обеспечения круглосуточного присутствия контролирующего персонала в системе.
4.1.3. Показатели назначения
4.1.3.1. CRQ-SCAL-1 Время реакции пользовательского интерфейса должно быть достаточно для функционирования интерфейса в виде дополненной реальности.
4.1.3.2 Время подготовки системы к работе оборудования игрока в различных режимах функционирования при условии наличия установленного программного обеспечения не должно превышать 5 минут.
4.1.3.3. Время подготовки системы к работе оборудования игрока в различных режимах функционирования при условии наличия установленного программного обеспечения не должно превышать 15 минут.
4.1.3.4. Приложения РМР РЖ должны иметь графический пользовательский интерфейс.
4.1.4. Требования к надежности
4.1.4.1. CRQ-ADD-1 Время восстановления системы должно быть не больше 5 часов.
4.1.4.2. Вероятность безотказной работы РИС ППУ за время непрерывного функционирования (Т = 8 часов) - 0,98.
4.1.4.3. Система должна обеспечивать возможность реконфигурации своих компонентов при выходе из строя любого узла таким образом, чтобы обеспечить функционирование системы как единого целого при изоляции отказавшего компонента. При этом время на подобную реконфигурацию не должно превышать 30 мин.
4.1.4.4. Пользовательские приложения должны иметь возможность в любой момент подключаться к системе и отключаться от нее без нарушения ее функционирования.
4.1.4.5. CRQ-ADD-2 ПО игрока должно поддерживать офф-лайн режим работы (с ограниченной функциональностью).
Примечание: набор функций, доступных в офф-лайн режиме должен быть уточнен на этапе проектирования.
4.1.5. Требования безопасности
TBD
4.1.6. Требования к эргономике и технической эстетике
TBD
4.1.7. Требования к транспортабельности (для подвижных АС)
4.1.7.1. CRQ-GEN-2 Интерфейсные элементы программно-технической реализации проекта должны быть носимы человеком.
4.1.8. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
TBD
4.1.9. Требования к защите информации от несанкционированного доступа
4.1.9.1. CRQ-SEC-1: Система должна обеспечивать безопасность обработки персональных данных пользователей согласно требованиям Федерального закона РФ от 01.01.01 года «О персональных данных».
4.1.10. Требования по сохранности информации при авариях
TBD
4.1.11. Требования к защите от влияния внешних воздействии
TBD
4.1.12. Требования к патентной чистоте
TBD
4.1.13. Требования по стандартизации и унификации
4.1.13.1. Система должна максимально базироваться на международных стандартах.
4.1.13.2. Обмен данными приложений в РМР РЖ должен работать поверх стека протоколов ТСР/IP.
4.1.14. Дополнительные требования
TBD
4.2. Требования к функциям (задачам)
4.2.1. Требования к отражению характеристик игрока
4.2.1.1. CRQ-GEN-3.1 Развитие игрока (изменение значений его характеристик) отражаются как изменения значений характеристик персонажа.
4.2.1.2. CRQ-GEN-3.2 Значения характеристик персонажа соответствуют значениям характеристик самого игрока.
4.2.1.3. CRQ-GEN-3.3 Персонаж имеет географические координаты, совпадающие с реальными координатами игрока.
4.2.1.4. CRQ-FN-4 Должна быть возможность передать системе и использовать информацию о личных особенностях игрока:
– устойчивость к алкоголю;
– заболевания, ограничивающие доступные виды активности.
4.2.1.5. CRQ-FN-5 Система должна иметь возможность вносить данные об умениях игрока. Например:
– умение плавать;
– умение водить машину.
Примечание: начальный состав умений будет определен на этапе проектирования.
4.2.1.5.1. CRQ-FN-5.1 Система должна обладать возможностью модифицировать список (добавлять, удалять, изменять описание) возможных умений.
Примечание: данная функциональность может быть доступна администраторам.
4.2.2. Требования к базовой функциональности интерфейса игрока
4.2.2.1. CRQ-FN-1 Пользователь имеет возможность взаимодействовать с другими людьми как с персонажами
4.2.2.1.1. CRQ-FN-1.1 Пользователю должна быть доступна возможность создавать группы.
4.2.2.1.2. CRQ-FN-1.2 Должна быть возможность устанавливать различные «отношения» между игроками (например, романтические) и отслеживать развитие этих отношений в относительные единицах.
4.2.2.2. CRQ-FN-1.3 Должна быть возможность «дружить» с другими персонажами. Доступный друзьям функционал (в частности, по взаимодействию) должен быть шире, чем у просто двух игроков.
4.2.2.2.1. CRQ-FN-1.3.1 Игроку должна быть доступна личная информация друзей (возможно, частично).
4.2.2.3. CRQ-FN-2 Игрок должен иметь возможность получать задания (квесты)
4.2.2.3.1. CRQ-FN-2.1 Награды за выполнение заданий должны быть реальными (то есть отображающимися на реальный мир).
4.2.2.4. CRQ-FN-3 Пользователю должен быть доступна возможность общаться с другими игроками.
4.2.2.4.1. CRQ-FN-3.1 Пользователю должен быть доступен чат с другими игроками.
4.2.2.4.1.1. CRQ-FN-3.1.1 Пользователю должно быть доступно голосовое общение с другими игроками.
4.2.2.4.1.2. CRQ-FN-3.1.2 Пользователю должен быть доступен групповой чат.
4.2.3. Требования к пользовательскому интерфейсу
4.2.3.1. CRQ-GEN-4 Пользовательский интерфейс игрока должен быть реализован с использованием технологии дополненной реальности.
4.2.3.2. CRQ-FN-GUI-1 Пользовательский интерфейс должен отображать характеристики собственного персонажа.
4.2.3.2.1 CRQ-FN-GUI-1.1 Пользовательский интерфейс должен отображать личные данные персонажа:
– национальность;
– раса;
– контактные данные;
– ФИО.
4.2.3.2.1.1 CRQ-FN-GUI-1.1.1 Личные данные других персонажей (игроков) могут быть доступны игроку с их индивидуального разрешения.
4.2.3.2.2. CRQ-FN-GUI-1.3 Пользовательский интерфейс должен отображать статические статусы персонажа, то есть такие, которые медленно изменяются с течением времени и недоступны системе непосредственно и/или постоянно.
4.2.3.2.2.1 CRQ-FN-GUI-1.3.1 Пользовательский интерфейс должен отображать показатель «Интеллект».
4.2.3.2.2.2 CRQ-FN-GUI-1.3.2 Пользовательский интерфейс должен отображать показатель «Ловкость».
4.2.3.2.2.3 CRQ-FN-GUI-1.3.3 Пользовательский интерфейс должен отображать показатель «Сила».
4.2.3.2.3. CRQ-FN-GUI-1.4 Пользовательский интерфейс должен отображать динамические статусы персонажа, то есть такие, которые изменяются с течением времени в зависимости от действий персонажа и/или игрока и доступны системе непосредственно.
4.2.3.2.3.1. CRQ-FN-GUI-1.4.1 Пользовательский интерфейс должен отображать текущий набор элементов экипировки персонажа.
Примечание: экипировка персонажа должна совпадать с элементами реальной одежды и/или предметами, носимыми игроком.
Примечание: предметы экипировки могут влиять на характеристики персонажа и/или приводить к возникновению или изменению (в том числе снятию) временных состояний.
4.2.3.2.3.2. CRQ-FN-GUI-1.4.2 Пользовательский интерфейс должен отображать текущий набор временных состояний персонажа (сленг. бафы, дебафы).
Например: опьянение, стресс, беременность, и др.
Примечание: Конкретный набор временных статусов будет определен во время проектирования системы.
4.2.3.2.3.3. CRQ-FN-GUI-1.4.3 Пользовательский интерфейс должен отображать текущий статус здоровья персонажа.
Примечание: статус здоровья отображается как снижение характеристики "HP" или как статусы заболеваний.
4.2.3.2.3.3.1. CRQ-FN-GUI-1.4.3.1 Пользовательский интерфейс должен отображать подсказки игроку о необходимости выполнить врачебные процедуры, необходимые для поддержания и/или восстановления здоровья:
- прием лекарств
- выполнение других врачебных процедур
4.2.3.2.3.4. CRQ-FN-GUI-1.4.4 Пользовательский интерфейс должен отображать текущий статус усталости персонажа.
Примечание: может показываться как отдельная характеристика или как снижение характеристики «Выносливость».
4.2.3.2.3.5. CRQ-FN-GUI-1.4.5 Пользовательский интерфейс должен отображать доступные персонажу ресурсы.
4.2.3.2.3.5.1. CRQ-FN-GUI-1.4.5.1 Пользовательский интерфейс должен отображать доступные персонажу поездки (проездные документы и/или оставшееся число поездок)
4.2.3.2.3.5.2. CRQ-FN-GUI-1.4.5.2 Пользовательский интерфейс должен отображать количество денег у персонажа.
4.2.3.2.4. CRQ-FN-GUI-1.2 Пользовательский интерфейс должен отображать социальные статусы персонажа, то есть такие, которые возникают и изменяются в зависимости от действий персонажа и/или игрока при взаимодействии с другими персонажами и/или игроками.
4.2.3.2.4.1. CRQ-FN-GUI-1.2.1 Пользовательский интерфейс должен отображать показатель «Харизма».
4.2.3.2.4.2. CRQ-FN-GUI-1.2.2 Пользовательский интерфейс должен отображать показатель «Репутация».
4.2.3.3. CRQ-FN-GUI-2 Пользовательский интерфейс игрока должен отображать открытые данные других персонажей.
4.2.3.3.1. CRQ-FN-GUI-2.1 Пользовательский интерфейс игрока должен отображать имена персонажей.
4.2.3.4. CRQ-FN-GUI-3 Пользовательский интерфейс должен отображать карту.
4.2.3.5. CRQ-FN-GUI-4 Пользовательский интерфейс должен отображать текущие квесты.
4.2.3.6. CRQ-FN-GUI-5 Пользовательский интерфейс должен отображать журнал событий.
4.1.3.7. CRQ-FN-GUI-6 Пользователю должны быть доступны статистические данные, относящиеся к игре.
Примечание: состав и представление статистики будут определены на этапе проектирования.
4.3. Требования к видам обеспечения
4.3.1. Требования по математическому обеспечению
Требования по данному разделу не предъявляются.
4.3.2. Требования по информационному обеспечению
Требования по данному разделу не предъявляются.
4.3.3. Требования по лингвистическому обеспечению
4.3.3.1. CRQ-GEN-1 Система должна быть многоязычной.
4.3.4. Требования по программному обеспечению
Требования по данному разделу не предъявляются.
4.3.5. Требования по техническому обеспечению
4.3.5.1. Программное обеспечение системы должно функционировать на платформе TBD.
4.3.6. Требования по метрологическому обеспечению
Требования по данному разделу не предъявляются.
4.3.7. Требования по организационному обеспечению
Требования по данному разделу не предъявляются.
4.3.8. Требования по методическому обеспечению
Требования по данному разделу не предъявляются.
5. СОСТАВ И СОДЕРЖАНИЕ РАБОТ ПО СОЗДАНИЮ СИСТЕМЫ
5.1. Содержание работ, сроки их выполнения приведены в таблице ниже.
Таблица 1 – Этапы выполнения и содержание работ по этапам
Этап выполнения работ | Выдаваемая научно-техническая продукция | Сроки исполнения |
1 ЭТАП Эскизно-технический проект | ||
2 Этап | ||
...... |
5.2. Порядок выполнения и приемки этапов, а также перечень работ, выполняемых на каждом этапе, должен соответствовать ГОСТ.........
6. ПОРЯДОК КОНТРОЛЯ И ПРИЕМКИ СИСТЕМЫ
TBD
7. ТРЕБОВАНИЯ К СОСТАВУ И СОДЕРЖАНИЮ РАБОТ ПО ПОДГОТОВКЕ ОБЪЕКТА АВТОМАТИЗАЦИИ К ВВОДУ СИСТЕМЫ В ДЕЙСТВИЕ
TBD
8. ТРЕБОВАНИЯ К ДОКУМЕНТИРОВАНИЮ
8.1. В Руководстве оператора должны быть приведены данные по квалификации администраторов системы.
9. ИСТОЧНИКИ РАЗРАБОТКИ
TBD


