IM Support Service/Specification

Скелет — значительно переделанный ГОСТ 19.201-78. Можно свободно добавлять свои требования, но удаление или исправление лучше согласовать в специальном обсуждении на форуме JRuDevels. Перед добавлением желательно почитать эти советы по написанию ТЗ.

Введение

Это техническое задание для Сервиса поддержки через IM.

Термины

Сеть 

Некоторая сеть мгновенного обмена сообщениями, в которую (напрямую или через транспорт) может входить сервис.

Сервер 

XMPP-сервер.

Клиент 

Пользователь сервиса поддержки, который пришел со своим вопросом.

Оператор 

Пользователь сервиса поддержки, который отвечает на вопросы клиентов.

Узел поддержки 

Группа операторов, которые смогут ответить на вопросы определенной тематики. Узел поддержки имеет по одному контактному адресу (идентификатору) в каждой из поддерживаемых IM-сетях.

Сервис поддержки

Разрабатываемый компонент к серверу, который сможет обслуживать произвольное число узлов поддержки.

Клиентское ПО 

ПО, которое используют абоненты и операторы для общения друг с другом. Это может быть XMPP-клиент или клиент любой другой IM-сети.

Назначение разработки

Сервис предназначен для организации технической поддержки через IM подобно тому как это делает call-центр в телефонии. Основные функции:

• один контактный адрес для клиентов
• автоматическое распределение клиентов по оператором с учетом занятости и присутствия
• ведение статистики
• сохранение разговоров

Области применения:

1. Предприятия, внедряющие корпоративный IM на основе XMPP, могут подключить к своему серверу этот компонент, создать там нужное количество узлов поддержки (например, по принципу один узел - одна тема) и организовать полноценную IM поддержку для своих клиентов.
2. Группы людей, сопровождающие какой-нибудь проект (свободное ПО, мероприятие, форум, игровой сервер и т.п.), могут создать свой узел на публичном сервисе поддержки и разместить его контактный адрес на сайте проекта.

Требования к программе

Программа должна включать в себя следующие основные модули:

1. Модуль логики, который отвечает за основной процесс взаимодействия клиента и оператора.
2. Модуль хранения информации (в базе данных, простых файлах и т.п.)
3. Модуль статистики

Должна быть возможность заменить любой из этих модулей на свой без затрагивания остальных. Например, заменить хранение в MySQL на хранение в PostgreSQL или в простых файлах.

В программе должны быть реализованы следующие пользовательские интерфейсы:

1. Интерфейс клиента
2. Интерфейс оператора
3. Интерфейс управления сервисом и узлами
4. Интерфейс просмотра статистики

Прочие требования:

1. Должна присутствовать возможность расширить функции программы или изменить основную логику работы с помощью плагинов.
2. Должен присутствовать программный интерфейс (RPC) с помощью которого внешние программы смогут забрать данные статистики, логи чатов или произвести автоматическую настройку.

Требования к интерфейсу клиента

Интерфейс должен быть простым и выдвигать как можно меньше требований к ПО на стороне клиента.

Должны быть реализованы следующие типы интерфейса клиента:

1. IM-интерфейс
2. Web-интерфейс

Должна быть возможность реализовать свои.

Требования к настраиваемости

Параметры интерфейса, который клиент может изменить:

1. Язык интерфейса

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