1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/qx20172310-TeamWork

Клонировать/Скачать
需求规格说明书.md 33 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 09.06.2025 02:21 3139053

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


## История редактирования
Дата | Описание | Автор :---:|:----:|:---: 2019. 11. 23 | Основная структура была сформирована | Полуторогречка 2017. 11. 30 | Улучшение основной структуры, получение баллов за выполнение заданий, установка желаний и конкретные требования | Полуторогречка 2017. 12. 07 | Добавление настроек входа и личного кабинета | Полуторогречка 2017. 12. 14 | Улучшение и упрощение интерфейса | Полуторогречка
## 0. Содержание * [Требования к спецификации документа](#требования-к-спецификации-документа) * [История редактирования](#история-редактирования) * [0. Содержание](#0-содержание) * [1. Введение](#1-введение) * [1. 1 Цель](#11-цель) * [1. 2 Фон](#12-фон) * [1. 3 Определения](#13-определения) * [1. 4 Ссылки](#14-ссылки) * [2. Обзор проекта](#2-обзор-проекта) * [2. 1 Описание продукта](#21-описание-продукта) * [2. 2 Функции продукта](#22-функции-продукта) * [2. 3 Характеристики пользователей](#23-характеристики-пользователей) * [2. 3. 1 Примеры сценариев пользователей](#231-примеры-сценариев-пользователей) * [2. 3. 2 Анализ требований пользователей](#232-анализ-требований-пользователей) * [2. 3. 3 Диаграмма использования](#233-диаграмма-использования) * [2. 3. 4 Описание использования](#234-описание-использования) * [2.4 Предположения и ограничения](#24-предположения-и-ограничения) * [2.4.1 Предположения](#241-предположения) * [2.4.2 Ограничения](#242-ограничения) * [3. Конкретные требования](#3-конкретные-требования) * [3.1 Функциональные требования](#31-функциональные-требования) * [3.1.1 Дизайн интерфейса](#311-дизайн-интерфейса) * [Интерфейс входа](#интерфейс-входа) * [Интерфейс выбора заданий](#интерфейс-выбора-заданий) * [Интерфейс маленького дерева](#интерфейс-маленького-дерева) (отменен) * [Интерфейс желаний](#интерфейс-желаний) * [Интерфейс настроек](#интерфейс-настроек) * [3.2 Требования к внешним интерфейсам](#32-требования-к-внешним-интерфейсам) * [3.2.1 Интерфейс пользователя](#321-интерфейс-пользователя) * [3.2.2 Интерфейс аппаратного обеспечения](#322-интерфейс-аппаратного-обеспечения) * [3.2.3 Интерфейс программного обеспечения](#323-интерфейс-программного-обеспечения) * [3.2.4 Интерфейс связи](#324-интерфейс-связи) * [3.3 Требования к производительности](#33-требования-к-производительности) * [3.3.1 Требования к точности](#331-требования-к-точности) * [3.4 Атрибуты](#34-атрибуты) * [3.4.1 Доступность](#341-доступность) * [3.4.2 Поддерживаемость](#342-поддерживаемость) * [4. Критерии проверки и требования](#4-критерии-проверки-и-требования) * [4. 1 Критерии проверки](#41-критерии-проверки) * [4. 1. 1 Документные критерии приемки](#411-документные-критерии-приемки) * [4. 1. 2 Программные критерии приемки](#412-программные-критерии-приемки) * [4. 1. 3 Интерфейсные критерии приемки](#413-интерфейсные-критерии-приемки) * [4. 1. 4 Функциональные критерии приемки](#414-функциональные-критерии-приемки) * [4. 1. 5 Критерии приемки игры](#415-критерии-приемки-игры) * [4. 2 Гибкость](#42-гибкость) * [4. 3 Временные характеристики требований](#43-временные-характеристики-требований) * [4. 4 Другие требования](#44-другие-требования)
## 1. Введение
### 1. 1 Цель
- После полугодового изучения Java и самостоятельного освоения Android Studio нам крайне необходимо четко понять уровень наших знаний и способность их применения. Поэтому, под руководством преподавателя, мы начали практическую работу по созданию проекта. - Определение нашего приложения: это приложение для саморегуляции и управления временем, основанное на платформе Android.Цель написания этого документа по функциональным требованиям — подробно представить пользовательские требования, концептуальное дизайнерское видение и анализ особенностей приложения; четко определить описание приложения, интерфейса программного обеспечения, функциональных требований и особенностей написания кода, чтобы облегчить координацию работы пользователей и разработчиков, и на этой основе предложить общий план дизайна, создать проверяемую основу для дальнейшего дизайна и разработки. - Ожидаемые читатели этого документа и рекомендации по чтению: 1. Менеджер проекта: менеджер проекта использует этот документ для понимания функциональных требований к продукту и на основе этого выполняет системный дизайн и управление проектом. 2. Программист: понимает особенности требований к программе и функциональные возможности системы. 3. Тестировщик: использует этот документ для создания тестовых сценариев и функционального тестирования программного обеспечения. 4. Пользователь: четко понимает способы использования программного обеспечения.
### 1.2 Обстоятельства
- Разработчики проекта: студенты группы 23 курса bk 2017 года Института электроники и информатики, Пекин. - Разрабатываемое программное обеспечение: это приложение для саморегуляции и управления временем. Это программное обеспечение будет выпущено на рынок для загрузки пользователями, которые используют его для управления своим временем, строго требуя от себя достижения своих целей быстрее и эффективнее, и получая удовлетворение от этого.
### 1.3 Определения
Номер | Сокращение | Определение ---|--- |----- 1 | app | Приложение, сокращение от Application, обычно относится к мобильным приложениям. 2 | Android | Android — это свободная и открытая операционная система на основе Linux, в основном используемая на мобильных устройствах, таких как смартфоны и планшеты, разработанная Google и открытым союзом мобильных телефонов.
### 1.4 Ссылки
- **Спецификация требований к программному обеспечению для системы подачи заявок** - **Спецификация требований к системе подачи заявок** - **Спецификация требований к приложению "Вместе покупаем"**
## 2. Обзор проекта
### 2.1 Описание продукта
- Приложение, разработанное для платформы Android. Каждый из нас сосредотачивает внимание на игре, полностью погружаясь в неё, но при обучении легко отвлекается и рассеивается. Это происходит потому, что результаты обучения не могут быть немедленно оценены, в то время как результаты игры оцениваются в реальном времени и мгновенно, например, убивая одного врага, вы сразу получаете награду. Это безусловно стимулирует вас и позволяет полностью погрузиться в игру.Однако обучение не такое, оно представляет собой процесс, который может долгосрочно улучшать вас, но при этом не всегда очевидно. Это называется "событием с долгим периодом полураспада" на платформе Zhihu, где Cu Tung поощряет нас делать больше таких действий. Исходя из этого, можно ли использовать некоторые принципы из игр в обучении и работе, чтобы сделать их более эффективными? Или же сделать так, чтобы студенты могли более четко планировать и организовать свое обучение и задачи?

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

2. 2 Описание функций продукта

  • Схема функций (WBS): Это приложение для управления временем и саморегуляции, где пользователи могут накапливать желаемые значения, выполняя задачи, которые затем можно обменять на награды. Цель приложения — помочь пользователям достигать своих целей и одновременно получать удовлетворение.

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

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

  • Сценарий A: Студент Минг, у которого много домашних заданий на выходные, но друзья приглашают его на фильм. Он не знает, что делать, и открывает приложение для управления временем и саморегуляции.
  • Сценарий B: Сотрудник Ван, которому было поручено много задач, не знает, с чего начать. Он открывает приложение для управления временем и саморегуляции.

#### 2. 3. 2 Анализ требований пользователей
- Сценарий A: Приложение простое и удобное для совмещения развлечений и обучения. - Сценарий B: Приложение практичное и помогает решать реальные проблемы, при этом пользователь получает удовлетворение.
#### 2. 3. 3 Диаграмма использования
![](https://images.gitee.com/uploads/images/2018/1202/202907_71e0cb27_1795244.png "QQ截图20181202202758.png") ![](https://images.gitee.com/uploads/images/2018/1219/141513_ffc3d73b_1795244.png "QQ截图20181219141409.png")
#### 2. 3. 4 Пояснение к случаю использования
Проект | Содержание --- | --- Название случая использования | Интерфейс задач Номер случая использования | 001 Основной участник | Пользователь A Носитель риска | Дизайнер Краткое описание | При входе в интерфейс задач появляется функция выбора задачи. Только после выбора задачи можно продолжить дальнейшие действия. Предварительное условие | Пользователь A уже скачал приложение. | Основной поток событий | 1. Пользователь A переходит в "интерфейс задач", создает задачу. 2.Пользователь заполняет информацию о задаче, устанавливает предполагаемое время завершения и количество очков, которые можно получить после выполнения задачи (с ограниченным максимумом). 3. Пользователь оценивает выполнение задачи в соответствии со своими обстоятельствами и получает соответствующее количество очков. |Дополнительный поток событий | 1. Пользователь A использует текстовый индекс для поиска задачи по её названию. |Последующее условие | Пользователь A меняет задачу и переходит в интерфейс выбора задач. |Другое | Отсутствует Проект | Содержание --- |--- Название случая использования | Интерфейс желаний Номер случая использования | 002 Основной участник | Пользователь B Носитель риска | Пользователь B Краткое описание | Пользователь должен использовать определённое количество очков для обмена на желаемое. Предварительное условие | Пользователь B накопил определённое количество очков. Поток событий | 1. Пользователь B переходит в интерфейс желаний. 2. Пользователь устанавливает желаемое и количество раз, когда оно может быть обменено. 3. Пользователь использует определённое количество очков для получения желаемого. |Другое | Отсутствует
### 2. 4 Предположения и ограничения
#### 2. 4. 1 Предположения
1.Практичность: предполагается, что пользователи приложения смогут быстро адаптироваться после пробного использования. 2. Поддержка пользователей: предполагается, что пользователи будут активно поддерживать и сотрудничать на всех этапах разработки приложения. 3. Поддержка технической стороны: предполагается, что члены группы на начальном этапе разработки будут хорошо знакомы с требованиями приложения и соответствующими знаниями. Предполагается, что при возникновении проблем в процессе разработки, они смогут получить своевременные консультации и помощь от преподавателей. 4. Сотрудничество персонала: предполагается, что состав группы не изменится, и в процессе разработки проекта не произойдет неожиданных обстоятельств, которые помешают участникам участвовать в разработке. 5. Ограничение по времени: предполагается, что срок окончания проекта не будет сдвинут. 6. Ограничение по требованиям: предполагается, что требования к проекту после их базового определения не будут существенно меняться.
#### 2.4.2 Ограничения
- Ограничение по персоналу: Члены группы являются студентами второго курса, всего 5 человек. - Ограничение по управлению: 1. В рамках текущего проекта, группа будет управляться одним лидером, который будет координировать работу всех членов группы.Каждый член группы будет отвечать за конкретные разделы процесса и будет работать в соответствии с графиком. Проблемы, возникающие в процессе разработки, будут решаться на совещаниях группы. 2. Группа участников впервые работает вместе и должна четко определить свои обязанности, взаимодействовать и быстро пройти период адаптации. При возникновении проблем необходимо, чтобы лидер группы мог эффективно координировать, чтобы быстро и эффективно завершить процесс разработки. - Технические ограничения: 1. Уровень технических навыков участников группы имеет определенные недостатки, недостаток опыта работы над подобными проектами, а также требуется улучшение навыков составления документации. 2. Участники группы имеют ограниченные навыки в области графического дизайна. - Временные ограничения: Срок разработки системы короткий, что делает время относительно напряженным. - Другие ограничения: В процессе разработки участники группы также имеют другие учебные задания, что может оказать определенное влияние на ход проекта.
## 3. Конкретные требования - Диаграмма приоритетов функций: ! [Введите описание изображения](https://images. gitee. com/uploads/images/2018/1219/141749_0d47658f_1795244. png "QQ截图20181219141725. png") - Требования к версиям - Версия Alpha - 1. Вход, регистрация. . . - 2.Различные элементы интерфейса: задачи, информация о задачах, состояние роста маленького дерева, баллы. - 3. Функции покупки предметов и т. д. - 4. Функции подсчета после выполнения или не выполнения задач. - Версия Beta - 1. Функции самостоятельного названия маленького дерева и т. д. - 2. Функции самостоятельного создания задач и т. д. - Версия выпуска - 1. Добавление каналов обратной связи пользователей, реализация функций общения с пользователями
### 3. 1 Требования к функциям
#### 3. 1. 1 Дизайн интерфейса
#### Интерфейс входа
- Пользователь выбирает вход или регистрацию аккаунта: ! [Введите описание изображения](https://images. gitee. com/uploads/images/2018/1127/210905_fa081e61_1795244. png "Screen Shot. png")
#### Интерфейс выбора задач
- После входа пользователя в приложение, предлагаются четыре различных типа задач для выбора. Пользователь может сделать разумный выбор задачи в соответствии со своими реальными обстоятельствами. ! [Введите описание изображения](https://images. gitee. com/uploads/images/2018/1127/211033_3cab290e_1795244. png "Screen Shot. png") - После выбора задачи пользователь переходит на соответствующий интерфейс задачи, где он может узнать информацию о задаче, такую как конкретное содержание, ограниченное время и т. д. ! [Введите описание изображения](https://images. gitee. com/uploads/images/2018/1127/211231_e7f11d83_1795244. png "Screen Shot. png")
#### Интерфейс маленького дерева (отменен)
- В интерфейсе маленького дерева пользователь может наблюдать за состоянием его роста. ! [Введите описание изображения](https://images. gitee. com/uploads/images/2018/1127/211327_543367bf_1795244. png "Screen Shot. png")
#### Интерфейс желаний
- Пользователи могут просматривать и управлять своими баллами. ! [](https://images. gitee. com/uploads/images/2018/1127/211449_05212401_1795244. png "ScreenShot. png")
#### Настройка интерфейса
- Пользователи могут настраивать свои личные данные. ! [Введите описание изображения](https://images. gitee. com/uploads/images/2018/1127/211540_550b1ff4_1795244. png "ScreenShot. png")
### 3. 2 Внешние интерфейсы
#### 3. 2. 1 Интерфейс пользователя
Нет специальных требований. #### 3. 2. 2 Интерфейс аппаратных средств
Нет специальных требований. #### 3. 2. 3 Интерфейс программного обеспечения
Нет специальных требований. #### 3. 2. 4 Коммуникационный интерфейс
Нет специальных требований. ### 3. 3 Требования к производительности
#### 3. 3. 1 Точность
Нет специальных требований.
### 3. 4 Свойства
#### 3. 4. 1 Доступность
1. Простота использования и понимания. Интерфейс проектировался с учетом удобства использования. 2. После выполнения операции отображается стандартное сообщение. #### 3. 4. 2 Поддержка обслуживания
1. Сохранение исходного кода системы. 2.Подробные комментарии к коду, включая процесс реализации методов и значения переменных. 3. Ясная структура системы и правила именования, а также стандарты оформления интерфейса. 4. Каждое тестирование фиксируется в лог-файле. 5. Постоянное тестирование различных аспектов.
## 4. Критерии и требования к приемке
### 4.1 Критерии приемки
#### 4.1.1 Критерии приемки документации
(1) План разработки проекта приложения (2) Требования к программному обеспечению (3) Временные записи и отчеты о проекте команды (блог команды)
#### 4.1.2 Критерии приемки программного обеспечения
Установочный пакет приложения
#### 4.1.3 Критерии приемки интерфейса
Все функции работают корректно, приложение не выходит из строя после входа в систему.
#### 4.1.4 Критерии приемки функций
(1) Возможность нормального входа и регистрации. (2) Нормальное добавление задач. (3) Нормальное отсчет времени. (4) Корректное отображение информации на интерфейсе. (5) Нормальное воспроизведение анимации и аудио.
#### 4.1.5 Критерии приемки приложения
Нет.
### 4.2 Гибкость
После завершения разработки данного программного обеспечения, требования к нему не изменятся в ближайшее время.Соответственно, при изменении требований, данное программное обеспечение способно адаптироваться к этим изменениям: изменения в методах использования. Методы использования данного программного обеспечения просты, и пользователи могут легко овладеть ими. В рамках предварительного анализа требований и проектирования интерфейса были учтены все аспекты, поэтому изменения в них маловероятны. Несмотря на это, мы можем внести изменения и расширить функционал приложения в соответствии с изменяющимися требованиями пользователей, что обеспечивает хорошую масштабируемость.
### 4.3 Временные характеристики
Требования к временным характеристикам этого приложения не слишком высоки, достаточно, чтобы оно отвечало на запросы пользователя в разумное время. Например, время отклика на нажатие кнопки не должно превышать 1 секунду.
### 4.4 Другие требования
#### Безопасность: Приложение не запрашивает у пользователя личную информацию и старается подчеркивать свою безопасность.
#### Надежность: Система обладает высокой устойчивостью и не имеет большого количества нестабильных факторов.
#### Требования к удобству использования: (1) Все интерфейсы системы должны быть простыми и удобными для использования. (2) После выполнения операции должна появляться унифицированная информация о завершении.
#### Требования к поддержке: (1) Сохранение исходного кода системы. (2) Подробные комментарии к коду, включая процесс реализации методов и значения переменных. (3) Ясная структура системы и правила именования, а также стандарты оформления интерфейсов. (4) Ведение журнала каждого отладочного сеанса. (5) Комплексное рассмотрение системы и усиление поддержки в последующем, постоянное тестирование с разных сторон.
#### Требования к производительности: (1) Полное отображение информации о задачах. (2) Нормальное воспроизведение анимации и аудио. (3) Нормальное управление баллами. (4) Сохранение пользовательских задач и связанных данных без потерь. (5) Правильное отображение времени.

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/qx20172310-TeamWork.git
git@api.gitlife.ru:oschina-mirror/qx20172310-TeamWork.git
oschina-mirror
qx20172310-TeamWork
qx20172310-TeamWork
master