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

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

Содержание

• 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 Критерии приемки внешних интерфейсов
    • 4. 1. 6 Критерии приемки производительности
    • 4. 1. 7 Критерии приемки атрибутов
    • 4. 1. 8 Критерии приемки функциональных требований
    • 4. 1. 9 Критерии приемки требований к внешним интерфейсам
    • 4. 1. 10 Критерии приемки требований к производительности
    • 4. 1. 11 Критерии приемки атрибутов
    • 4. 1. 12 Критерии приемки критериев приемки
    • 4. 1. 13 Критерии приемки критериев приемки документации
    • 4. 1. 14 Критерии приемки критериев приемки программного обеспечения
    • 4. 1. 15 Критерии приемки критериев приемки аппаратного обеспечения
    • 4. 1. 16 Критерии приемки критериев приемки коммуникационных интерфейсов
    • 4. 1. 17 Критерии приемки критериев приемки внешних интерфейсов
    • 4. 1. 18 Критерии приемки критериев приемки производительности
    • 4. 1. 19 Критерии приемки критериев приемки атрибутов
    • 4. 1. 20 Критерии приемки критериев приемки функциональных требований
    • 4. 1. 21 Критерии приемки критериев приемки требований к внешним интерфейсам
    • 4. 1. 22 Критерии приемки критериев приемки требований к производительности
    • 4. 1. 23 Критерии приемки критериев приемки атрибутов
    • 4. 1. 24 Критерии приемки критериев приемки критериев приемки
    • 4. 1. 25 Критерии приемки критериев приемки критериев приемки документации
    • 4. 1. 26 Критерии приемки критериев приемки критериев приемки программного обеспечения
    • 4. 1. 27 Критерии приемки критериев приемки критериев приемки аппаратного обеспечения
    • 4. 1. 28 Критерии приемки критериев приемки критериев приемки коммуникационных интерфейсов
    • 4. 1. 29 Критерии приемки критериев приемки критериев приемки внешних интерфейсов
    • 4. 1. 30 Критерии приемки критериев приемки критериев приемки производительности
    • 4. 1. 31 Критерии приемки критериев приемки критериев приемки атрибутов
    • 4. 1. 32 Критерии приемки критериев приемки критериев приемки функциональных требований
    • 4. 1. 33 Критерии приемки критериев приемки критериев приемки требований к внешним интерфейсам
    • 4. 1. 34 Критерии приемки критериев приемки критериев приемки требований к производительности
    • 4. 1. 35 Критерии приемки критериев приемки критериев приемки атрибутов
    • 4. 1. 36 Критерии приемки критериев приемки критериев приемки критериев приемки
    • 4. 1. 37 Критерии приемки критериев приемки критериев приемки критериев приемки документации
    • 4. 1. 38 Критерии приемки критериев приемки критериев приемки критериев приемки программного обеспечения
    • 4. 1. 39 Критерии приемки критериев приемки критериев приемки критериев приемки аппаратного обеспечения
    • 4. 1. 40 Критерии приемки критериев приемки критериев приемки критериев приемки коммуникационных интерфейсов
    • 4. 1. 41 Критерии приемки критериев приемки критериев приемки критериев приемки внешних интерфейсов
    • 4. 1. 42 Критерии приемки критериев приемки критериев приемки критериев приемки производительности
    • 4. 1. 43 Критерии приемки критериев приемки критериев приемки критериев приемки атрибутов
    • 4. 1. 44 Критерии приемки критериев приемки критериев приемки критериев приемки функциональных требований
    • 4. 1. 45 Критерии приемки критериев приемки критериев приемки критериев приемки требований к внешним интерфейсам
    • 4. 1. 46 Критерии приемки критериев приемки критериев приемки критериев приемки требований к производительности
    • 4. 1. 47 Критерии приемки критериев приемки критериев приемки критериев приемки атрибутов
    • 4. 1. 48 Критерии приемки критериев приемки критериев приемки критериев приемки критериев приемки
    • 4. 1. 49 Критерии приемки критериев приемки критериев приемки критериев приемки документации
    • 4. 1. 50 Критерии приемки критериев приемки критериев приемки критериев приемки программного обеспечения
    • 4. 1. 51 Критерии приемки критериев приемки критериев приемки критериев приемки аппаратного обеспечения
    • 4. 1. 52 Критерии приемки критериев приемки критериев приемки критериев приемки коммуникационных интерфейсов
    • 4. 1. 53 Крит2 Критерии приемки программного обеспечения
    • 4.1.3 Критерии приемки интерфейса
    • 4.1.4 Критерии приемки функций
    • 4.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 Ссылки

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

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

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.4.2 Ограничения

1. Человеческие ограничения: все члены группы являются студентами второго курса, всего 5 человек.

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

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

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.1.2 Критерии приемки программного обеспечения

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

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

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

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

|Номер |Название функции |Операционный интерфейс |Подробное описание |Примечания| |------|:----------:|:----------:| :----------------------------: |:------:| |1 |Выбор персонажа |Интерфейс магазина |Пролистывание персонажей и выбор при нажатии| | |2 |Управление персонажем |Интерфейс игры |Нажатие на кнопку для изменения действий персонажа| | |3 |Препятствия |Интерфейс игры |Препятствия появляются по определенному закону| | |4 |Музыка |Все интерфейсы |Предоставление музыкального сопровождения игры, которое можно выключить вручную| | |5 |Анимация персонажа |Интерфейс игры |Нажатие на кнопку для изменения действий персонажа при преодолении препятствий| | |6 |Рейтинг |Интерфейс рейтинга |Нажатие на кнопку для отображения лучшего результата|

4.2 Гибкость

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

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

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