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

История изменений

Содержание

• 1. Введение
  • 1.1 Цель
  • 1.2 Контекст
  • 1.3 Определения
  • 1.4 Ссылки на документы
• 2. Обзор проекта
  • 2.1 Описание продукта
  • 2.2 Функции продукта
  • 2.3 Характеристики пользователей
    • 2.3.1 Примеры сценариев пользователей
    • 2.3.2 Анализ требований пользователей
    • 2.3.3 Описание сценариев
  • 2.4 Предположения и ограничения
    • 2.4.1 Предположения
    • 2.4.2 Ограничения
• 3. Конкретные требования
  • 3.1 Функциональные требования
  • 3.2 Требования к внешним интерфейсам
    • 3.2.1 Интерфейс пользователя
    • 3.2.2 Интерфейс аппаратного обеспечения
    • 3.2.3 Интерфейс программного обеспечения
    • 3.2.4 Коммуникационный интерфейс
  • 3.3 Требования к производительности
    • 3.3.1 Требования к точности
  • 3.4 Атрибуты
    • 3.4.1 Доступность
    • 3.4.2 Поддерживаемость
• 4. Критерии приемки и требования
  • 4.1 Критерии приемки
    • 4.1.1 Критерии приемки документации
    • 4.1.2 Критерии приемки программного обеспечения
    • 4.1.3 Критерии приемки интерфейса
    • 4.1.4 Критерии приемки функций
    • 4.1.5 Критерии приемки производительности1. 5 Критерии приемки игр
  • 4. 2 Гибкость
  • 4. 3 Требования к временным характеристикам

1. Введение

1. 1 Цель

Цель данного проекта - применить наши знания Java и разработки приложений для Android на практике и продолжить повышение своих навыков под руководством преподавателя. Мы планируем создать небольшое приложение для мобильных устройств. Игра предназначена для развлечения и отдыха, разработана с использованием Android Studio. Цель написания данного документа - подробно описать методы использования игры, концепции разработки, требования к реализации, интерфейсы и анализ кода; чтобы облегчить сотрудничество разработчиков и продвижение всего проекта. Предполагаемые читатели и рекомендации по чтению:

1. Менеджер проекта: менеджер проекта использует этот документ для понимания ожидаемых функций продукта и на основе этого для системного проектирования и управления проектом.
2. Программист: для понимания особенностей требований и функций системы.
3. Тестировщик: для создания тестовых сценариев и тестирования программного обеспечения на соответствие функциональным и нефункциональным требованиям.
4. Пользователь: для понимания способа использования программного обеспечения.

1. 2 Контекст

Разработчик проекта: группа 23 класса 2017 года, Школа электроники и информатики, Пекин. Настоящее приложение для мобильных устройств предназначено для развлечения и отдыха. Эта небольшая игра позволяет расслабиться в свободное время и одновременно тренировать реакцию игрока.

1. 3 Определения

1. 4 Ссылки на документы

• Требования к спецификации приложения APP

2. Обзор проекта

Паркуры — это современный экстремальный вид спорта, популярный по всему миру, где местом проведения являются повседневные окружающие условия. Используя наши технологии, мы интегрировали паркур в мобильные устройства, создав игру "Паркур". Игра посвящена тренировке реакции и ловкости, а также убийству времени, являясь увлекательной и конкурентоспособной мини-игрой.

2. 1 Описание продукта

Игра разработана на Android Studio и представляет собой мини-игру в жанре паркура. Игроки выбирают персонажа в магазине, бегут по трассе и избегают препятствий, проходят уровни по результатам и открывают новых персонажей в магазине.

2. 2 Функциональность продукта

Схема функциональности

2. 3 Характеристики пользователей

Продукт предназначен для всех пользователей, которые могут использовать Android-устройства. Для пользователей, которые хотят провести время в развлечениях в кратчайшие сроки.

2. 3. 1 Примеры пользовательских сценариев

• Сценарий пользователя 1: Студент Хай во время десятиминутного перерыва между уроками хочет отдохнуть, посмотреть матч? Времени слишком мало, чтобы получить удовольствие. . . Проверить микроблог? Нечего интересного. . . Итак, он открыл приложение паркура и с удовольствием прошел уровень, открыв нового персонажа, и счастливым вернулся в класс.
• Сценарий пользователя 2: Студент Цинь во время обеденного перерыва в столовой чувствует себя скучным, случайно открывает приложение паркура, и скучное время пролетело мгновенно!

2. 3. 2 Анализ пользовательских требований

• Сценарий 1: Функция прохождения уровней и открытия новых персонажей позволяет игрокам быстро получить удовлетворение.
• Сценарий 2: Каждый уровень можно пройти за время, которое контролируется игроком, и это не слишком сложно, чтобы можно было играть в любое время.

2. 3. 3 Описание сценариев использования

2. 4 Предположения и ограничения

2. 4. 1 Предположения

1. Удобство использования: предполагается, что пользователи игры смогут быстро овладеть игрой после пробного использования.
2. Поддержка пользователей: предполагается, что пользователи будут активно поддерживать и сотрудничать на всех этапах разработки игры.
3. Техническая поддержка: предполагается, что члены группы будут сотрудничать на начальном этапе разработки, определять задачи и учиться самостоятельно, а также обращаться к преподавателям и ассистентам по мере необходимости.
4. Сотрудничество членов группы: предполагается, что состав группы не изменится до завершения разработки.
5. Временные ограничения: предполагается, что сроки разработки не будут сокращены.
6. Ограничения по требованиям: предполагается, что требования к проекту не будут существенно изменяться после их определения.

2. 4. 2 Ограничения

Численный состав: члены группы — студенты второго курса, всего 5 человек. Управление: 1. В рамках разработки будет действовать модель, при которой один человек будет назначен руководителем группы, а остальные будут выполнять свои обязанности.Каждый участник отвечает за конкретные этапы процесса и выполняет их в соответствии с графиком. Проблемы, возникающие в ходе разработки, решаются на совместных собраниях группы.

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

Технические ограничения:

1. Уровень навыков членов группы в определенной области недостаточен, у них нет опыта работы над подобными проектами, а также требуется улучшение навыков составления документации.
2. Члены группы имеют ограниченные навыки в области графического дизайна.

Временные ограничения: Период разработки системы короткий, что делает время ограниченным.

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

3. Конкретные требования

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

3.1.1 Примеры дизайна интерфейса

• Начальный экран Пользователь выбирает начать игру, завершить игру или просмотреть инструкции по игре
• Экран магазина Пользователь выбирает персонажа игры
• Экран игры Пользователь управляет кнопками прыжка и наклона для избегания препятствий
• Экран результатов Отображает результаты пользователя, объявляет прохождение уровня, позволяет вернуться в магазин для выбора нового персонажа, выйти из игры или продолжить игру.

3.2 Требования к внешним интерфейсам

3.2.1 Интерфейс пользователя Нет специальных требований

3. 2. 2 Интерфейс аппаратного обеспечения

Нет специальных требований

3. 2. 3 Интерфейс программного обеспечения

Нет специальных требований

3. 2. 4 Коммуникационный интерфейс

Нет специальных требований

3. 3 Требования к производительности

3. 3. 1 Требования к точности

1. Точность столкновения персонажа с препятствием должна быть высокой.
2. Скорость бега персонажа должна быть умеренной.
3. Чем выше уровень, тем больше и сложнее препятствия.

3. 4 Атрибуты

3. 4. 1 Доступность

1. Легкость использования и понимания. Простой и удобный дизайн интерфейса.
2. После завершения операции отображается единое сообщение.

3. 4. 2 Поддерживаемость

• Сохранение исходного кода системы.
• Подробные комментарии к коду.
• Ясная структура системы и правила именования, а также стандарты дизайна интерфейса.
• Каждое тестирование фиксируется в журнале.
• Постоянное тестирование с разных сторон.

4. Критерии и требования для проверки и приемки

4. 1 Критерии приемки

4. 1.1 Критерии приемки документации

1. План разработки проекта приложения
2. Документация по требованиям к программному обеспечению
3. Временные записи и отчеты о проекте команды (блог команды)

4. Критерии приемки программного обеспечения

Установочный пакет приложения

5. Критерии приемки интерфейса

4. 1. 4 Критерии приемки функций

#### 4. 1. 5 Критерии приемки игры

### 4.2 Гибкость

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

4.3 Временные характеристики

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