IEEE Software Requirements Specification Template

реклама
Спецификация требований
для
«Планировщика отпусков»
Подготовлено Ильиным, Маниным, Строгановой
Кафедра РВКС
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-сервера на различных
машинах
Аудит и контроль:
 Логгирование работы системы
 Возможность отследить время работы системы для каждого запроса
Скачать