Спецификация требований для «Планировщика отпусков» Подготовлено Ильиным, Маниным, Строгановой Кафедра РВКС 22.10.07 Спецификация требования для «Планировщика отпусков» страница 1 История изменений Фамилия Дата Причина изменений Версия Ильин Манин 22.10.07 12.11.07 Отсутствие документа Отсутствие требований к пользовательскому интерфейсу 0.5 0.6 Спецификация требования для «Планировщика отпусков» страница 2 1. Требования к внешним интерфейсам 1.1 Пользовательский интерфейс Пользователь получает доступ к приложению с помощью интернет-бразуера. В файле «Screen shots.doc» приведены скрин-шоты основных страниц. Эти скрин-шоты задают только общий вид приложения, в деталях реальный интерфейс может отличаться, если на то будут причины. Важное требование к пользовательскому интерфейсу: функциональность, относящаяся к разным ролям, должна находиться на разных страницах (вкладках). Это необходимо для того, чтобы в случае, когда у пользователя появляются новые роли (например, у него появились подчиненные – он стал Team Leader’ом), ему нужно было освоить только новую часть интерфейса. 1.2 Программные интерфейсы Приложение должно хранить свои данные в базе данных MySQL 5.0. Взаимодействие приложения и базы должно происходить через интерфейс JDBC. Логическая схема базы данных описана в файле «db.jpeg» 2. Функциональные требования В этом разделе описаны основные роли, поддерживаемые приложением. Для каждой роли указанны функциональные требования. Для каждого требования указан его приоритет. Значение приоритета – число от 1 до 5. Расшифровки значений приоритетов: 5 – важная функция, без которой приложение бесполезно 4 – приложение может работать и без этой функции, но это заметно усложнит работу 3 – без этой функции можно легко обойтись, но с ней удобнее 2 – функция, которая иногда бывает полезна, но не часто 1 – незначительные улучшения, разные «красивости» Описание требования представлено в следующем виде: <номер требования> <словесное описание> <приоритет> 2.1. Сотрудник компании (Team Member) Описание и приоритет Для этой роли характерны действия, которые может выполнить любой сотрудник компании. Приоритет – 5. Функциональные требования Team Member имеет возможность: Спецификация требования для «Планировщика отпусков» страница 2 1. Просматривать расписание отпусков сотрудников, имеющих им общего начальника, и непосредственного начальника 4 2. Сортировать расписание отпусков 2 3. Подать начальнику заявку на отпуск 5 4. Просматривать ответы на свои заявки 5 5. Просматривать еще не обработанные заявки 3 6. Попросить о переносе отпуска 3 7. Отозвать необработанную заявку 3 8. Просматривать количество оставшихся в году отпускных дней 1 9. Попросить отпуск за свой счет 2 10. Попросить отменить отпуск 2 11. Получать извещения об ответах на заявки по почте 1 2.2. Сотрудник, имеющий подчиненных (Team Leader) Описание и приоритет Роли соответствуют те действия, который может выполнить сотрудник, имеющий подчиненных. Приоритет – 5. Функциональные требования Team Leader имеет возможность: 1. Просматривать расписание отпусков своих подчиненных 4 2. Просматривать пришедшие заявки на отпуск 5 3. Подтверждать/отклонять заявки 5 4. Предложить изменить сроки отпуска, предложенного в заявке 3 5. Просматривать статистику отпусков своих подчиненных (например, количество дней с последнего отпуска, количество уже использованных отпускных дней) 3 6. Предложить своему подчиненному отпуск 1 2.3 Работник отдела кадров (Resource Manager) Описание и приоритет Сотрудник, отвечающий за работу с кадрами. Приоритет – 4. Функциональные требования Resource Manager имеет возможность: 1. Просматривать расписание отпусков всех сотрудников 2. Просматривать пришедшие заявки на отпуск (уже одобренные соответствующими Team Leader’ами) 3. Подтверждать/отклонять пришедшие заявки 4. Просматривать статистику отпусков сотрудников 2 4 4 3 Спецификация требования для «Планировщика отпусков» страница 2 5. При принятии решения по заявке увидеть, не противоречит ли данный отпуск правилам компании 3 3. Нефункциональные требования 3.1 Требования к производительности Нагрузка на приложение: До 10 000 сотрудников в базе До 100 000 заявок на отпуск До 1000 человек в день, работающих с приложением До 100 запросов в минуту Время отклика: Время загрузки страницы не более 1 секунды 3.2 Требования к безопасности Безопасность: Защита данных от несанкционированного доступа Разделение пользователей по группам с различными правами доступа Аутентификация всех пользователей при входе в систему 3.3 Требования к качеству Тестирование приложения: Покрытие модульными тестами не менее 90% кода Функциональное тестирование всех основных вариантов использования приложения Удобство использования: Минимальное количество действий пользователя для выполнения базовых операций Наглядное представление наиболее значимой информации Расширяемость: Разбиение проекта на слои Возможность подменять реализацию любого слоя без внесения изменений в остальные Возможность работы базы данных, web-сервера и application-сервера на различных машинах Аудит и контроль: Логгирование работы системы Возможность отследить время работы системы для каждого запроса