Введение
Данный документ проектируется Егором Гаркавым для описания программного продукта «Тестирующая программа общего назначения». А так же системных, функциональных и не функциональных требований к данному продукту. Соглашения по оформлению требований основаны на стандарте IEEE-830-1998_RU. Приложение рассчитано на широкий круг пользователей и не требует особых умственных способностей.
Назначение
· Систематизация, усвоение и фиксирование всех требований к продукту.
· Описание поведения будущей системы.
· создание продукта, приближенного к промышленным корпоративным продуктам
Область применения
Область применения системы – образовательная.
Общее описание
Назначение продукта – автоматизация тестирования определенного количества пользователей.
Продукт должен предоставлять возможность регистрации, создания, и прохождения тестов.
Продукт рассчитан для OS Windows, начиная от Windows 97 до Windows 10.
Ограничений по возрасту не будет.
Программный продукт не должен нарушать законодательство РБ, другие ограничения не предусматриваются.
В программе должно быть предусмотрена возможность интерактивной помощи, и пользовательская документация.
Допущения: возможен внешний релиз продукта с некритическими багами, количество, обнаруженных, которых, не должно превышать 85% от общего количества багов.
Зависимости: не должно быть.
Спецификация требований
Требования для разработки этого продукта:
· среды: Idea, NetBeans и Eclipse и сервер Apache Tomcat.
· Требуется установленная СУБД – MYSQL;
· беспроводная, локальная или другие сети
Функциональные требования
Работа системы:
Основные функциональные возможности системы представлены в виде таблиц.
| ID | UI001 |
| Цель | Каждый пользователь может зарегистрироваться в системе |
| Участники | Незарегистрированные пользователи |
| Приоритет | П1 |
| Предусловие | Пользователь не должен быть зарегистрирован в системе |
| Триггер | Пользователь нажимает кнопку «войти» => «регистрация» |
| Основной сценарий | 1. Пользователь вводит будущий логин в поле «логин». Имя пользователя не должно уже содержаться в БД пользователей и соответствовать стандарту о корректном имени пользователя, принятому разработчиком. 2. Пользователь вводит в поле «пароль» свой пароль. 3. Пользователь нажимает кнопку «зарегистрироваться» для заверения регистрации. |
| Альтернативный сценарий | 2А. Пользователь не заполнил поле логин. 2Б. Пользователь ввел не корректное имя пользователя. 3А. Пользователь не заполнил поле пароль. |
| Расширения | 2А_1. Вывести сообщение об ошибке «заполните поле «логин» 2Б_1. Вывести сообщение об ошибке «Введено неверное имя пользователя» 3А_1.Вывсести сообщение об ошибке «Введите пароль». |
| ID | UI002 |
| Цель | Администратор может создавать вести базу данных с вопросами |
| Участники | Администраторы |
| Приоритет | П1 |
| Предусловие | Пользователь должен быть наделен правами администратора |
| Триггер | После входа, администраторы нажимает кнопку «список вопросов» |
| Основной сценарий | 1. Администратор должен нажать на кнопку «добавить вопрос» 2. Заполнить поля «текст вопроса», «ответ 1», «ответ 2», «ответ 3» любыми символами. 3. Выбрать правильный вариант ответа на по ползунке 4. Нажать на кнопку «сохранить вопрос». |
| Альтернативный сценарий | 1А. Администратор, выбирает уже существующий вопрос и нажимает на кнопку «редактировать вопрос» 1Б. Администратор, выбирает уже существующий вопрос и нажимает на кнопку «удалить вопрос». 3А. Администратор не заполнил 1 из полей |
| Расширения | 1А_1. Отредактировать вопрос в соответствии с П.2 и 3 основного сценария, повторить П.4 1Б_1. Вывести окно, с подтверждением удаления, содержащим надпись «Действительно удалить?», «да» «нет». 3А_1.Вывсести сообщение об ошибке «Заполните все ключевые поля». |
| ID | UI003 |
| Цель | Пользователь может пройти тестирование |
| Участники | Пользователи |
| Приоритет | П1 |
| Предусловие | Пользователь должен быть зарегистрирован и авторизирован |
| Триггер | После входа, пользователь нажимает кнопку «пройти тестирование» |
| Основной сценарий | 1. Нажать кнопку «легкий тест» 2. Нажать кнопку «начать тест» 3. Выбрать правильный вариант ответа путем нажатия радио-кнопки, 4. Нажать на кнопку «дать ответ». 5. Если тест не закончен то перейти к П3, иначе нажать на кнопку «узнать результат» |
| Альтернативный сценарий | 1А. Пользователь нажал на кнопку «тяжелый тест» 2А. Пользователь не выбрал ответ 2Б. Пользователь выбрал не верный ответ |
| Расширения | 1А_1. Продолжить выполнять тест в соответствии с основным сценарием 2Б_1. Заблокировать П4 основного сценария, до момента выбора ответа 2Б_2. Вывести сообщение «ответ не верен». |
Количественные показатели для нефункциональных
Требований.
· Время обучения персонала: 2ч.
· Время восстановления системы после сбоя: 1ч.
· Сохранение результате при сбое работы программы
· Процент событий, приводящих к сбоям: 1.
· Вероятность изменения данных при сбоях: 0,1
· В ходе выполнения тестирование приложение не должно обрабатывать ответ выше 0,05 секунды.
Удобство использования
Системная цель:
Система должна быть простой в эксплуатации для опытного оператора.
Проверяемое нефункциональное требование:
Опытному оператору должны быть знакомы все системные функции после двух часов обучения работе с данной системой. После такого обучения среднее число ошибок оператора не должно превышать двух за рабочий день.
Требования надежности
1. Вероятность выхода системы из строя должна составлять 0-1 процент.
2. Коэффициент готовности системы – 98 из 100.
3. Время восстановления системы – 1 час.
4. Количество ошибок на функцию (в средним) – 0,1 багов.
5. Доступность системы: часов непрерывной работы, поддержка на 2-х последних этапах разработки (“Завершение”, “Сдача проекта”).