основная цель – мобильность – возможность запустить клиент там где есть браузер и интернет, и условия не позволяют установить настольное приложение (например: отсутствие прав для запуска сторонних приложений, блокировка фаерволами).
должен работать как при наличии Java Script?, так и при его отсутствии (требование мобильности)
интерфейс должен быть унифицирован с Plesk
при наличии Java Script?, желательно использовать AJAX-технологии, как в Plesk'e
должно работать во всех версиях популярных браузеров (IE 5/6/7, Firefox, Opera 9) максимально одинаково

1. Настольное приложение (вероятно Java) – низкий приоритет

основные цели:
- максимально возможная скорость реакции на действия пользователя
- минимально возможный потребляемый траффик
в итоге:
- максимально толстый клиент, с большинством предварительных проверок на стороне пользователя
- желательно использовать некоторый бинарный протокол для минимизации траффика (пока что можно остановиться на сжатии XML-RPC запросов)

Общие требования:

клиенты должны быть максимально простыми для повседневного типового использования, интуитивно понятны, не перегружены лишними и редкоиспользуемуми возможностями, какие есть в SCM.
но в тоже время должна быть возможность тонкой настройки по требованию.
мультиязычность – должны быть простые средства для локализации клиента (для web-клиента – см. Plesk); в базовом варианте должно быть как минимум два языка – английский и русский.

Установка, конфигурирование, отладка:
Должны существовать утилиты для обслуживания системы:

Инсталятор Агента на Solaris. Должен включать в себя утилиту для создания пользователя-администратора и смены его пароля.
Инсталятор web-клиента на web-сервер.

Функциональные требования

Неавторизованный ПС

Для следующих UC необходимым требованием является, что ПС является Неавторизованным ПС.
1) Login (Авторизация)
Предусловие: То, что ПС является Неавторизованным ПС по сути означает, что либо ПС только что запустил Клиент, либо что ПС применил Logout
Сценарий:
1. Запрашиваются логин и пароль. Пароль не должен отображаться на экране в явном виде.
2. Пользователь нажимает кнопку входа в систему
3. Клиент производит начальную проверку введенных данных – является ли логин и пароль введенные пользователем корректными логином и паролем в Системе. Если не являются – происходит возврат на шаг 1, причем поле логин должно быть автоматически заполнено изначально введенными ПС на 1-м шаге данными. Если являются – отсылается запрос Серверу, проверяется существование Профиля ПС с такими логином-паролем. Если проверка завершилась успешно – устанавливается привязка ПС (точнее Клиента) к этому Профилю ПС. В противном случае – переход на шаг 1 с сообщением об некорректном логине и пароле и автозаполнением логина старым значением.
Дополнительные пожелания:
Все сообщения об ошибках должны выглядеть одинаково.
Должна быть в некотором виде система защиты от подбора пароля – например максимальное число попыток входа с одного IP-адреса. При большом количестве неудачных попыток входа каким-либо образом должны быть отправлено сообщение администраторам системы.

Авторизованный ПС

Для следующих UC необходимым требованием является, что ПС является Авторизованным ПС.
1) Logout (Выход из Системы)
Описание: текущий ПС становится Неавторизованным ПС и переводится на страницу авторизации.

2) Смена пароля
Описание:
1.Запрашиваются текущий пароль, новый пароль и подтверждение нового пароля.
2. Если введеный текущий пароль не является паролем текущего Профиля ПС – переход на шаг 1 с сообщением о том что старый пароль неверный.
3. Проверяются новый пароль и подтверждение на корректность и совпадение. В случает неудачи – соответствующие сообщения об ошибке.
4. Происходит изменение пароля текущего Профиля ПС на новый.

По ролям

Для следующих UC необходимым требованием является, что ПС является Авторизованным ПС и Профиль ПС имеет роль, указанную в заголовке.

End-user

Сервисы

1) Просмотр доступных сервисов
Идея:
Просмотр доступных сервисов (т.е. включенных для данного пользователя) в виде списка, с возможностью быстрого перехода к «Настройки/использование сервиса» каждого конкретного сервиса.

2) Настройки/использование сервиса
Примечание:
Что именно должно быть реализовано в данном пункте определяется для каждого сервиса по своему. Для дополнительной информации см. Вам запрещён доступ

Service SRS.

Лимиты

1) Просмотр своих лимитов.
Идея:
Просмотр потребления основных своих ресурсов и соответствующих им лимитов
Описание:
Должны отображаться следующие поля:

дисковая квота: доступно/использовано
сетевой траффик за месяц: доступно/использовано

MyWackoSite: zonemng/SRS3 ...

Zonemng Software Requirement Specification

Общие требования

Протокол взаимодействия Клиента и Агента

Клиенты